claude-code: hold the review's findings on proposed instructions (hq ADR 0274)
mesh/merge-gate fail: builds claude-code → ace, g14, novox, shanks; no bus step; a manifest the change touches fails the module check: claude-code uses the…
mesh/repo-check pass: its merge-check.sh passed, each part in its toolchain: merge-check.sh (go), merge-check-typescript.sh (typescript)
mesh/delivery superseded: a newer head of the same pull request
mesh/merge-gate fail: builds claude-code → ace, g14, novox, shanks; no bus step; a manifest the change touches fails the module check: claude-code uses the…
mesh/repo-check pass: its merge-check.sh passed, each part in its toolchain: merge-check.sh (go), merge-check-typescript.sh (typescript)
mesh/delivery superseded: a newer head of the same pull request
An @ after any whitespace or punctuation, invisible and control characters, and top headings are refused; every node judges a proposal record as the module would have made it before applying an approval, never applies one older than its section's last change, never takes an unreadable record for an empty one, and keys a node section by its nodes. The controller records the warrant from the router's word alone.
This commit is contained in:
@@ -152,10 +152,10 @@ proves who answered (Telegram) carries either. The phone shows the whole text wh
|
||||
leave the mesh, else its first lines and a fingerprint; the whole text is read at the controller's terminal with
|
||||
`mesh-cli ask claude-code claude_code_proposals '{"id": "<id>"}'`. Decline, or no answer within a day, discards it.
|
||||
**Every node proves the approval itself**: it reads the router's own record of the ask under this module's name,
|
||||
composes the ask again from the proposal and holds the warrant to it (the same ask digest, the option's bound act,
|
||||
judges the record as this module would have made it, composes the ask again from the proposal and holds the warrant to it (the same ask digest, the option's bound act,
|
||||
the text's digest, in time), and only then writes the section into its own `approved.json`, which the managed
|
||||
instruction file renders under "Instructions the operator approved". A proposal is decided once per node; a record
|
||||
deleted from the bus removes nothing. Refused: shell lines, front matter, an `@` file reference, anything shaped like
|
||||
instruction file renders under "Instructions the operator approved". A proposal is decided once per node, and an approval older than the last change applied to its section is never applied; a record
|
||||
deleted from the bus removes nothing. Refused: shell lines, front matter, any `@` after a non-letter (a file the instruction file may read in), invisible or control characters, headings of level one to three, anything shaped like
|
||||
a secret, more than 16 KiB, a name the terminal sets, and — at once, naming the terminal's line — whenever no channel
|
||||
that proves its sender is there. The controller's hand-act log records each warrant once (`warranted`), read from the
|
||||
router's record. The text is never logged.
|
||||
|
||||
Reference in New Issue
Block a user