Where new code goes is a design question: playbook 08, the developer and the code reviewer check it against designs 20 and 26 #515

Merged
mesh-tools merged 2 commits from docs/placement-is-a-design-question into main 2026-11-04 22:23:45 +00:00
Member

On 2026-11-04 a small fix (issue 1748, the builder's retake) put a new seat type into mesh-sdk, against the design section Where a seat's code goes (mesh-sdk takes no seat-specific type; a seat's types live in its contract in its domain's contracts module). The rule to ask the knowledge base first was in place, but each step let it pass:

  • playbook 08 asked the knowledge base only "if a design question is open", and the lead treated placement as its own choice;
  • the developer built the lead's handover, which said where the code goes;
  • the code reviewer checked against the handover's rulings, not against the designs;
  • the preparer still said mesh-sdk holds seat contracts;
  • the mesh-sdk test that refuses a seat type comes only with the registry milestone.

This change:

  • playbook 08 step 1 and playbook 07's prepare (answer 3): where each new piece of code goes is always a design question. Before any code, the lead asks the knowledge base and reads the section Where a seat's code goes; the note names the line that places every new exported type, field, constant, package or module. A handover quotes those lines and never decides a placement itself.
  • mesh-preparer: carries the section's split (contract in the domain's contracts module or the seat-set package, logic over a seat in its client package, mesh-sdk only the runtime and seat-neutral parts) and names the placing line for each new identifier.
  • mesh-developer: checks each new exported identifier against that section; a handover that places it elsewhere is reported, never built.
  • mesh-code-reviewer: the handover and the lead's rulings are claims to check, never limits; a misplaced identifier is a finding, checked by the reviewer itself.

No record is named by number in the new lines (discover-knowledge-eagerly). go test ./... at the root: pass.

Reviewed-by: review-515@shanks at b525f1059b
Pushed-by: fix-1965@shanks

https://claude.ai/code/session_01JG73KJNrH5EgFXMKKYSrig

On 2026-11-04 a small fix (issue 1748, the builder's retake) put a new seat type into mesh-sdk, against the design section *Where a seat's code goes* (mesh-sdk takes no seat-specific type; a seat's types live in its contract in its domain's contracts module). The rule to ask the knowledge base first was in place, but each step let it pass: - playbook 08 asked the knowledge base only "if a design question is open", and the lead treated placement as its own choice; - the developer built the lead's handover, which said where the code goes; - the code reviewer checked against the handover's rulings, not against the designs; - the preparer still said mesh-sdk holds seat contracts; - the mesh-sdk test that refuses a seat type comes only with the registry milestone. This change: - **playbook 08 step 1 and playbook 07's prepare (answer 3):** where each new piece of code goes is always a design question. Before any code, the lead asks the knowledge base and reads the section *Where a seat's code goes*; the note names the line that places every new exported type, field, constant, package or module. A handover quotes those lines and never decides a placement itself. - **mesh-preparer:** carries the section's split (contract in the domain's contracts module or the seat-set package, logic over a seat in its client package, mesh-sdk only the runtime and seat-neutral parts) and names the placing line for each new identifier. - **mesh-developer:** checks each new exported identifier against that section; a handover that places it elsewhere is reported, never built. - **mesh-code-reviewer:** the handover and the lead's rulings are claims to check, never limits; a misplaced identifier is a finding, checked by the reviewer itself. No record is named by number in the new lines (discover-knowledge-eagerly). `go test ./...` at the root: pass. Reviewed-by: review-515@shanks at b525f1059b6914b078079f6eb009fd5412e51274 Pushed-by: fix-1965@shanks https://claude.ai/code/session_01JG73KJNrH5EgFXMKKYSrig
mesh-tools added 1 commit 2026-11-04 22:18:08 +00:00
Where new code goes is a design question: the playbook, the developer and the reviewer check it against designs 20 and 26
mesh/delivery closed: a newer head of the same pull request
mesh/check pass 69f95f551d19 on d4ae72782336 | unit 39 run, 0 kept, 1 skipped | integration 39 run, 0 kept, 1 skipped | composition passed in 17s on 4…
69f95f551d
A small fix's lead placed a seat's type in mesh-sdk by its own handover (issue 1748), against design 26;
the developer built the handover and the reviewer checked against it, so it passed review and its check.

Claude-Session: https://claude.ai/code/session_01JG73KJNrH5EgFXMKKYSrig
Author
Member

Delivery novox/hq@b525f1059b69 — merged since 2026-11-04T22:23:47Z

Source — source.main moved to novox/hq@f0c05d1edb. Whether it reached the machines is mesh-delivery-view's, derived from source.main, the wants and the haves.

Transitions

  • 2026-11-04 22:21 (new) → proposed (announced): novox/hq#515's head announced
  • 2026-11-04 22:21 proposed → ready (accepted): a verdict names this commit and the trunk's head as its trunk commit, the gate passed or warned, and the repository's own check did not fail; or the check gates no merge (check-gates-merge false)
  • 2026-11-04 22:23 ready → merged (merged): on the trunk its modules follow: merged there

The commit's note under refs/notes/mesh-plan keeps every transition of this change up to its merge: git log --notes=mesh-plan.

<!-- mesh-delivery:view --> **Delivery** `novox/hq@b525f1059b69` — **merged** since 2026-11-04T22:23:47Z **Source** — source.main moved to novox/hq@f0c05d1edb84. Whether it reached the machines is `mesh-delivery-view`'s, derived from `source.main`, the wants and the haves. **Transitions** - 2026-11-04 22:21 (new) → proposed (announced): novox/hq#515's head announced - 2026-11-04 22:21 proposed → ready (accepted): a verdict names this commit and the trunk's head as its trunk commit, the gate passed or warned, and the repository's own check did not fail; or the check gates no merge (check-gates-merge false) - 2026-11-04 22:23 ready → merged (merged): on the trunk its modules follow: merged there The commit's note under `refs/notes/mesh-plan` keeps every transition of this change up to its merge: `git log --notes=mesh-plan`.
jschoubben added 1 commit 2026-11-04 22:21:02 +00:00
Name the design section, not its number; the preparer and playbook 07 place new code the same way (review 1)
mesh/delivery merged: source.main moved to novox/hq@f0c05d1edb84
mesh/check being carried to b525f1059b69 on f0c05d1edb84 | from d4ae72782336
b525f1059b
Claude-Session: https://claude.ai/code/session_01JG73KJNrH5EgFXMKKYSrig
mesh-tools merged commit f0c05d1edb into main 2026-11-04 22:23:45 +00:00
mesh-tools deleted branch docs/placement-is-a-design-question 2026-11-04 22:23:45 +00:00
Sign in to join this conversation.
No Reviewers
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: novox/hq#515