Read what exists before writing code, in the prepare step

Each layer (research, decisions, survey, review) checked the layer before
it and none read the running code, so effects of the controller's removed
jobs surfaced only after delivery. Playbook 07's prepare step now writes,
per context file, what exists today, every effect and reader of what is
removed or moved, and each one's fate with its test; the review refuses
work without it. Playbook 08 reads its area the same way, briefly.

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

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

@@ -44,6 +44,10 @@ A small fix (one repository, one issue, about an hour of work) follows
   on the bus; two reviews read the code, no test ran it under a node's real permissions, and once it was live every
   node's agent was refused that read and stopped composing (issue 1126). How-we-build's rule "A bus permission is
   proven under the real permission" (ADR 0560) is what the review now asks for.
+- **A change built on what was remembered, not on what runs.** In the days up to 2026-11-02 a release took the
+  controller's jobs apart from the records and the survey alone. Jobs nobody had named surfaced only after the
+  delivery, a moved module's wiring and a changed failure label's readers were never read, and every check found one
+  more fault. Each layer had checked the layer before it; none had read the running code. Step 0 item 3a is the answer.
 - **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.
 
@@ -55,7 +59,7 @@ opened **once**, after the review, and **one check** (ADR 0548). It runs in five
 
 | Step | What happens | Bound |
 |---|---|---|
-| 0. Prepare | the lead settles the open questions and writes one context file per repository | 15 minutes |
+| 0. Prepare | the lead reads what exists today in the code and on the live mesh, settles the open questions and writes one context file per repository, opening with what exists, what relies on it and what happens to each | 15 minutes, longer when what exists is large: code never starts on an incomplete answer |
 | 1. Develop | one fixing agent per repository builds every issue locally, the whole unit suite before every commit, the integration tests compiled (those that exercise the change are run by name before the push, step 3); 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 |
@@ -114,8 +118,33 @@ issue whether it is being fixed in between, after the delivery, or waits, and on
    2026-10-26: "that is simply our delivery plan and milestones, we've already researched it"); propose new research
    only for what no record decides. A fixing agent that meets an undecided design question
    stops, and its run is spent again.
+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
+   context file (item 4) opens with a section `What exists today` that answers three questions, in writing:
+   1. **What exists today for this feature**, read from the code (file:line) and from the live mesh through the mesh
+      MCP server's tools (the seats, the modules on each machine, their state on the bus, their tools' answers), never
+      from memory and never from a record alone. Where the code or the mesh contradicts a record, the answer says so,
+      and the lead settles it as item 3 says.
+   2. **Everything the change touches, replaces or removes, and what relies on each today.** For a part that is removed
+      or moved (a module, a seat, a job of a module, a file, a value's form, a label others read), every effect it has
+      is listed, found mechanically from its code and not recalled: each bus write (bucket key, stream subject, event),
+      each file it writes, each credential or grant it issues or rotates, each plan or record it makes, each process or
+      container it starts, each verb, tool or request it answers, and each timer it runs. Then, for each effect, every
+      reader that relies on it (a search across every repository and the live bus, file:line or address). The search is
+      written down as run (the pattern and where), so the review can run it again.
+   3. **For each item of the second answer, what happens to it after the change** (kept as it is, moved to a named seat,
+      module or verb, replaced by a named part, or dropped and why nothing needs it), **and the test that proves it**: an
+      acceptance criterion (item 5) at its level, or, for a dropped effect, the search showing no reader is left.
+   Code starts only when the three answers are complete for every repository: no fixing agent starts on a context file
+   without them, and an effect found later is the prepare step missed, written into the answer and its issue before the
+   fix. In the days up to 2026-11-02 the controller was taken apart without this answer: jobs nobody had named (making
+   a provision's credentials for a new consumer, planning a module's next build) surfaced only after the delivery; a
+   module was moved without reading how its pieces were wired; a failure label was changed without reading what relied
+   on it; and each check found one more fault the preparation should have known.
 4. **Write one context file per repository**, `.work/<slug>/<repo>.context.md`. It is what a fixing agent
    reads instead of rediscovering the code, and it is reused by every agent and every round:
+   - first, the section `What exists today` with item 3a's three answers;
    - the issues it builds, in order, each with: the files and functions it changes, the decisions it builds
      with (quoted, with where each was decided), and its acceptance criteria (item 5), each with the test that
      proves it;
@@ -271,6 +300,12 @@ issue whether it is being fixed in between, after the delivery, or waits, and on
    key and stream the diff creates or writes (search the diff for the bucket and stream names) and finds each in the
    lifetime answer with a deleter and event, or a time to live; it reads the switch-over answer and checks it was done as
    written or that the operator's choice is recorded; it reads the integration-level answer against the check the pull requests will ask. A missing answer, or a key or stream the diff creates that the answer omits, is a change asked.
+6b. **The reviewer holds the change to each context file's `What exists today`** (step 0, item 3a). It refuses to
+   review a repository whose context file lacks the section or leaves one of its three answers open: that is the
+   prepare step undone, sent back to the lead, and not a round. For every part the diff removes, moves or changes the
+   form of, it runs the recorded search again on the reviewed tree and finds each effect and each reader in the second
+   answer; for each, it reads in the diff that the third answer's fate happened and that its test exists. An effect or a
+   reader the search finds and the answer omits, or a fate the diff does not carry out, makes the change wrong.
 7. **A finding outside the issues' done-when and their acceptance criteria is never a change asked, in any round.** More hardening, a
    further case, a nicer form: the reviewer opens it with `issue-tracker.open` and names the number in its
    report, and the round does not wait for it. What a round asks is only what makes the change wrong against
@@ -632,6 +667,12 @@ issues in `fixing` that nobody works on reads to the operator as stuck work.
   request into a feature branch exists. A pull request per issue, or an agent waiting on a merge check in
   step 1, is the failure this playbook prevents.
 - A context file exists per touched repository under `.work/<slug>/` while the feature runs.
+- Every context file opens with `What exists today` holding step 0 item 3a's three answers, each search written as run
+  (`grep -n -A3 'What exists today' .work/<slug>/*.context.md`), and its time (the file's commit or the lead's note) is
+  older than the repository's first commit of the feature; the review report says it ran the searches again (step 2,
+  item 6b). A fixing agent started on a file without the section, or an effect of a removed or moved part met only
+  after the delivery, is the prepare step skipped, named in the next detailed report and written into the playbook's
+  lessons here.
 - No issue of a running milestone is sized over an hour in its prepare note; an issue whose fixing agent passes
   twice its bound was not split.
 - Every issue of a running milestone has a note from the prepare step naming its files and tests (file:line), how

00-META/process/08-small-fixes.md

@@ -33,7 +33,12 @@ processing power"). Everything before the push is local and fast, and no try is
 ## Steps
 
 1. **Read the issue and the code it names** (the session's own model, or one read-only agent on the smaller
-   model answering exact questions with file:line). If a design question is open, it is settled before any
+   model answering exact questions with file:line). **Read what exists in the fix's area today, briefly, before any
+   code** (playbook [07](07-feature-branches.md) step 0 item 3a, at a small fix's size): what the code and the live mesh
+   (through the mesh MCP server's tools) do there now, and for each value, label, file or job the fix changes or removes,
+   every reader that relies on it, found by a search across the repositories (written down as run) and not from memory,
+   with what happens to each after the fix. It is a few lines in the issue's note, under `What exists today`, and the
+   review runs the search again; a reader it finds that the note omits makes the fix wrong. If a design question is open, it is settled before any
    code is written: on the issue, through the knowledge base (`knowledge-base.ask` first: what is decided is read before anything is designed), or by the operator. A fix that turns out to
    need a second repository, or more than about an hour, stops here and becomes a feature; one that needs a
    decision stays a small fix. **The session's own model (the larger) then writes the issue's acceptance
@@ -59,7 +64,7 @@ processing power"). Everything before the push is local and fast, and no try is
    writer writes it; the review asks it.
 4. **One review of the local commit** (a reviewer that did not write it, larger
    model; at most 3 rounds, as playbook 07; from round 2 only what is wrong; it reads each acceptance criterion
-   against its test, as playbook 07 step 2 item 6; a finding outside the issue's done-when and its acceptance
+   against its test, as playbook 07 step 2 item 6; it runs the `What exists today` search again, as playbook 07 step 2 item 6b; a finding outside the issue's done-when and its acceptance
    criteria is opened as an issue of its own, never asked as a change; it judges the integration tests by reading them against the code, as playbook 07 step 2 item 4 says; it answers playbook 07 step 2 item 10's two questions, on state and seams and on mesh-agnostic repositories, in its report). The reviewer's findings go back to the same agent that wrote the fix, continued by
    its id, so the fix keeps its context. A playbook or design edit of a few lines may skip the reviewer: the
    operator's Approve of its merge is its review, and the review record says so.
@@ -146,6 +151,9 @@ reading itself and uses one subagent only for the review.
 - A pull request with no review record at its head (the Approve's ask says so first), a fix to a module's
   running pushed with no integration test of the module whole, or a review report
   asking a change outside the issue's done-when and acceptance criteria, is the failure of steps 4 to 6.
+- A fixed code issue shows a note with `What exists today` (`issue-tracker.get`) older than its first commit, its
+  search written as run; one without is step 1 skipped, and a reader of a changed value met only after the delivery
+  is that note left short.
 - A fixed code issue shows a note headed `Acceptance criteria` (`issue-tracker.get`) older than its first
   commit, and each criterion's label is cited by a test in the pushed tree
   (`git grep -n '<issue>/AC<n>'`); one without is step 1 skipped.

00-META/process/playbooks.html

@@ -221,8 +221,8 @@ code{font:12.5px ui-monospace,monospace;background:var(--soft);padding:1px 5px;b
   </g>
   <!-- lead -->
   <rect x="110" y="56" width="160" height="52" rx="8" fill="var(--card)" stroke="var(--dec)" stroke-width="2"/>
-  <text x="190" y="78" text-anchor="middle" class="t">Survey · criteria</text>
-  <text x="190" y="96" text-anchor="middle" class="mute">context file per repo</text>
+  <text x="190" y="78" text-anchor="middle" class="t">What exists · survey</text>
+  <text x="190" y="96" text-anchor="middle" class="mute">criteria · context file per repo</text>
   <rect x="340" y="56" width="140" height="52" rx="8" fill="var(--card)" stroke="var(--dec)" stroke-width="2"/>
   <text x="410" y="78" text-anchor="middle" class="t">Up to trunk</text>
   <text x="410" y="96" text-anchor="middle" class="mute">each branch, local</text>
@@ -275,6 +275,7 @@ code{font:12.5px ui-monospace,monospace;background:var(--soft);padding:1px 5px;b
   <div class="box">
     <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>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 context file; no code before it is complete, and the review refuses work without it.</li>
       <li>Every open question settled: on the issue, in the knowledge base, or by the operator.</li>
       <li>Into each issue: every file and test it touches (file:line), how it is checked and delivered, a group's merge order.</li>
       <li><span class="tag new">new</span>Every other reader and writer of each value the change touches, each with a criterion.</li>
@@ -463,15 +464,15 @@ 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, settle every question.","Write one context file per repository.","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 issue.","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, 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, settle every question.","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)","Write one context file per repository, opening with what exists today.","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 issue.","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, 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","Review rounds spent on what a run would show","A node agent's bus reads, proven only by review"],
+  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"],
   check:"The checker's one status, mesh/check; the review record; the tracker's move."},
  {n:"08",name:"Small fixes",kind:"build",c:"--build",
   trig:"One issue in one repository, about an hour of work.",
   who:"The session, with one reviewer on the larger model.",
-  steps:["Read the issue and the code; settle any open question.","Write the acceptance criteria.","Move the issue to fixing.","Build on fix/<issue>-<slug> in its own worktree.","A test that fails today first, on behaviour. (new)","Nothing is pushed and no try runs before the review. (new)","One review of the local commit.","Push the reviewed head once; only then open the pull request. (new)","The operator's Approve; the merge; the delivery, followed in the status view. (new)","Prove the fix live and resolve the same hour.","During a milestone: ride in its delivery group, unless broken for the operator now. (new)"],
+  steps:["Read the issue and the code; settle any open question.","Read what exists in the fix's area today, briefly: every reader of what the fix changes. (new)","Write the acceptance criteria.","Move the issue to fixing.","Build on fix/<issue>-<slug> in its own worktree.","A test that fails today first, on behaviour. (new)","Nothing is pushed and no try runs before the review. (new)","One review of the local commit.","Push the reviewed head once; only then open the pull request. (new)","The operator's Approve; the merge; the delivery, followed in the status view. (new)","Prove the fix live and resolve the same hour.","During a milestone: ride in its delivery group, unless broken for the operator now. (new)"],
   prod:"One pull request, one delivery, a resolved issue.",
   next:"—",bounds:"About an hour · one review, one push, one check",
   prev:["A fix reviewed after its pull request opened","A long part run twice","A fix waiting on someone else's delivery","Ten SDK merges and eight controller merges in a day, one per fix"],