Have the prepare read the code and list where design and code disagree

In milestone 47/G's develop the lead answered over 100 questions, most of
them a design line meeting the code: a form the code cannot take, or a part
assumed built that was not. The prepare had read the design alone. The
operator, 2026-11-11 about 23:45 CET: the prepare reads the code each design
line lands in as well, and lists every such place before any developer
starts; the lead answers each in one line against the principles.

Claude-Session: https://claude.ai/code/session_01NcbgfGKaxw984XyAPfLm4h

.claude/agents/mesh-preparer.md

@@ -1,20 +1,21 @@
 ---
 name: mesh-preparer
-description: Prepares one milestone or small fix of the Novox mesh before any code is written (hq playbook 07, the prepare step; playbook 08), from the milestone's part of its design alone - one build map per repository (where each design line lands in code, what exists there today and what relies on it, the subtasks and their order) and the list of design questions the design does not answer. Decides nothing; writes only its build maps and the milestone file's design questions.
+description: Prepares one milestone or small fix of the Novox mesh before any code is written (hq playbook 07, the prepare step; playbook 08), from the milestone's part of its design and the design's main file, read whole, then the code each design line lands in - one build map per repository (where each design line lands in code, what exists there today and what relies on it, the subtasks and their order), the list of design questions the design does not answer, and the list of places where a design line and the code disagree. Decides nothing; writes only its build maps and the milestone file's two lists.
 tools: Read, Grep, Glob, Bash, Write, mcp__mesh__mesh_call, mcp__mesh__mesh_describe, mcp__mesh__mesh_search, SendMessage
 model: opus
 ---
 
 You prepare one change of the Novox mesh for the lead who started you. The caller's handover names the issue, the
 design and its milestone part at an hq commit, and where your files go (playbook 07, step 0). You write the build
-maps and the milestone file's section `Design questions`, nothing else; you call no verb that writes and make no git
+maps and the milestone file's sections `Design questions` and `Design meets code`, nothing else; you call no verb that writes and make no git
 write.
 
-**The design is your only input.** Read the milestone part and the design's main file whole, at the commit the
+**The design is your only input for what is built.** Read the milestone part and the design's main file whole, at the commit the
 handover names, then hq's playbook 07 (step 0 and step 0b), the glossary (`00-META/glossary.md`) and the mesh's
 instructions (`/etc/claude-code/CLAUDE.md`). Do not read decision records or the knowledge base to judge the design:
 they were read when it was written and reviewed. Read the issues the handover names (`issue-tracker.get`) for their
-done-when. Code shows what exists, never what is to be built.
+done-when. Code shows what exists, never what is to be built; but it says whether a line can be built as written, so
+you read it too (next paragraph).
 
 **Then map each design line onto code**, as playbook 07 step 0 says: per repository, every design line it builds
 ("design NN M §n") with the files and functions it changes, its subtask (about thirty minutes, one change, its
@@ -28,14 +29,24 @@ callers and kinds, as on main) with the design lines that name that seat, field
 design question. Code: read the repositories at `origin/main` (`git fetch`, `git show`, `git grep`),
 never a working tree; the live mesh through its tools.
 
+**Then read the code each design line lands in, and list where they disagree** (playbook 07 step 0, items 3 and 10;
+the operator, 2026-11-11). For each design line, read at `origin/main` the files and functions it changes, the
+contracts, types and packages it uses and the rules the code holds there (a guard, a check, a test that refuses), and
+ask: can the code take the form the line names; is every part the line assumes built (a verb, a field, a package, an
+event, a module) there on main; does the line break a rule the code holds. Each no is an entry under `Design meets
+code`: the design line, the code (file:line at the commit read, each repository's commit named once at the top),
+which of the three it is, and your recommendation, said as one. The lead answers these against the principles before
+develop starts; you answer none. An entry that leaves a choice no principle settles is a design question instead.
+
 **Everything the design does not say is a design question, never your answer.** A reader or an effect with no fate,
 a field's form, a key and who deletes it, a bound, a caller, an owner, a tool for a new state, an interaction whose
-seat, verb, event or provision the design does not name, code or a live state that contradicts a design line: list
+seat, verb, event or provision the design does not name, a live state that contradicts a design line: list
 each under `Design questions` with the design line (or the missing one), what it leaves to its builder, where you met
 it (file:line or the tool's answer) and your recommendation, said as one. A build map holds no sentence about how
 anything should be, no finding of your own and no ruling; where you think a design line wrong by the mesh's
 principles, it is a design question too, and you map the line as written.
 
 Report to the caller in under 30 lines: the build maps' paths, the count of design lines mapped per repository and
-any line not mapped, the subtasks' order, and the design questions, one line each with your recommendation. Glossary
+any line not mapped, the subtasks' order, the design questions and the entries of `Design meets code`, one line each with your
+recommendation. Glossary
 words only; a guess is said as one.

00-META/process/07-feature-branches.md

@@ -56,6 +56,11 @@ A small fix (one repository, one issue, about an hour of work) follows
   answered, all found in develop. The design is now the only input to the prepare and to develop, the prepare's only
   output is where each design line lands and what the design does not answer, the operator answers that (or, for a
   question of internal form only, the design writer, step 0), and develop starts only when it is all answered (step 0b, *Design complete*).
+- **A design that met the code only in develop.** On 2026-11-11, in the develop step of milestone 47/G, the lead
+  answered over 100 questions, most of them a design line meeting the code: a line naming a form the code cannot
+  take, or assuming a part already built that was not. The prepare had read the design alone. It now reads the code
+  each design line lands in as well, and lists every place where the two disagree before any developer starts
+  (step 0, items 3 and 10; the operator, 2026-11-11).
 - **A module proven only after it reached the machines.** The mail modules were delivered with unit tests
   only, then failed live three times (issues 859, 865, 868) and took five more hours of fixes.
 
@@ -67,8 +72,8 @@ opened **once**, after the review, and **one check** (ADR 0548). It runs in five
 
 | Step | What happens | Bound |
 |---|---|---|
-| 0. Prepare | from the milestone part alone: where each design line lands in code, what exists there today and what relies on it, as one build map per repository; and every design question, the design's silences, listed | 15 minutes, longer when what exists is large: code never starts on an incomplete answer |
-| 0b. Design complete | every design question is answered, by the operator or, for one of internal form only, by `hq-design-writer` (step 0); each answer is written into the milestone part (playbook 02) and its build map rows added | until the list is empty: develop never starts before |
+| 0. Prepare | from the milestone part and the design's main file, read whole, then the code each design line lands in: where each line lands, what exists there today and what relies on it, as one build map per repository; every design question, the design's silences, listed; and every place where a design line and the code disagree, listed | 15 minutes, longer when what exists is large: code never starts on an incomplete answer |
+| 0b. Design complete | every design question is answered, by the operator or, for one of internal form only, by `hq-design-writer` (step 0); each answer is written into the milestone part (playbook 02) and its build map rows added; every place where design and code disagree is answered by the lead in one line against the principles | until the list is empty: develop never starts before |
 | 1. Develop | one fixing agent per repository builds every design line of its build map locally, each commit citing the lines it builds, the whole unit suite before every commit, the integration tests compiled, and once per head it reports those of the packages it touched and their importers run against an embedded bus (below); nothing is pushed | the milestone's issues, 30 minutes each |
 | 2. Review | one reviewer reads all of it, the local commits, judging the integration tests by reading them against the code; reports go both ways; at most 3 rounds | 15 minutes |
 | 3. Check | push the reviewed heads once and open the pull requests together; the checker's one check runs the integration tests; no further review unless the check fails | one check run |
@@ -134,8 +139,8 @@ interaction travels (the seat, verb, event, provision, state on the bus, manifes
 design does not name is a design question, never the preparer's finding with its own alternative. The mesh paths
 are held where they are decided: the reviewers by architectural domain judge the milestone part before it is built
 (playbook [02](02-graduation.md), *Answering a design question*).
-- **The prepare's only output** is one build map per repository (item 4) and the list of design questions
-  (item 10). It writes no findings of its own, no recommendations into the build map and no rulings, and no file of
+- **The prepare's only output** is one build map per repository (item 4), the list of design questions and the list
+  of places where a design line and the code disagree (item 10). It writes no findings of its own, no recommendations into the build map and no rulings, and no file of
   the milestone holds a statement of how something should be.
 - **Who answers a design question** (the operator, 2026-11-11). A question that changes nothing the operator sees,
   nobody's permissions (who may call, publish or read what) and no data kept or removed (an internal wire form, a
@@ -146,6 +151,10 @@ are held where they are decided: the reviewers by architectural domain judge the
   developer's or a reviewer's, nor a lead's of another session; one that seems internal but touches who may call,
   what the operator sees or data is the operator's. The lead's part is the process: who works on what, on which
   model, the waits and the reports, and asking the operator.
+- **Who answers where design and code disagree** (the operator, 2026-11-11). A place the prepare lists under
+  `Design meets code` (item 10) is answered by the lead, tested against the principles (`00-META/principles.md`), in
+  one line in the milestone's lead-answers file naming the principle that settles it, without a design batch or a
+  review round; one no principle settles is a design question and goes as above.
 - **One milestone has one lead.** A session that held part of the work hands its branches and heads to the lead and
   stops; between sessions travel heads, commits, design questions and the hq commits that answer them, never an
   instruction on how to build.
@@ -153,8 +162,11 @@ are held where they are decided: the reviewers by architectural domain judge the
 How it is checked: every subtask in a build map and every commit of the milestone cites the design lines it builds
 ("design NN M §n"), and the review finds code that cites none (step 2, item 2a); the milestone's files hold no
 rulings (`grep -n -i 'ruling' .work/<slug>/*.md` finds none); a question answered by anyone but the operator, other than one of
-internal form only answered by `hq-design-writer` in a design line the reviewers by architectural domain read, is a
-breach the lead names at the next report.
+internal form only answered by `hq-design-writer` in a design line the reviewers by architectural domain read, or an
+entry of `Design meets code` answered by the lead in its lead-answers file, is a breach the lead names at the next
+report; the milestone file's `Design meets code` names, for each repository a design line lands in, the `origin/main`
+commit the prepare read, and a developer's question that is a design line meeting code the prepare read is a miss
+of the prepare the lead names at the next report.
 
 1. **Name the feature once:** `feat/<slug>`, the same branch name in every repository it touches (but see the
    exception for a new manifest word in phase 3: a release that must merge first has a name of its own). The
@@ -166,11 +178,17 @@ breach the lead names at the next report.
    `main` (`git worktree add --detach .work/<slug>/mesh-tools main`), never symlinks. **A repository's own
    clone stays on `main`** (the operator, 2026-10-17): no work is done in it and no branch is checked out
    there, so a session that opens in it reads what holds now; fetch and fast-forward it before reading.
-3. **Read the milestone part and the design's main file whole**, before any code; the preparer reads nothing else
-   to know what is to be built. Every question the code or the live mesh raises that the milestone part does not
-   answer goes onto the list of design questions (item 10), never into an answer of the preparer's or the lead's. A
-   fixing agent that meets a design question stops that part, and its run is spent again: the prepare is where the
-   questions are found.
+3. **Read the milestone part and the design's main file whole, then the code each design line lands in**, before any
+   code is written (the operator, 2026-11-11: the prepare reads the code as well as the design). The design is the
+   only thing the preparer reads to know what is to be built; the code, read at `origin/main` in each repository a
+   line lands in, says whether the line can be built as written. For each design line the preparer reads the files
+   and functions it changes, the contracts, types and packages it uses, and the rules the code holds there (a guard,
+   a check, a test that refuses), and asks three things: can the code take the form the line names; is every part the
+   line assumes built (a verb, a field, a package, an event, a module) there on main; does the line break a rule the
+   code holds. Each no goes onto the list `Design meets code` (item 10). Every question the code or the live mesh
+   raises that the milestone part does not answer goes onto the list of design questions (item 10). Neither is ever
+   answered by the preparer. A fixing agent that meets either stops that part, and its run is spent again: the
+   prepare is where both are found.
 3a. **Read what exists today, and write it down before any code** (the operator, 2026-11-02: "if i ask to implement
    feature A, you'd better first check what exists today with regards to feature A"). Research, decisions, the survey
    and the review each check the layer before them; this is the step that checks the running code. Each repository's
@@ -288,7 +306,12 @@ breach the lead names at the next report.
    concerns (or the section where a line is missing), what the line leaves to its builder, where the prepare met it
    (file:line or the tool's answer), and the preparer's recommendation, said as a recommendation. A design that
    contradicts a decision in force, a reader or an effect with no fate, a lifetime, a caller, a bound, a field's
-   form, a tool for a new state: each is a question. The list is the prepare's last output and step 0b's input.
+   form, a tool for a new state: each is a question.
+   Then, under `Design meets code`, every place item 3 found where a design line and the code disagree, each with
+   the design line, the code (file:line at the `origin/main` commit read), which of the three it is (a form the code
+   cannot take, a part the line assumes built that is not, a rule in code the line would break), and the preparer's
+   recommendation, said as a recommendation. An entry that leaves a choice no principle settles is a design question
+   and is listed above instead. The two lists are the prepare's last output and step 0b's input.
 
 ## Step 0b — Design complete
 
@@ -299,14 +322,18 @@ the design before the code).
 1. **The lead sorts each question and asks the operator's.** A question of internal form only (step 0, *Who answers
    a design question*) goes to `hq-design-writer` in its handover; every other one the lead asks the operator, one per
    ask, as playbook [02](02-graduation.md), *Answering a design question*, says, and adds each ask to its wait list.
-   The lead answers none and passes on no answer of its own; a question the writer finds is not of internal form only
-   it hands back for the operator.
+   The lead answers no design question and passes on no answer of its own; a question the writer finds is not of
+   internal form only it hands back for the operator.
+1a. **The lead answers each entry of `Design meets code`** in one line in the milestone's lead-answers file, tested
+   against the principles (`00-META/principles.md`) and naming the principle that settles it (step 0, *Who answers
+   where design and code disagree*); an entry no principle settles moves to the design questions and is asked as
+   item 1 says. The entry names the hq commit that holds its answer.
 2. **Each answer is written into the milestone part** by `hq-design-writer` on hq's branch of the milestone, as a
    design line (the operator's citing the operator and the date, the writer's own giving its reason) (or, outside every record's question, after its decision record), and the four reviewers by
    architectural domain read the amended part in one round.
 3. **The preparer adds the new lines to the build maps** (item 4) and the question's entry names the hq commit that
    answers it.
-4. **The design is complete** when every entry names its answering commit. Then step 1 starts, from the milestone
+4. **The design is complete** when every entry of both lists names its answering commit. Then step 1 starts, from the milestone
    part at that commit.
 
 **A question met later stops only its part.** A developer or the reviewer who meets a question the milestone part
@@ -319,8 +346,8 @@ until the part is amended (playbook [02](02-graduation.md)) and their build map
 the design was complete joins the milestone only where each of its commits builds a design line of the complete part,
 and the review reads it as new code.
 
-How it is checked: the milestone file's `Design questions` all name an answering hq commit older than the first
-commit of step 1 (`git log` of each repository's branch against hq's); a commit with no design line, or one built on
+How it is checked: the milestone file's `Design questions` and `Design meets code` all name an answering hq commit
+older than the first commit of step 1 (`git log` of each repository's branch against hq's); a commit with no design line, or one built on
 an answer no hq commit holds, is a finding of the review (step 2, item 2a).
 
 ## Step 1 — Develop (one fixing agent per repository, smaller model)

00-META/process/playbooks.html

@@ -282,6 +282,7 @@ code{font:12.5px ui-monospace,monospace;background:var(--soft);padding:1px 5px;b
     <h3>Step 0 · what the lead writes before any agent starts</h3>
     <ul style="margin:6px 0;padding-left:20px;font-size:14px">
       <li><span class="tag new">new</span>The milestone part of the design is the only input: the prepare maps each design line onto code (a build map per repository, each row citing its line) and lists every design question, what the design does not answer. It writes no findings or rulings of its own.</li>
+      <li><span class="tag new">new</span>The prepare reads the design whole, then the code each design line lands in, and lists under Design meets code every place where they disagree: a form the code cannot take, a part the line assumes built that is not, a rule in code the line would break. The lead answers each in one line against the principles before develop starts.</li>
       <li><span class="tag new">new</span>Design complete: the operator answers each question, or the design writer one of internal form only (no change to what the operator sees, no permission, no data kept or removed), read by the reviewers by architectural domain; the answer is written into the milestone part, and only then does develop start. Nobody else answers one.</li>
       <li><span class="tag new">new</span>What exists today, read from the code and the live mesh, never from memory: every effect of a part removed or moved (bus writes, files, credentials, plans, processes, calls answered), every reader relying on each, what happens to each after the change and its test. It opens each build map; no code before it is complete, and the review refuses work without it.</li>
       <li><span class="tag new">new</span>Subtasks ordered so a user starts from the commit that adds its contract; one writer per file; one placement of the siblings for every agent.</li>
@@ -475,7 +476,7 @@ const P = [
  {n:"07",name:"Features",kind:"build",c:"--build",
   trig:"Work that changes code across issues or repositories, too large for a small fix.",
   who:"A lead (larger model), one fixing agent per repository (smaller), one reviewer (larger).",
-  steps:["Prepare: name the branch, make the worktrees, read the milestone part and the design's main file whole. (new)","Every agent is one of hq's definitions (mesh-preparer, mesh-developer, mesh-code-reviewer, mesh-watcher); the lead writes only the handover. (new)","The prepare's only output: a build map per repository, each row a design line and where it lands, and the design questions. No rulings. (new)","Design complete: the operator answers every question (the design writer one of internal form only), each written into the milestone part; then develop. (new)","Read what exists today from the code and the live mesh: every effect of what is removed or moved, every reader of each, what happens to each and its test. No code before it is complete; the review refuses work without it. (new)","The build map opens with what exists today; subtasks ordered contract first, one writer per file.","Write the findings and acceptance criteria into each issue.","Survey every other reader and writer of each changed value. (new)","Answer three questions in the milestone file: who deletes each new key and stream, how the switch-over is tried on one node first, what the one check does not cover. The review checks them. (new)","List every part the change reaches; copy fixtures from the real writer.","Develop: one agent per repository, one commit per subtask, each citing its design lines; a question stops only its subtask. (new)","A test fails first on behaviour, not on compiling. (new)","Bring each branch up to the trunk; nothing is pushed, no try runs. (new)","Review all of it against the design lines, code no line asks for a finding, reading the integration tests against the code; at most 3 rounds; the report answers the state-and-seams and mesh-agnostic questions. (new)","A group pins the group's own mesh-sdk head in every member. (new)","Push the reviewed heads once and read each forge head against the reviewed commit; no draft pull request, no fix round on an open one. (new)","Open one pull request per repository, together, with Reviewed-by and Pushed-by; the one check runs. A failed check is read, fixed, reviewed, pushed once more. (new)","The operator's Approve on Telegram; the group merges in one pass.","Follow the delivery in the status view (moving, settled, stuck, delivered) to done; resolve the issues; clean up. (new)","When the builder cannot deliver its own fix: revert, a build by a session's call, a registration at the terminal, copies kept outside the store; a broken controller is put back by a want the operator writes, a hand build by mesh-hand-compose and a want. (new)"],
+  steps:["Prepare: name the branch, make the worktrees, read the milestone part and the design's main file whole, then the code each design line lands in. (new)","List every place where a design line and the code disagree; the lead answers each in one line against the principles before develop. (new)","Every agent is one of hq's definitions (mesh-preparer, mesh-developer, mesh-code-reviewer, mesh-watcher); the lead writes only the handover. (new)","The prepare's only output: a build map per repository, each row a design line and where it lands, and the design questions. No rulings. (new)","Design complete: the operator answers every question (the design writer one of internal form only), each written into the milestone part; then develop. (new)","Read what exists today from the code and the live mesh: every effect of what is removed or moved, every reader of each, what happens to each and its test. No code before it is complete; the review refuses work without it. (new)","The build map opens with what exists today; subtasks ordered contract first, one writer per file.","Write the findings and acceptance criteria into each issue.","Survey every other reader and writer of each changed value. (new)","Answer three questions in the milestone file: who deletes each new key and stream, how the switch-over is tried on one node first, what the one check does not cover. The review checks them. (new)","List every part the change reaches; copy fixtures from the real writer.","Develop: one agent per repository, one commit per subtask, each citing its design lines; a question stops only its subtask. (new)","A test fails first on behaviour, not on compiling. (new)","Bring each branch up to the trunk; nothing is pushed, no try runs. (new)","Review all of it against the design lines, code no line asks for a finding, reading the integration tests against the code; at most 3 rounds; the report answers the state-and-seams and mesh-agnostic questions. (new)","A group pins the group's own mesh-sdk head in every member. (new)","Push the reviewed heads once and read each forge head against the reviewed commit; no draft pull request, no fix round on an open one. (new)","Open one pull request per repository, together, with Reviewed-by and Pushed-by; the one check runs. A failed check is read, fixed, reviewed, pushed once more. (new)","The operator's Approve on Telegram; the group merges in one pass.","Follow the delivery in the status view (moving, settled, stuck, delivered) to done; resolve the issues; clean up. (new)","When the builder cannot deliver its own fix: revert, a build by a session's call, a registration at the terminal, copies kept outside the store; a broken controller is put back by a want the operator writes, a hand build by mesh-hand-compose and a want. (new)"],
   prod:"One pull request per repository, one source revision delivered, resolved issues, no branch or worktree left.",
   next:"02 (when it ships)",bounds:"Prepare 15 min · 30 min per issue · review 15 min, ≤ 3 rounds · one check, pushed once",
   prev:["Pull requests as scratchpads","Context bought again and again","A change built on what was remembered, not on what runs","Review rounds spent on what a run would show","A node agent's bus reads, proven only by review"],

AGENTS.md

@@ -26,7 +26,9 @@ research effort to the knowledge base from a draft (playbooks 01 and 02) and fol
 from the knowledge base and maps each interaction onto a mesh path. An agent that prepares, builds or reviews code
 starts from the milestone's part of its design alone, builds what its design lines say, and decides nothing: what
 the design does not answer is a design question for the operator, answered in the design before any code
-(playbook 07). The lead writes only the handover, never an agent's way of working and never an answer to a design
+(playbook 07). The prepare also reads the code each design line lands in and lists every place where a line and the
+code disagree, which the lead answers in one line against [`00-META/principles.md`](00-META/principles.md) before
+develop starts (playbook 07, step 0). The lead writes only the handover, never an agent's way of working and never an answer to a design
 question. A subagent runs in the session that started it, from hq: its way of working comes from its definition and hq's playbooks, its knowledge from the knowledge base or, for building, the design; one given a coding task works in a worktree under hq's `.work/` and also reads the conventions of the repository it changes, and where those contradict hq, hq wins and the agent says so.
 
 ## The development cycle