Answer develop's questions against a short list of principles, so a detail needs no design batch
The operator, 2026-11-11 about 21:30 CET: a living list of principles; the lead answers each question against it and does not register every detail. Adds 00-META/principles.md, the lead-answers file G-20 with A-1, and lets the developer take a lead answer from it. Claude-Session: https://claude.ai/code/session_01JG73KEq4zoDfM9WtYpcQgZ
This commit is contained in:
@@ -29,7 +29,7 @@ operator; never build otherwise.
|
||||
**A question the design does not answer stops that subtask.** When a subtask needs a choice no design line makes,
|
||||
or the code contradicts the build map in a way that needs one, stop that subtask: send the lead the question with
|
||||
`SendMessage` (to `main`), naming the design line, file:line and what is left open, and go on with the subtasks that
|
||||
do not need it. Never guess it, build around it or build both ways; an answer counts only once an hq commit holds it.
|
||||
do not need it. Never guess it, build around it or build both ways; an answer counts only once an hq commit holds it: a design line, or the lead's one-line answer in the milestone's lead-answers file, which names the principle (`00-META/principles.md`) that settles it.
|
||||
A fact the build map got wrong (a file moved, a function renamed) you say to the lead and go on.
|
||||
|
||||
**How you work.** Worktrees from `origin/main` on the branch the handover names, subtasks in the build map's order:
|
||||
|
||||
@@ -0,0 +1,30 @@
|
||||
---
|
||||
status: canonical
|
||||
updated: 2026-11-11
|
||||
---
|
||||
|
||||
# The principles
|
||||
|
||||
A short, living list. Every question met while building is tested against these principles and answered by the
|
||||
lead in one line; only a question no principle settles goes to the operator or to a decision record. A detail that
|
||||
a principle settles is not written down as a design line or a record. The list changes when the operator says so:
|
||||
add, sharpen or drop a principle in a pull request to this file.
|
||||
|
||||
1. **NATS-native.** Every interaction between modules is an event, or a call over the bus where an answer is
|
||||
needed. A module keeps its data in the bus's own storage, and reads another module's data only by asking it,
|
||||
through its verbs or its tools.
|
||||
2. **The mesh owns the truth.** State lives in the mesh and is written onto the nodes from there. Nothing is changed
|
||||
by hand on a node.
|
||||
3. **Failure is loud.** Nothing reports success when it did nothing, and nothing fails silently. When in doubt, fail.
|
||||
4. **A module is steered by its tools.** Everything a module holds can be read, everything it does can be started
|
||||
by hand, and everything that goes wrong can be recovered, all through its tools.
|
||||
5. **Everything ships the same way.** The mesh's own parts go through the same build, check and delivery as any app.
|
||||
6. **Nothing is exposed publicly.** No data leaves the mesh unasked: no secret in a record, a log or a public
|
||||
repository, no service reachable from outside unless it is meant to be. Inside the mesh, every agent and module
|
||||
is trusted; who may do what is not a question to ask.
|
||||
7. **The simplest thing that works.** Prefer what already exists. No new mechanism unless it is needed, and fewer
|
||||
parts over more.
|
||||
8. **One word per thing**, from the [glossary](glossary.md).
|
||||
|
||||
How it is checked: the one code review of a milestone checks the code against these principles and the design's
|
||||
shape; an answer to a develop question names the principle that settles it.
|
||||
@@ -0,0 +1,20 @@
|
||||
---
|
||||
layer: to-be
|
||||
status: in-progress
|
||||
design: 47
|
||||
milestone: G
|
||||
updated: 2026-11-11
|
||||
decisions:
|
||||
- "ADR 0667"
|
||||
---
|
||||
# 47, milestone G — the lead's answers to develop's questions
|
||||
|
||||
The operator, 2026-11-11 about 21:30 CET: a develop question is tested against [the principles](../../../00-META/principles.md)
|
||||
and answered by the lead in one line, without a design batch or a review round for a detail. Each answer here is one line,
|
||||
names the principle that settles it, and is cited as "design 47 G A-n".
|
||||
|
||||
- **A-1** (§686, §640, §687, §689; principle 7, principle 3) `views.FindingBody`'s accessors follow Go's idiom, `Kind()` and
|
||||
`SetKind(v)` per field; the subject is one pair, `Subject()` and `SetSubject(...)`, with its fields as plain values in the
|
||||
contract struct's order; the writer is given the generated contract's constructors for `finding-cleared`, `findings-stated`
|
||||
and `findings-asked` when it is made, never plain maps, so a contract mismatch fails at compile time; `Observed.Findings`
|
||||
and `Pending` hold `FindingBody` values.
|
||||
@@ -103,5 +103,6 @@ The part is eighteen files, each read whole, its design lines numbered across th
|
||||
- [G-17-develop-answers-seventh](G-17-develop-answers-seventh.md): develop's seventh batch: the operator's answers of 2026-11-11 15:14 to 15:42 CET (callers by class, the five parts' findings, the forge and image registry's other entries, the gate's kept data), how every part reads the catalog half per watched branch, and the refreshed build maps' questions (§610 to §676).
|
||||
- [G-18-fix-round-six-seven](G-18-fix-round-six-seven.md): the fix round of §587 to §676: the approval mark once no verb names its callers, the keeper's snapshots, the recovery module's verbs, the node-engine's kept entries, the gate before a marked verb's running, develop's D-16 to D-49, and a delivery's wait on another machine's network (§677 to §705).
|
||||
- [G-19-outside-wait-and-refusals](G-19-outside-wait-and-refusals.md): a delivery's wait on an outside cause, written whole once (§706, in place of §705), and the finding writer's own refusals in every bundle (§707, amending §580).
|
||||
- [G-20-lead-answers](G-20-lead-answers.md): the lead's one-line answers to develop's questions, each tested against the principles (A-1 on).
|
||||
|
||||
Design 34's milestone [every-event](../34-milestones/every-event.md) and design 46's milestone [7-approval-mark](../46-milestones/7-approval-mark.md) ship in milestone G's release, built in its repositories beside G's lines (lead-47, 2026-11-11 15:30 CET); where one of their lines and a line of G differ, G's later line holds and the other is corrected in place (§624 to §626).
|
||||
|
||||
@@ -47,6 +47,7 @@ every commit cites the design lines it builds: playbook 07's step 0b, held by it
|
||||
|
||||
| Question | Read |
|
||||
|---|---|
|
||||
| What do we test every question against? | [`00-META/principles.md`](00-META/principles.md) — the short, living list of principles |
|
||||
| What does this word mean? | [`00-META/glossary.md`](00-META/glossary.md) |
|
||||
| How do I do X in this repo? | [`00-META/process/`](00-META/process/) — the playbook index is in `00-overview.md` |
|
||||
| What was decided, and why? | the knowledge base, through the mesh MCP server: `knowledge-base.ask` with the question in plain words, `knowledge-base.get` with a record's number (`reasoning: true` for the why), `knowledge-base.holds` with a topic of the reading order ([`02-DECISIONS/README.md`](02-DECISIONS/README.md)) |
|
||||
|
||||
Reference in New Issue
Block a user