The first session ended at post 10. The design did not. I came back to it and, before writing a single new decision, asked the least glamorous question a solo project can ask itself: how far along is this, really, and what would it take to call it ready for someone else to review in depth?
The answer was more useful than I expected, because it forced a distinction I had been blurring: a settled mechanism is not a hardened design.
The fork: promote now, or hold and harden
Composition was already reconciled into the binding docs. Coherence had seventeen recorded decisions covering the whole load-bearing core: binding, determinism, precedence, persona content, gender, explainability, detection, activation, the explicit accessor, and a second entity proving the abstraction generalizes. It was tempting to call that reviewable and promote it too.
A: promote coherence into the binding docs now.
17 decisions, self-consistent, composition already went. Looks done.
B: hold. The mechanism is settled, but the seams between features are not.
Harden first, promote second.
I took B. The tell was that I could not yet answer a reviewer's most obvious question, "what happens when a composed child is itself a person," without pointing at an open fork. A design you cannot stress at the seams is decided, not done.
What "hardened" actually means
The value of taking stock was turning a vague "almost there" into a concrete,
finite list. Three passes stand between the current state and an in-depth review:
1. Cross-feature interaction pass.
Where correctness bugs hide once two features exist. Composition x coherence is
done (next post). Uniqueness, null-probability, and locale remain.
2. Surface-enumeration pass.
Collect every public member the design has accumulated into one list to accept
or cut. Public surface is locked, so this is the gate that matters most.
3. Consistency re-read.
Read all the decisions straight through for contradictions and stale
cross-references, the kind that creep in when you decide one fork at a time.
Only after those does coherence get promoted into the binding docs. The interaction
pass goes first on purpose: it is the one most likely to send an earlier decision
back for revision, and there is no point freezing a surface that a later pass might
reopen.
Why this is allowed to be slow
This is the brief doing its job again. Solo, no deadline, quality over speed is
exactly the license to harden before review instead of shipping a plausible-looking
design and patching it under pressure later. It is also why I keep refusing to frame
this work as a countdown to code. "Ready to build" is a finish line that a design in
this phase does not have and should not pretend to.
Takeaway
Before you add the next feature, find out whether the last ten are actually done or
merely decided. The useful output of taking stock is not a percentage, it is a short
list of named hardening passes that make the gap between "I made these decisions" and
"someone could review this" explicit and finite.
What's next
First pass on the list is the cross-feature interactions, and the sharpest one is
where the two big v1.1 threads touch. Post 10 asserted that boundary in a single
paragraph. A reader, reasonably, asked me to actually show it. Next post: the seam,
worked out in full.
SOCIAL SHARE CARD GENERATOR