replicatelisted

The lineage loop. Children start with the scaffold *plus* everything this repository has learned that is true anywhere — heredity, not just copying. ## Hold in mind 1. Only `Scope: portable` knowledge crosses repositories — project-specific rules in a child are noise that erodes trust in the whole memory system. 2. Knowledge is inherited; verification state is not. Ledger entries cross; run stamps and source watermarks reset. 3. Inherited entries arrive as `Status: inherited`, not `candidate`: the child re-earns promotion with its own evidence. Rules entering the child's CLAUDE.md are the one exception — they arrive active, so each one is gated on the user's explicit yes at replicate time: the generation boundary is a review gate, because persisted rules files are an injection channel and a poisoned rule would otherwise propagate to every descendant unreviewed. 4. The child must not keep the template's identity: name, facts block, and README head must be rewritten before first commit. 5. The child's first session should run `/bootstrap` — say so explicitly in the handoff. ## Steps 1. Interview the user (skip anything already given in the argument): project name, one-line purpose, expected stack (or unknown), GitHub visibility (public/private) or local-only. Gate: restate name, visibility, and destination path, and wait for an explicit yes before creating anything. 2. Create the child: - **GitHub path** (preferred): `gh repo create <name> --template <owner>/<template-re