git:20260814.06fa906 to git:20260814.739f70b

+ # /03 — the machines find consensus by themselves

+ > 🧒 **When reporting to a non-technical owner:** finish with a simple "In plain words" recap (his rule [[eli5-always]]). Only in the message TO him.

+ The owner said "03" / "you handle it yourselves" → that is a MANDATE: the Claude peers negotiate among themselves and execute on their own. I do NOT ask for permission again — I **announce and go**. The owner is needed at exactly 2 gates (below).

+ **Argument:** `/03 <topic/decision>` — what to agree on. If there is no topic (a bare "03") — take the subject from the current conversation; if it is ambiguous, formulate the proposal from context yourself.

+ **Aliases:** `003` = `03` (the extra zero is ignored); case does not matter [[commands-case-insensitive]]. Do not confuse it with "02" — that is escalation TO the owner (the approval channel), the opposite direction.

+ ## Step 0 — Peer liveness ONLY from a live signal (pitfall 2026-07-04)

+ Before pinging a node or declaring "down/alive" — ask for a fact, don't guess from mtime:

+ Liveness = Syncthing `connected==True` **OR** a fresh `.tg-seen-<node>` (the Telegram rail). 🟡 = alive over Telegram, Syncthing flapped — that is NOT death. ⛔ NEVER judge by the mtime of file markers (`.read-*`, `.robot-done-*`, the presence of `log-<node>.jsonl`) — a Telegram-rail follower does not write them by design. Canon: [[peer-liveness-live-signal]].

+ ## Step 1 — A one-line announcement, WITHOUT waiting for a "yes"

+ Drop exactly one line to the owner and move on immediately (he can cancel, but I don't wait):

+ 🤝 unless you object, I'm going to agree this with <peers> over the coordination channel: "<topic>"…

+ `<peers>` = the other machines of the fleet (the hub `HUB-1`, the laptop `LAPTOP-1`, teammates' machines). Who is online is visible on the bus; an exact list is not critical, the engine broadcasts to everyone.

+ ## Step 2 — Determine the risk tier (this decides whether the owner is needed)

+ - **Tier-0/1** (safe, reversible: which machine runs a background job, scheduling, format choice, tagging, a dedup judgement) → the peers close it themselves.

+ - **Tier-2** (money · outbound sends · irreversible · secrets · editing the SHARED canon CLAUDE.md / the Bible / operating-agreement) → even with agreement it is NOT auto-committed, it goes to the owner via the approval flow.

+ In doubt — pick the higher tier (safer).

+ ## Step 3 — Open the proposal through the engine

+ - ⚠️ **FIRST check that no one else already has a thread on THIS action** (pitfall 07-17: the hub and the anchor independently opened #0eaf6c3c and #490b0384 for the same canon merge → a duplicate): `consensus.py pending` + `consensus.py list`. There is an open proposal from a peer for the same action → **reply into it** (`respond <id> accept/counter`), do NOT open your own alongside. Open a new one only if none exists.

+ python "%USERPROFILE%\.claude\scripts\consensus.py" propose "<ACTION in one line>" --details "<evidence/context>" --tier <0|1|2>

+ (Bash variant: `python "$USERPROFILE/.claude/scripts/consensus.py" propose "<action>" --details "<evidence>" --tier <N>`.)

+ - ⚠️ **The action goes into `"<subject>"`, the evidence/diagnostics into `--details`.** The tier tripwire scans ONLY the subject (the action) for stop-words, not the evidence. Dump diagnostics ("…laptop **sends**…", "**apikey** matches") into the subject and it will falsely raise the tier to 2 and wake the owner for nothing. Keep the subject short and about the action.

+ - The engine dual-sends the event into the coordination chat + `_machine-bus` (by construction; a single rail is forbidden) → the negotiation is visible in the chat.

+ - A Tier-2 propose is escalated to the owner BY THE ENGINE (`❓ QQQ=yes / NO=no`) and is NOT committed.

+ - Remember the `#id` from the output.

+ ## Step 4 — Negotiate to agreement

+ The other machine answers `respond <id> accept|counter|reject`. When I am the responding side, first run `pending` (a 0-LLM worklist of "what is waiting for MY answer"), then judge on the merits (cheap model groundwork, [[model-routing-sonnet-grunt]]) and answer with the same verb. Timeouts/rounds are driven by the deterministic `tick` (0-LLM, already inside the inbox robot; the timeout = the SLA of the slowest peer, a sleeping laptop/Mac is given longer than the hub):

+ ## Step 5 — Execute and cross-check (anti "works-on-my-machine")

+ - Agreed (status=agreed) and Tier-0/1 → `commit <id>` → **apply the real change** → `verify <id> "<evidence>"`.

+ - A task is globally done ONLY when BOTH machines independently post `VERIFY` (>=2). One peer saying "done" is not done.

+ ## Step 6 — The gates to the owner (exactly 2, otherwise without him)

+ ⛔ **I NEVER hand-write a question to the owner into a chat** — only through the `approval.py` engine [[remote-approval-qqq]]. A hand-written ask has no `#id`: `approval.py due` cannot see it (no re-ping and no escalation), and a later "+" from him has nothing to attach to — the answer falls through the crack between states (incident 07-21, the permission had to be entered by hand). I never hardcode chat ids in the skill: the engine takes the addresses from `~/.claude/approval.json → targets`.

+ **How an ask is minted:**

+ python "%USERPROFILE%\.claude\scripts\approval.py" ask "<what + why + risk> (consensus #<id>)" --cat <money|delete|outbound|secret|config|other>

+ → prints JSON `{id, ask_text, targets}`. `ask_text` is posted by **the calling session** (approval.py is a recorder, not a sender) to `targets` IN ORDER: the approval channel FIRST (a sterile "the owner's attention is needed" channel), then a mirror into the fleet log chat / WhatsApp / DM. I catch the answer with `approval.py check` (stdin = the replies from MCP) → `APPROVED/REJECTED/EXPIRED <id>`. A hanging ask is never abandoned: `approval.py due` prints re-ping envelopes — the same session or the inbox robot posts them to the approval channel. That also covers the "minted an id but never managed to post it" break: an unsent ask resurfaces as a `due` envelope within the freshness window (15 min) instead of dying silently.

+ **Ask dedup (otherwise two questions for one dispute):** before `ask`, check `approval.py pending` — if an open ask carrying this `consensus #<id>` already exists (it may have been minted by `tick` or by a peer), do NOT mint a second one. That is why the consensus id MUST appear in the ask text: it is the only link between the consensus thread and the question to the owner.

+ **Classification — what even deserves the approval channel** ([[remote-approval-qqq]] §Classification 07-14): **A** internal / fleet-reversible · **B** our content into our own channels · **C** a short, on-topic outbound message to a third party → I decide MYSELF as a co-founder, journal it into `approvals.db` and report after the fact — those do NOT go to the approval channel. Only **D** "the owner's physical hands are needed" (2FA/UAC/a password; phrase it as a click path, not "give me the go-ahead") and **E** categorically serious matters (money · irreversible deletion · secrets to third parties · legal commitments · mass mailing · a new peer) go there. In doubt between C and E → E.

+ **The gates (exactly two):**

+ 1. **A Tier-2 action of class D/E** → `escalate <id> "<why>"` records the STATE of the thread, but by itself it creates no trackable question → in the same move, mint an ask via `approval.py ask` (see above) and post its `ask_text`. A `QQQ`/`+` arrives from an authorized signer (the owner or one of the two co-signers) → `approve <id> "<who/where/msg-id>"` records the OK in the thread → only then `commit`.

+ 2. **The peers did not converge** within the round_cap (3) / a timeout on something above Tier-0 → first a **tie-break by the anchor node** (`ANCHOR-1` — the coordinator, the source of truth and the arbiter of cross-machine disputes). The anchor is dead / unable to arbitrate (leader-down >70 min → the hub becomes arbiter-for-this-tick) → and **only then** wake the owner through the same `approval.py ask` route.

+ - **Do NOT escalate:** a safe Tier-0 deadlock → the tie-break (disagree-and-commit) closes it by itself, don't bother the owner.

+ - ⚠️ On a round cap/timeout, `tick` may shout into the approval channel over its own rail — that does NOT replace the ask: it carries no `#id` from the approval engine. `tick` shouted → mint the ask through `approval.py` anyway, so the question has an id, a re-ping and a recorded answer.

+ ## Report to the owner (after the fact, briefly)

+ What was agreed · with whom · the verdict (✅ committed+verified / ⏳ waiting for approval / 🔴 dispute → over to you) · what was actually done. An "in plain words" line at the end.

+ ### Boundaries

+ - The Tier-2 hard stop holds: "you handle it yourselves" does NOT grant the right to spend money / send outbound / rewrite the canon on your own.

+ - Only the owner commits canon, through the hub [[machine-governance-leader-follower]].

+ - Failure modes (a byzantine peer, an auto-loop, a false VERIFY) are an open DR; until it closes we keep Phase 1 conservative.

+ - The engine is the single source of truth for state (`_machine-bus/_decisions/log-<MACHINE>.jsonl`); I don't duplicate its logic, I only call its verbs.