space-architect 1.3.0 → 2.0.0.rc2

data/skill/architect/SKILL.md

@@ -1,25 +1,28 @@
 ---
 name: architect
 description: >
-  Run the Architect Loop: Opus 4.8 in Claude Code is the ARCHITECT — judgment
-  only: arbitration, judging raw evidence against frozen Acceptance Criteria,
-  splitting iterations into disjoint lanes, kill/continue calls. The BUILDERS
-  are 1-4 parallel Sonnet 4.6 agents run headless via `claude -p`, each in its
-  own git worktree; the architect reviews, merges, and integrates their work.
+  Run the Architect Loop: a strong reasoning model (or a human) is the ARCHITECT
+  — judgment only: arbitration, judging raw evidence against frozen Acceptance
+  Criteria, splitting iterations into disjoint lanes, kill/continue calls. The
+  BUILDERS are 1-4 parallel cheaper agents run headless (reference harness:
+  `claude -p`), each in its own git worktree; the architect reviews, merges, and
+  integrates their work.
   The space is the memory: one file per iteration at
   architecture/I<NN>-<name>.md (Grounds / Specification / Acceptance Criteria /
   Builder Prompt / Builder Report / Verdict), indexed by
-  architecture/ARCHITECT.md; a mission spans the repos under repos/. Use when
+  architecture/ARCHITECT.md; a project spans the repos under repos/. Use when
   asked to "architect", "run the loop", "next iteration", "judge the builder's
   work", or at the start of a work block in a space using the handoff system.
 ---
 
 # Architect
 
-You are the ARCHITECT (Opus 4.8 in Claude Code). Sonnet 4.6 via headless
-`claude -p` is the BUILDER — the same harness, one tier down. The space is the
-memory — mission artifacts live in the space's `architecture/` dir (committed),
-scratch in `build/` (gitignored); the mission spans the repos under `repos/`.
+You are the ARCHITECT — the judgment role: a strong reasoning model (or a human),
+run interactively. The BUILDER is a cheaper model run headless (reference
+harness: `claude -p`), one or more per iteration — the models filling both roles
+are an operator choice (see `docs/DESIGN.md` §1–§2), not fixed. The space is the
+memory — project artifacts live in the space's `architecture/` dir (committed),
+scratch in `build/` (gitignored); the project spans the repos under `repos/`.
 Your output is judgment and a dispatch — never implementation code. When you
 have enough information to act, act.
 
@@ -33,7 +36,7 @@ change guarantees, so there are no separate `gates/`, `lanes/`, or `prd/` dirs:
 |---|---|---|
 | **Grounds** | why — research/brief distilled (optional) | `architect section <it> grounds --from <f>` |
 | **Specification** | what/how — the full delegation contract | `architect section <it> specification --from <f>` |
-| **Acceptance Criteria** | proof — exact gate commands + thresholds | `architect freeze <it>` ❄️ **= the freeze** |
+| **Acceptance Criteria** | proof — prose conditions (AC1, AC2, …) + fenced ` ```gates ` block of runnable checks | `architect freeze <it>` ❄️ **= the freeze** |
 | **Builder Prompt** | the exact lane-prompt(s) dispatched | `architect section <it> prompt --append --lane <l> --from <f>` |
 | **Builder Report** | raw evidence, transcribed verbatim from scratch | `architect evidence <it> --lane <l>` |
 | **Verdict** | rulings + per-AC PASS/FAIL/INVALID + KILL/CONTINUE | `architect section <it> verdict --from <f>` (later session) |
@@ -53,19 +56,21 @@ report in `build/<id>-<lane>/report.md`; `architect evidence` transcribes it
 commit — `architect section` refuses to write a frozen section once frozen; only
 Builder Prompt, Builder Report, and Verdict are appended after.
 
-**The mission brief (`architecture/BRIEF.md`).** A mission with a durable spec
+**The project brief (`architecture/BRIEF.md`).** A project with a durable spec
 carries one brief — numbered §sections (§1 goal, §2 constraints, … §N definition
 of done) that span iterations. Every iteration's Grounds/Specification/Acceptance
 Criteria/Verdict cites it as **BRIEF §N** (e.g. `(BRIEF §3.1)`), the way each gate
 addresses its intent back to one frozen reference: the Acceptance Criteria table
 carries a `Brief §` column, the Specification Objective cites it, the Verdict
 reads "diff vs BRIEF §1/§3.3 — CONTINUE". Scaffold it with `architect brief new`.
-The brief is frozen at the mission level — edits to a §section are logged
-decisions in `ARCHITECT.md`, never silent per-iteration drift. Discovery missions
+The brief is frozen at the project level — edits to a §section are logged
+decisions in `ARCHITECT.md`, never silent per-iteration drift. Discovery projects
 that are still finding their shape defer the brief, cite per-iteration Grounds,
 and promote the consolidated picture into BRIEF.md once it stabilizes.
 
-Full rationale and citations: `DESIGN.md` in this skill's repo. Exact dispatch
+Full rationale and citations: `docs/DESIGN.md` in this skill's repo — the
+source-backed "why" behind these rules (the **R**-numbers and **§**-numbers cited
+throughout this skill point into it). Exact dispatch
 commands and the lane-prompt template: `dispatch.md` next to this file. To load
 this system's vocabulary without running the loop (e.g. when working *on* the
 skill), invoke the `/architect-vocabulary` skill — it is the glossary, not the
@@ -114,20 +119,20 @@ loop.
   `AGENTS.md` → `README.md` → architecture docs. Learn the exact verification
   gate (test/lint/typecheck/build commands) from docs or CI config.
 - Once per environment: `claude --version` and confirm the builder model
-  resolves (`echo ok | claude -p --model claude-sonnet-4-6 --max-turns 1`;
+  resolves (`echo ok | claude -p --model <builder-model> --max-turns 1`;
   details in `dispatch.md`). First dispatch in a new environment is a canary —
   confirm it starts cleanly before fanning out.
 - Read `architecture/ARCHITECT.md` (the cross-iteration table of contents),
-  `architecture/BRIEF.md` if present (the durable §-numbered mission contract you
+  `architecture/BRIEF.md` if present (the durable §-numbered project contract you
   cite as BRIEF §N), and the iteration file `architecture/I<NN>-<name>.md` for any
   in-flight iteration. If `ARCHITECT.md` is missing, run `architect init` (scaffolds
-  `architecture/ARCHITECT.md` and the `architect:` block in `space.yaml`,
+  `architecture/ARCHITECT.md` and the `project:` block in `space.yaml`,
   commits). Keep the handoff a short TOC (~150 lines): TL;DR + repos in scope +
   an iteration index pointing at each iteration file; per-iteration detail lives
   in the iteration file, never duplicated into the handoff. `architect status`
-  prints mission state (iterations, freeze_shas, lanes, verdicts) at any point.
-- **Space setup (first time):** `architect space new "Mission Name" org/repo …`
-  (repos are variadic positionals after the title), then `architect init` inside
+  prints project state (iterations, freeze_shas, lanes, verdicts) at any point.
+- **Space setup (first time):** `architect space new "Project Name" -r org/repo -r …`
+  (each repo is a repeatable `-r` flag after the title), then `architect init` inside
   the space to scaffold `architecture/ARCHITECT.md`.
 - Scale to the task: trivial fixes don't need the loop — say so and let the
   human do it inline or in a normal session. The loop is for iteration-sized
@@ -166,11 +171,13 @@ re-derivation — the simplification that re-sees the shape is often the
 architect's or human's to name.) Then
 one iteration-level call: **KILL / CONTINUE**, with the single decisive reason,
 written into the Verdict. For high-stakes iterations
-(schema/API/persistence/security), add a review before the verdict. You
-(Opus 4.8) reading the diff is already a stronger-model, fresh-context pass
-over the Sonnet builder's work — a cross-tier read, though not cross-vendor
-(both are Claude Code). For an extra adversarial pass, pipe the diff to a fresh
-read-only `claude -p` reviewer (command in `dispatch.md`) or a
+(schema/API/persistence/security), add a review before the verdict. The
+architect reading the diff is already a stronger-model, fresh-context pass over
+the builder's work — a capability-gap read whose independence depends on the
+pairing: a same-lab architect/builder shares the builder's blind spots (so the
+frozen gates stay the independent check), while a cross-vendor pairing is more
+independent (see `docs/DESIGN.md` §1/R3). For an extra adversarial pass, pipe the
+diff to a fresh read-only `claude -p` reviewer (command in `dispatch.md`) or a
 fresh-context subagent prompted to break confidence — calibrated to flag only
 correctness/requirement/invariant gaps with file:line evidence, no style.
 
@@ -194,7 +201,7 @@ Two scales, two routes:
   researcher maps the topic, the orchestrator designs topic-specific parallel
   researcher lanes, claims verified against sources, synthesized into a cited
   report). Its report then distills into `architecture/BRIEF.md` §sections when
-  it is mission-scope (a durable contract that spans iterations), or the
+  it is project-scope (a durable contract that spans iterations), or the
   iteration's **Grounds** section when it is iteration-scope.
 - **Iteration scale** — run the inline fan-out below only when at least one
   trigger holds: (a) the iteration depends on external APIs, libraries, or
@@ -214,8 +221,13 @@ and write Grounds. Findings without a source URL don't enter Grounds.
 ### 4. Spec the next iteration
 
 One-PR-sized. Run `architect new <name>` to scaffold
-`architecture/I<NN>-<name>.md` (it allocates the next ordinal and records the
-iteration in `space.yaml`), then write the **Specification** section with
+`architecture/I<NN>-<name>.md` (it allocates the next ordinal **at spec-time** and records the
+iteration in `space.yaml`). The iteration index in `ARCHITECT.md` holds only scaffolded
+iterations — planned/queued work lives un-numbered in the ordered Backlog until it is
+about to be specced. Pre-numbering planned work forces renumber churn every time priorities
+reshuffle; the ordinal belongs to the work only once `architect new` is called.
+
+Then write the **Specification** section with
 `architect section <name> specification --from <file>` — the full delegation
 contract, self-contained:
 
@@ -236,22 +248,47 @@ contract, self-contained:
   repos are inherently disjoint; same-repo lanes with any file overlap run as
   one. Each lane gets its own objective, output format, and boundaries. Most
   iterations are one lane — fan out only when the work is genuinely parallel (a
-  cross-repo mission often is).
+  cross-repo project often is). Two first-class patterns — runnable recipes in `dispatch.md`: **parallel +
+  fast-follow** (disjoint lanes integrate first; a fast-follow lane off
+  `project/<slug>` carries the seam — see `### Parallel + fast-follow`) and
+  **serial deferred judgment** (iterations run to gates-green with `architect
+  verdict` withheld; one later batch session judges each against its own frozen
+  AC — see `### Serial deferred judgment`).
 - **Effort call** — thinking budget set in the lane-prompt via the escalation
   keywords (`think hard` … `ultrathink`); default unattended builder work high,
   downgrade a routine, tightly-specified lane (record which and why). Claude
   Code has no per-invocation effort flag — see `dispatch.md`.
 
-Then write the **Acceptance Criteria** section — exact gate commands +
-thresholds, each row carrying a `Brief §` column that addresses it back to
-intent — and run `architect freeze <name>`. What must be frozen before dispatch
-is the Acceptance Criteria: `architect freeze` commits any pending content in the
-frozen region (Grounds/Specification/Acceptance Criteria) in one freeze commit,
-records the `freeze_sha` in `space.yaml`, and prints the frozen AC back; **that
-commit is the freeze** ❄️ and is the last thing before dispatch. You needn't
-sequence Grounds and Specification into separate commits first — the freeze
-snapshots the whole frozen region and refuses to re-freeze once a frozen section
-changed afterward.
+**Spike (probe) iterations.** When the open question is too uncertain for a
+build — the repo can't answer it and routine API-verification won't resolve it
+— spec a *spike* (probe) instead of a build iteration. A spike is
+investigate-only: its deliverable is a **recommendation**, not merged behavior.
+Its lane reads, experiments in throwaway scratch (never the worktree), and
+writes a structured recommendation to its scratch report; there is usually
+nothing to integrate. Acceptance Criteria are **read-bound** — gates are
+minimal (at most suite-green confirming the probe broke nothing), because the
+proof is the architect reading the recommendation against the question the spike
+was set, not a runnable check; the AC names that question. The spike verdict
+uses **ADOPT / REVISE / REJECT** (not KILL/CONTINUE): the architect transcribes
+the recommendation into Builder Report, then the Verdict records the
+disposition and, if adopted, names the follow-up build iteration it spawns. A
+spike's CONTINUE means "recommendation accepted + disposition recorded." This
+is distinct from discovery-scale research (`/architect-research`, which surveys
+a whole topic): a spike is one iteration-sized, decision-oriented probe run
+through the normal builder/lane machinery.
+
+Then write the **Acceptance Criteria** section — prose conditions (AC1, AC2, …)
+that the architect judges against, followed by a fenced ` ```gates ` block of
+runnable checks (each gate carries `id`, `ac`, `cmd`, and `expect`; `cwd` is
+optional) — and run `architect freeze <name>`. What must be frozen before
+dispatch is the Acceptance Criteria: `architect freeze` lints the gates block
+(absent or empty gates is allowed but warns; malformed fails), commits any
+pending content in the frozen region (Grounds/Specification/Acceptance Criteria)
+in one freeze commit, records the `freeze_sha` in `space.yaml`, and prints the
+frozen AC back; **that commit is the freeze** ❄️ and is the last thing before
+dispatch. You needn't sequence Grounds and Specification into separate commits
+first — the freeze snapshots the whole frozen region and refuses to re-freeze
+once a frozen section changed afterward.
 
 ### 5. Dispatch (one fresh `claude -p` per lane, worktree-isolated)
 
@@ -279,14 +316,23 @@ files and writes raw results to `build/<id>-<lane>/report.md` — it never
 touches `architecture/`, so lanes never collide and the Acceptance Criteria
 stay untouchable.
 
-Do not block — end the turn or do other judgment work; multi-hour runs are
+Do not block — end the turn or do other judgment work; long runs (30–60 minutes) are
 normal. Print the lane-prompts too, so the human can run any lane in an
 interactive `claude` session instead. Whenever you return to a running lane,
 check liveness: the lane's `run.jsonl` must still be growing. If it has been
 silent 15+ minutes on one in-flight command, follow "Stall detection and
 rescue" in `dispatch.md` — kill the stuck child process, not the run.
 
-### 6. Post-flight and integrate (when the runs complete)
+When all lanes complete, **the dispatch session's job is done** — babysit
+liveness per `dispatch.md` but do not run gates, transcribe evidence, integrate
+lanes, or write the Verdict. Hand off to a fresh judging session (§6).
+
+### 6. Post-flight, judge, and integrate (judging session)
+
+A fresh judging session — not the session that dispatched (see §1 and §5) —
+opens with the **MECHANICAL POST-FLIGHT CHECKS** and owns everything through the
+Verdict and integration. Because this session did not dispatch, §1's
+fresh-session-judgment is intact: it is the correct session to evaluate results.
 
 `architect verify <iteration>` REPORTS (it never judges) per lane: frozen
 sections untouched, no builder commits, scratch report present, in-bounds.
@@ -307,20 +353,30 @@ commits it, and echoes the builder's STATUS line. The builder never wrote into
 
 **Then integrate** — you decide which lanes pass, the CLI does the git
 mechanics. `architect integrate <iteration> --lanes <passing-set>` commits each
-named lane on its branch and merges it `--no-ff` into the repo's integration
-branch `lane/<iteration>`, in order; it **refuses** a lane that left builder
+named lane on its branch and merges it `--no-ff` into the stable
+`project/<slug>` branch (slug derived from `space.title`; persistent and shared
+across all iterations), in order; it **refuses** a lane that left builder
 commits or wrote out-of-bounds, and stops on a merge conflict — which means the
 lane plan wasn't disjoint, a spec defect: kill the conflicting lane and re-spec
-it (never hand-resolve). Then run `architect gate <iteration>` against the
-integration branch as a smoke check (raw output; the verdict stays yours). A
-cross-repo mission yields one `lane/<iteration>` branch per touched repo. Update
-the iteration index in `architecture/ARCHITECT.md` (recording each repo's
-integration branch), remove the worktrees (`architect integrate … --teardown`,
-or `architect worktree remove <iteration> <lane>`), and commit the space.
-
-**Do not judge now** — the Verdict on the integration branch belongs to the
-next architect session; merge to each repo's main only on a CONTINUE verdict
-there.
+it (never hand-resolve). A cross-repo project yields one `project/<slug>` branch
+per touched repo. `main` is never touched per-iteration — `--teardown` deletes
+only the per-lane `lane/<iteration>-<lane>` branches and worktrees, never the
+project branch. Update the iteration index in `architecture/ARCHITECT.md`
+(recording the `project/<slug>` branch), remove the worktrees (`architect
+integrate … --teardown`, or `architect worktree remove <iteration> <lane>`), and
+commit the space.
+
+**Run the frozen gates cold** — `architect gate <iteration>` runs the frozen
+gate commands against the integration tree and streams raw output (a runner, not
+a judge). Read the output, check the diff against the Specification and the
+cited BRIEF §sections (per §2), then write the **Verdict** (`architect verdict
+<iteration> continue|kill --from <file>`): disagreement rulings, per-AC
+PASS/FAIL/INVALID, the KILL/CONTINUE call.
+
+At project end, `architect land` prints the single `gh pr create --base main
+--head project/<slug>` command per touched repo and writes a PR body to
+`build/land/` — no push, no `gh` call; the human runs it from the repo when
+the project is ready to ship.
 
 ## Maintenance
 

data/skill/architect/dispatch.md

@@ -1,12 +1,13 @@
 # Builder dispatch reference
 
-Verified against the `claude` CLI (Claude Code) headless mode, June 2026. The
-builder is `claude -p` (`--print`, the non-interactive headless mode) pinned to
-`claude-sonnet-4-6` — the *same binary the architect runs, one tier down*. Key
-facts the skill encodes: lane-prompts go in on **stdin** (Claude Code has no
-`@file`, and a big quoted lane-prompt as a shell argument gets mangled); the
-model is pinned with `--model claude-sonnet-4-6` (the `sonnet` alias floats to
-the latest Sonnet — pin the full id); there is **no `-C`/working-dir flag**, so
+Verified against the `claude` CLI (Claude Code) headless mode — the reference
+harness — June 2026. The builder is `claude -p` (`--print`, the non-interactive
+headless mode) pinned to the configured builder model (`<builder-model>`) — a
+cheaper model run headless via the same harness the architect uses. Key facts the
+skill encodes: lane-prompts go in on **stdin** (Claude Code has no `@file`, and a
+big quoted lane-prompt as a shell argument gets mangled); the model is pinned with
+`--model <builder-model>` (a floating alias drifts to whatever ships next — pin
+the full id); there is **no `-C`/working-dir flag**, so
 per-lane dispatch `cd`s into the worktree; permissions are the **tool
 allow/deny lists** (`--allowedTools`/`--disallowedTools`) plus
 `--permission-mode`, not a sandbox; web access is the built-in
@@ -27,21 +28,22 @@ If a lane committed, treat the worktree as tampered: reset and re-dispatch.
 
 **Preflight (once per environment):** run `claude --version`, and confirm the
 builder model resolves with a one-shot canary
-(`echo ok | claude -p --model claude-sonnet-4-6 --max-turns 1`). No API key —
+(`echo ok | claude -p --model <builder-model> --max-turns 1`). No API key —
 the builder runs on your Claude plan — but note headless `claude -p` draws on
 the Agent SDK credit pool (separate from interactive usage since June 15 2026;
-see `DESIGN.md` §4). On the first real dispatch in a new environment, launch
+see `docs/DESIGN.md` §4). On the first real dispatch in a new environment, launch
 ONE canary lane and confirm it starts cleanly before fanning anything out.
 
 ## Canonical dispatch — `architect dispatch <iteration> <lane>`
 
 The canonical path is `architect dispatch <iteration> <lane>`. The tool
-assembles the canonical `claude -p` argv, pins the model to `claude-sonnet-4-6`,
+assembles the canonical `claude -p` argv, pins the builder model (the lane's
+configured model or the CLI's reference default; see `docs/DESIGN.md` §4),
 reads the lane prompt from `build/<id>-<lane>/prompt.md` on stdin, and streams
 `--output-format stream-json --verbose` output to
 `build/<id>-<lane>/run.jsonl`. Run each lane as its own **background Bash tool
-call** (`run_in_background`) so your turn doesn't block for the full multi-hour
-run.
+call** (`run_in_background`) so your turn doesn't block for the full run (30–60
+minutes is typical).
 
 Write the lane's prompt to `build/<id>-<lane>/prompt.md` first (never pass a
 big prompt as a shell argument — shells mangle quotes), then:
@@ -72,7 +74,7 @@ reaps those now-orphaned `claude` processes, and every lane dies at once with no
 `result` — partial diffs, no reports (this exact failure has happened: three
 lanes killed at the same second, zero output). One blocking dispatch per
 background Bash tool keeps each lane attached to a harness-tracked task that
-survives the full multi-hour run and reports completion per lane.
+survives the full run and reports completion per lane.
 
 ### What the tool runs under the hood
 
@@ -82,7 +84,7 @@ and as the manual fallback:
 ```bash
 # write prompt to build/<id>-<lane>/prompt.md first, then:
 ( cd build/<id>-<lane>/wt && \
-  claude -p --model claude-sonnet-4-6 \
+  claude -p --model <builder-model> \
     --permission-mode acceptEdits \
     --allowedTools 'Read,Edit,Write,Grep,Glob,Bash,WebSearch,WebFetch' \
     --disallowedTools 'Bash(git commit:*),Bash(git push:*),Bash(git reset:*),Bash(git merge:*),Bash(git rebase:*),Bash(git checkout:*),Bash(git branch:*)' \
@@ -100,48 +102,153 @@ over the allow list (deny always takes precedence) as the runtime first line
 against commits. Redirect stderr (`2>&1`) into the run-log so a dispatch error
 lands somewhere instead of vanishing.
 
-### Integration (architect-only, after per-lane post-flight passes)
+### Integration (judging session — after per-lane post-flight passes)
 
-You decide which lanes pass; the CLI does the git mechanics. Canonical path:
+This block runs in the judging session, not the dispatch session — the dispatch
+session's job ends when builders finish (see SKILL.md §5–6). You decide which
+lanes pass; the CLI does the git mechanics. Canonical path:
 
 ```bash
 architect integrate <iteration> --lanes <passing-set>   # e.g. --lanes lane-a,lane-b
 architect gate <iteration>                              # integration smoke (raw output; verdict stays yours)
 architect integrate <iteration> --lanes <passing-set> --teardown   # or remove worktrees + lane branches after
+architect land                                          # end of project: prints gh pr create --base main --head project/<slug>
 ```
 
 `architect integrate` commits each named lane on its branch and merges it
-`--no-ff` into the repo's `lane/<iteration>` integration branch, in order. It
-**refuses** a lane that left builder commits or wrote out-of-bounds (the
-mechanical post-flight checks), and aborts on a merge conflict. A merge conflict
-= the lane plan wasn't disjoint = a spec defect: kill the conflicting lane and
-re-spec; don't hand-resolve builder conflicts. It runs **no gates and makes no
-verdict** — `architect gate` streams the raw gate output for you to judge.
+`--no-ff` into the repo's stable `project/<slug>` branch (slug of `space.title`,
+persistent across all iterations), in order. It **refuses** a lane that left
+builder commits or wrote out-of-bounds (the mechanical post-flight checks), and
+aborts on a merge conflict. A merge conflict = the lane plan wasn't disjoint = a
+spec defect: kill the conflicting lane and re-spec; don't hand-resolve builder
+conflicts. It runs **no gates and makes no verdict** — `architect gate` streams
+the raw gate output for you to judge. `--teardown` deletes only the per-lane
+`lane/<iteration>-<lane>` branches and worktrees; it never deletes the
+`project/<slug>` branch.
 
 Under the hood / manual fallback (one lane shown):
 
 ```bash
-git -C repos/<repo> checkout -b lane/<iteration> <repo-base>
+# check out or create the project integration branch:
+git -C repos/<repo> checkout project/<slug> 2>/dev/null || \
+  git -C repos/<repo> checkout -b project/<slug> <repo-base>
 git -C build/<id>-<lane>/wt add -A
 git -C build/<id>-<lane>/wt commit -m "lane <lane>: <what>"
 git -C repos/<repo> merge --no-ff lane/<iteration>-<lane>
 <run the gate commands>          # integration smoke after every merge
 architect worktree remove <iteration> <lane>
 git -C repos/<repo> branch -d lane/<iteration>-<lane>
+# at project end:
+architect land                   # prints gh pr create --base main --head project/<slug>
 ```
 
+### Parallel + fast-follow
+
+Use when an iteration is near-disjoint — all but a thin shared seam (a
+registration line, an index entry, a shared require). Route the seam into a
+dedicated fast-follow lane; the parallel lanes stay genuinely disjoint and
+integrate without conflict.
+
+**Recipe:**
+
+1. **Spec the seam out of the parallel lanes.** Assign the seam file(s) to the
+   fast-follow lane's `--touch` set and exclude them from every parallel lane's
+   touch-set — so the parallel set is disjoint by construction.
+
+2. **Create worktrees and dispatch the parallel lanes** (off the repo base):
+   ```bash
+   architect worktree add <repo> <iteration> lane-a
+   architect worktree add <repo> <iteration> lane-b
+   architect dispatch <iteration> lane-a   # own background Bash call each
+   architect dispatch <iteration> lane-b
+   ```
+
+3. **Judging session — integrate the parallel set.** `project/<slug>` advances
+   to their merged tip:
+   ```bash
+   architect integrate <iteration> --lanes lane-a,lane-b
+   architect gate <iteration>
+   ```
+
+4. **Create the fast-follow lane off the integrated tip.** `--base` accepts any
+   git ref — passing `project/<slug>` roots the new worktree at the merged tip
+   (the keystone move):
+   ```bash
+   architect worktree add <repo> <iteration> ff --base project/<slug>
+   architect dispatch <iteration> ff
+   ```
+
+5. **Judging session — integrate the fast-follow lane.** Because it descends
+   directly from `project/<slug>`, the `--no-ff` merge appends cleanly with no
+   conflicts:
+   ```bash
+   architect integrate <iteration> --lanes ff
+   architect gate <iteration>
+   ```
+
+**Invariant:** the parallel lanes must stay disjoint — a conflict among them is
+still a disjointness defect (kill and re-spec; never hand-resolve). The
+fast-follow lane is the sanctioned home for the seam and never conflicts because
+it is a descendant of the integrated tip.
+
+### Serial deferred judgment
+
+Use when several iterations (or serial same-file lanes within one iteration)
+should run to gates-green without a judging session between each — batching cold
+AC judgment into one later session.
+
+**Recipe:**
+
+Per iteration, freeze and dispatch as normal. In a fresh judging session, run
+post-flight, integrate, and gate — but **withhold `architect verdict`**:
+
+```bash
+# judging session (per iteration) — stop before verdict:
+architect integrate <iteration> --lanes <passing-set>
+architect gate <iteration>
+# do NOT run: architect verdict <iteration> continue|kill
+```
+
+Each integrated-but-unjudged iteration surfaces as `awaiting-verdict` in
+`architect status`:
+
+```bash
+architect status
+# II   Iteration          …  Verdict
+# 03   some-feature       …  awaiting-verdict
+# 04   another-feature    …  awaiting-verdict
+```
+
+One later batch judging session evaluates all `awaiting-verdict` iterations,
+oldest-first. For each: read its own frozen AC from its freeze commit, run its
+gates cold, and record the verdict:
+
+```bash
+architect gate <iteration>               # run the frozen gates cold
+architect verdict <iteration> continue   # or: kill
+```
+
+**§1 preserved:** each verdict is cold and fresh-session — the batch judging
+session did not dispatch any of these iterations, so the §1
+fresh-session-judgment rule holds for every verdict in the batch.
+
+**Deliberate risk:** iteration N+1 integrated on top of N's not-yet-judged work
+rests on a foundation that a later KILL at N would revert. Accept this coupling
+only consciously, and always judge oldest-first so a KILL stops you before you
+compound it.
+
 ## Operating guidance
 
 - Background each lane as its own harness task and let the **per-lane
-  completion notification** bring you back (multi-hour runs are normal); read
+  completion notification** bring you back (long runs — 30–60 minutes — are normal); read
   `build/<id>-<lane>/run.jsonl` and the repo state afterwards. Do not write a
   blocking `while pgrep …; sleep` wait loop as a Bash command — that is itself
   a launcher that ties up a turn. When you return to a lane, check liveness via
   run-log growth (the stall rules below still apply unchanged).
 - Pin the model explicitly. The tool does this automatically (`--model
-  claude-sonnet-4-6`). The `sonnet` alias floats to the latest Sonnet — fine
-  interactively, but automations pin the full id so a model bump can't silently
-  change builder behavior mid-project.
+  <builder-model>`). A floating alias (a bare "latest"/tier tag) drifts to
+  whatever ships next — fine interactively, but automations pin the full id so a
+  model bump can't silently change builder behavior mid-project.
 - Effort = thinking budget. Claude Code has no per-invocation effort flag the
   way Codex exposed `model_reasoning_effort`; the builder sets thinking depth
   **in the block** via the escalation keywords (`think` < `think hard` <
@@ -166,16 +273,17 @@ git -C repos/<repo> branch -d lane/<iteration>-<lane>
   `claude -p --continue …`, never a `&` loop (a `&` launcher orphans the
   resumed lanes exactly as it does fresh ones). Never resume across iterations —
   every iteration gets a fresh context.
-- Cross-model review gate (high-stakes iterations): the architect is Opus 4.8
-  and the builder is Sonnet 4.6 — both Claude Code, so this is a
-  cross-*tier* read inside one lab, not cross-vendor (see `DESIGN.md` R3). The
-  architect (Opus) reading the diff is already the stronger-model fresh-context
-  pass. For an extra adversarial pass, pipe the instruction + diff to a fresh
-  read-only reviewer:
+- Capability-gap review gate (high-stakes iterations): the architect outranks the
+  builder, so the architect reading the diff is already a stronger-model,
+  fresh-context pass over it. How independent that read is depends on the pairing
+  — a same-lab architect/builder shares the builder's blind spots (the frozen
+  gates stay the independent check), a cross-vendor pairing is more independent
+  (see `docs/DESIGN.md` §1/R3). For an extra adversarial pass, pipe the
+  instruction + diff to a fresh read-only reviewer:
   ```bash
   { echo "Review this diff against the spec. Flag ONLY correctness/requirement/invariant gaps with file:line evidence. No style."; \
     git -C <repo-root> diff <base>...HEAD; } \
-  | claude -p --model claude-sonnet-4-6 --allowedTools 'Read,Grep,Glob'
+  | claude -p --model <builder-model> --allowedTools 'Read,Grep,Glob'
   ```
 - `build/` is already gitignored by the space, so no extra `.gitignore` entry
   is needed. Scratch never reaches the space repo; only `architecture/` is
@@ -287,11 +395,11 @@ against them, do not edit or work around) ===
 
 ## Builder-side standing setup (one time per machine/repo)
 
-- The builder is the same `claude` binary as the architect, one tier down —
-  nothing extra to install. `architect dispatch` pins the model per dispatch
-  (`--model claude-sonnet-4-6`); a `~/.claude/settings.json` `"model"` default
-  is fine interactively, but automations pin it explicitly so a default can't
-  silently swap the builder.
+- The builder is the same `claude` binary as the architect (reference harness),
+  running a cheaper model — nothing extra to install. `architect dispatch` pins
+  the model per dispatch (`--model <builder-model>`); a `~/.claude/settings.json`
+  `"model"` default is fine interactively, but automations pin it explicitly so a
+  default can't silently swap the builder.
 - Repo `CLAUDE.md` is the builder's standing context — Claude Code loads it
   root-down automatically. Put exact build/test commands and repo gotchas there;
   the loop's PHASE rules stay in the dispatch block so they version with the