Create the Contract, Not the Product

"Birth builds the empty room and labels the door correctly. It does not decide what the room is for."

What Birth Writes

A newborn shell is deliberately, honestly empty. Birth renames the template's architecture doc to match the product stem — cwkNewThing becomes a doc named for NEWTHING — and replaces the name tokens throughout. It materializes a cwk-product.json stamped with the exact repository id and version 0.0.0, which is the honest label for a scaffold. It adds a conservative, empty entry to the operation registry — importantly, no writer capability is inferred for the new shell. That's the whole of Birth's authorship: the contract, correctly named and honestly versioned.

What Birth Refuses to Write

What Birth does not do is decide what the product actually is. It doesn't fill the architecture doc with real design. It doesn't invent features, pick a stack, or write product intent into the scaffold. Version 0.0.0 isn't a placeholder Birth is embarrassed by — it's a truthful statement: 'this is a shell; no product contract exists yet.' Setting it to 1.0.0 to look finished would be a lie, and inventing an architecture the product doesn't have yet would be a hallucination. Birth stays honest by staying empty.

Why the Empty Shell Is the Right Deliverable

SCAFFOLD prose and real product decisions remain deliberate Dad-and-Pippa work — a conversation, not a generator's guess. This is the same discipline as everything else in Firelink: the tool does the mechanical, verifiable part (create, name, version, register with no assumed powers) and stops precisely where judgment begins. A birth that tried to be helpful by filling in a plausible product would be inventing decisions no one made — the exact hallucination the whole family is built to avoid. The honest shell is the better gift, because it's a true starting point rather than a confident fiction.

This is the shrine's discipline turned inward on creation itself. Firelink can make the room and hang the correct sign on the door — new, empty, version 0.0.0, no powers assumed — and then it steps back so the people who know what the product is can decide what it becomes. Building the skeleton is the tool's job; giving it a soul is ours.

Code

Birth writes the contract; Dad + Pippa write the product·text

  BIRTH WRITES (mechanical, verifiable):
    - rename docs/APP-ARCHITECTURE.md -> docs/NEWTHING-ARCHITECTURE.md
    - replace <repo-name> / <app-name> / <APP-NAME> tokens
    - cwk-product.json with the exact id, version = 0.0.0  (honest: a shell)
    - a conservative, EMPTY operation-registry entry
        -> no writer capability inferred for the newborn
    - create private remote, initial push, ledger rows, verify

  BIRTH DOES NOT WRITE (judgment, not mechanism):
    x  the real architecture inside the doc
    x  the product's features, stack, or design
    x  any version above 0.0.0 to 'look finished'
    x  any assumed capability the shell hasn't earned

  0.0.0 is not a placeholder to be embarrassed by. It is the truth.

Exercise

Think about a scaffolding or code-generator tool you've used (a framework's 'new project' command, a template generator). Where does it stop — does it produce an honest empty skeleton, or does it pre-fill opinions and sample features you then have to delete? List one thing it generated that was really a decision you hadn't made yet. What would the 'contract, not product' version have left empty instead, and why is empty more honest?

Hint

Generators that scatter TODO sample code and example features are making product decisions for you. The 'contract only' version writes the structure and the honest version marker, and leaves every real choice as a blank a human fills — a true starting point instead of someone else's guess.

Create the Contract, Not the Product

What Birth Writes

What Birth Refuses to Write

Why the Empty Shell Is the Right Deliverable

Code

External links

Exercise

Progress

Comments 0