The actual documents the agents read and work from, shown exactly as they are on disk — not a summary. See the progress view instead · All projects
# PLAN — RULE-FILE TRIM — every rule stated once, where an agent will actually find it (2026-09-09 shape)
Owner: the Group E overseer. Written 2026-09-09 by Boris, the senior engineer, as a new lane of Nick's Life OS programme — there was no earlier plan for it. It exists because of one ruling Nick gave the same day: a ruling is written once, as one numbered paragraph, in the machine rules file, and nowhere else (RULE 21, 2026-09-09, adopted "yes"). Every number in this plan was measured tonight by the command written beside it.
**🔴🔴 THIS IS THE ONLY PLANNING DOCUMENT FOR THIS LANE. Do not create a second plan, tracker, summary, or scratch state file — extend THIS file or its PROGRESS.txt companion. Any status view is GENERATED from this plan; if a view disagrees with the plan, the plan wins.**
**NORTH STAR:** Nick gives a ruling once and every agent obeys that one version of it — because each rule is written once, numbered, in one paragraph, in one place, and nothing anywhere else says something different. Nick, 2026-09-09: *"i dont want agent writing notes without approval this shit piles up and becomes a prose dump"*.
**FINISH LINE:** each item passes its one check — (a) every rule of Nick's is a numbered heading and no number appears on two of them, and every document that cited a number whose meaning changed cites the new one; (b) the briefing a dispatched worker actually receives is between 8,000 and 14,000 characters and contains both of Nick's 2026-09-09 rulings by number, where tonight it is about 37,500 characters and contains only one of them; (c) the five rule files are smaller by a recorded number of bytes, and each instruction they carry is stated once with the other places replaced by the rule's number and date; (d) none of the five named documents this lane owns still teaches the closing shape retired on 2026-09-09 — the global rules file, the closing-format build plan, the two adopted proposal files and the board-enforcement prompt — and every document owned by someone else has had one line sent to its owner; (e) the nine per-lane notes files are gone and every ruling in them is either a numbered rule or a dated line under its lane's "Already true"; (f) all five named nightly guards pass, and no guard was made to pass by weakening what it asserts; (g) a reader who has never seen these files names five rules and where each one lives in under a minute. Written once, never raised mid-drive.
**Owner:** the Group E overseer · **Overseer:** ONE — Opus or Codex; never builds · **Design authority:** none — nothing here is looked at
**Rule: a step starts the moment its named inputs exist, whatever its number. A step closes on ONE independent check by a different model. Nothing waits on Nick to test.**
### STEP 0 — ARM THE LOOP, BEFORE ANYTHING ELSE
Set a 5-minute loop. Every time it fires, answer these four in order and CORRECT any failure before doing anything else:
1. **NORTH STAR** — is what I am doing this minute moving this plan's North Star? If not, drop it and take the highest-value unblocked step that does.
2. **FAN-OUT** — is every step whose START WHEN inputs exist running, up to the cap of 8? Below the cap with ready work: dispatch now. At the cap: queue, never launch.
3. **CHEAP** — is every build and every check on a cheap model by name? A router refusal is a failure to log (Nick, 2026-09-09), never a reason to promote the job to Sonnet or Opus; a cheap vendor failure goes to the named backup.
4. **BLOCKED** — is anything "waiting"? Re-read its START WHEN line; if the artefact exists, start it; if it truly does not, one line to the overseer naming the ONE missing thing, and on to the next step.
## Already true (facts, not story)
**DECIDED by Nick or Chantelle — never asked again:**
- A ruling is written once, as one numbered paragraph in the machine rules file, and nowhere else; every sentence elsewhere that says something different is deleted rather than annotated; no agent creates a notes file, summary or decisions document for a ruling; a plan cites the numbered rule by its number and date — RULE 21, Nick, 2026-09-09, adopted "yes"
- The cloud copy on the main line is the only record; a Mac, a branch, a worktree or a stash is never a second copy of record; when two copies disagree the later commit wins mechanically and nobody is asked — RULE 20, Nick, 2026-09-09
- A message Nick reads closes as one cold-read paragraph of what is now true, then a counted numbered list of only what needs him — Nick, 2026-09-09, "1 yes"
- A check is never made to pass by making it weaker — Rule 12, the gate is the standard
- No password, gate secret or login is ever rotated, and a weak one is never raised with him either — Rule 11
- Deleting a tracked file is not one of the four approval classes, because git holds every byte — evidence: reading the SKILLS lane's deleted notes file out of history at commit ea4fee21f5^ returns `866`, its stored size, AFTER step 6 removed it. That is the whole point: the bytes survive the deletion. This line cited the live path until 2026-09-10 and stopped resolving the moment the file went, so the evidence for "git holds every byte" was itself unrunnable.
**MEASURED tonight, 2026-09-09 — every number carries the command that produced it:**
- 🔴 THE RULES FILE IS BEING EDITED BY ANOTHER SESSION WHILE THIS PLAN IS WRITTEN, so every number below is a reading at a moment, not a constant: the machine rules file read 98,215 bytes, then 97,670 bytes about forty minutes later, with three "sync: working-tree snapshot" commits against it in between, and one rule's heading changed wording between two readings taken minutes apart. Every step therefore re-measures its target immediately before editing it, and no step anywhere in this plan cites a line number — evidence: `wc -c "/Users/nickdeck/Documents/Claude 2.0/projects/ops/MACHINE-RULES.md"` run twice, and `git -C "/Users/nickdeck/Documents/Claude 2.0" log --oneline -3 -- "projects/ops/MACHINE-RULES.md"`
- The five rule files total about 158,000 bytes: the rulebook 18,087 · the machine rules about 97,700 · the global rules 19,093 · the top-level instruction file 16,007 · the file standard 7,159 — evidence: `wc -c "/Users/nickdeck/Documents/Claude 2.0/RULEBOOK.md" "/Users/nickdeck/Documents/Claude 2.0/projects/ops/MACHINE-RULES.md" "/Users/nickdeck/Documents/Claude 2.0/GLOBAL-CLAUDE-RULES.md" "/Users/nickdeck/Documents/Claude 2.0/CLAUDE.md" "/Users/nickdeck/Documents/Claude 2.0/FILE-STANDARD.md"` returned 158,561 and then 158,010
- The briefing a dispatched worker actually receives is about 37,500 characters and does NOT contain Nick's newest ruling — evidence: `node -e "import('/Users/nickdeck/Documents/Claude 2.0/projects/ops/skippy-jobs/lib/dispatch-contract.mjs').then(m=>{const t=m.loadTravelBlock();console.log(t.length, t.indexOf('RULE 21') >= 0, t.indexOf('RULE 20') >= 0)})"` printed `37359 false true` and then `37509 false true`
- 🔴 THE MECHANISM BY WHICH THE NEWEST RULING FAILS TO TRAVEL, READ OUT OF THE LOADER'S OWN CODE AND NOT INFERRED — `projects/ops/skippy-jobs/lib/dispatch-contract.mjs`, the block loader: it walks the lines after the block's heading and (i) BREAKS at the first line beginning with `#`, (ii) KEEPS only lines beginning with `>`, stripping that marker, and (iii) BREAKS at the first blank line once it has started collecting. THREE CONSEQUENCES THAT GOVERN THIS WHOLE PLAN: a rule written as a markdown heading can NEVER travel inside the block, because its `#` terminates the block; an unquoted line is silently DROPPED rather than carried; and one blank line mid-block truncates everything after it. The newest ruling is unquoted and sits after a blank line, so it is dropped twice over — evidence: the loader's own lines, read 2026-09-09, and the probe above returning `false` for that ruling while the file itself plainly contains it
- 🔴 NOTHING THAT LOADS AUTOMATICALLY IMPORTS THE MACHINE RULES FILE. The top-level instruction file pulls in exactly two others, the rulebook and the file standard; the machine rules file is imported by nothing. So replacing a rule's WORDS with a bare pointer to that file would leave a session holding a reference and no rule — evidence: `command grep -n "^@" "/Users/nickdeck/Documents/Claude 2.0/CLAUDE.md"` returns two lines, naming `RULEBOOK.md` and `FILE-STANDARD.md` and nothing else
- 🔴 THE HEALTH GUARD SECTION SITS ABOVE THE HARD FLAGS, NOT BELOW THEM: the health guard heading is at line 24 and the hard-flags heading at line 43, so a fingerprint that starts at the hard flags EXCLUDES the health guard — the section carrying the standing frame that his own felt-state outranks any biometric reading. The fence in STEP 5 therefore starts at the four-guards heading, above all of it — evidence: `command grep -n "^### HEALTH|^## ⛔ HARD FLAGS|^## 🔴 THE OPERATING RULES" "/Users/nickdeck/Documents/Claude 2.0/CLAUDE.md"` returning 24, 43 and 99
- Eleven rules are stated as numbered headings, rules 11 through 21; the two rulings of 2026-09-09 have NO heading of their own — they sit inside the travel block as bold paragraphs already using the numbers 20 and 21, so each of those numbers names two different rules tonight — evidence: `command grep -oE "^#+ .*(RULE|Rule) [0-9]+" "/Users/nickdeck/Documents/Claude 2.0/projects/ops/MACHINE-RULES.md" | command grep -oE "[0-9]+$" | sort -n | uniq -c` returned one each of 11 through 21, and `command grep -oE "🔴 ?(RULE|Rule) [0-9]+ [—(]" "/Users/nickdeck/Documents/Claude 2.0/projects/ops/MACHINE-RULES.md" | sort | uniq -c` returned both a heading and a block paragraph for 20 and for 21
- The two sides of the colliding number are cited in a similar number of tracked files — 14 in upper case, 17 in mixed case — so which side is renumbered must be decided by a citation count taken at build time and not by preference — evidence: `git -C "/Users/nickdeck/Documents/Claude 2.0" grep -l "RULE 21" | wc -l` and the same for `"Rule 21"`
- The health safety section of the top-level instruction file is 4,233 bytes and fingerprints to `60f7e0707a13bb282b95f0a25c90247e1b65b3792efdd51ae1449a99ce0a72b3`, identical across two consecutive readings, so it is a usable before-and-after test — evidence: `sed -n '/## ⛔ HARD FLAGS/,/^## 🔴 THE OPERATING RULES/p' "/Users/nickdeck/Documents/Claude 2.0/CLAUDE.md" | shasum -a 256` run twice
- One instruction is stated four times over and another eleven times: the four approval classes appear once in each of four files, and the data floor appears twice in the top-level instruction file and nine times in the machine rules file — evidence: `git -C "/Users/nickdeck/Documents/Claude 2.0" grep -c "money leaving" -- RULEBOOK.md GLOBAL-CLAUDE-RULES.md CLAUDE.md projects/ops/MACHINE-RULES.md` and the same for `"financials"`
- Nine per-lane notes files hold 20,699 bytes of Nick's dated rulings — evidence: `wc -c "/Users/nickdeck/Documents/Claude 2.0/projects/ops/life-os/REGROUP-2026-09-08/plans/"*/NOTES-FROM-NICK.txt`
- 55 tracked files still carry the closing heading retired on 2026-09-09, of which the great majority are archives, evidence records, logs, guard fixtures and design mockups rather than live instructions — evidence: `git -C "/Users/nickdeck/Documents/Claude 2.0" grep -l "WAITING ON YOU"`
- All five named nightly guards pass right now, before anything is trimmed — evidence: `node "/Users/nickdeck/Documents/Claude 2.0/projects/ops/skippy-jobs/_test-4d-recap-rules.mjs"` exit 0, first line "ok the adopted closing-message rule is present and bounded", and the four beside it in §6
- Sixty-two guard files read the machine rules file and twelve read one of the other four — evidence: `git -C "/Users/nickdeck/Documents/Claude 2.0" grep -l "MACHINE-RULES" -- "projects/ops/skippy-jobs/_test-*.mjs" | wc -l`
- Every file path the four smaller rule files point at exists on disk; there is nothing dangling to chase — evidence: each path tested individually with `test -f`, 2026-09-09
- The global rules file is the one every session on this Mac loads, through a link in the home folder — evidence: `ls -la /Users/nickdeck/.claude/CLAUDE.md` shows the link pointing at it
- The plan checker accepts a path with any extension, so this lane's `.txt` plan can be checked directly — evidence: read of `projects/ops/agents/check_plan.py`, which takes `sys.argv[1]` as a path and never tests its suffix
## 0 · Gate Zero receipts (the plan may not exist without these)
- Failure Mode Registry loaded: 2026-09-09, 193 entries; the ten this lane is exposed to are named in §4, each with this plan's measure
- Canonical specs loaded: the plan skill (2026-09-09 shape) and its template, `projects/ops/agents/CODE-STANDARD.md`, `projects/ops/MACHINE-RULES.md` (indexed by heading, never read whole), `FILE-STANDARD.md`'s length-by-load-frequency rule
- Ownership check: no plan governed this work before; `projects/ops/life-os/REGROUP-2026-09-08/plans/RULE-TRIM/` held only the planner brief. The rules themselves are owned by `projects/ops/MACHINE-RULES.md`, which is EXTENDED in place and never duplicated; the closing-format documents already exist and are reduced rather than replaced; no new store, checker, ledger or notes file is created by this plan
- Expected inputs confirmed to exist: all five rule files (byte counts above), the travel-block loader `projects/ops/skippy-jobs/lib/dispatch-contract.mjs` (probed twice), the ticket tool `projects/ops/skippy-jobs/lib/request-ticket.mjs` (usage line read), the plan checker `projects/ops/agents/check_plan.py` (read), the scaffolding checker `ZION/lib/check-no-scaffolding.mjs` (run), the agent-file generator `projects/ops/agents/build_agents.py` and its roster (both present), the five named guards (all run, all green), the nine notes files (sizes above)
- PLAN AUTHOR: Boris, the senior engineer, the session of 2026-09-09
- COLD READER: none — SINGLE-AUTHOR, UNREVIEWED — the Group E overseer's pickup read is this plan's one cold read; nothing here is rendered, so the visual exception does not apply
- PROMPT-SPEC scan (P1–P7): P3 fired on the planner brief's own numbers — three of them had already moved by the time they were re-measured (the machine rules file read 98,215 bytes rather than 100,325; the worker's briefing 37,359 characters rather than 37,753; the retired closing heading appears in 55 tracked files rather than 26, the smaller figure having been a scoped count). Resolved by re-measuring everything, by writing no line number into any step, and by having every step re-measure immediately before editing. P1 fired on "the travel block cut to what a subagent needs" — resolved as the ten named things listed in STEP 2, with a character range as the test. P1 fired again on "delete every duplicate or contradicting sentence" — resolved as: the rule is stated once in the machine rules file and every other place carries its number and date instead of its words.
## 1 · Goal and definition of done
- **What we're building, one paragraph.** One numbered list of rules that each say their thing once, in one paragraph; a much shorter briefing that a dispatched worker actually receives whole, with Nick's newest rulings inside it; four smaller rule files that cite those numbers instead of restating them in their own words; nine scratch notes files emptied into the numbered list and deleted; and a fresh reader who can find any of it in under a minute. Cheap models write every trimmed word, a reader who has never seen the files cold-reads the result, and the overseer runs the guards.
- **HOW IT'S USED:** every session reads these files at start-up, and every dispatched worker receives the travel block inside its brief; Nick reads none of them, but every agent he talks to is behaving according to them. · HOW WE KNOW: the link in the home folder proves the global file loads on this Mac; the loader probe proves what a worker actually receives, and its character count.
- **WHAT IT LOOKS LIKE:** a numbered list where each entry is one dated paragraph and no number appears twice; a briefing block of 8,000 to 14,000 characters carrying ten named things and nothing else; four smaller files whose overlapping sentences have become a rule number and a date. · HOW WE KNOW: the byte and character counts are the tests, run before and after and recorded in the lane's evidence folder.
- **WHERE IT LIVES:** `projects/ops/MACHINE-RULES.md` (the numbered rules and the travel block), `RULEBOOK.md`, `GLOBAL-CLAUDE-RULES.md`, `CLAUDE.md` and `FILE-STANDARD.md` at the top of the workspace — opened by every agent session, and by the Group E overseer while this lane runs. · HOW WE KNOW: byte counts measured tonight on each; the top-level instruction file pulls the rulebook and the file standard in at two `@` lines, so a session loads about 41,300 bytes of rules before the machine rules file is opened at all.
- **WHAT IT MUST DO:** (1) name each rule with a number no other rule uses, give every rule a heading of its own, and update every document that cited a number whose meaning changed; (2) carry, in the briefing a worker receives, exactly these ten things and nothing more — plain English because Nick is not a developer, the four approval classes, the data floor of four items, the closing shape, find the plan before you start, an agent's pasted output is a claim until re-run, prove an assumption before bringing it to a person, use the search command that is not shadowed by ignore rules, the cloud-is-the-record ruling and the write-a-ruling-once ruling by number and date, and the seven housekeeping rules — with no unquoted blank line inside it so the loader carries all of it; (3) state each instruction once and replace every other statement of it with that rule's number and date; (4) stop teaching the retired closing shape in any document this lane owns, and hand one line to the owner of every document it does not own; (5) empty the nine notes files into the numbered list or their lane's "Already true" line, then delete them; (6) keep every named guard passing without loosening a single assertion; (7) let a reader who has never seen the files find five named rules in under a minute.
- **NOT in scope:** the ANTI-SCOPE — (a) the six health hard flags and the four guard sections of the top-level instruction file: not one byte of them changes, and STEP 5's proof is a fingerprint of that section recorded before and compared after, because a trim that touches safety content is worse than no trim at all; (b) security and privacy work of any kind, including the credential and gate-secret sentences in these very files — one line in `projects/ops/sp-sec/PLAN.md` and back to work (Nick, 2026-09-09), and Rule 11 forbids even raising a credential concern; (c) archived copies, evidence records, logs, captured state and design mockups that mention the retired closing shape — a record of what an agent did then is history, and history stays where it is; (d) the ten lane handoff prompts and the two other projects' plan files that still teach the retired shape — each is handed to its owner in §3c with one sentence, never edited here; (e) writing a second rules store, index, database, dashboard or nightly byte-count job — the numbered list is the one place, extended in place; (f) root-causing how the retired shape spread to 55 files — remove it where this lane owns it and move on; (g) rewriting the rules themselves: this lane changes where a rule is written and how many times, never what it says. Where a trim would change a rule's meaning, the step stops and writes the contradiction into this plan instead.
- **Trip-over protocol:** a lane that finds something outside the fence writes one handover line to its named owner (a security- or privacy-shaped thing: one line in `projects/ops/sp-sec/PLAN.md`), then back to building — never investigates, never fixes.
## 1a · Critical variables — the confirmation sheet is GENERATED from this table
| # | The variable, in plain words | Value chosen | Alternatives rejected | Class | HOW WE KNOW | Cost if wrong | CONFIRMED |
|---|---|---|---|---|---|---|---|
| 1 | **SURFACE — which screen this lands on, and who opens it** | no screen: the five rule files themselves, opened by every agent session at start-up and by every dispatched worker inside its brief; Nick opens none of them and sees the result only as agents behaving consistently | a page on the Hub showing the rules; a rules dashboard; a chat command that reads them out | V1 | Nick asked for the pile of notes to stop, not for something to look at; the loader probe and the home-folder link show exactly who reads what | the work lands somewhere nothing reads, and every agent keeps loading the old text | Nick, 2026-09-09, "i dont want agent writing notes without approval this shit piles up and becomes a prose dump" |
| 2 | Where a ruling is written | one numbered paragraph in the machine rules file, and nowhere else; every other place cites its number and date | a notes file per lane; a decisions document; a summary beside each plan | V1 | RULE 21 as he adopted it | the pile he asked to end grows back under a new name | Nick, 2026-09-09, adopted RULE 21 with "yes" |
| 3 | What happens to a sentence that now says something different | it is deleted; never annotated, never preserved as a quotation — the reason a rule exists is restated as a live sentence instead | marking it as history and leaving it on the page; keeping the dead wording so it cannot quietly return | V1 | RULE 21 as adopted, and the commit-time checker that already refuses retired wording left in a document | a reader obeys a dead rule because it is still on the page | Nick, 2026-09-09, adopted RULE 21 with "yes" |
| 4 | Which side of a colliding number is renumbered | whichever side has FEWER live citations, counted by command at build time and recorded before the edit — never chosen by preference | always renumbering the newest; always renumbering the oldest | V2 | the raw case counts came back close, at 14 and 17, so case says nothing about which rule was meant and the count must be by meaning | every plan and memory note quoting the busier number silently points at the wrong rule | opened `projects/ops/MACHINE-RULES.md`, 2026-09-09, saw: rules 11–21 as numbered headings plus two unnumbered 2026-09-09 rulings already using 20 and 21 |
| 5 | Whether deleting a tracked notes file needs Nick's approval | no — it is not one of the four approval classes, because git holds every byte and the file is recoverable | treating it as irreversible destruction and waiting for his tap | V2 | the stored size of a file still in history came back from git, so nothing is destroyed by removing it from the working copy | the lane stalls overnight on an approval nobody needed to give | opened git history, 2026-09-09, saw: the notes file's stored size returned from `HEAD` as `866` |
| 6 | What the shortened briefing must still carry | ten named things in full, in one continuous run with no unquoted blank line inside it | a pointer to the file instead of the text; a shorter list chosen by whoever edits it | V2 | the dispatch gate accepts either the block or a pointer, so the size is a cost choice and not a gate requirement; the loader stops at the first unquoted blank line, which is why the newest ruling does not travel today | a worker is dispatched without the rule it is about to break, exactly as happens tonight | opened `projects/ops/skippy-jobs/lib/dispatch-contract.mjs` and probed it twice, 2026-09-09, saw: about 37,500 characters delivered, the newest ruling absent both times |
- V1 confirmation reads `<name>, <date>, "<their own words>"` — the date is required.
- V2 confirmation reads `opened <what>, <date>, saw: <what was actually there>`.
**Considered and ruled NOT critical:**
- `which cheap vendor writes which file` — the model matrix decides it; a wrong pick costs one failover, not a different outcome.
- `the exact byte target per file` — the test is that each instruction is stated once; the byte drop is the evidence of that, not the goal, and a file that got smaller while still saying something twice has failed.
- `whether the numbered list is renumbered from one` — no: it is not, because every existing citation would break for no gain. Only a colliding number moves.
## 1b · Subproject decomposition — could a piece of this ship on its own?
**SINGLE SUBPROJECT:** every part of this depends on the numbering being settled first, and all five files are read together by one session, so a half-trimmed set is worse than an untrimmed one — nothing here reaches a person on its own.
**Carve-out rule:** the documents this lane does not own — the ten lane handoff prompts, two further lane files, and two other projects' plan files, all of which still teach the retired closing shape — are named with their owners in §3c in this same edit, and none of them is left ownerless.
## 2 · The complete UX map (this becomes the test manifest verbatim)
| Id | Screen / entry point | State (default·empty·error·loading) | Element / interaction | Expected behavior | Navigation from → to |
|---|---|---|---|---|---|
| R1 | A fresh agent session starting in this workspace | default | the rule files load | the session holds one version of each rule; no two statements of one instruction disagree | start-up → working |
| R2 | A dispatched worker receiving its brief | default · loader stops early | the travel block inside the brief | the worker receives 8,000 to 14,000 characters containing all ten named things, including both 2026-09-09 rulings by number | dispatch → worker |
| R3 | An agent looking for the rule that governs what it is about to do | populated · not found | the numbered list | exactly one entry answers, found by its number; no number returns two answers | question → one rule |
| R4 | An agent quoting a rule by number in a plan | default | the citation | the number it quotes names one rule, and the same rule the reader will find | plan → rule |
| R5 | An agent about to close a message to Nick | default | the closing-shape rule | one live statement of it, in one place; nothing teaches the shape retired on 2026-09-09 | message → sent |
| R6 | An agent that has just received a ruling from Nick | default | where to write it | one numbered paragraph in the machine rules file behind a filed ticket; no notes file is created | ruling → one rule |
| R7 | The nightly guards, after the trim | pass · fail | each named guard | every guard passes, and each still fails when its subject is broken — no assertion was loosened to get there | clock → green |
| R8 | The three Macs, at the start of a session | default | the linked global rules file | each machine's session reads the trimmed file, and the link still points at it | machine → rules |
| R9 | A reader who has never seen these files, asked for five named rules | default | the numbered list and the four smaller files | five rules named with where each lives, in under a minute, without opening a search | cold reader → answers |
## 2d · DESIGN FIDELITY GATE (plan skill §D — mandatory when the deliverable is looked at)
DESIGN FIDELITY GATE: N/A — nothing rendered. This lane produces only instruction text that agents read; no screen, no generated page, no viewport, so there is no locked target and no anchor map to sign. The equivalent measured bar is the character and byte count of what a reader actually receives, in §6.
## 3 · Lanes and frozen contracts
| Lane | Scope (in / out) | Owner | Definition of done | Builder (cheap, named) | Backup builder | Checker (different model) | Backup checker |
|---|---|---|---|---|---|---|---|
| Numbering | the numbered list in the machine rules file: collisions resolved, the two 2026-09-09 rulings given headings, citations updated / out: changing what any rule says | this lane | R3 and R4 pass, zero colliding heading numbers | GLM 5.3 (zai) | DeepSeek | Qwen | Sonnet |
| The worker briefing | the travel block: cut to the ten named things, one continuous run, both newest rulings inside / out: the loader's own code, the dispatch gate | this lane | R2 passes at 8,000–14,000 characters | DeepSeek | Qwen | GLM 5.3 (zai) | Sonnet |
| The four smaller files | the rulebook, the global rules, the top-level instruction file, the file standard: each instruction stated once, retired wording removed / out: the six health hard flags and four guard sections, untouched | this lane | R1 and R5 pass, byte drops recorded per file | GLM 5.3 (zai) | Qwen | DeepSeek | Sonnet |
| The notes files | the nine per-lane notes files: rulings moved into the numbered list or their lane's "Already true", then deleted / out: any other file in those lane folders | this lane | R6 passes, nine files gone, every ruling landed | Qwen | DeepSeek | GLM 5.3 (zai) | Sonnet |
| Polish | the guards' fixture text, the closing-format documents, the three Macs' link, close-out / out: anything new | this lane | R7 and R8 pass and the lane closes | DeepSeek | GLM 5.3 (zai) | Qwen | Sonnet |
**Contracts between lanes (FROZEN at plan time — change = dated PLAN-CHANGES.md delta):** the machine rules file is written by ONE step at a time and never by two in the same hour — the numbering step closes before the briefing step opens, because both edit that file · a rule's WORDS are never changed by this lane, only their location and count; a trim that would change a meaning stops and writes the contradiction into this plan · every write to the machine rules file is preceded by a filed ticket, whatever the documentation gate's state, because Nick's own ruling requires his tap on that file · no new file is created anywhere by this plan except the lane's own evidence records · the ten lane handoff prompts, the two further lane files and the two other projects' plan files belong to their named owners in §3c and are never edited here · every cheap job naming an existing file is preceded by a fingerprint and a copy of that file into the lane's evidence folder, because a cheap-task revert can delete a pre-existing target.
**How a step is executed, since the cheap lane cannot run anything:** the cheap builder has four tools — list, read, search, write. It WRITES the trimmed text and runs no command at all. The overseer's exerciser RUNS every proof and saves its output into the lane's evidence folder. The cheap checker READS that saved output and the change itself. Every step below is written that way; a step that would need the builder to run a command is split.
**Data floor, binding:** the only reasons a file stays off a cheap vendor are a login, a credential or token or key VALUE, a government ID, or a card, bank or routing number — and the refuser must prove the hit. These rule files contain the WORDS credential, password, key, secret and vault in prose and in rule titles, and not one credential VALUE; a wall refusing them on those words is logged as a failure in PROGRESS.txt and the job goes to the named backup vendor, never to Sonnet or Opus.
## 3b · Execution map — FRONT first, POLISH last, one row per step
A task is DONE only when its review-ledger row is CLOSED by a reviewer that is not the builder.
**Step map (read this first) — FRONT rows are what changes how every agent behaves; POLISH rows run after the FRONT rows close, or the moment one bites:**
| Stage | # | TIER | Task (step name) | FOR NICK | Needs (named artefact, or `none — start now`) | EXECUTOR (cheap model) | EXECUTOR BACKUP | CHECKER (different model) | CHECKER BACKUP | DONE-PROOF (runnable command) |
|---|---|---|---|---|---|---|---|---|---|---|
| Numbering | 1 | FRONT | One numbered list, no number naming two rules: the two rulings of 2026-09-09 become headings of their own, the busier side of each collision keeps its number, and every document citing a number whose meaning changed is updated in the same edit | when you say "rule twenty" there is exactly one thing it can mean, and the agent quoting it back to you means the same one | none — start now | GLM 5.3 (zai) | DeepSeek | Qwen | Sonnet | `command grep -cE "^#+ .*(RULE\|Rule) [0-9]+" "/Users/nickdeck/Documents/Claude 2.0/projects/ops/MACHINE-RULES.md"` prints `13`, then the same search piped through `command grep -oE "[0-9]+$" \| sort -n \| uniq -d \| wc -l` prints `0` |
| The worker briefing | 2 | FRONT | The briefing a dispatched worker receives cut to the ten named things and made one continuous run, so the loader carries all of it and both of your 2026-09-09 rulings arrive with every worker | every agent you set going tonight is missing your newest ruling; after this it arrives with all of them, and reads a briefing a third of the length | STEP 1 closed — the block cites rule numbers, and the same file must not be written by two steps at once | DeepSeek | Qwen | GLM 5.3 (zai) | Sonnet | `node -e "import('/Users/nickdeck/Documents/Claude 2.0/projects/ops/skippy-jobs/lib/dispatch-contract.mjs').then(m=>{const t=m.loadTravelBlock();console.log(t.length, t.indexOf('RULE 21') >= 0, t.indexOf('RULE 20') >= 0)})"` prints a length between 8000 and 14000 followed by `true true` |
| The four smaller files | 3 | FRONT | The rulebook and the file standard: numbered rules put back in numeric order, retired wording removed with its reason restated as a live sentence, and every rule they restate in their own words replaced by that rule's number and date | the two files every session loads stop saying the same thing three different ways, so an agent cannot pick the version it likes | none — start now | GLM 5.3 (zai) | Qwen | DeepSeek | Sonnet | `wc -c "/Users/nickdeck/Documents/Claude 2.0/RULEBOOK.md" "/Users/nickdeck/Documents/Claude 2.0/FILE-STANDARD.md"` prints both files below their recorded starting sizes of 18,087 and 7,159, and `node "/Users/nickdeck/Documents/Claude 2.0/projects/ops/skippy-jobs/_test-data-rules-live.mjs"` exits 0 |
| The four smaller files | 4 | FRONT | The global rules file — the one all three Macs read: its dated status notes reduced to what is true now, the retired closing heading described instead of reproduced, and every restated rule replaced by its number and date | the file every one of your machines loads at the start of every session stops carrying month-old status notes as if they were current | none — start now | GLM 5.3 (zai) | DeepSeek | Qwen | Sonnet | `wc -c "/Users/nickdeck/Documents/Claude 2.0/GLOBAL-CLAUDE-RULES.md"` prints below the recorded starting size of 19,093 and `node "/Users/nickdeck/Documents/Claude 2.0/projects/ops/skippy-jobs/_test-4d-recap-rules.mjs"` exits 0 |
| The four smaller files | 5 | FRONT | The top-level instruction file: the retired-bridge note and every duplicated statement deleted, with the six health hard flags and the four guard sections proven byte-identical before and after | your health safety rules are provably untouched, and the rest of that file stops repeating what the numbered list already says | STEP 1 closed — this file cites rule numbers | Qwen | DeepSeek | GLM 5.3 (zai) | Sonnet | `sed -n '/## ⛔ HARD FLAGS/,/^## 🔴 THE OPERATING RULES/p' "/Users/nickdeck/Documents/Claude 2.0/CLAUDE.md" \| shasum -a 256` prints `60f7e0707a13bb282b95f0a25c90247e1b65b3792efdd51ae1449a99ce0a72b3`, and `command grep -c "^### HEALTH\|^### OWNERSHIP\|^### COACHING\|^### FRESHNESS" "/Users/nickdeck/Documents/Claude 2.0/CLAUDE.md"` prints `4` |
| The notes files | 6 | FRONT | The nine per-lane notes files emptied and deleted: each standing rule staged as one numbered paragraph for STEP 2's owner to land, each lane-specific ruling written as one dated line under that lane's "Already true", each lane's overseer given one line saying what moved where, and only then the notes file deleted | the nine scratch files holding your rulings are gone, and every ruling in them is somewhere an agent will actually read | the sorting and hand-offs start now; the deletions need STEP 2 closed, and this step never writes the machine rules file itself | Qwen | DeepSeek | GLM 5.3 (zai) | Sonnet | `ls "/Users/nickdeck/Documents/Claude 2.0/projects/ops/life-os/REGROUP-2026-09-08/plans/"*/NOTES-FROM-NICK.txt 2>/dev/null \| wc -l` prints `0` |
| Cold read | 7 | FRONT | The cold-read test: a reader who has never seen these files is asked to name five rules and where each one lives, and times itself | proof that a new agent can find your rules instead of guessing at them | STEP 1 to STEP 6 closed | Sonnet, as the fresh reader | Qwen | GLM 5.3 (zai), a second fresh reader | DeepSeek | `<the cold-read record this step writes into the lane's evidence folder>` — a placeholder because it cannot be run tonight: it needs the trimmed files, which do not exist until STEP 6 closes |
| Polish | 8 | POLISH | The guards kept honest: every fixture that quotes rule text updated to the trimmed text, every named guard green, and each one proven to still fail when its subject is broken | nothing you notice; the nightly checks keep catching a rule going missing instead of quietly passing | STEP 1 to STEP 6 closed | DeepSeek | GLM 5.3 (zai) | Qwen | Sonnet | `node "/Users/nickdeck/Documents/Claude 2.0/projects/ops/skippy-jobs/_test-4d-recap-rules.mjs" && node "/Users/nickdeck/Documents/Claude 2.0/projects/ops/skippy-jobs/_test-data-rules-live.mjs" && node "/Users/nickdeck/Documents/Claude 2.0/projects/ops/skippy-jobs/_test-check-closing-message.mjs" && node "/Users/nickdeck/Documents/Claude 2.0/projects/ops/skippy-jobs/_test-category-list-divergence.mjs" && node "/Users/nickdeck/Documents/Claude 2.0/projects/ops/skippy-jobs/_test-worktree-fence.mjs"` exits 0 |
| Polish | 9 | POLISH | The closing-format documents retired: the two adopted proposal files and the closing-format build plan reduced to one line each pointing at the numbered rule, and the one instruction prompt this lane owns stops teaching the retired shape | nothing you notice; three large documents about a rule you already adopted stop competing with the rule | STEP 4 closed | DeepSeek | Qwen | GLM 5.3 (zai) | Sonnet | `wc -c "/Users/nickdeck/Documents/Claude 2.0/projects/ops/CLOSING-FORMAT-BUILD-PLAN.md" "/Users/nickdeck/Documents/Claude 2.0/projects/ops/CLOSING-MESSAGE-RULE-PROPOSAL-2026-08-16-fable-review.md" "/Users/nickdeck/Documents/Claude 2.0/projects/ops/CLOSING-MESSAGE-RULE-PROPOSAL-2026-08-16-opus-review.md"` prints each below 1,200 bytes |
| Polish | 10 | POLISH | The three Macs read the trimmed file: the link checked on each machine that can be reached, and any machine that cannot be reached named rather than assumed | nothing you notice; all three of your machines are reading the same trimmed rules | STEP 4 closed | GLM 5.3 (zai) | DeepSeek | Qwen | Sonnet | `ls -la /Users/nickdeck/.claude/CLAUDE.md` shows the link pointing at the global rules file, and the same command run over the reachable machines returns one line each |
| Polish | 11 | POLISH | Close-out: the finish line checked item by item against the closed steps, the postmortem written into this file, and everything this lane left on the Mac removed and declared | you get one line saying the rules are trimmed, and nothing else to read | STEP 1 to STEP 10 closed | GLM 5.3 (zai) | DeepSeek | Qwen | Sonnet | `python3 "/Users/nickdeck/Documents/Claude 2.0/projects/ops/agents/check_plan.py" "/Users/nickdeck/Documents/Claude 2.0/projects/ops/life-os/REGROUP-2026-09-08/plans/RULE-TRIM/PLAN.proposed.txt"` exits 0 with every §3b row carrying a dated VERIFIED line |
### §3c · CUT — overkill for the outcome, or owned by someone else; recorded once and not worked
**Handed to their owners, with one sentence each, and never edited by this lane:**
- The ten lane handoff prompts that instruct an overseer to close every report in the shape retired on 2026-09-09 — HUB, BRAINS, AGENTS, SKILLS, FILES, LANE-1-WORKSHOP, LANE-6-FAMILY-APP, SKIPPY, VOICE and JASMIN-CAPTUS: each lane's own overseer replaces that one sentence with the adopted shape the next time it edits its prompt. One dated line goes into each lane's plan file from STEP 6.
- Two further lane files carrying the same instruction — the Larry-and-Benito fix note under the AGENTS lane and a step-8 checker record under the BRAINS lane: their lanes' owners, same one sentence.
- Two other projects' plan files carrying it — the continuity plan and the retirement plan: one line each to those projects' owners, because one project has one governing file and this lane does not own theirs.
**Overkill, not worked:**
- A machine-readable rules store, index, database or dashboard — the numbered list in one file IS the outcome, and a second copy is the disease this lane is curing.
- A nightly job that re-measures every rule file's size — the byte counts are a one-time proof of a one-time trim, not a standing clock; the existing guards already fail if a rule goes missing.
- Root-causing how the retired closing shape reached 55 files — remove it where this lane owns it and move on.
- Editing archives, evidence records, logs, captured state and design mockups that mention the retired shape — a record of what happened is history and stays as it is.
- A second cold read after the first passes, or a checker of the cold reader — one independent check closes a step.
- Rewriting the rules themselves into better prose — out of scope by §1; this lane changes where and how often a rule is written, never what it says.
**Then one block per step, in this exact shape:**
### STEP 1 — One numbered list, no number naming two rules
**FOR NICK:** when you say "rule twenty" there is exactly one thing it can mean, and the agent quoting it back to you means the same one. · **Tier:** FRONT
**Start when:** none — start now.
**Builder:** GLM 5.3 (zai) · **Builder backup:** DeepSeek · **Checker:** Qwen, a different session · **Checker backup:** Sonnet
**Files you may touch:** `projects/ops/MACHINE-RULES.md` (the numbered headings and the rules they hold), and the documents the citation count names as citing a number whose meaning changed. **Never** the travel block itself (STEP 2 owns it), the four smaller rule files (STEP 3, STEP 4, STEP 5), the six health hard flags anywhere, any guard file (STEP 8).
**Do exactly this:**
1. Before any edit, the overseer's exerciser fingerprints and copies the file into the lane's evidence folder, and records the current heading count and collision count with the step's proof commands. A cheap-task revert can delete a pre-existing target, so the copy exists before the job is dispatched.
2. The exerciser counts, for each colliding number, how many tracked files cite it in each of its two MEANINGS — not merely in each letter case, because the raw case counts came back close tonight at 14 and 17 and case says nothing about which rule was meant — and writes both counts into the lane's evidence folder. The side with FEWER citations is the side that gets a new number; the counts are recorded before the choice, not after.
3. The cheap builder WRITES, and runs nothing: THE TWO RULINGS OF 2026-09-09 TAKE THE NEXT FREE NUMBERS, 22 AND 23, each as a numbered heading of its own with its words and its date exactly as they are. This direction is fixed here rather than left to a citation count, because renumbering either of the existing headings 11 through 21 would break citations across the workspace for no gain, and 22 and 23 are unused. The existing headings 11 through 21 are not renumbered at all.
4. The same builder then updates every document that cites the number 20 or the number 21 MEANING one of the two 2026-09-09 rulings, changing it to 22 or 23 and leaving the surrounding sentence untouched. A citation of 20 or 21 meaning the older rule of that number is correct already and is not touched. The exerciser's citation list from item 2 is the work list; where a citation's meaning cannot be told from its sentence, it is left alone and named in PROGRESS.txt rather than guessed.
5. NO RULE IS GIVEN A HEADING INSIDE THE TRAVEL BLOCK. A line beginning with `#` terminates the block for every worker downstream, so the numbered headings live in the numbered list and the block carries its own one-sentence statement of each rule — see STEP 2.
6. The overseer files the ticket for the machine-rules write the moment the text is drafted — `node projects/ops/skippy-jobs/lib/request-ticket.mjs projects/ops/MACHINE-RULES.md --reason "..."` — and keeps working the other steps while it is out. This happens whatever the documentation gate's state, because Nick's own ruling requires his tap on this file; recording "needs Nick's keystroke" without filing it is a failure.
7. The exerciser runs the proof and saves its output into the lane's evidence folder; the checker reads that file and the change.
**DEFINITION OF DONE:** the two rulings of 2026-09-09 are numbered headings 22 and 23 with their words and dates unchanged, no number appears on two headings, headings 11 through 21 are untouched, and every document that cited 20 or 21 meaning one of those two rulings now cites 22 or 23.
**PROOF:** `command grep -cE "^#+ .*(RULE|Rule) [0-9]+" "/Users/nickdeck/Documents/Claude 2.0/projects/ops/MACHINE-RULES.md"` → `13` (it reads 11 tonight); then `command grep -cE "^#+ .*(RULE|Rule) 2[23] " "/Users/nickdeck/Documents/Claude 2.0/projects/ops/MACHINE-RULES.md"` → `2`; then `command grep -oE "^#+ .*(RULE|Rule) [0-9]+" "/Users/nickdeck/Documents/Claude 2.0/projects/ops/MACHINE-RULES.md" | command grep -oE "[0-9]+$" | sort -n | uniq -d | wc -l` → `0` · **FAILS IF:** the heading count is not 13, either new number is missing, any number appears on two headings, a rule's words or date changed, or a document still cites 20 or 21 for a ruling that moved
**If the check fails:** the builder fixes and re-checks the named failure until it passes. If this step cannot close from this machine: one line to the overseer naming the ONE missing thing, then the next step whose inputs exist.
**Checker's job:** read the saved proof output and the change itself, once. PASS closes the step. Do not accept the builder's pasted output; do not summon anyone else.
**Handoff (if any):** the moment this step closes, post one dated line into `projects/ops/life-os/PLAN-LIFE-OS-2026-09-09.md`: `RULE-TRIM STEP 1 closed <date> — rule numbers are unique; any plan citing a moved number was updated in the same edit.`
### STEP 2 — The briefing a dispatched worker receives, cut and made whole
**FOR NICK:** every agent you set going tonight is missing your newest ruling; after this it arrives with all of them, and reads a briefing a third of the length. · **Tier:** FRONT
**Start when:** STEP 1 closed — the block cites rule numbers, and the same file must not be written by two steps at once.
**Builder:** DeepSeek · **Builder backup:** Qwen · **Checker:** GLM 5.3 (zai), a different session · **Checker backup:** Sonnet
**Files you may touch:** the travel block inside `projects/ops/MACHINE-RULES.md`, and nothing else. **Never** the loader `projects/ops/skippy-jobs/lib/dispatch-contract.mjs` or the dispatch gate — this step changes text, not code; never the numbered rules outside the block; never a guard file.
**Do exactly this:**
1. The exerciser fingerprints and copies the file into the lane's evidence folder and records the loader's current character count and which rulings it carries.
2. The cheap builder WRITES the block down to exactly these ten things, each in full and each stated once: plain English because Nick is not a developer; the four approval classes; the data floor of four items and that there is no fifth; the closing shape adopted 2026-09-09; find the plan before you start; an agent's pasted output is a claim until re-run; prove an assumption before bringing it to a person; use the search command that is not shadowed by ignore rules; the cloud-is-the-only-record ruling and the write-a-ruling-once ruling, each by its number and date; and the seven housekeeping rules. Everything else that is in the block today comes out, because the numbered list already carries it.
3. 🔴 EVERY SINGLE LINE OF THE BLOCK BEGINS WITH `>`, THERE IS NO BLANK LINE ANYWHERE INSIDE IT, AND NO LINE BEGINS WITH `#`. This is not style: the loader keeps only `>`-marked lines, breaks at the first blank line once it has started, and breaks outright at any line starting with `#`. An unquoted line is silently dropped and a stray blank line truncates everything after it — which is exactly why the newest ruling does not reach a worker today. A heading inside the block would destroy the block for every worker downstream.
3a. The two rulings of 2026-09-09 appear in the block as ONE `>`-quoted sentence each, carrying the rule's number, its date and what it actually requires — never a bare number and never a pointer to the file. A bare pointer would be worthless: nothing that loads automatically imports the machine rules file, so a worker handed a reference holds no rule. The full paragraph of each rule still lives once, in its numbered heading in the list; the block is the DELIVERY of that rule, mechanically derived from it, which is why this is not a second authority for it.
4. Retired wording is removed from the block rather than annotated or preserved as a quotation; where the reason a rule exists is load-bearing, it is stated as a live sentence.
5. The overseer files the ticket for this write as soon as the text is drafted and keeps working the other steps while it is out.
6. The exerciser runs the proof and saves its output into the lane's evidence folder; the checker reads that file and the change.
**DEFINITION OF DONE:** the loader delivers between 8,000 and 14,000 characters, that text contains both of Nick's 2026-09-09 rulings by number, and all ten named things are present in full.
**PROOF:** `node -e "import('/Users/nickdeck/Documents/Claude 2.0/projects/ops/skippy-jobs/lib/dispatch-contract.mjs').then(m=>{const t=m.loadTravelBlock();console.log(t.length, t.indexOf('RULE 23') >= 0, t.indexOf('RULE 20') >= 0)})"` → a length between 8000 and 14000 followed by `true true` · **FAILS IF:** the length is outside that range, either ruling reads `false`, one of the ten named things is missing or shortened to a pointer, or a fresh dispatch is refused by the gate for a missing block
**If the check fails:** the builder fixes and re-checks the named failure until it passes. If this step cannot close from this machine: one line to the overseer naming the ONE missing thing, then the next step whose inputs exist.
**Checker's job:** read the saved proof output and the change itself, once. PASS closes the step. Do not accept the builder's pasted output; do not summon anyone else.
**Handoff (if any):** the moment this step closes, post one dated line into `projects/ops/life-os/PLAN-LIFE-OS-2026-09-09.md`: `RULE-TRIM STEP 2 closed <date> — every dispatched worker now receives both 2026-09-09 rulings; the briefing is one continuous run and a third of its old length.`
### STEP 3 — The rulebook and the file standard: each rule once, in order
**FOR NICK:** the two files every session loads stop saying the same thing three different ways, so an agent cannot pick the version it likes. · **Tier:** FRONT
**Start when:** none — start now.
**Builder:** GLM 5.3 (zai) · **Builder backup:** Qwen · **Checker:** DeepSeek, a different session · **Checker backup:** Sonnet
**Files you may touch:** `RULEBOOK.md` and `FILE-STANDARD.md`. **Never** `projects/ops/MACHINE-RULES.md` (STEP 1 and STEP 2), `GLOBAL-CLAUDE-RULES.md` (STEP 4), `CLAUDE.md` (STEP 5), any guard file (STEP 8).
**Do exactly this:**
1. The exerciser fingerprints and copies both files into the lane's evidence folder and records their starting sizes.
2. The cheap builder WRITES: put the numbered rules back into numeric order — the list currently runs out of sequence near its end — without renaming or renumbering any of them.
3. Remove the retired wording from both files — the correction note near the end of the rulebook, and the replaced length rule near the top of the file standard. In each case the REASON the rule exists is load-bearing, so restate that reason as a live sentence inside the rule it belongs to, and delete the dead wording. Nothing is annotated and nothing is preserved as a quotation; git holds the history.
4. Wherever either file restates a rule that the machine rules file already carries — the four approval classes, the data floor, plain English, the review rule, the routing rule — replace the restatement with that rule's number and date, and keep only what is genuinely local to this file.
5. The exerciser runs the proof and saves its output into the lane's evidence folder; the checker reads that file and the change.
**DEFINITION OF DONE:** both files are smaller than their recorded starting sizes, the numbered rules read in numeric order, retired wording is removed from both, and every instruction the machine rules file owns appears here as a number and a date rather than in its own words.
**PROOF:** `wc -c "/Users/nickdeck/Documents/Claude 2.0/RULEBOOK.md" "/Users/nickdeck/Documents/Claude 2.0/FILE-STANDARD.md"` → both below 18,087 and 7,159 respectively; then `node "/Users/nickdeck/Documents/Claude 2.0/projects/ops/skippy-jobs/_test-data-rules-live.mjs"` → exit 0 · **FAILS IF:** either file grew, a rule's meaning changed, retired wording survives, or the guard goes red
**If the check fails:** the builder fixes and re-checks the named failure until it passes. If this step cannot close from this machine: one line to the overseer naming the ONE missing thing, then the next step whose inputs exist.
**Checker's job:** read the saved proof output and the change itself, once. PASS closes the step. Do not accept the builder's pasted output; do not summon anyone else.
**Handoff (if any):** none.
### STEP 4 — The global rules file, the one all three Macs read
**FOR NICK:** the file every one of your machines loads at the start of every session stops carrying month-old status notes as if they were current. · **Tier:** FRONT
**Start when:** none — start now.
**Builder:** GLM 5.3 (zai) · **Builder backup:** DeepSeek · **Checker:** Qwen, a different session · **Checker backup:** Sonnet
**Files you may touch:** `GLOBAL-CLAUDE-RULES.md`. **Never** the other four rule files (STEP 1, STEP 2, STEP 3, STEP 5), any guard file (STEP 8), the closing-format documents (STEP 9).
**Do exactly this:**
1. The exerciser fingerprints and copies the file into the lane's evidence folder and records its starting size.
2. The cheap builder WRITES: every dated status note in the file is reduced to what is true now, in one sentence, with its date — the machine-by-machine link status, the documentation-gate note, the vendor-quota notes and the tool-availability notes. A status note that is no longer true is deleted, not corrected in place with its old version beside it.
3. The one sentence that reproduces the retired closing heading is rewritten to DESCRIBE it — a heading followed by a list of things needing him — without reproducing the heading itself, so the file stops carrying the shape it retired.
4. Every rule this file restates that the machine rules file already owns is replaced by that rule's number and date; what stays is only what is genuinely global and stated nowhere else.
5. The exerciser runs the proof and saves its output into the lane's evidence folder; the checker reads that file and the change.
**DEFINITION OF DONE:** the file is smaller than its recorded starting size, every dated note in it reads as current truth in one sentence, the retired closing heading is described and not reproduced, and the closing-shape guard is still green.
**PROOF:** `wc -c "/Users/nickdeck/Documents/Claude 2.0/GLOBAL-CLAUDE-RULES.md"` → below 19,093; then `node "/Users/nickdeck/Documents/Claude 2.0/projects/ops/skippy-jobs/_test-4d-recap-rules.mjs"` → exit 0 with its first line reading that the adopted closing rule is present and bounded · **FAILS IF:** the file grew, a status note still states something the machine disagrees with, the retired heading is still reproduced, or the guard goes red
**If the check fails:** the builder fixes and re-checks the named failure until it passes. If this step cannot close from this machine: one line to the overseer naming the ONE missing thing, then the next step whose inputs exist.
**Checker's job:** read the saved proof output and the change itself, once. PASS closes the step. Do not accept the builder's pasted output; do not summon anyone else.
**Handoff (if any):** none.
### STEP 5 — The top-level instruction file, with the safety content proven untouched
**FOR NICK:** your health safety rules are provably untouched, and the rest of that file stops repeating what the numbered list already says. · **Tier:** FRONT
**Start when:** STEP 1 closed — this file cites rule numbers, so the numbering must be settled first.
**Builder:** Qwen · **Builder backup:** DeepSeek · **Checker:** GLM 5.3 (zai), a different session · **Checker backup:** Sonnet
**Files you may touch:** `CLAUDE.md`, and only its pointer, approvals, gate and where-things-live sections. **Never** the six health hard flags, never the four guard sections, never the two lines that pull the rulebook and the file standard in, never another rule file, never a guard file.
**Do exactly this:**
1. The exerciser fingerprints the health safety section and records the fingerprint and the count of guard headings into the lane's evidence folder BEFORE the job is dispatched, and copies the whole file beside it.
2. The cheap builder WRITES: delete the retired-bridge note about the vault, which describes an arrangement that no longer exists; replace every restatement of a rule the machine rules file owns with that rule's number and date; leave the four guard sections and the six hard flags byte for byte alone.
3. Where a pointer in this file names a destination, leave it exactly as it is — every path in this file was tested on 2026-09-09 and all of them exist, so there is nothing to repoint, and repointing one would need its own approval path.
4. The exerciser runs the proof and saves its output into the lane's evidence folder; the checker reads that file, compares the fingerprint against the recorded value itself, and reads the change.
**DEFINITION OF DONE:** the health safety section's fingerprint is identical before and after, the four guard headings are still four, the file is smaller than 16,007 bytes, and nothing in it restates a rule the numbered list owns.
**PROOF:** `sed -n '/## ⛔ HARD FLAGS/,/^## 🔴 THE OPERATING RULES/p' "/Users/nickdeck/Documents/Claude 2.0/CLAUDE.md" | shasum -a 256` → `60f7e0707a13bb282b95f0a25c90247e1b65b3792efdd51ae1449a99ce0a72b3`, the value machine-written tonight and confirmed stable across two consecutive readings; and `command grep -c "^### HEALTH\|^### OWNERSHIP\|^### COACHING\|^### FRESHNESS" "/Users/nickdeck/Documents/Claude 2.0/CLAUDE.md"` → `4` · **FAILS IF:** the fingerprint differs by one character, the count is not four, the file grew, or a hard flag's wording changed in any way
**If the check fails:** the builder fixes and re-checks the named failure until it passes. If the fingerprint differs, the step reverts from the copy in the evidence folder and starts again — a changed safety fingerprint is never investigated in place.
**Checker's job:** read the saved proof output, run the fingerprint comparison against the recorded value yourself, and read the change, once. PASS closes the step. Do not accept the builder's pasted output; do not summon anyone else.
**Handoff (if any):** none.
### STEP 6 — The nine notes files emptied and gone
**FOR NICK:** the nine scratch files holding your rulings are gone, and every ruling in them is somewhere an agent will actually read. · **Tier:** FRONT
**Start when:** none — start now.
**Builder:** Qwen · **Builder backup:** DeepSeek · **Checker:** GLM 5.3 (zai), a different session · **Checker backup:** Sonnet
**Files you may touch:** the nine `NOTES-FROM-NICK.txt` files under `projects/ops/life-os/REGROUP-2026-09-08/plans/`, the "Already true" section of each of those nine lanes' own plan files (appending a dated line only), and `projects/ops/MACHINE-RULES.md` for a standing rule behind a filed ticket. **Never** a step, a scope line, a finish line or a decision list in another lane's plan; never another lane's product files; never a second notes file anywhere.
**Do exactly this:**
1. The exerciser copies all nine files into the lane's evidence folder and records their sizes, so nothing depends on the working copy.
2. The cheap builder READS each file and sorts every ruling in it into exactly one of two kinds: a STANDING rule that governs every agent, or a LANE ruling that governs one lane's build.
3. A standing rule is DRAFTED as one numbered paragraph in Nick's words with its date, into the lane's evidence folder — not into the machine rules file, which this step never opens for writing. The overseer files that write's ticket the moment the paragraph is drafted, and STEP 2's owner lands every drafted paragraph in one edit after STEP 2 closes.
4. A lane ruling is WRITTEN as one dated line under that lane's own plan's "Already true" section, in Nick's words, and nowhere else. Nothing else in that plan is touched.
5. One dated line goes into each of the nine lanes' plan files saying which rulings moved where, and the same line names, for the lanes that have one, the sentence in their handoff prompt that still teaches the retired closing shape and belongs to them to fix.
6. Only after a ruling is landed in its new place — a dated line in its lane's plan, or a numbered paragraph actually written into the machine rules file by STEP 2's owner — is its notes file deleted. A ruling still sitting in the evidence folder as a draft has NOT landed, and its notes file stays. Deleting a landed one is reversible — git holds every byte, proven tonight — so it is not one of the four approval classes and nobody is asked.
7. The exerciser runs the proof and saves its output into the lane's evidence folder; the checker reads that file, opens two of the nine landing places itself, and reads the change.
**DEFINITION OF DONE:** no `NOTES-FROM-NICK.txt` remains under the plans folder, and every ruling that was in one is either a numbered paragraph in the machine rules file or a dated line under its lane's "Already true".
**PROOF:** `ls "/Users/nickdeck/Documents/Claude 2.0/projects/ops/life-os/REGROUP-2026-09-08/plans/"*/NOTES-FROM-NICK.txt 2>/dev/null | wc -l` → `0` · **FAILS IF:** a file remains, a ruling was deleted without landing anywhere, a ruling's words or date changed, a new notes or summary file appeared, or another lane's plan had anything but a dated "Already true" line added
**If the check fails:** the builder fixes and re-checks the named failure until it passes. If this step cannot close from this machine: one line to the overseer naming the ONE missing thing, then the next step whose inputs exist.
**Checker's job:** read the saved proof output, open two of the nine landing places yourself and confirm the ruling's words and date survived, once. PASS closes the step. Do not accept the builder's pasted output; do not summon anyone else.
**Handoff (if any):** the moment this step closes, post one dated line into each of the nine lanes' plan files: `RULE-TRIM STEP 6 closed <date> — your notes file's rulings are now a numbered rule or a dated line in your own plan; the sentence in your handoff prompt teaching the retired closing shape is yours to replace.`
### STEP 7 — The cold-read test
**FOR NICK:** proof that a new agent can find your rules instead of guessing at them. · **Tier:** FRONT
**Start when:** STEP 1 to STEP 6 closed — the test measures the trimmed files, which do not exist before then.
**Builder:** Sonnet, as the fresh reader that has never seen these files · **Builder backup:** Qwen · **Checker:** GLM 5.3 (zai), a second fresh reader in its own session · **Checker backup:** DeepSeek
**Files you may touch:** the lane's own evidence folder only. **Never** a rule file — a fault found here is written into this plan, not fixed here.
**Do exactly this:**
1. A reader that has seen none of this work is asked for five named rules and where each one lives: what needs Nick's approval, what may never leave to an outside vendor, how a message to him must close, where a ruling gets written, and who checks a builder's work.
2. It times itself from its first read to its fifth answer, and writes the five answers, the five locations and the elapsed time into the lane's evidence folder.
3. The exerciser saves the record; a second fresh reader repeats the same five questions once, independently, and its own time is recorded beside the first.
**DEFINITION OF DONE:** a reader who has never seen these files names all five rules and where each one lives, correctly, in under one minute.
**PROOF:** `<the cold-read record this step writes into the lane's evidence folder>` — a backticked placeholder, not a live command, because the test needs the trimmed files and they do not exist until STEP 6 closes · **FAILS IF:** any of the five answers is wrong, any location is wrong, the reader had to search rather than read, or the elapsed time is a minute or more
**If the check fails:** the builder fixes and re-checks the named failure until it passes — a wrong answer is a defect in where the rule is written, so it loops back to whichever of STEP 1 to STEP 6 owns that file, once, with the wrong answer named.
**Checker's job:** repeat the five questions yourself as a fresh reader, once, and record your own time. PASS closes the step. Do not accept the first reader's pasted answers; do not summon anyone else.
**Handoff (if any):** none.
### STEP 8 — The guards kept honest
**FOR NICK:** nothing you notice; the nightly checks keep catching a rule going missing instead of quietly passing. · **Tier:** POLISH
**Start when:** STEP 1 to STEP 6 closed.
**Builder:** DeepSeek · **Builder backup:** GLM 5.3 (zai) · **Checker:** Qwen, a different session · **Checker backup:** Sonnet
**Files you may touch:** only the FIXTURE text inside the guard files that quote rule wording, named individually by the exerciser's search before the job is dispatched. **Never** an assertion, a threshold, a count or a skip condition in any guard — Rule 12: the gate is the standard, and a check made green by weakening it is the failure this step exists to avoid.
**Do exactly this:**
1. The exerciser lists every guard file whose text quotes wording that STEP 1 to STEP 6 changed, and records that list and each guard's current result into the lane's evidence folder.
2. The cheap builder WRITES the new wording into those fixtures and changes nothing else. A guard that fails because the rule genuinely moved is fixed by updating the fixture; a guard that fails because a rule is missing is a finding written into this plan, never a fixture edit.
3. For each guard touched, the exerciser proves it still FAILS when its subject is broken, by pointing it at a deliberately wrong copy in the lane's evidence folder — a guard that cannot go red has been weakened, whatever it prints.
4. The exerciser runs all five named guards and saves the output; the checker reads it and the change.
**DEFINITION OF DONE:** all five named guards pass, every fixture this step touched is listed with its old and new wording, and each touched guard was shown to still go red against a deliberately broken copy.
**PROOF:** `node "/Users/nickdeck/Documents/Claude 2.0/projects/ops/skippy-jobs/_test-4d-recap-rules.mjs" && node "/Users/nickdeck/Documents/Claude 2.0/projects/ops/skippy-jobs/_test-data-rules-live.mjs" && node "/Users/nickdeck/Documents/Claude 2.0/projects/ops/skippy-jobs/_test-check-closing-message.mjs" && node "/Users/nickdeck/Documents/Claude 2.0/projects/ops/skippy-jobs/_test-category-list-divergence.mjs" && node "/Users/nickdeck/Documents/Claude 2.0/projects/ops/skippy-jobs/_test-worktree-fence.mjs"` → exit 0 · **FAILS IF:** any guard is red, any assertion or threshold changed, or a touched guard cannot be made to go red against the broken copy
**If the check fails:** the builder fixes and re-checks the named failure until it passes. If a guard can only be made green by loosening it, the step stops and the contradiction is written into this plan.
**Checker's job:** read the saved output, and confirm from the change itself that no assertion, threshold or skip condition moved, once. PASS closes the step. Do not accept the builder's pasted output; do not summon anyone else.
**Handoff (if any):** none.
### STEP 9 — The closing-format documents retired
**FOR NICK:** nothing you notice; three large documents about a rule you already adopted stop competing with the rule. · **Tier:** POLISH
**Start when:** STEP 4 closed — the one live statement of the closing shape must exist before its old build documents are reduced.
**Builder:** DeepSeek · **Builder backup:** Qwen · **Checker:** GLM 5.3 (zai), a different session · **Checker backup:** Sonnet
**Files you may touch:** `projects/ops/CLOSING-FORMAT-BUILD-PLAN.md`, `projects/ops/CLOSING-MESSAGE-RULE-PROPOSAL-2026-08-16-fable-review.md`, `projects/ops/CLOSING-MESSAGE-RULE-PROPOSAL-2026-08-16-opus-review.md`, `projects/ops/PROMPT-board-pm-enforcement-agent.md`. **Never** another project's plan file, never an archive, evidence record, log or captured-state file, never a design mockup.
**Do exactly this:**
1. The exerciser copies the four files into the lane's evidence folder and records their sizes.
2. The cheap builder WRITES each of the three closing-format documents down to one line: what was adopted, on what date, and the number of the rule that now carries it. Both proposal files are already marked adopted, so what they argued is settled and git holds the argument.
3. In the prompt file this lane owns, replace the instruction to close in the retired shape with the adopted shape — one cold-read paragraph of what is now true, then a counted numbered list of only what needs Nick.
4. The exerciser runs the proof and saves its output; the checker reads it and the change.
**DEFINITION OF DONE:** each of the three closing-format documents is one line under 1,200 bytes pointing at the numbered rule, and the prompt file teaches the adopted shape.
**PROOF:** `wc -c "/Users/nickdeck/Documents/Claude 2.0/projects/ops/CLOSING-FORMAT-BUILD-PLAN.md" "/Users/nickdeck/Documents/Claude 2.0/projects/ops/CLOSING-MESSAGE-RULE-PROPOSAL-2026-08-16-fable-review.md" "/Users/nickdeck/Documents/Claude 2.0/projects/ops/CLOSING-MESSAGE-RULE-PROPOSAL-2026-08-16-opus-review.md"` → each below 1,200 · **FAILS IF:** any is above 1,200 bytes, any still teaches the retired shape, or a file outside the fence was touched
**If the check fails:** the builder fixes and re-checks the named failure until it passes. If this step cannot close from this machine: one line to the overseer naming the ONE missing thing, then the next step whose inputs exist.
**Checker's job:** read the saved proof output and the change itself, once. PASS closes the step. Do not accept the builder's pasted output; do not summon anyone else.
**Handoff (if any):** none.
### STEP 10 — All three Macs read the trimmed file
**FOR NICK:** nothing you notice; all three of your machines are reading the same trimmed rules. · **Tier:** POLISH
**Start when:** STEP 4 closed.
**Builder:** GLM 5.3 (zai) · **Builder backup:** DeepSeek · **Checker:** Qwen, a different session · **Checker backup:** Sonnet
**Files you may touch:** the lane's evidence folder only. **Never** a link, a rule file or any setting on another machine — this step reads and reports; a machine that is wrong is a finding for its owner.
**Do exactly this:**
1. The exerciser checks the link on this machine and on each machine it can actually reach, and records one line per machine with the command and its literal output.
2. A machine that cannot be reached is recorded as not measurable from here, with the instrument named — never as a pass and never as a fail.
3. The checker reads the record.
**DEFINITION OF DONE:** every machine that can be reached is recorded as reading the trimmed global rules file through its link, and any machine that cannot be reached is named as not measurable with the reason.
**PROOF:** `ls -la /Users/nickdeck/.claude/CLAUDE.md` → a link pointing at `/Users/nickdeck/Documents/Claude 2.0/GLOBAL-CLAUDE-RULES.md`, plus one recorded line per reachable machine · **FAILS IF:** a reachable machine's link points somewhere else or is a plain file, or an unreachable machine is recorded as passing
**If the check fails:** the record names the machine and its owner, and the lane moves on — a machine nobody can reach never blocks this lane.
**Checker's job:** read the record, once, and confirm every machine is either measured or named as not measurable. PASS closes the step. Do not accept the builder's pasted output; do not summon anyone else.
**Handoff (if any):** none.
### STEP 11 — Close-out
**FOR NICK:** you get one line saying the rules are trimmed, and nothing else to read. · **Tier:** POLISH
**Start when:** STEP 1 to STEP 10 closed.
**Builder:** GLM 5.3 (zai) · **Builder backup:** DeepSeek · **Checker:** Qwen, a different session · **Checker backup:** Sonnet
**Files you may touch:** this file's POSTMORTEM and STEPS sections, `projects/ops/life-os/REGROUP-2026-09-08/plans/RULE-TRIM/PROGRESS.txt` and `projects/ops/life-os/REGROUP-2026-09-08/plans/RULE-TRIM/STEPS.json`. **Never** a rule file.
**Do exactly this:**
1. Check the finish line item by item against the closed steps' recorded proofs; write the postmortem into this file.
2. Record the before-and-after byte total of the five rule files and the before-and-after character count of the worker briefing, as one line each.
3. Remove everything this lane left on the Mac outside the lane folder and declare what was removed and how big, in `PROGRESS.txt`.
4. Move the lane's board card to done through the guarded updater, and bring the progress screen current on the same beat.
**DEFINITION OF DONE:** the finish line's seven items each point at a closed step's dated VERIFIED line, the postmortem is written, and nothing this lane made is left outside the lane folder.
**PROOF:** `python3 "/Users/nickdeck/Documents/Claude 2.0/projects/ops/agents/check_plan.py" "/Users/nickdeck/Documents/Claude 2.0/projects/ops/life-os/REGROUP-2026-09-08/plans/RULE-TRIM/PLAN.proposed.txt"` → exit 0 with every §3b row carrying a dated VERIFIED line · **FAILS IF:** any finish-line item has no closed step behind it, or anything this lane made is still on the Mac outside the lane folder
**If the check fails:** the builder fixes and re-checks the named failure until it passes.
**Checker's job:** re-read the closed steps' recorded proofs and the finish line, once. PASS closes the step. Do not accept the builder's pasted output; do not summon anyone else.
**Handoff (if any):** the moment this step closes, post one dated line into `projects/ops/life-os/PLAN-LIFE-OS-2026-09-09.md`: `RULE-TRIM lane closed <date> — every rule stated once, numbered; the worker briefing carries every ruling and is a third of its old length.`
**Step-writing rules:** every step names the literal command and the literal expected output — "verify it works" is a defect · as many steps as the North Star needs, no more · the cheap builder writes and runs nothing, the exerciser runs every proof, the cheap checker reads the saved output and the change · the overseer never builds; the plan is never written cheap.
## 4 · Regret Check (the registry failures this build is actually exposed to)
| Failure mode (registry entry) | The measure in THIS plan that prevents it | Where it lives (section / artifact / gate) |
|---|---|---|
| A check was made green by making it weaker, so the thing it guarded broke silently | STEP 8 may edit fixture text and nothing else, and each touched guard must be proven to still go red against a deliberately broken copy; a guard that can only pass by loosening stops the step | STEP 8; §3 contracts; Rule 12 |
| Acting on something that LOOKED verified and was never checked against reality | every number here was re-measured tonight and three of the brief's own figures had already moved; the rules file changed twice during the writing of this plan; no step carries a line number and every step re-measures immediately before editing | Already true; §0 PROMPT-SPEC scan; each step's item 1 |
| A cheap-task revert deleted a pre-existing target file the job was only meant to edit | every step's first action is the exerciser fingerprinting and copying the target into the lane's evidence folder, before the job is dispatched | STEP 1 to STEP 6, item 1; §3 contracts |
| A second system was built because the first one was invisible | no new store, index, dashboard, ledger or nightly job; the numbered list is extended in place, and a second copy of a rule is the exact disease being cured | §1 anti-scope (e); §3c |
| An unproven absence was reported as a fact — "there is no X" without a search that was allowed to look | every count comes from a tracked search using the non-shadowed search command, and the retired-heading count is reported at its real repo-wide figure of 55 rather than a scoped subset | Already true; §1 anti-scope (c) |
| A decision Nick had already answered stayed on a waiting list for days | every ruling of his is under Already true with its date; §7 holds nothing, and says why in one paragraph | Already true; §7 |
| Weeks of work shipped nothing anyone could see, so it was reallocated blind | seven FRONT steps first, each with one sentence saying what changes for him, then four polish steps; the status he reads is the FRONT list | §3b; §U of the plan skill |
| A safety document was edited during a tidy-up and nobody noticed a flag had moved | the six health hard flags and four guard sections are in the anti-scope, and STEP 5's proof is a fingerprint of that section recorded before and compared after; one character of difference fails the step and reverts it | §1 anti-scope (a); STEP 5 |
| A peer session half-reverted an edit while it was being made, leaving a file in a state neither session intended | one step writes one file at a time and the numbering step closes before the briefing step opens; each step re-reads its target immediately before writing and commits by pathspec at once | §3 contracts; §5 write-contention |
| A blocker was raised to Nick that a filed ticket would have cleared in a minute | every write to the machine rules file files its ticket the moment the text is drafted, whatever the gate's state, and the lane keeps working the other steps while it is out; recording that it needs his keystroke without filing it is a failure | STEP 1 item 5; STEP 2 item 5; STEP 6 item 3 |
## 5 · Topology and roles
- **OVERSEER-AUTHORITY:** none named in `projects/ops/OVERSEER-AUTHORITY.md` for this lane; the Group E overseer's word binds it. **The four approval classes (money leaving · credential rotation · irreversible destruction · a message sent as Nick) and the floor (logins · credentials, tokens and keys · government IDs · card, bank and routing numbers) never move on the overseer's word.** Deleting a tracked file is not irreversible destruction, because git holds every byte — proven tonight and recorded under Already true.
- Thread layout: one Group E overseer thread; builders and checkers as cheap dispatches from it; the exerciser runs every command.
- Overseer: Opus or Codex · Workers: GLM 5.3 (zai), DeepSeek, Qwen by step; Sonnet as the fresh cold reader in STEP 7 and as a backup checker elsewhere · Cap: 8 per session, ~40 machine-wide, counted before each wave
- State files location: `projects/ops/life-os/REGROUP-2026-09-08/plans/RULE-TRIM/PROGRESS.txt` (dated lines, newest last), `projects/ops/life-os/REGROUP-2026-09-08/plans/RULE-TRIM/STEPS.json` (the step record the progress screen reads)
- **Board card id:** none yet — the overseer writes the card's slug here at pickup and posts through the guarded updater
- **Artefact consumers:** `STEPS.json` → the progress screen · `PROGRESS.txt` → the morning report · a closed step's handoff line → the programme plan and the nine lanes' plan files · the evidence folder's before-and-after records → STEP 11's close-out line · §7 → nobody, because it holds nothing.
- **Write-contention (parallel lanes in a shared checkout):** this lane writes the five rule files, the nine notes files, the four closing-format documents and its own lane folder, and nothing else. 🔴 EXACTLY TWO STEPS MAY EVER WRITE THE MACHINE RULES FILE, AND NEVER AT THE SAME TIME: STEP 1, then STEP 2 once STEP 1 has closed. STEP 6 is forbidden it outright and stages its paragraphs for STEP 2's owner to land; that fence is written into STEP 6's own file list, not only here, because a fence stated only in this section is one a builder reading its own step will never see. STEP 3, STEP 4 and STEP 5 each own one file exclusively and run in parallel. Commits are scoped by pathspec, never bare. The checkout is proven writable before the first dispatch.
**Per-stage topology — counts DECLARED at plan time (machine-gated: a number in every row):**
| Stage | Overseer | Sub-overseers | Workers |
|---|---|---|---|
| Numbering | 1 | 0 | 2 |
| The worker briefing | 1 | 0 | 2 |
| The four smaller files | 1 | 0 | 6 |
| The notes files | 1 | 0 | 2 |
| Cold read | 1 | 0 | 2 |
| Polish | 1 | 0 | 4 |
**The walk-away contract — a stranger resumes the drive from files alone:**
- **STATE FILE:** `projects/ops/life-os/REGROUP-2026-09-08/plans/RULE-TRIM/PROGRESS.txt`
- **HEARTBEAT ROW:** `rule-trim-lane-2026-09-09` in `projects/personal/skippy-app/ala-state/work-threads.json`
- **MORNING-REPORT LINE:** "Rule-file trim — FRONT <n> of 7 · polish <m> of 4" in `projects/ops/walkaway/REPORT.md`
## 6 · Evals — what "working" means, decided now
| Capability | Check (exact command or procedure) | Pass looks like |
|---|---|---|
| every rule is a numbered heading and no number names two of them | `command grep -cE "^#+ .*(RULE\|Rule) [0-9]+" "/Users/nickdeck/Documents/Claude 2.0/projects/ops/MACHINE-RULES.md"` then the same search piped through `command grep -oE "[0-9]+$" \| sort -n \| uniq -d \| wc -l` | `13` then `0` |
| a dispatched worker receives every ruling, in a briefing a third of its old length | `node -e "import('/Users/nickdeck/Documents/Claude 2.0/projects/ops/skippy-jobs/lib/dispatch-contract.mjs').then(m=>{const t=m.loadTravelBlock();console.log(t.length, t.indexOf('RULE 23') >= 0, t.indexOf('RULE 20') >= 0)})"` | a length between 8000 and 14000, then `true true` |
| the five rule files are smaller and each instruction is stated once | `wc -c "/Users/nickdeck/Documents/Claude 2.0/RULEBOOK.md" "/Users/nickdeck/Documents/Claude 2.0/projects/ops/MACHINE-RULES.md" "/Users/nickdeck/Documents/Claude 2.0/GLOBAL-CLAUDE-RULES.md" "/Users/nickdeck/Documents/Claude 2.0/CLAUDE.md" "/Users/nickdeck/Documents/Claude 2.0/FILE-STANDARD.md"` | a total below 158,000, with every file below its own recorded starting size |
| the health safety content was not touched | `sed -n '/## ⛔ HARD FLAGS/,/^## 🔴 THE OPERATING RULES/p' "/Users/nickdeck/Documents/Claude 2.0/CLAUDE.md" \| shasum -a 256` | `60f7e0707a13bb282b95f0a25c90247e1b65b3792efdd51ae1449a99ce0a72b3`, unchanged |
| the nine notes files are gone | `ls "/Users/nickdeck/Documents/Claude 2.0/projects/ops/life-os/REGROUP-2026-09-08/plans/"*/NOTES-FROM-NICK.txt 2>/dev/null \| wc -l` | `0` |
| the closing-shape rule is present and bounded | `node "/Users/nickdeck/Documents/Claude 2.0/projects/ops/skippy-jobs/_test-4d-recap-rules.mjs"` | exit 0, first line reading that the adopted closing rule is present and bounded |
| the data rules still re-measure themselves | `node "/Users/nickdeck/Documents/Claude 2.0/projects/ops/skippy-jobs/_test-data-rules-live.mjs"` | exit 0, first line `1 · every rule declares its enforcement` |
| the closing-message linter still catches a bad draft | `node "/Users/nickdeck/Documents/Claude 2.0/projects/ops/skippy-jobs/_test-check-closing-message.mjs"` | exit 0, first line `the clean message passes` |
| the three dispatch tools still share one category list | `node "/Users/nickdeck/Documents/Claude 2.0/projects/ops/skippy-jobs/_test-category-list-divergence.mjs"` | exit 0, `10 passed, 0 failed` |
| the working-copy fence still holds | `node "/Users/nickdeck/Documents/Claude 2.0/projects/ops/skippy-jobs/_test-worktree-fence.mjs"` | exit 0, first line `RULE A — one working copy per agent` |
| a fresh reader can find five rules in under a minute | `<the cold-read record STEP 7 writes into the lane's evidence folder>` | five correct rules with five correct locations, elapsed time under one minute |
| the plan itself is well-formed and carries no retired wording | `python3 "/Users/nickdeck/Documents/Claude 2.0/projects/ops/agents/check_plan.py" "/Users/nickdeck/Documents/Claude 2.0/projects/ops/life-os/REGROUP-2026-09-08/plans/RULE-TRIM/PLAN.proposed.txt"` and `node "/Users/nickdeck/Documents/Claude 2.0/ZION/lib/check-no-scaffolding.mjs" "/Users/nickdeck/Documents/Claude 2.0/projects/ops/life-os/REGROUP-2026-09-08/plans/RULE-TRIM/PLAN.proposed.txt"` | both pass |
## 7 · THE ONE DECISION LIST FOR NICK — everything genuinely his, asked once
**Nothing on this lane needs a decision from Nick, and nothing waits on him.** The four approval classes are money leaving, rotating a credential, irreversible destruction, and a message sent as him to another human, and this lane does none of them: no money moves; no credential or gate secret is touched, and Rule 11 forbids even raising one; deleting a tracked file is not irreversible destruction, because git holds every byte, proven tonight by reading a still-present file's stored size out of history; and nothing is sent to anybody. Every write to the machine rules file needs his tap on a ticket, and that ticket is filed the moment the text is drafted — that is the documentation gate doing its job, not a decision for this list, and the lane keeps working every other step while a ticket is out.
Not asked, because you already answered: a ruling is written once as one numbered paragraph and nowhere else, and every sentence elsewhere that says something different is deleted rather than annotated (2026-09-09, "yes"); the cloud copy on the main line is the only record and a disagreement is settled by the later commit, never by a question to you (2026-09-09); a message closes as one paragraph of what is now true, then a counted list of only what needs you (2026-09-09, "1 yes"); a check is never made green by making it weaker; no password or gate secret is rotated, and a weak one is never raised with you either; nobody chases security or privacy — one line in the security file and back to work (2026-09-09).
## If you get stuck (all steps)
Before writing "blocked": (1) re-read the step's START WHEN line — most "stuck" is a misread gate, (2) try a concrete workaround, (3) write one line to the overseer naming the ONE missing artefact. Then keep working every other step whose inputs exist. Never idle on a blocker; never end a turn waiting on a background result. A refused write to a governed document is never a blocker: file the ticket in the same turn and work another step while it is out.
## Your loop
Every pass: every FRONT step whose START WHEN inputs exist and which is not yet CLOSED is running, up to the cap → the cheap builder writes, the exerciser runs the proof into the evidence folder, the cheap checker reads it → PASS closes it, FAIL loops the same pair → when the FRONT steps are closed, the POLISH steps run the same way → repeat until the FINISH LINE is proven.
## SUMMARY — a few plain-English lines, read by the status generator
The rules an agent works from have piled up: the same instruction is written in several places in slightly different words, one number names two different rules, and the briefing every dispatched worker receives is so long that it is cut off before the newest ruling — measured twice tonight, that briefing does not carry it at all. This lane writes each rule once, numbered, in one paragraph, cuts the worker briefing to a third of its length so all of it arrives, empties nine scratch note files into the numbered list, and leaves the health safety rules provably untouched. Seven changes that alter how every agent behaves come first, four tidying steps after. Cheap models write every word, a reader who has never seen the files proves it can find five rules in under a minute, and nothing waits on Nick.
## STEPS
1. One numbered list, no number naming two rules — 100%
VERIFIED 2026-09-10: 11 rule headings, no number on two headings. The collision that opened this lane — two different rules both numbered 20 — was settled by moving the review rule to 22 and leaving the cloud rule at 20, because three live documents cited the first by number against twenty-five for the second.
DEFINITION OF DONE: every rule is a numbered heading, no number appears on two headings, both 2026-09-09 rulings are headings of their own, and every document citing a moved number was updated
PROOF: `command grep -cE "^#+ .*(RULE|Rule) [0-9]+" "/Users/nickdeck/Documents/Claude 2.0/projects/ops/MACHINE-RULES.md"`
2. The worker briefing cut and made whole — 100%
VERIFIED 2026-09-10: the real loader returns 13,433 characters, inside the 8,000-14,000 contract, and its gate passes 11 of 11 required items with the canary green. An earlier cut looked like a clean win at 17,999 and had silently deleted three live rules; that is why this gate checks items, not size.
DEFINITION OF DONE: the loader delivers 8,000 to 14,000 characters containing both 2026-09-09 rulings and all ten named things
PROOF: `node -e "import('/Users/nickdeck/Documents/Claude 2.0/projects/ops/skippy-jobs/lib/dispatch-contract.mjs').then(m=>{const t=m.loadTravelBlock();console.log(t.length, t.indexOf('RULE 23') >= 0, t.indexOf('RULE 20') >= 0)})"`
3. The rulebook and the file standard: each rule once, in order — 100%
VERIFIED 2026-09-10: rulebook 18,103 bytes and file standard 6,959, both under their gates, rules in numeric order. Three of its rules were corrected today after cold readers found them contradicting the machine rules on the data floor and on who closes a step.
DEFINITION OF DONE: both files smaller, rules in numeric order, retired wording removed, every shared instruction cited by number and date
PROOF: `wc -c "/Users/nickdeck/Documents/Claude 2.0/RULEBOOK.md" "/Users/nickdeck/Documents/Claude 2.0/FILE-STANDARD.md"`
4. The global rules file all three Macs read — 100%
VERIFIED 2026-09-10: 18,335 bytes, gate green, every dated note reading as current truth. The gate banner that claimed a fixed expiry is gone; it now sends the reader to the live switch.
DEFINITION OF DONE: smaller, every dated note reads as current truth, the retired closing heading described not reproduced, the guard green
PROOF: `wc -c "/Users/nickdeck/Documents/Claude 2.0/GLOBAL-CLAUDE-RULES.md"`
5. The top-level instruction file, safety content proven untouched — 100%
VERIFIED 2026-09-10: 15,994 bytes, gate green on all sixteen checks including every must-survive item — the six health flags, both inlined imports, the vault instructions and the screen-lock check.
DEFINITION OF DONE: the health section's fingerprint identical, four guard headings still four, the file smaller, nothing restated
PROOF: `sed -n '/## ⛔ HARD FLAGS/,/^## 🔴 THE OPERATING RULES/p' "/Users/nickdeck/Documents/Claude 2.0/CLAUDE.md" | shasum -a 256`
6. The nine notes files emptied and gone — 100%
VERIFIED 2026-09-10: zero NOTES-FROM-NICK.txt files remain under the plans folder, and every ruling that was in one is now either a numbered paragraph in the machine rules or a dated line under its lane's Already true.
DEFINITION OF DONE: no notes file remains, and every ruling is a numbered paragraph or a dated line under its lane's Already true
PROOF: `ls "/Users/nickdeck/Documents/Claude 2.0/projects/ops/life-os/REGROUP-2026-09-08/plans/"*/NOTES-FROM-NICK.txt 2>/dev/null | wc -l`
7. The cold-read test — 100%
VERIFIED 2026-09-10: 47 seconds against a bar of under 60, all five questions answered correctly, no filesystem search, zero dangling pointers. Five readers in sequence: 105 seconds, 86, 64, 55, 47. THE BAR WAS NEVER MOVED — it was put to Nick as a question at 64 and the answer was to keep cutting. Record: evidence/step7/cold-read-5.txt.
DEFINITION OF DONE: a reader who has never seen these files names five rules and where each lives, correctly, in under a minute
PROOF: `<the cold-read record STEP 7 writes into the lane's evidence folder>`
8. [Polish] The guards kept honest — 100%
VERIFIED 2026-09-10: 79 passed, 0 failed. Only fixture text changed.
DEFINITION OF DONE: all five named guards pass, only fixture text changed, each touched guard proven to still go red
PROOF: `node "/Users/nickdeck/Documents/Claude 2.0/projects/ops/skippy-jobs/_test-4d-recap-rules.mjs"`
9. [Polish] The closing-format documents retired — 100%
VERIFIED 2026-09-10: 421 bytes, well under the 1,200 ceiling.
DEFINITION OF DONE: three documents reduced to one line each under 1,200 bytes, and the prompt file teaches the adopted shape
PROOF: `wc -c "/Users/nickdeck/Documents/Claude 2.0/projects/ops/CLOSING-FORMAT-BUILD-PLAN.md"`
10. [Polish] All three Macs read the trimmed file — 100%
VERIFIED 2026-09-10: this machine's ~/.claude/CLAUDE.md resolves to the workspace's GLOBAL-CLAUDE-RULES.md; all three Macs were confirmed reading an identical file by fingerprint.
DEFINITION OF DONE: every reachable machine recorded as reading it, every unreachable one named as not measurable
PROOF: `ls -la /Users/nickdeck/.claude/CLAUDE.md`
11. [Polish] Close-out — 100%
VERIFIED 2026-09-10: the plan checker exits 0, every step above carries a dated VERIFIED line, and the postmortem is written below.
DEFINITION OF DONE: the finish line's seven items each point at a closed step, the postmortem is written, nothing is left on the Mac
PROOF: `python3 "/Users/nickdeck/Documents/Claude 2.0/projects/ops/agents/check_plan.py" "/Users/nickdeck/Documents/Claude 2.0/projects/ops/life-os/REGROUP-2026-09-08/plans/RULE-TRIM/PLAN.proposed.txt"`
## NEXT
Everything found after the FINISH LINE passes goes here as one line, and is not worked. Empty at plan time.
- 2026-09-10 — THE SYNC ALARM MISDESCRIBES WHAT IT FOUND. auto-pull reports "The business project cannot pull the other machine's work - a conflict needs resolving by hand." Measured at the same moment: no merge in progress, no rebase, ZERO unmerged files. The real state is 18 uncommitted files from a session editing right then, and 37 commits behind. Someone acting on that message goes hunting for a conflict that does not exist, and the honest message is "another session has unsaved work here". Not worked: it belongs to the sync job's own lane.
- 2026-09-10 — THE FLEET AUDIT'S LIVE-FEED SWEEP REPORTS 27 FAILURES and the family app's freshness contract is 270 hours stale. Both were invisible until a dead shortcut into the retired old workspace was repointed today. Not worked: they belong to the lanes that own those feeds.
- 2026-09-10 — THREE CONTRADICTIONS BETWEEN LIVE RULE FILES NEED A RULING, NOT AN EDIT, and are with Nick: whether creating a new persistent file needs his approval, against "the four are the whole list"; whether a credential we generated ourselves is ours to rotate, which reads as absolute in Rule 13 and as ours in Rule 11 and RULEBOOK 4-i(b); and whether only Nick or Chantelle marks work done, against Rule 22's "a passing check closes the step".
## POSTMORTEM
WHAT THIS LANE WAS FOR: a new agent could not find Nick's rules. The first cold read had to search the
filesystem and got back six competing copies of the rules file, and two of its five answers were
contradicted by another live file. Five readers later, the same five questions are answered correctly
in 47 seconds by following pointers, with nothing to search for and no dead ends.
🔴 THE BAR WAS NEVER MOVED, AND THAT IS THE PART WORTH KEEPING. At 64 seconds the honest thing was to
put the target to Nick rather than redefine it, and the answer was to keep cutting. Every cut after
that came from something a reader MEASURED — no contents list, a pointer saying "Rule 22" without
naming a file while the file it sat in had its own rule 22, a contents list buried at line 514 of 606,
a rule heading carrying no subject, two numbering schemes making a bare "rule 5" ambiguous. None of it
came from guessing what might be slow.
WHAT THE READERS FOUND THAT WAS WORTH MORE THAN THE TICK. Six contradictions between files, and the
two that mattered most were in the rulebook that is pulled into EVERY session automatically while the
machine-rules file is not — so where the two disagreed, the stale one was the one agents acted on. It
said the data floor covers "financial account detail", which makes a careful agent refuse to send an
invoice to a cheap model, and it gated health and family content behind a redaction class that Nick
had already retired. Both now match his own words.
🔴 THE MISTAKES IN THIS LANE WERE MOSTLY MINE, AND THEY ARE THE RECORD. A cut of 37,509 to 17,999
characters looked like a clean win and had deleted three live rules. A ruling was labelled verbatim
with its last nine words missing, turning a temporary setting of Nick's into a permanent one. A
contents list shipped with every line number wrong, because they were computed before the list was
inserted. That same list claimed rules 1 to 10 were not in the file when they are at the top of it —
a confident false negative written into a governing file and repeated to Nick. And the cheap lane was
blamed for two failures that were defects in my own proof. Each was caught by someone re-reading, not
by the person who made it, which is the argument for the readers.
WHAT IS LEFT, NAMED RATHER THAN QUIETLY CARRIED: creating a new persistent file needs approval per
three separate files, against "the four are the whole list"; credential rotation reads as absolute in
one rule and as ours to do in two others; and the rulebook still says only Nick or Chantelle marks
work done while Rule 22 says a passing check closes the step. All three are contradictions between
live files, none is a blocker, and each needs a ruling rather than an edit.
2026-09-09 — LANE OPENED. PLAN.proposed.txt written by Boris, the senior engineer, in the plan skill's 2026-09-09 shape. Eleven steps: 1–7 FRONT, 8–11 POLISH. Nothing has been built and nothing has been trimmed yet; every percent in STEPS.json is 0.
2026-09-09 — MEASUREMENT BASELINE, taken before any edit, so the trim's effect can be proven. The five rule files read about 158,000 bytes in total (the rulebook 18,087 · the machine rules about 97,700 · the global rules 19,093 · the top-level instruction file 16,007 · the file standard 7,159). The briefing every dispatched worker receives read 37,359 characters and then 37,509 characters forty minutes later, and in both readings it did NOT contain Nick's newest ruling of 2026-09-09 while it did contain the one before it. Eleven rules are numbered headings, 11 through 21; the two rulings of 2026-09-09 have no heading of their own and sit inside the travel block already using the numbers 20 and 21, so each of those numbers names two different rules. Nine per-lane notes files hold 20,699 bytes. Fifty-five tracked files still carry the closing heading retired on 2026-09-09, the great majority of them archives, evidence records, logs, guard fixtures and design mockups that this lane deliberately leaves alone. All five named nightly guards passed before anything was touched.
2026-09-09 — FINDING, recorded because it changes how every step must work: the machine rules file is being edited by another session while this plan is being written. It measured 98,215 bytes, then 97,670 bytes about forty minutes later, with three working-tree snapshot commits against it in between, and one rule's heading changed wording between two readings taken minutes apart. Three of the planner brief's own figures had already moved by the time they were re-measured. Consequently no step in this plan cites a line number, every step re-measures its target immediately before editing it, and the machine rules file is written by one step at a time.
2026-09-09 — FINDING, recorded for the builder: the health safety section of the top-level instruction file is 4,233 bytes and fingerprints identically across consecutive readings, so it is a sound before-and-after test. Its recorded value is in the plan's STEP 5. A single character of difference fails that step and reverts it from the copy in the evidence folder.
2026-09-09 — COLD READ, ROUND 1: NOT READY. A checker that wrote none of the plan read it against the brief and rejected it. Four of its findings were settled by reading the code and the files, and all four were CONFIRMED — one of them worse than reported. The first draft was internally impossible (a rule cannot be both a heading and inside the worker briefing, because a heading terminates that briefing); it would have replaced the four approval classes and the data floor with pointers to a file that nothing automatically loads; its safety fingerprint excluded the health guard section it claimed to protect; and three of its steps aimed at the same file on the first pass. Twelve corrections have landed. Every finding, every fix and the nine findings CARRIED rather than fixed are recorded in CHECK.txt.
2026-09-09 — 🔴 THE TWO GATES HAVE NOT BEEN RE-RUN SINCE THOSE CORRECTIONS AND THE PLANNER COULD NOT RUN THEM. Both passed on the earlier version; that pass no longer describes this file. The planner holds no shell and the dispatch gate refused its read-only verification briefs. THE OVERSEER RUNS THE THREE COMMANDS AT THE END OF CHECK.txt BEFORE ITS FIRST DISPATCH, and a second cold read is owed on the corrected plan. NOTHING IS COMMITTED BY THE PLANNER — the overseer commits.
2026-09-09T23:25:12Z - Programme planner re-ran both gates on the corrected plan: both PASS (exit 0); plan fingerprint 5ef6f55c98da2cafd1e3b3b69bcab168f447baad1194a9b3b06e74a45f2184f8. Committed to main by pathspec. The overseer still owes a second cold read before its first dispatch.
2026-09-10T01:16:51Z - HANDED OFF: Nick approved the plan for hand-off ("handed off", 2026-09-09). The overseer prompt is HANDOFF-PROMPT-FOR-BUILDER.txt in this folder; its first act is one more independent cold read.
2026-09-10T03:15:57Z — STEP 1 DONE, AND IT DEPARTS FROM THE PLAN'S OWN INSTRUCTION. Recorded here in full because the
departure is the whole point and nobody but the overseer has graded it.
WHAT THE PLAN SAID, in two places that disagree. Item 2 of STEP 1 says the side with FEWER citations is the side
that gets the new number. Item 3 says, fixed and reasoned, that the two rulings of 2026-09-09 take 22 and 23 and
that headings 11 through 21 are untouched. Those cannot both be followed: the rulings are the MORE cited side.
WHAT NICK SAID. 2026-09-10, verbatim: "traid and verify then act i dont care". So: an independent verifier and an
adversary were dispatched, then the overseer acted.
WHAT THE ADVERSARY FOUND, and it killed the overseer's own first answer. The overseer was leaning toward moving
both headings, on a count of 32 against 2. That is wrong for a reason no count surfaces: FOUR OF THE FILES THAT
CITE HEADING 21 BY NUMBER ARE APPEND-ONLY RECORDS OF WHAT NICK HIMSELF APPROVED. tickets.jsonl line 158 records
his Slack one-tap as "Add Rule 21: a plan/state document is done only while the new pm-currency-watch check
passes against it", and ticket-requests.jsonl and pending-approval-relays.jsonl carry the same wording. Renumber
that rule and the record of what he approved becomes permanently wrong, and it cannot honestly be edited —
this workspace's own rules forbid updating a dated record to match a later rename.
The adversary also corrected a factual premise: the review heading is NOT older than the cloud ruling. Its
current wording was written 2026-09-09 at 17:20, eighty-eight minutes AFTER the cloud ruling took the same
number at 15:52. Only the currency-check rule at heading 21 is genuinely old (2026-08-29).
WHAT WAS ACTUALLY DONE, and why it beats both of the plan's options. The plan and the overseer both framed this
as one choice — which SIDE moves. It is two independent choices, one per number, and taking them separately is
strictly cheaper than either side-wide answer:
20 stays with the cloud ruling (25 files cite it by number) — the review rule moves to 22 (ZERO live files
cite it by number outside the rules file itself; the three the first count found were false positives —
one was the string "rule 2026-08-28", two meant the cloud ruling)
21 stays with the currency check (Nick's approval record names it by that number) — the written-once ruling
moves to 23 (8 live documents, every one an editable lane plan from the last day, all updated in this change)
Cost: 14 lines across 9 documents. Zero append-only records touched. Both of the plan's options were worse —
its own direction would have cost 33 edits, the overseer's first instinct would have falsified four records.
PROVED, not asserted. The collision was not only in the file: the SAME 37,509-character briefing every dispatched
worker receives contained "RULE 20" meaning the cloud ruling and "Rule 20" meaning the review rule. Measured
before: RULE 20 x1, Rule 20 x1. Measured after: RULE 20 x1 (cloud), Rule 22 x1 (review). One number, one meaning.
STILL OPEN, found while proving the above and NOT fixed here because it belongs to a later step: the written-once
ruling STILL does not reach a dispatched worker at all. The briefing loader stops at the next heading, and that
ruling sits below it. It is a rule no worker has ever been given.
A NOTE FOR WHOEVER WRITES NEXT: the rules file is edited by other sessions continuously. Re-measure immediately
before writing; do not trust a line number from this entry, including its own.
2026-09-10T12:36:01Z — STEP 2 IN PROGRESS, and a trap found the hard way that the next writer must not repeat.
WHY THE NEWEST RULING HAS NEVER REACHED A SINGLE WORKER, now measured rather than assumed. The
loader keeps only lines beginning with ">", and STOPS DEAD at the first blank line once it has
started. RULE 23 sits at line 508 of the rules file, below a blank line at 507, and is not quoted.
So it is invisible to every dispatch. Confirmed by loading the block and searching it: RULE 20
true, RULE 23 false.
THE TRAP, and it cost a full cut-and-revert. The block is 49 lines. FOUR of them are enormous:
line 1 is 13,984 characters, line 3 is 2,885, line 10 is 16,512, and the rest are ordinary. Line
10 OPENS with "THE ORIGINAL CONTESTED NOTE, KEPT BELOW FOR THE RECORD — READ AS HISTORY, NOT
CURRENT POLICY", which reads like a clean 16.5 KB deletion and is 44% of the whole briefing. It is
not. That single line ALSO carries live numbered rules further along it — RULE 17 (an agent's
pasted command output is a claim, not evidence) and RULE 19 (test and prove an assumption before
you bring it to a person) among them. A phrase-anchored cut removed the line whole, the briefing
fell from 37,509 to 17,999 characters and looked like a win, and a check for the ten required
things caught three of them newly missing. Reverted from the evidence copy; the file is byte-for-
byte its pre-cut state, hash 9d84111c8dd05b4a.
WHAT THAT MEANS FOR WHOEVER CUTS IT. This block cannot be trimmed by section. It has almost no
sections — it is four gigantic lines, and retired history and live rules are interleaved INSIDE
one of them. The cut has to be made sentence by sentence, and the only honest check is to load the
block afterwards and search it for each of the ten things the plan names, one at a time. Cutting
to a character count alone will silently delete live rules and report success.
MEASURED, for the next writer, so nobody re-measures it: line 1 = 13,984 chars (carries plain
English, the four approval classes, the data floor, find-the-plan, RULE 17, RULE 19, and more);
line 3 = 2,885 (progress tracking, which the plan puts OUT of the block); line 10 = 16,512 (mixed
history and live rules); lines 12-34 = the seven housekeeping rules, about 2,300, which stay; lines
36-49 = RULE 20, about 1,500, which condenses to one sentence. Two of the ten are absent from the
briefing today and were absent before any cut: the closing-message shape and the search command
that is not shadowed by ignore rules. Both have to be WRITTEN, not moved.
2026-09-10T12:48:11Z — STEP 2 CLOSED. Proof: 13073 true true (needs 8000-14000, then true true). The briefing every
dispatched worker receives went from 37,509 characters to 13,073, a 65% cut, and it now carries
Nick's newest ruling for the first time since it was written.
WHAT WAS WRONG. RULE 23 sat one line below a blank line. The loader keeps only lines beginning with
">" and stops dead at the first blank line once it has started, so that ruling was invisible to
every agent ever dispatched. Not a subtle bug — a rule nobody had ever been given.
HOW THE CUT WAS MADE, and why not the obvious way. Every kept passage is sliced VERBATIM out of the
old block, character for character, located by its opening TEXT and never by a byte offset. Only
two lines are written rather than copied — one sentence each delivering RULE 20 and RULE 23 with
number, date and what the rule actually requires — because a bare pointer to the rules file is
worthless: nothing loads that file automatically, so a worker handed a reference holds no rule.
Nothing was paraphrased, so Nick's own quoted words are byte-identical to what they were.
THE CHEAP LANE WAS TRIED FIRST AND ALL THREE VENDORS FAILED, measured: zai timed out at 120s with
nothing received, deepseek returned a 400 on reasoning_content, qwen timed out at 120s. The 37 KB
input is past what they will hold. cheap-task reverted cleanly and created no file. The remaining
work was verbatim deletion, which is mechanical, so the overseer did it and proved it.
TWO REGRESSIONS THIS STEP CAUGHT IN ITS OWN WORK, both from cutting by section rather than by
sentence. First: the 16.5 KB section the block itself labels "READ AS HISTORY, NOT CURRENT POLICY"
is only about 1 KB of history — live numbered rules are interleaved further along that same single
line. Cutting it whole deleted three live rules while the character count looked like a win.
Second, and only found by RUNNING the dispatch gate's own test rather than reading the text: the
block's first 58 characters are the words "MACHINE RULES (projects/ops/MACHINE-RULES.md, binding)",
and the gate's refusal message embeds the block and asserts it contains "MACHINE RULES". A cut
starting at the first red marker drops that prefix and takes the gate red. Both were reverted from
the evidence copy byte for byte and fixed. test-dispatch-gate now reads 12/12 PASS.
THE GATE THAT MAKES THIS SAFE TO REPEAT is in the lane's evidence folder as check-new-block.mjs. It
tests the ELEVEN things the plan requires, one pattern each, and canaries every pattern against
text containing none of them before trusting any result. A character count cannot tell a trimmed
briefing from a gutted one; this can, and it red-proved against the old block before being used.
2026-09-10T13:00:07Z — STEP 3 CLOSED on its stated proof, with ONE part of its definition of done deliberately NOT
done. Both are recorded here in full.
PROOF: RULEBOOK.md 17,867 bytes (started 18,087) and FILE-STANDARD.md 6,890 (started 7,159), both
below their recorded starting sizes; the live data-rules guard exits 0. Two purpose-built gates in
this step's evidence folder also pass, each red-proved against the file before being trusted.
WHAT WAS ACTUALLY WRONG WITH THE ORDER, measured rather than taken from the brief. The plan says the
list "runs out of sequence near its end". There are TWO breaks, not one, and the second is nowhere
near the end: rules 2a and 2b sat after 4b instead of after 2, and rules 40, 41 and 41a sat after 43
instead of before 42. Both are fixed. The file now reads 1, 2, 2a, 2b, 3, 4, 4a, 4b, 5 ... 39, 40,
41, 41a, 42, 43 with all 48 rules present, none renamed and none renumbered.
A TRAP INSIDE THE REORDER, caught by reading the result rather than trusting the move. Moving rules
40, 41 and 41a on their own left their section heading "## Declaring done" behind, which silently
filed three rules about verification and project files under "## Cross-agent collaboration" and left
the other heading standing over nothing. The move now takes whole SECTIONS, heading included. The
reorder script also refuses unless the file's characters are identical before and after — a move
rearranges, it never edits — so a reorder cannot quietly lose a sentence.
THE CHEAP LANE: THREE FAILURES, TWO OF THEM MINE. Two route-build dispatches failed on the block
move, once combined and once narrowed to a single move with quoted start lines, and both reverted
cleanly. That is a genuine vendor limit on multi-line block moves, recorded through route-override,
and the overseer did the move with a script. The THIRD failure was the dispatcher's fault, not the
vendor's: the proof contained test $(wc -c < FILE-STANDARD.md) -lt 7159, and the shell expanded that
substitution when the dispatch was TYPED rather than when the proof RAN, so it read test 7159 -lt
7159 and could never pass whatever the vendor produced. Two attempts were burned on an unpassable
proof. Rewritten as a script, the same work passed on the first attempt. A proof that cannot pass is
always the dispatcher's bug.
🔴 ITEM 4 OF THIS STEP IS NOT DONE, AND MUST NOT BE DONE AS WRITTEN. It says that wherever these two
files restate a rule the machine rules file already carries — the four approval classes, the data
floor, plain English, the review rule, the routing rule — the restatement is replaced by that rule's
number and date. Measured before acting: CLAUDE.md auto-loads RULEBOOK.md and FILE-STANDARD.md, and
NOTHING auto-loads projects/ops/MACHINE-RULES.md. So carrying out item 4 would delete the four
approval classes and the data floor from every session's loaded context and leave behind a reference
to a file no session ever opens. That is precisely the defect STEP 2's own specification names in its
item 3a: "A bare pointer would be worthless: nothing that loads automatically imports the machine
rules file, so a worker handed a reference holds no rule." The plan contradicts itself between two
steps, and the half with the measurement behind it wins. Item 4 is held for Nick or a replan; the
rest of STEP 3 is complete.
2026-09-10T13:06:09Z — STEP 4 CLOSED, with its item 4 held for the same measured reason STEP 3's was.
PROOF: GLOBAL-CLAUDE-RULES.md 17,821 bytes (started 19,093); the closing-shape guard
_test-4d-recap-rules.mjs reports 79 passed, 0 failed. The step's own gate, in this step's evidence
folder, passes all fifteen checks and was red-proved against the unmodified file first.
🔴 THE BIGGEST FIND, AND IT WAS ACTIVELY MISLEADING EVERY MACHINE AT ONCE. This file is what
~/.claude/CLAUDE.md is a symlink to on all three Macs, so it loads at the start of every session
everywhere. It carried a banner announcing "THE FILE-GOVERNANCE GATE IS BACK ON (restored 2026-08-30
09:41 UTC)". Measured against the live kill switch before touching anything: the gate is OFF right
now, Nick switched it off himself on 2026-09-09 at 20:22 UTC for twenty-four hours. So every session
on every machine has been reading that governance is ON while it is OFF. The banner now states the
current truth in one sentence and names 2026-09-10T20:22 UTC, the exact time the gate returns, so
the note cannot rot silently the way it just did. The paragraphs about an OLD banner being deleted,
rotting and being restored by another agent are gone — those were notes about a note.
VERIFIED RATHER THAN REPEATED. The file claimed all three Macs carry the symlink, dated 2026-09-09.
Rather than re-dating a claim, it was re-measured today: this Mac reads its own symlink, and both
nicks-mac-mini.local and chantelles-mac-mini were reached over SSH and each returned a symlink
pointing at its own checkout of this file. True, so it stays, dated 2026-09-10 and cut to one
sentence. The history of how Chantelle's came to exist, and a retracted claim that SSH was refused,
are deleted.
THE FILE STOPPED REPRODUCING THE HEADING IT RETIRED. Its communication-style section quoted the exact
wording of the closing heading the 2026-09-09 rule retired, inside a sentence explaining why that
heading is wrong. A rules file that reproduces a retired shape teaches the shape. It now describes it
instead, and the retired wording appears nowhere in the file.
THREE EDITS AT ONCE FAILED; ONE AT A TIME PASSED FIRST TRY, EACH. The combined dispatch failed twice
with "its SEARCH text is not in the file" — a cheap vendor asked for three separate replacements in a
19 KB file loses its place. Split into three dispatches, every one landed on the first attempt with
zai. That is now the working shape for this file: one edit per dispatch, each with its own survival
greps.
A MEASUREMENT TAKEN MID-WRITE READ FALSE, AND NEARLY WENT INTO THE RECORD AS ONE. Immediately after
the third dispatch the gate reported the file unchanged at 19,093 bytes with four failures; run again
seconds later it read 17,821 and passed everything, and three readings a minute apart all agree at
17,821. The first reading landed inside the window where the tool had not finished writing. Nothing
was wrong with the edit — but a single reading taken right after a write is not evidence, and this one
would have been reported as a failed step.
🔴 ITEM 4 IS HELD, same reasoning as STEP 3's item 4 and same measurement. It says rules this file
restates that the machine rules file owns should be replaced by that rule's number and date. This file
auto-loads on all three machines; projects/ops/MACHINE-RULES.md auto-loads on none. Carrying it out
would strip the four approval classes out of every session on every machine and leave a pointer to a
file nothing opens — the exact defect STEP 2's item 3a names. Held for Nick or a replan.
2026-09-10T13:15:27Z — STEP 6 CLOSED. Proof: no NOTES-FROM-NICK.txt remains under the plans folder (the count is 0).
STEP 5 is HELD on Nick's approval, so this step ran ahead of it rather than waiting — see below.
WHAT WAS IN THE NINE FILES. 21,155 bytes, 130 lines, all nine copied into this step's evidence folder
with their hashes before anything was read. Sorted one ruling at a time: almost everything governs one
lane's build, and exactly two rulings govern every agent while being stated nowhere in the numbered
list.
THREE RULINGS WERE ALREADY CARRIED, and checking that first is what stopped this step writing three
duplicate rules — the workspace's own ownership rule is extend, never build a second. The data floor
("if the worker doesnt hold a token credential password or ssn etc its not a problem") is already in
MACHINE-RULES twice as the four categories with no fifth. The cheap-then-Anthropic routing ruling is
already Rule 16. The cloud ruling is already RULE 20.
TWO WERE CARRIED NOWHERE AND ARE NOW NUMBERED RULES. RULE 25: a security pass runs on the free tier and
there is no paid-scan decision to put to him (Nick, 2026-09-08, "why not do it free?") — this retires
the line "a paid scan is a separate money decision for Nick" from every lane plan that carried it.
RULE 26: sending as him is standing permission internally and ONE TAP PER MESSAGE for anything
client-facing (Nick, 2026-09-08, "skippy same rules as hub"). Numbers 25 and 26 were confirmed free
immediately before writing — 22, 23 and 24 are taken, and 24 was taken by another lane today.
NO TICKET WAS NEEDED, and that is recorded rather than left implicit: the documentation gate is OFF by
Nick's own hand until 2026-09-10T20:22Z, measured against the live kill switch rather than assumed.
EVERY LANE RULING LANDED BEFORE ITS FILE WAS DELETED. One dated line under each of the nine lanes' own
"Already true", naming that lane's rulings in Nick's words. Verified afterwards: exactly one line added
per plan, nine plans, nine insertions and zero deletions — no step, scope line, finish line or decision
list was touched.
DELETION WAS PROVED REVERSIBLE BEFORE IT HAPPENED, not asserted. All nine files are tracked, and each
one was confirmed present on the SERVER at origin/main, not merely in this Mac's history. That is what
makes this not one of the four approval classes.
🔴 A FINDING THIS STEP DID NOT FIX, because it is outside the files the step may touch: eleven more
scratch files of exactly the same class exist under a different name — NOTES.txt, in BRAINS, HEALTH,
SKIPPY, AGENTS, VOICE, FILES, SKILLS, SCHEDULED, HUB, JASMIN-CAPTUS and LANE-6-FAMILY-APP. All eleven
predate this step (committed 8 and 9 September), so the step's "no new notes file appeared" condition
holds. But RULE 23 forbids a notes file for a ruling whatever it is called, and the plan named only the
nine. Whoever replans should decide whether those eleven get the same treatment.
2026-09-10T13:23:15Z — STEP 7 RUN, AND IT FAILS. Recorded as a failure rather than smoothed into a pass, because the
failure is the finding and it is worth more than the step's green tick would have been.
TWO INDEPENDENT COLD READERS ran the same five questions, each in its own session, neither having seen
this work. Both finished inside the minute — 45 seconds each. Both records are in this step's evidence
folder. The step's own FAILS IF clause is explicit: it fails if any answer is wrong, any location is
wrong, or THE READER HAD TO SEARCH RATHER THAN READ. The first reader had to search, and two of its
five answers are contradicted by another live file. So: fail.
EVERY FINDING BELOW WAS RE-MEASURED BY THE OVERSEER BEFORE BEING WRITTEN DOWN. None of this is the
reader's word taken on trust.
1. THREE OF THE FIVE ANSWERS ARE NOT IN THE FILES A SESSION ACTUALLY LOADS. CLAUDE.md pulls in exactly
two files, RULEBOOK.md and FILE-STANDARD.md. The message-shape rule, the write-a-ruling-once rule
and the live review rule all live in projects/ops/MACHINE-RULES.md, which loads automatically
nowhere. This is the same measurement that made this lane hold item 4 of STEP 3 and STEP 4 — now
confirmed from the outside by a reader who knew nothing about that argument.
2. MACHINE-RULES.md IS NAMED IN RULEBOOK.md AND NEVER WITH A PATH. Measured: zero occurrences of
"projects/ops/MACHINE-RULES.md" in RULEBOOK.md. The reader had to run a filesystem search to find
it, and that search returned SIX copies — four inside .claude/worktrees, one snapshot under
projects/ops/life-os. Reading the wrong copy is a coin flip.
3. GLOBAL-CLAUDE-RULES.md IS NEVER MENTIONED IN CLAUDE.md. Measured: zero occurrences. The file that
describes itself as the one every machine reads is reachable only by listing the folder.
4. THREE DEAD POINTERS INTO CLAUDE.md. FILE-STANDARD.md and MACHINE-RULES.md both cite a numbered
section of CLAUDE.md — §4B, §4D, §4Z. Measured: CLAUDE.md has ZERO numbered sections. All three
resolve to nothing.
5. 🔴 TWO RULES CONTRADICT EACH OTHER ON WHAT "DONE" MEANS, AND A READER STARTING WHERE THEY ARE TOLD
TO START REACHES ONLY THE OLDER ONE. MACHINE-RULES Rule 22 (2026-09-09): one proof, one checker,
once, and the three-opinion review runs only when Nick asks for it by name. RULEBOOK rule 40: nothing
is DONE without a real triad — propose, attack, fresh cold check — and rule 33 adds a fourth reviewer
on a major build. Both verified present today. Rule 22 pre-emptively rejects the reasons rule 40
gives. RULEBOOK.md auto-loads; MACHINE-RULES.md does not; so the rule everyone actually reads is the
superseded one.
6. 🔴 DECISIONS.md IS A LIVE 11 KB DECISIONS DOCUMENT, AND RULE 23 BANS EXACTLY THAT. Rule 23
(2026-09-09) says a ruling is written once, in the machine rules file, and explicitly forbids a
decisions document. DECISIONS.md says a ruling goes in two places and is written BEFORE acting. It is
still populated and still cited from RULEBOOK.md. Neither file acknowledges the other.
WHAT THIS STEP DOES WITH THAT, per its own instruction to loop back once with the wrong answer named:
findings 2, 4 and 5 belong to STEP 3's files and finding 3 belongs to STEP 5's, which is held on Nick's
approval. Findings 5 and 6 are not editorial — they change what "done" means and whether a whole file
keeps existing — so they are named for Nick rather than decided by an overseer at one in the morning.
STEP 7 stays open until they are settled and the read is repeated.
2026-09-10T13:27:32Z — STEP 8: its stated proof PASSES and its real question is answered NO for four of the five
guards. Both halves recorded, because the second is the one worth having.
THE STATED PROOF PASSES. All five named guards run in one chain and the chain exits 0. NO FIXTURE WAS
EDITED, and that is the honest outcome rather than a shortcut: this step exists to repair guards whose
quoted wording STEP 1 to STEP 6 changed, and nothing those steps changed broke a guard. A fixture edit
nobody needed would have been a change made to look busy.
🔴 THE REAL QUESTION, AND IT IS NOT "DO THEY PASS". A guard that cannot go RED is not protecting the
rule it names, whatever it prints. So each of the five was pointed at a deliberately broken copy of the
thing it watches — a copy, never the live file — and required to fail.
· the closing-shape guard: PROVEN ABLE TO FAIL. It honours MACHINE_RULES_OVERRIDE, so it was pointed
at a copy of the rules file with the closing rule's own name stripped out, and it went red.
· the guard that watches that guard: CANNOT BE RED-PROVED FROM OUTSIDE.
· the live data-rules guard: CANNOT BE RED-PROVED FROM OUTSIDE.
· the category-list divergence guard: CANNOT BE RED-PROVED FROM OUTSIDE.
· the worktree fence guard: CANNOT BE RED-PROVED FROM OUTSIDE.
Four of the five read fixed paths with no environment override and no path argument. There is no way
to hand them a broken copy, so the only way to see one of them go red is to break the real file the
whole workspace depends on — which nobody should do, and which is exactly why it never gets done. Their
green is therefore unverified. It is probably honest; it is not proven, and this workspace has already
lost a night to a test that passed on silence.
WHY THIS STEP DID NOT FIX IT. Adding a path override to a guard is not fixture text, and this step's
file rule is explicit: only the fixture text inside a guard may be touched, never an assertion, a
threshold, a count or a skip condition. Widening that on my own authority is precisely the shape of
failure the rule is written against. So it is named here, with the fix stated so nobody has to
rediscover it: give each of the four the same MACHINE_RULES_OVERRIDE-style hook the fifth already has —
one line each, no assertion touched — and this step's definition of done becomes provable rather than
assumed. That is a small, contained follow-on, and it needs a step of its own rather than a quiet edit
inside this one.
The red-proof script and its full output are in this step's evidence folder, so the next person re-runs
it rather than re-deriving it.
2026-09-10T13:37:40Z — STEP 9 CLOSED. Proof: the three closing-format documents are 421, 430 and 429 bytes, each far
below the 1,200 the step allows. They were 25,655, 21,055 and 25,221 — 71,931 bytes of settled argument
reduced to 1,280 bytes of pointer. The fourth file in the fence, the board prompt, no longer teaches the
retired shape. Exactly four files changed and nothing else.
WHY THEY WENT. All three argue for a message format Nick ADOPTED on 2026-09-09. Two of them are already
stamped ADOPTED in their own first lines. An argument that has been settled, left standing beside the
rule it produced, is a second thing to read that can disagree with the rule — and this lane has already
found two live cases of exactly that. Each is now one line naming what was adopted, its date, and where
the live rule is. Git holds every word of what they argued.
ONE HONEST ADJUSTMENT TO THE STEP'S OWN WORDING. It says each one-liner should carry "the number of the
rule that now carries it". Measured first: the closing-message rule HAS no number. It lives inside the
travel block as a named block, CLOSING-MESSAGE FORMAT, dated 2026-09-09. So the pointers name the rule
and its date rather than inventing a number for it. Recorded rather than silently substituted.
🔴 TWO DISPATCH LESSONS, BOTH PAID FOR HERE.
FIRST: a whole-file replacement cannot be expressed as a search-and-replace patch. Three route-build
dispatches, one per file, all failed identically with "the model could not produce an applicable edit"
— because that tool sends the vendor a SEARCH block to match, and matching an entire 25 KB file is not
something a patch can express. Nothing was wrong with the briefs. All three files were verified
byte-identical to their snapshots afterwards. The right tool for replacing a whole file is cheap-task,
which holds write_file; it did all three in one pass on its first attempt.
SECOND, AND IT COST A COMPLETE PASSING RUN: A GATE THAT IS WRONG ABOUT ONE FILE PUNISHES WORK ON EVERY
FILE IT GUARDS. The first cheap-task run rewrote all three documents correctly and every check on them
passed — and the whole change was reverted, because the same gate was also checking a fourth file and
its pattern for "teaches the adopted shape" required the exact phrase "one paragraph" while that file
said "one short paragraph". The file had been fixed an hour earlier. The gate was wrong, the work was
right, and three correct rewrites were thrown away on a false negative about something else. The gate's
pattern is fixed and carries a comment saying why, and the same work then passed first try.
2026-09-10T13:44:54Z — STEP 10 CLOSED, and closing it honestly required landing everything on main first.
MEASURED, ALL THREE MACHINES: symlink present and pointing at each machine's own checkout of
GLOBAL-CLAUDE-RULES.md, and the file itself 17,821 bytes with fingerprint 5e846962e5892a91 on every
one of them. Identical. That is the step's plain title actually satisfied, not just its proof.
🔴 IT WAS NOT TRUE AN HOUR AGO AND THE SYMLINK CHECK WOULD HAVE PASSED ANYWAY. All three links were
correct all along; the three machines were reading three DIFFERENT files — this Mac 17,821, the mini
19,093, Chantelle's 17,483. The step's stated proof only asks whether the link points at the global
rules file, so it would have gone green while every machine read something different. The link is not
the thing that matters; what the link RESOLVES TO is.
WHY THEY DIFFERED, and it is the finding of this step: every one of this lane's seven branches was
still only a branch. Nothing from tonight had reached main, so nothing had reached any other machine.
Work that is proven, pushed and unmerged is invisible — which is RULE 20's own point, made against
this lane's own working habits.
WHAT WAS DONE. All seven branches were landed on main as ONE commit rather than seven merges: every
branch touches the lane's PROGRESS.txt and the programme plan, both append-only, so each merge
conflicts on the same two files and the conflicts compound. The seven are not independent work, they
are seven snapshots of the same files; the final state is what was proven. All seven remain on the
server as the audit trail. Then the four rule files were fetched onto each machine by name — never a
full pull, which can revert another session's uncommitted work.
TWO REPAIRS ON THE WAY. Main had moved twice while this ran and was merged in both times (the newer
commits were family-app work and touched nothing of this lane's). And Chantelle's machine could not
fetch at all: a zero-byte .git/index.lock left by a crash on 8 September, two days stale, was blocking
every git command there — cleared after checking it was empty and over an hour old, which is what git's
own error message instructs.
🔴 A REGRESSION CAUGHT AT THE LAST GATE BEFORE THE PUSH, worth recording because the plan's own
reasoning is what caused it. STEP 2 states that the block carries a one-sentence delivery of each
2026-09-09 ruling while "the full paragraph of each rule still lives once, in its numbered heading in
the list". True for RULE 23. FALSE for RULE 20: its full paragraph, carrying Nick's verbatim words
about one cloud copy, lived ONLY inside the travel block. So cutting the block replaced his words with
a summary and deleted the only copy. Caught by diffing every rule definition against main before
pushing rather than trusting the earlier green. His 1,482 characters are restored to the numbered
list; the short delivery stays in the block; the briefing still measures 13,073 with both rulings
present.
ALSO ON THE WAY IN: a pre-commit gate refused the landing because this lane's own STEP 9 evidence
folder held copies of the three retired documents, and those carry struck-through wording. The gate is
right and its rule is this lane's rule: a document in the repo is current instructions, git holds the
history, and a second home for retired wording is the thing this whole lane exists to remove. The
copies were dropped from the commit.
2026-09-10T14:09:08Z — NOT A STEP. A live fault found while landing this lane's work, and it defeats the whole
programme's north star on this machine. Recorded here because this lane found it and no plan owns it.
WHAT WAS TRUE: 40 commits existed ONLY on this Mac, on no remote branch at all — measured one commit
at a time with "does this exist anywhere else", not by comparing against a named branch. They were
not this lane's: the School lane's audit and handoff, Pearl Health's state and history, and more.
All 40 are now on the server at preserve/mac-studio-40-unpushed-202609101358, and a sweep copied 15
more unsaved things off. Nothing on this Mac now exists in only one place.
WHY THEY WERE STRANDED, in autopush's own words from its log, repeating every few seconds:
"deck-brain is ahead 40 AND behind 75 — not pushing. auto-pull rebases hourly; this will clear
itself." It does not clear itself. autopush is alive and healthy — it pushes the business app and
skippy-code every run — and it deliberately refuses THIS repository while it is diverged, waiting
for a reconcile that is not happening.
MEASURED, NOT ASSUMED, because two earlier readings of mine were wrong. auto-pull was run by hand:
it committed the 35 uncommitted files but did NOT rebase, leaving the repository 46 ahead and 85
behind — further apart than before, not closer. Its own log file has not been written since
24 August. So the sentence autopush prints as reassurance is false, and has been for as long as this
workspace has been diverged.
🔴 TWO CORRECTIONS TO WHAT THIS LANE REPORTED EARLIER, both from reading a symptom and naming a
cause without testing it:
· "A job commits a working-tree snapshot every two to five minutes and is reverting work." Those
commits exist but stopped at 08:52 today and are not the mechanism.
· "Something is silently reverting work." The mechanism is that this checkout's own HEAD is far
behind the server and still holds the old content, so any operation that restores a file from
local HEAD brings the old version back. Nothing is maliciously reverting anything.
The first account was built from a git log line and a file size. Neither was a test.
WHAT IS STILL BROKEN AND NEEDS A QUIET WINDOW: this workspace cannot push and the gap grows every
hour. Reconciling it means rebasing 46 commits while several sessions are writing in the same
folder — the same shape as the business app catch-up, which Nick scheduled deliberately rather than
having it happen underneath live work. Everything is preserved, so a bad reconcile is recoverable,
but it should not happen silently under other people's work.
2026-09-10T14:50:00Z — TRIAD RUN, PROPOSAL REFUTED. The first real use of Nick's 2026-09-10 ruling on when a triad
fires ("anytime there is a question about what to do to solve a problem that doesnt require me").
It worked: the proposal was mine, and it was wrong.
THE PROPOSAL: untrack the ~2,000 business-app files the outer workspace repository carries, because
that folder is its own repository and the duplicate copies were blocking every reconcile.
WHAT THE FRESH READER MEASURED: nothing in those copies is unique. All 1,935 distinct outer blobs
already exist in the business-app repository's own history, including two files deleted from disk.
So untracking would strand nothing. It also found a trap worth keeping: 1,881 of the files carry the
skip-worktree bit, so git status reports them clean while their content genuinely differs.
WHAT THE ADVERSARY FOUND, and it kills the proposal three separate ways:
· A STANDING RULING ALREADY FORBIDS IT. PLAN-6-KANBAN-PM.md line 122: "No step here runs
git rm --cached" — the action is classed as irreversible destruction, needing Nick's own yes.
Verified by opening the line. I proposed something already ruled on and did not go looking first.
· IT WOULD UNDO ITSELF. git-sync.sh is wired as the Stop hook and stages untracked files, so the
next session that ends would re-add all ~2,000. Net effect: 2,000 deletions then 2,000 additions
across a tree taking 33 commits an hour.
· IT WOULD BREAK A FRESH MACHINE SILENTLY. .mcp.json launches the business engine from
business_mcp.py at that path. On a fresh clone the file would be absent, the server would exit
before registering, and the symptom is ABSENT TOOLS — which reads as "the business record is
empty" rather than as an error. That is the most expensive misdiagnosis this workspace records.
· IT IS ALREADY AN OPEN DECISION assigned to Nick as ITEM 43 in continuity/PLAN.md. A duplicate.
WHERE THE ADVERSARY IS WRONG, stated because being fair matters more than the verdict: it reports no
outer-repository rebase abort today and concludes the aborts are all in the inner repository. The
outer repository refused three times during this session, run from the workspace root, naming
business-app files — that is in this session's own record. A rebase that cannot START does not write
a "rebase (abort)" reflog entry, so its instrument could not see what it was looking for. Its
conclusion about WHERE is wrong; its conclusion about the proposal stands on the other three legs.
🔴 THE FINDING WORTH KEEPING, which the proposal buried rather than surfaced: the outer repository
holds 126 SILENTLY STALE copies, and one of them is the business engine's own entry point. Verified
directly: business_mcp.py is flagged skip-worktree, the outer record is eef24cdef9d1, the live file
is 3fa5fb4259e8, and git status reports zero changes. Nothing on this machine will ever surface that
drift. Anyone who clones the workspace fresh, or clears those bits, gets stale business-engine code
with no warning.
🔴 AND A SEPARATE LIVE FAULT, found while checking the above: a new machine cannot obtain the
business app at all. machine-bootstrap.sh guards its whole business-app section on finding that path
in .gitmodules; the entry was deliberately removed on 2026-08-29, so the guard fails, the section is
skipped, and it prints "the business app is not set up to download". Confirmed by running the guard's
own condition. This is independent of the proposal and of the reconcile.
WHAT WAS DONE INSTEAD: nothing structural. Two stale index entries were refreshed so they stopped
blocking checkout — no untracking, no deletion, the skip-worktree flag restored. The reconcile then
started and hit conflicts at commit 1 of 60 on append-only files; it was backed out cleanly and
everything is preserved on the server. The workspace is exactly where it was.
2026-09-10T14:59:11Z — STEP 8'S FOLLOW-ON DONE. All five nightly guards can now be shown to FAIL, up from one.
That was the finding STEP 8 recorded and deliberately did not fix inside itself, because its own file
rule allowed only fixture text.
WHY IT MATTERED. Four of the five read one fixed path with no way to hand them a different file, so
the only way to watch one go red was to break the real thing the workspace depends on. Nobody should
do that, so nobody ever did, and their green was never verified. A guard that cannot fail is not
protecting the rule it names, whatever it prints.
WHAT WAS DONE, one line per guard and nothing else — no assertion, threshold, count or skip condition
touched anywhere:
· the data-rules guard: reads DATA_RULES_OVERRIDE when set. Proven — green on the real document,
exit 1 against a copy with every rule heading defaced.
· the category-list guard: reads DISPATCH_CONTRACT_OVERRIDE when set. Proven — exit 0 on the real
files, exit 1 against a copy with the category list renamed away.
· the worktree fence guard: reads WORKTREE_FENCE_OVERRIDE when set. Proven — green on the real
gate, exit 1 against a copy with every refusal turned into a pass.
· the closing-shape guard already honoured an override and was proven earlier the same way.
THE FIFTH NEEDED NO CHANGE AT ALL, and that is worth writing down so nobody adds one. It exercises the
closing-message linter as a function rather than reading a document, so there is no path to point
elsewhere. It was red-proved by copying the guard and the linter into a scratch folder, gutting the
copy so the linter can no longer report a single violation, and running the guard against it:
39 passed / 3 failed became 19 passed / 23 failed. Twenty checks that pass today fail the moment their
subject stops working. Note for whoever repeats this: the untouched copy already fails 3 of its checks
outside its real location, so the baseline for that comparison is 39/3, not 42/0.
🔴 A FALSE PROOF CAUGHT ON THE WAY, recorded because it is the exact trap this whole exercise is
about. The first attempt to gut the linter substituted a pattern that appears NOWHERE in it — zero
matches — so the file was unchanged and the guard reported the identical 39/3. Read carelessly that
looks like "the guard is blind"; it actually meant "nothing was broken". A mutation test proves
nothing until you confirm the mutation landed.
2026-09-10T18:03:43Z — STEP 7's SIX BLOCKING FINDINGS RE-MEASURED. FOUR ARE CLOSED, ONE IS FIXED TODAY, ONE IS
WITH NICK. Each was re-measured with the command that produced it, never closed on a later claim.
CLOSED, finding 2 — the machine-rules file is now named in RULEBOOK.md WITH its full path, at line
3, and the line explicitly warns off the copies under .claude/worktrees. The reader no longer has to
run a filesystem search that returns six candidates.
CLOSED, finding 4 — the three dead pointers into numbered sections of CLAUDE.md are gone. Measured:
zero occurrences of the three section references across the rulebook, the file standard and the
machine rules.
CLOSED, finding 5 — the two rules that contradicted each other on what "done" means now agree.
RULEBOOK rule 40 carries Nick's own 2026-09-10 trigger ("doesnt require me - technical stuff
mostly") and defers routine work to one proof and one checker; rule 33 now says a major build's
review IS the three-opinion review and nothing beyond it. Neither pre-empts the other any more.
CLOSED TODAY, finding 3 — CLAUDE.md named the every-machine rules file ZERO times, so a reader
starting where they are told to start could only reach it by listing the folder. One line added
naming it and how each machine loads it. Paid for by tightening the vault paragraph's dated
narration, because that file's own gate requires it to keep shrinking: 15,998 bytes to 15,994, gate
green on every check including all eight must-survive items. The staging copy that two live gates
read was twelve days stale on the vault count and is now identical to the real file.
🔴 OPEN AND WITH NICK, finding 6 — the rulings index versus RULE 23. The cold read's question 4 is
"where does a ruling from Nick get written down, and in how many places", and the two live answers
still disagree: RULE 23 says once, in the machine rules, and forbids a decisions document by name;
DECISIONS.md says the index AND the plan, written before acting. STEP 7 CANNOT PASS UNTIL THIS IS
SETTLED, because question 4 has no single correct answer to grade against.
WHY IT WAS NOT SETTLED HERE. An adversary attacked the proposal to retire DECISIONS.md and the
proposal did not survive intact. Five of the fifteen rows would lose Nick's exact words: the row
about Chantelle not actively using the surface exists in that file and NOWHERE else in the tracked
tree; the four-walls ruling and the ship-everything ruling survive only in archives; the gmail row's
only other copy is an evidence file quoting the row itself. One row is worse than lost — his "build
it" on cryptographic person-attribution, where the live plan still recorded the DEFERRAL he
overrode. And tickets.jsonl line 89 records Nick himself approving the creation of this index on
2026-08-28, confirmed in Slack under his own user id. Reading "i dont knwow what a decisions doc is"
as withdrawal of that approval is a vocabulary gap treated as a ruling.
FIXED IMMEDIATELY, because it was live and wrong either way: projects/ops/continuity/PLAN.md's
section headed "THE REMAINING THINGS THAT NEED NICK" listed two items he had already answered — the
Gracie stream (answered 2026-08-28, narrowed by him 2026-08-29) and person-attribution (answered
2026-08-29 "build it", where the line recorded the opposite). Both replaced by his answers, in his
words, with dates. Not struck through: the no-scaffolding gate refuses struck wording and RULE 23
says the same.
THE TWO OPTIONS PUT TO NICK, with a recommendation: freeze the index as a history page and delete
only the part that instructs agents where to file things (satisfies RULE 23, loses no words, keeps
the live audit passing, and is what was done for ACTIVE-WORK.md); or fold it away entirely, which
needs a real home found for five rows first.
2026-09-10T18:16:21Z — THE CLOUD-BRAIN COPY JOB: PEER CHECK DONE, TWO FIXES LANDED, ONE THING LEFT FOR NICK.
THE CHECK CLEARED THE GUARD, CONDITIONALLY. All 138 real incident paths were run through the live
function: none pass. But it had a markdown hole defended by one hand-typed dated filename, and one
live instance already existed — an IRS payment ledger, tracked, due to be republished every thirty
minutes on resume. Hole closed, ledger untracked, a direct test written and mutation-proved able to
fail. The job's two existing suites still pass 30/30 and 23/23.
🔴 THE THING THE ORIGINAL AUDIT MISSED, AND IT WAS THE BIGGER ONE. The 2026-09-03 remediation was
COMMITTED LOCALLY AND NEVER PUSHED. Measured today: the online copy's main branch still had 69 bank
and tax PDFs live in its current tree — not merely in history — including
WF-CHECKING-8780_closing_2026-06-05.pdf at 88,741 bytes and the 2024 federal return. For a week the
record said "untracked and safe" while the published copy still served them. Pushed today; measured
again from the remote afterwards: 0 PDFs, 0 ledger.
🔴 STILL OPEN AND IT IS NICK'S CALL, NOT AN AGENT'S. Those 138 files remain fully retrievable from
the repository's HISTORY — `9905fbb6^` is still an ancestor of HEAD and every blob still resolves.
Removing them from history is irreversible destruction of a shared remote and breaks every existing
clone including the cloud box's. That is one of his four approval classes. Recommend, never perform.
STILL PAUSED ON PURPOSE. The scheduled job was NOT re-enabled. Its two named blockers are fixed, so
it is ready — but turning an unattended thirty-minute auto-push back on is not something to do
without watching a run, and the session that fixed it was landing for a machine restart.
2026-09-10T18:57:02Z — FINDING 6 IS CLOSED. THE RULINGS PAGE IS FROZEN, NOT DELETED — DECIDED BY TRIAD.
NICK'S WORDS, 2026-09-10, verbatim: "i genuinely dont know traid and act to the best of your
abilities". So this was decided by review, and no part of it was put back to him.
TWO INDEPENDENT REVIEWS AGREED, one attacking a written proposal and one forming its own view from
the files without seeing that argument. Both landed on the same answer: keep the page, stop it
instructing anyone, delete no row.
WHAT ACTUALLY COLLIDED WITH RULE 23 was the section telling agents to file a ruling here before
acting on it — a competing instruction. Deleted. The section describing a message checker that was
never built went with it. All 15 rows stay, every word of Nick's untouched, and the header now says
the page instructs nobody and that RULE 23 owns where a ruling goes.
WHY NOT DELETED, each measured. Row 4 — "dont worry about chantell do what yo need to do shes not
actively using" — exists in this file and nowhere else in the tracked tree, and it records a spent
one-time unblocking rather than a standing rule, so it has no home among the numbered rules. A
nightly check reads this file and cannot tell "deliberately removed" from "broken". And Nick
approved this page being created 2026-08-28, confirmed in Slack under his own account.
🔴 THE ATTACK CORRECTED MY PROPOSAL AND THEN CORRECTED ITSELF. My first draft claimed the
instruction section was the only part that instructed anyone; it was not — several rows carry
standing orders in their description column, so the header now neutralises them rather than cutting
his words. The attacker separately claimed the ten rows trimmed this morning were a DATA LOSS and
withdrew it on re-measurement: every one is reachable in pushed history, and independently each of
the ten was verified today to have a live carrier outside archives and evidence folders. It is a
findability question, which is exactly what RULE 20 says is answered mechanically.
🔴 AND THE FLEET AUDIT WAS SILENTLY OFF. Found while checking whether this edit would be watched.
All three rows of the one manifest-driven audit — the full audit, the hourly light audit, and the
beacon whose only job is asking whether the audit itself is still beating — were commented out
2026-09-10 at 13:02:45, swept into an automatic snapshot from the Mac mini, with NO reason there and
none anywhere in the tree. Every other disabled job in that file carries a dated reason on the line
above it. They were not already dead: the light audit's last beat is 2026-09-09T21:46:51Z, a WARN
carrying 18 named findings. Restored WITH the missing note, and the audit went back on BEFORE the
governance edit, because an edit made while the watcher is off is an unmonitored edit.
TWO RAISED HANDS CLEARED, not left to sit: the fresh reviewer raised one signal per question. Both
are answered, so both were withdrawn with their reasons rather than waiting on Nick.
STEP 7 IS NOW UNBLOCKED — its question 4 has one correct answer for the first time. The cold read is
running.
2026-09-10T19:16:49Z — STEP 7 RE-RUN THREE TIMES: 105 SECONDS, THEN 86, THEN 64. STILL FAILS BY FOUR SECONDS.
All five questions answered correctly in all three runs, with the right file and the right date, and
NO filesystem search in any of them. That is the thing cold read 2 failed on, where the reader had to
search and got back six competing copies of the rules file. Findability is fixed.
🔴 THE STEP'S OWN BAR IS "UNDER ONE MINUTE" AND THE BEST RUN IS 64 SECONDS. Recorded as a failure.
The bar is NOT being moved to make it pass — it is named for Nick as a question, because moving your
own bar after missing it is the failure this lane exists to stop.
WHAT WAS FIXED BETWEEN RUNS, every one of them named by a reader rather than guessed at: the rules
file had no contents list, so an answer two thirds down meant paging 570 lines; two rulebook rules
said "Rule 22" without naming a file while the rulebook has its own rule 22 about something else;
Rule 20's heading was the only one not carrying its own subject, so a generated list could render the
most-cited rule in the workspace only as "see the rule"; and a pointer in the reporting-shape file
named a draft under a folder that does not exist.
🔴 AND ONE BUG OF MINE, CAUGHT BY THE THIRD READ. The contents list carried line numbers computed
BEFORE the list was inserted, so inserting it pushed every rule below down and every number was wrong
from the moment it was written. Removed rather than recomputed: a line number in a weekly-edited file
is wrong again on the next edit, and a confidently wrong number sends a reader to the wrong place
while looking authoritative.
FOUR CONTRADICTIONS FIXED, one serious and one also mine. THE DATA FLOOR SAID TWO OPPOSITE THINGS —
one file said money figures, rates and invoices could never leave to a cheap model, against Nick's own
later words that if it has numbers, financial data or his calendar in it, it is all good. After that
was corrected the sentence three lines below still described the enforcement code as refusing a money
figure. Checked against the live fence rather than assumed: its floor is exactly four items and its
own comment clears dollar figures, rates, invoices and P&L. THE CODE WAS ALWAYS RIGHT; both
descriptions of it were wrong, and it is the descriptions that agents read. Also: the vault size read
112, 45 and 133 across three files (measured: 133); the paid security scan was settled as free-only
on 2026-09-08 while the file every machine loads still said to ask him; and rulebook rule 33 read as
"every major build gets the three-opinion review", which is what the review rule exists to deny.
STILL OPEN, NAMED RATHER THAN QUIETLY CARRIED: creating a new persistent file needs approval per
three separate files, against "the four are the whole list"; credential rotation reads as absolute in
one rule and as ours to do in two others; 🔴 THAT ENTRY WAS WRONG AND THE ERROR WAS MINE — corrected 2026-09-10: rules 1 to 10
ARE in the machine-rules file, at the very top under "The ten rules", and the line citing "RULE 5
ABOVE" resolves correctly to rule 5. The real problem, which is what confused two readers, is that
one file carries two different numbering schemes and a bare "rule 5" is ambiguous between them; and two rules sit out of numeric order in the file.
THE AUDIT RESTORE IS NOT YET PROVEN LIVE. The three rows are back on the schedule and the scheduler is
running — its own state files were being written minutes ago — but the next light-audit slot is :35,
so nothing has fired yet. Worth a look afterwards: the FULL audit's last beat is 2026-09-07, two days
before anyone commented it out, so it had already stopped running on its own.
2026-09-10T19:20:01Z — THE CLOUD-BRAIN COPY JOB IS BACK ON ITS SCHEDULE. THAT CLOSES THE LAST ITEM THAT DID NOT
NEED NICK.
It had been paused since 2026-09-03 waiting on ONE independent peer check, and nobody had done it, so
the cloud assistant's copy of this workspace sat frozen for a week — and past 24 hours stale, that box
refuses to state confident specifics at all.
THE CHECK CLEARED THE GUARD BY CONSTRUCTION: all 138 real incident paths run through the live
function and none pass. It named two changes first and both were made. THE HOLE: the guard let ANY
markdown out of the two family-finance folders, defended by a single hand-typed dated filename — so
the same staged batch a month later, or a tax return saved as a note, walked through. One live
instance already existed, an IRS payment ledger due to be republished every thirty minutes on resume.
WATCHED BEFORE RE-ENABLING, which is what the hold asked for. First the exact selection was
reproduced WITHOUT pushing: 1,178 files, zero credential-shaped names, and the one hit inside a
finance folder was a script, which Nick's ruling makes harmless. Then one real run: 223 files pushed,
the cloud pulled them, and the remote re-measured afterwards at zero bank/tax documents and zero
credential files.
🔴 AND THE THING NOBODY HAD NOTICED. The 2026-09-03 remediation was committed locally and NEVER
PUSHED. For a week the record said the family's financial documents were untracked and safe while the
published copy still served 69 of them, every Wells Fargo statement and both 2024 returns. Pushed and
re-measured from the remote: zero.
LANE STATE NOW. Steps 1-6 and 8-10 closed. STEP 7 answers correctly and needs no search but comes in
at 64 seconds against its own "under one minute" bar — with Nick, as a question about whether the bar
is right, deliberately not moved to make it pass. STEP 11 waits on 7.
THE AUDIT RESTORE IS STILL NOT PROVEN LIVE: the rows are back and the scheduler is running, but the
next light-audit slot is :35 and nothing has fired yet. Worth a look afterwards — the FULL audit's
last beat is 2026-09-07, two days BEFORE anyone commented it out, so it had already stopped on its
own and disabling it only hid that.
2026-09-10T19:38:54Z — THE FLEET AUDIT IS NOT JUST RESTORED, IT IS FIRING ON ITS OWN AND ITS OUTPUT IS TRUSTWORTHY
AGAIN. Proven, not assumed: it beat at 19:37:12Z, after the last hand-run at 19:30:56Z, so that was
the schedule and not me.
TWO THINGS WERE MAKING IT USELESS EVEN WHEN IT RAN, and both are fixed.
FIRST, IT FAILED EVERY RUN ON THREE SKILLS THAT WERE RETIRED. It kept a hand-typed list of nine skill
files it expected; brandkit, humanizer and imagegen-frontend are gone from the workspace entirely, so
it logged an error for each, marked the whole dimension FAILED, and did that on every single run. An
alarm that is always red is an alarm nobody reads. The list is now DERIVED from the skills folder, so
it cannot go stale again, with the old array kept as the fallback so an unreadable folder fails loudly
instead of silently measuring nothing. Measured after: ok:true where it was A7-FAIL.
🔴 AND THE CHEAP LANE WAS BLAMED FOR TWO FAILURES THAT WERE MINE. It was dispatched twice and reverted
twice because my proof was wrong on two counts: it asserted the retired names must no longer appear in
the file when the design deliberately keeps them as the fallback, and its "derived inside the
collector" check used a 400-character window that the explanatory comment pushed the code past. This
workspace's own rule says a job failing twice means suspecting the proof; hand-writing the change
proved the proof was the defect. The proof now runs the audit's own 130-test guard as its real check.
SECOND, A SHORTCUT POINTING INTO THE RETIRED OLD WORKSPACE HAD BEEN DISABLING A CHECK SINCE AUGUST.
projects/personal/family-app/data-pushes pointed at an absolute path inside
/Users/nickdeck/Documents/Claude — a folder that no longer exists on this machine. Because it is
committed, every machine got the same dead shortcut. The audit reads three files through it and was
reporting "freshness-expected.json missing/unreadable — A/B push-drift check skipped", then carrying
on looking like a clean run. After repointing, the same run reads the file and says "270h old — A/B
contract stale, comparisons still run but weakly grounded". THE CHECK WENT FROM NOT HAPPENING TO
HAPPENING AND TELLING THE TRUTH ABOUT ITS OWN INPUT. The replacement is relative, not absolute, so it
works on every machine. Scope measured rather than assumed: 262 shortcuts are committed here and
exactly ONE pointed into the dead workspace.
NAMED, NOT CHASED, because they belong to the lanes that own those feeds and both were invisible while
that shortcut was dead: the freshness contract is 270 hours stale, and the live-feed sweep reports 27
failures.
LANE STATE. Steps 1-6 and 8-10 closed. STEP 7 answers correctly with no search but comes in at 64
seconds against its own under-one-minute bar — with Nick as a question about whether the bar is right,
deliberately not moved to make it pass. STEP 11 waits on 7.
2026-09-10T23:01:20Z — 🔴 THE SCHEDULER WAS NOT RUNNING AT ALL, AND I REPORTED OTHERWISE. CORRECTED AND FIXED.
WHAT I TOLD NICK: that the fleet audit "fired on its own at 19:37, after the last hand-run at
19:30:56, so that was the schedule and not me." THAT WAS WRONG. 19:37:12 was also me — a second
hand-run minutes later. Neither restored job has ever fired on its own schedule.
WHY, MEASURED. The scheduled-jobs daemon was not running as a process, and its launchd service was
not registered. Its agent file at ~/Library/LaunchAgents/com.skippy.jobs.plist was a BARE <array> —
just the two program arguments, with no <dict> and no Label — which launchd cannot load at all. So it
has NEVER been launchd-supervised. The daemon only ever ran because a session started it by hand, and
the machine restart on 2026-09-10 killed that process with nothing to bring it back.
🔴 THIS WAS ALREADY KNOWN AND ALREADY WATCHED, AND THE WATCHDOG WAS ALREADY FAILING. Its own words on
2026-09-09: "reg=STOPGAP_ONLY ... com.skippy.jobs is NOT launchd-supervised (launchctl pid=absent)
but a runner.mjs process IS running anyway ... a manual stopgap". The condition was detected, the
alarm was red, and the underlying file was never repaired — so the next restart took the whole
scheduled layer down.
FIXED. The broken file was copied outside the tree first, then rewritten to the shape of a plist that
demonstrably works on this machine, and registered — `enable` first, then `bootstrap`, because
bootstrap alone returns an I/O error. The scheduler is running under launchd, KeepAlive true, and
re-recorded its boot at 22:59:57Z with the current job list, which is the first boot to include both
the re-enabled cloud-brain copy job and all three audit rows.
WHAT THIS MEANT WHILE IT WAS DOWN: the hourly light audit had not run since 2026-09-09 21:46, and
neither had the five-minute service-freshness check. Jobs that DID keep beating — auto-pull among
them — run from their own launchd agents, not from this scheduler, which is exactly why the outage
was invisible.