Cite GB-001 in your first message.

# GB-001 — Finish the M5 fault ring: a real fault storm, and the brownout case

gimbal-bench · next · gate none · machine formd-t1
Freshness: last audit 2026-08-19 · 153 commits unattributed then

## Project context

Firmware and a commissioning bench that can prove, from a record, that the fixture stays a light.

## What this is

**This is the next thing built, and the ruling says so in its own words.** The fault ring (M5) needs nothing from any of them, and it is the next thing built. — D15, `owner-decisions-20260814.md` Layers one and two exist and are measured (`ring-first-read-20260814.md` `c02b507`, `ring-mirror-20260814.md` `669a3a7`, both 2026-08-14). Layer one found three real defects within an hour of existing — *"none of them visible in the live serial log"*. What is left is the list the mirror capture writes down about itself:

## Where it stands

No evidence recorded. It cannot be closed until something can be clicked.
Next, from the last handoff: NO HANDOFF RECORDED — nobody wrote down where this was left.

## Already ruled out — read before proposing anything

- **R-034 · Any flash or NVS write on a fault path**
  **No fault path touches flash.** An NVS commit erases a page and can block for tens of milliseconds; the stop budget is 50 ms and does not negotiate.
- **R-035 · Restoring the fault ring from flash whenever flash has a copy**
  `mirrorRestore()` returns immediately **unless layer one came back empty**.
- **R-039 · Un-parking Zigbee before the fault ring and the drills**
  **Zigbee is ruled (D3) and parked (D15). Not dead, not next.** Both halves matter; either one alone gets the priority wrong in an opposite direction.
- **R-040 · Tombstoning `spot-bench.yaml` wholesale**
  The file names exactly what survives D3:

## Work here, not in product-os

Repo: `gimbal-bench`. product-os TRACKS the work; it does not host it. Make the change there and come back only to write the handoff.
Machine: **formd-t1**. If that is not where you are, the honest answer is "resume on formd-t1" — not a plan you cannot execute.

## Chats already working on this

- claude-code · work-laptop · Fix stale product-os entry in state/repos.js
  RESUME — last active 2026-08-19; could NOT check whether work landed in its repo — resume, but re-read the brief first
  A verified way back exists on work-laptop, but it names that machine's paths and the session id, so it is not republished. Run `python3 tools/kickoff.py GB-001` there.

## Decisions in force

- **DEC-003** (D3) — Transport is Zigbee, C6 as router, light included
- **DEC-015** (D15) — Zigbee stays parked until the fault ring and the drills are done

## Rules

- Nothing is done without evidence — a commit SHA, a file path, or a
  dated note. If you cannot produce one, it is not done. Say so.
- Say "I couldn't look", never "no changes". An empty result and an
  unreachable repo are different facts.
- Do not write his decided fields: project, gate, machine_affinity,
  parked/dropped, or the evidence rule. Draft into state/drafts/
  instead — never straight into the task.
- Do not reorder state/backlog.md. That file is his judgement, and it
  is the only order there is. Say so once if you disagree, then work
  on what he put at the top.

Cite GB-014 in your first message.

# GB-014 — Un-park Zigbee — the decision D15 leaves open

gimbal-bench · next · gate external
Freshness: last audit 2026-08-19 · 153 commits unattributed then

## Project context

Firmware and a commissioning bench that can prove, from a record, that the fixture stays a light.

## What this is

**This is a decision, not a task, and it has not been taken.** It exists as a node because of what the graph said without it. With `GB-001` pointing straight at `GB-005`, the chain read *finish the fault ring → Z-M1*, which invites exactly one wrong inference: that completing the fault ring un-parks Zigbee automatically. It does not. Something has to happen between them that no agent can do, and a chain that hides an unmade decision is worse than one that shows it.

## Where it stands

No evidence recorded. It cannot be closed until something can be clicked.
Next, from the last handoff: NO HANDOFF RECORDED — nobody wrote down where this was left.

## Already ruled out — read before proposing anything

- **R-039 · Un-parking Zigbee before the fault ring and the drills**
  **Zigbee is ruled (D3) and parked (D15). Not dead, not next.** Both halves matter; either one alone gets the priority wrong in an opposite direction.
- **R-029 · Replacing the dead-man with a hub-sourced liveness timer**
  Over Zigbee a brief dropout takes **seconds** to recover, not milliseconds, so a 400 ms timer would trip constantly on a healthy system. Loosening it to seconds means seconds of uncommanded …
- **R-042 · `esp-zigbee-lib` enums in the Z-M0 mailbox**
  The mailbox uses **primitive types (uint16/uint8), not esp-zigbee-lib enums**, so it compiles ahead of the library. Using the library's enums couples the milestone to a dependency the …

## Work here, not in product-os

Repo: `gimbal-bench`. product-os TRACKS the work; it does not host it. Make the change there and come back only to write the handoff.
Gate `external`: this needs hardware or a person that may not be present.

## Chats already working on this

- claude-code · work-laptop · Fix stale product-os entry in state/repos.js
  RESUME — last active 2026-08-19; could NOT check whether work landed in its repo — resume, but re-read the brief first
  A verified way back exists on work-laptop, but it names that machine's paths and the session id, so it is not republished. Run `python3 tools/kickoff.py GB-014` there.

## Decisions in force

- **DEC-015** (D15) — Zigbee stays parked until the fault ring and the drills are done
- **DEC-003** (D3) — Transport is Zigbee, C6 as router, light included

## Rules

- Nothing is done without evidence — a commit SHA, a file path, or a
  dated note. If you cannot produce one, it is not done. Say so.
- Say "I couldn't look", never "no changes". An empty result and an
  unreachable repo are different facts.
- Do not write his decided fields: project, gate, machine_affinity,
  parked/dropped, or the evidence rule. Draft into state/drafts/
  instead — never straight into the task.
- Do not reorder state/backlog.md. That file is his judgement, and it
  is the only order there is. Say so once if you disagree, then work
  on what he put at the top.

Cite GB-005 in your first message.

# GB-005 — Z-M1 — variant, partitions and the c-patch signing scaffold

gimbal-bench · next · gate none · machine formd-t1
Freshness: last audit 2026-08-19 · 153 commits unattributed then

## Project context

Firmware and a commissioning bench that can prove, from a record, that the fixture stays a light.

## What this is

**Z-M1** | **Variant + partitions + signing scaffold** — `GIMBAL_ZIGBEE` dependent flag + compound suffix + `#error` + the 7th mega_gate leg (flight image); `zigbee_zczr`; the c-patch build-time signer + the verify-before-handoff scaffold. **No Zigbee code yet.**

## Where it stands

No evidence recorded. It cannot be closed until something can be clicked.
Next, from the last handoff: NO HANDOFF RECORDED — nobody wrote down where this was left.

## Already ruled out — read before proposing anything

- **R-039 · Un-parking Zigbee before the fault ring and the drills**
  **Zigbee is ruled (D3) and parked (D15). Not dead, not next.** Both halves matter; either one alone gets the priority wrong in an opposite direction.
- **R-027 · R2 in the "c-boot" sub-form**
  Ruled, then overturned by adversarial review **the same day**:
- **R-028 · Secure boot (`CONFIG_SECURE_BOOT_V2`) — rejected for now, not forever**
  Hardware-capable and genuinely stronger — it protects the bootloader too. Rejected because:
- **R-029 · Replacing the dead-man with a hub-sourced liveness timer**
  Over Zigbee a brief dropout takes **seconds** to recover, not milliseconds, so a 400 ms timer would trip constantly on a healthy system. Loosening it to seconds means seconds of uncommanded …

## Work here, not in product-os

Repo: `gimbal-bench`. product-os TRACKS the work; it does not host it. Make the change there and come back only to write the handoff.
Machine: **formd-t1**. If that is not where you are, the honest answer is "resume on formd-t1" — not a plan you cannot execute.

## Chats already working on this

- claude-code · work-laptop · Fix stale product-os entry in state/repos.js
  RESUME — last active 2026-08-19; could NOT check whether work landed in its repo — resume, but re-read the brief first
  A verified way back exists on work-laptop, but it names that machine's paths and the session id, so it is not republished. Run `python3 tools/kickoff.py GB-005` there.

## Decisions in force

- **DEC-015** (D15) — Zigbee stays parked until the fault ring and the drills are done
- **DEC-003** (D3) — Transport is Zigbee, C6 as router, light included

## Rules

- Nothing is done without evidence — a commit SHA, a file path, or a
  dated note. If you cannot produce one, it is not done. Say so.
- Say "I couldn't look", never "no changes". An empty result and an
  unreachable repo are different facts.
- Do not write his decided fields: project, gate, machine_affinity,
  parked/dropped, or the evidence rule. Draft into state/drafts/
  instead — never straight into the task.
- Do not reorder state/backlog.md. That file is his judgement, and it
  is the only order there is. Say so once if you disagree, then work
  on what he put at the top.

Cite GB-006 in your first message.

# GB-006 — Z-M0 — the §9.1 mailbox primitive

gimbal-bench · next · gate none · machine formd-t1
Freshness: last audit 2026-08-19 · 153 commits unattributed then

## Project context

Firmware and a commissioning bench that can prove, from a record, that the fixture stays a light.

## What this is

**Z-M0** | **The §9.1 mailbox primitive** — single-slot coalesce-to-latest admission record using **primitive types (uint16/uint8), not esp-zigbee-lib enums** [§10 hole 4], so it compiles ahead of the library; the always-honored stop latch bypassing + purging the slot; a fake producer.

## Where it stands

No evidence recorded. It cannot be closed until something can be clicked.
Next, from the last handoff: NO HANDOFF RECORDED — nobody wrote down where this was left.

## Already ruled out — read before proposing anything

- **R-039 · Un-parking Zigbee before the fault ring and the drills**
  **Zigbee is ruled (D3) and parked (D15). Not dead, not next.** Both halves matter; either one alone gets the priority wrong in an opposite direction.
- **R-042 · `esp-zigbee-lib` enums in the Z-M0 mailbox**
  The mailbox uses **primitive types (uint16/uint8), not esp-zigbee-lib enums**, so it compiles ahead of the library. Using the library's enums couples the milestone to a dependency the …
- **R-029 · Replacing the dead-man with a hub-sourced liveness timer**
  Over Zigbee a brief dropout takes **seconds** to recover, not milliseconds, so a 400 ms timer would trip constantly on a healthy system. Loosening it to seconds means seconds of uncommanded …

## Work here, not in product-os

Repo: `gimbal-bench`. product-os TRACKS the work; it does not host it. Make the change there and come back only to write the handoff.
Machine: **formd-t1**. If that is not where you are, the honest answer is "resume on formd-t1" — not a plan you cannot execute.

## Chats already working on this

- claude-code · work-laptop · Fix stale product-os entry in state/repos.js
  RESUME — last active 2026-08-19; could NOT check whether work landed in its repo — resume, but re-read the brief first
  A verified way back exists on work-laptop, but it names that machine's paths and the session id, so it is not republished. Run `python3 tools/kickoff.py GB-006` there.

## Decisions in force

- **DEC-015** (D15) — Zigbee stays parked until the fault ring and the drills are done
- **DEC-003** (D3) — Transport is Zigbee, C6 as router, light included

## Rules

- Nothing is done without evidence — a commit SHA, a file path, or a
  dated note. If you cannot produce one, it is not done. Say so.
- Say "I couldn't look", never "no changes". An empty result and an
  unreachable repo are different facts.
- Do not write his decided fields: project, gate, machine_affinity,
  parked/dropped, or the evidence rule. Draft into state/drafts/
  instead — never straight into the task.
- Do not reorder state/backlog.md. That file is his judgement, and it
  is the only order there is. Say so once if you disagree, then work
  on what he put at the top.

Cite GB-008 in your first message.

# GB-008 — Z-M3 — Zigbee bring-up as a light

gimbal-bench · next · gate none · machine formd-t1
Freshness: last audit 2026-08-19 · 153 commits unattributed then

## Project context

Firmware and a commissioning bench that can prove, from a record, that the fixture stays a light.

## What this is

**Z-M3** | **Zigbee bring-up AS A LIGHT** — router join (`zczr`), on/off/level clusters, the APSDE filter (stage-E record, TC source-bind), telemetry shell. Greenfield bulk. The fan-out point: §6 states *"Z-M4/Z-M5/Z-M6 on Z-M3"*, which is where three of this chain's four leaves attach.

## Where it stands

No evidence recorded. It cannot be closed until something can be clicked.
Next, from the last handoff: NO HANDOFF RECORDED — nobody wrote down where this was left.

## Already ruled out — read before proposing anything

- **R-039 · Un-parking Zigbee before the fault ring and the drills**
  **Zigbee is ruled (D3) and parked (D15). Not dead, not next.** Both halves matter; either one alone gets the priority wrong in an opposite direction.
- **R-029 · Replacing the dead-man with a hub-sourced liveness timer**
  Over Zigbee a brief dropout takes **seconds** to recover, not milliseconds, so a 400 ms timer would trip constantly on a healthy system. Loosening it to seconds means seconds of uncommanded …
- **R-042 · `esp-zigbee-lib` enums in the Z-M0 mailbox**
  The mailbox uses **primitive types (uint16/uint8), not esp-zigbee-lib enums**, so it compiles ahead of the library. Using the library's enums couples the milestone to a dependency the …

## Work here, not in product-os

Repo: `gimbal-bench`. product-os TRACKS the work; it does not host it. Make the change there and come back only to write the handoff.
Machine: **formd-t1**. If that is not where you are, the honest answer is "resume on formd-t1" — not a plan you cannot execute.

## Chats already working on this

- claude-code · work-laptop · Fix stale product-os entry in state/repos.js
  RESUME — last active 2026-08-19; could NOT check whether work landed in its repo — resume, but re-read the brief first
  A verified way back exists on work-laptop, but it names that machine's paths and the session id, so it is not republished. Run `python3 tools/kickoff.py GB-008` there.

## Decisions in force

- **DEC-015** (D15) — Zigbee stays parked until the fault ring and the drills are done
- **DEC-003** (D3) — Transport is Zigbee, C6 as router, light included

## Rules

- Nothing is done without evidence — a commit SHA, a file path, or a
  dated note. If you cannot produce one, it is not done. Say so.
- Say "I couldn't look", never "no changes". An empty result and an
  unreachable repo are different facts.
- Do not write his decided fields: project, gate, machine_affinity,
  parked/dropped, or the evidence rule. Draft into state/drafts/
  instead — never straight into the task.
- Do not reorder state/backlog.md. That file is his judgement, and it
  is the only order there is. Say so once if you disagree, then work
  on what he put at the top.

Cite GB-002 in your first message.

# GB-002 — Rescue D1-D11 off formd-t1 and commit them

gimbal-bench · next · gate none · machine formd-t1
Freshness: last audit 2026-08-19 · 153 commits unattributed then

## Project context

Firmware and a commissioning bench that can prove, from a record, that the fixture stays a light.

## What this is

**Eleven owner rulings exist in exactly one place, and it is not a repository.** D12-D16 are safe: full prose, committed, `e4d71a9`. D1-D11 are not. They survive only as one-line digests in a section headed: # 5. Owner decisions — D1 through D15 exist in §4; D16 exists only by reference; no D17–D20

## Where it stands

No evidence recorded. It cannot be closed until something can be clicked.
Next, from the last handoff: NO HANDOFF RECORDED — nobody wrote down where this was left.

## Already ruled out — read before proposing anything

- **R-026 · Reading a pre-2026-08-13 wire capture without asking whether the tap was open**
  An open tap changes three things at once: TX succeeds, the error counters drain (*"CAN error counters fall only on a successful transmission"*), and canonical SAFE becomes reachable on a …
- **R-038 · Reading "no head-dropping observed" as "the head does not drop"**
  The first map on 2026-08-15 was genuinely good — five tilt poses, released 5-minute windows, *"**the head does not fall anywhere**"*, worst case 0.62° one-time settle and 0.01°/min creep. …
- **R-066 · Two agents writing one working tree**
  The multi-machine design makes **cross-machine** conflict structurally impossible: `state/threads/by-machine/<id>.json` is written by exactly one machine's indexer, so two machines syncing …

## Work here, not in product-os

Repo: `gimbal-bench`. product-os TRACKS the work; it does not host it. Make the change there and come back only to write the handoff.
Machine: **formd-t1**. If that is not where you are, the honest answer is "resume on formd-t1" — not a plan you cannot execute.

## Chats already working on this

- claude-code · work-laptop · Fix stale product-os entry in state/repos.js
  RESUME — last active 2026-08-19; could NOT check whether work landed in its repo — resume, but re-read the brief first
  A verified way back exists on work-laptop, but it names that machine's paths and the session id, so it is not republished. Run `python3 tools/kickoff.py GB-002` there.

## Decisions in force

- **DEC-003** (D3) — Transport is Zigbee, C6 as router, light included
- **DEC-015** (D15) — Zigbee stays parked until the fault ring and the drills are done

## Rules

- Nothing is done without evidence — a commit SHA, a file path, or a
  dated note. If you cannot produce one, it is not done. Say so.
- Say "I couldn't look", never "no changes". An empty result and an
  unreachable repo are different facts.
- Do not write his decided fields: project, gate, machine_affinity,
  parked/dropped, or the evidence rule. Draft into state/drafts/
  instead — never straight into the task.
- Do not reorder state/backlog.md. That file is his judgement, and it
  is the only order there is. Say so once if you disagree, then work
  on what he put at the top.

Cite Q-001 in your first message.

# Q-001 — Does Spot Mode (Auto/Hold/Manual) survive gate A?

gimbal-bench · next · gate none
Freshness: last audit 2026-08-19 · 153 commits unattributed then

## Project context

Firmware and a commissioning bench that can prove, from a record, that the fixture stays a light.

## What this is

**This is a question, not a task, and the source is explicit that it is unruled:** `Spot Mode` (Auto/Hold/Manual) → a gate-A product question (no deployed-profile analog under D12 — re-derive or retire) The tension it sits in is real and both halves are sourced:

## Where it stands

No evidence recorded. It cannot be closed until something can be clicked.
Next, from the last handoff: NO HANDOFF RECORDED — nobody wrote down where this was left.

## Already ruled out — read before proposing anything

- **R-029 · Replacing the dead-man with a hub-sourced liveness timer**
  Over Zigbee a brief dropout takes **seconds** to recover, not milliseconds, so a 400 ms timer would trip constantly on a healthy system. Loosening it to seconds means seconds of uncommanded …
- **R-030 · Relying on the motors' own comm timeout as the safety net**
  It exists and it is a real backstop, but it removes power. On a brakeless gravity axis that risks a drop rather than a hold.
- **R-032 · A flat `0x81` pin for the mute entry-stop opcode**
  Rejected along with a second writer for `kaLastTxOk`. The chosen mechanism selects from the mute's own live evidence: ACKed solicits → the motor likely heard → hold (`0x81`); un-ACKed → …
- **R-038 · Reading "no head-dropping observed" as "the head does not drop"**
  The first map on 2026-08-15 was genuinely good — five tilt poses, released 5-minute windows, *"**the head does not fall anywhere**"*, worst case 0.62° one-time settle and 0.01°/min creep. …

## Work here, not in product-os

Repo: `gimbal-bench`. product-os TRACKS the work; it does not host it. Make the change there and come back only to write the handoff.

## Chats already working on this

- claude-code · work-laptop · Fix stale product-os entry in state/repos.js
  RESUME — last active 2026-08-19; could NOT check whether work landed in its repo — resume, but re-read the brief first
  A verified way back exists on work-laptop, but it names that machine's paths and the session id, so it is not republished. Run `python3 tools/kickoff.py Q-001` there.

## Decisions in force

- **DEC-003** (D3) — Transport is Zigbee, C6 as router, light included
- **DEC-015** (D15) — Zigbee stays parked until the fault ring and the drills are done

## Rules

- Nothing is done without evidence — a commit SHA, a file path, or a
  dated note. If you cannot produce one, it is not done. Say so.
- Say "I couldn't look", never "no changes". An empty result and an
  unreachable repo are different facts.
- Do not write his decided fields: project, gate, machine_affinity,
  parked/dropped, or the evidence rule. Draft into state/drafts/
  instead — never straight into the task.
- Do not reorder state/backlog.md. That file is his judgement, and it
  is the only order there is. Say so once if you disagree, then work
  on what he put at the top.

Cite GB-004 in your first message.

# GB-004 — M6 on hardware: the motor-silent limb, MUTE-CLEAR, and the armed lane

gimbal-bench · next · gate none · machine formd-t1
Freshness: last audit 2026-08-19 · 153 commits unattributed then

## Project context

Firmware and a commissioning bench that can prove, from a record, that the fixture stays a light.

## What this is

M6's mute machinery landed and flashed on 2026-08-15. One limb is proven live: proven live: `MUTE cause=bus-no-ack` at 2.3 s from boot and the same paragraph names what is not:

## Where it stands

Evidence on file: 19dd790, 34b9f7c, 1525192, 7f5b060.
Next, from the last handoff: unchanged — the dev-gated reply-drop drill on the `+mutesim` image, as

## Already ruled out — read before proposing anything

- **R-055 · Proving the armed-lane mute by physically unplugging a connector**
  The drill is self-defeating and the capture works out why:
- **R-031 · Auto-disarm on the ACKed half of an armed mute**
  Three reasons, all recorded: killing a two-axis session for a one-axis fault that disarm cannot cure buys nothing the degrade does not; at the archived 2-minute cadence auto-disarm makes …
- **R-032 · A flat `0x81` pin for the mute entry-stop opcode**
  Rejected along with a second writer for `kaLastTxOk`. The chosen mechanism selects from the mute's own live evidence: ACKed solicits → the motor likely heard → hold (`0x81`); un-ACKed → …
- **R-033 · A third mute cause**
  No archived slow-motor regime exists, and the RX-CORRELATION-ERROR lines already discriminate the shape on the wire. Same family as F3's rejection of a new READY blocker: `reply_stale` …

## Work here, not in product-os

Repo: `gimbal-bench`. product-os TRACKS the work; it does not host it. Make the change there and come back only to write the handoff.
Machine: **formd-t1**. If that is not where you are, the honest answer is "resume on formd-t1" — not a plan you cannot execute.

## Chats already working on this

- claude-code · work-laptop · Fix stale product-os entry in state/repos.js
  RESUME — last active 2026-08-19; could NOT check whether work landed in its repo — resume, but re-read the brief first
  A verified way back exists on work-laptop, but it names that machine's paths and the session id, so it is not republished. Run `python3 tools/kickoff.py GB-004` there.

## Decisions in force

- **DEC-016** (D16) — The M6 armed-mute forks, settled by adoption
- **DEC-003** (D3) — Transport is Zigbee, C6 as router, light included
- **DEC-015** (D15) — Zigbee stays parked until the fault ring and the drills are done

## Rules

- Nothing is done without evidence — a commit SHA, a file path, or a
  dated note. If you cannot produce one, it is not done. Say so.
- Say "I couldn't look", never "no changes". An empty result and an
  unreachable repo are different facts.
- Do not write his decided fields: project, gate, machine_affinity,
  parked/dropped, or the evidence rule. Draft into state/drafts/
  instead — never straight into the task.
- Do not reorder state/backlog.md. That file is his judgement, and it
  is the only order there is. Say so once if you disagree, then work
  on what he put at the top.

Cite Q-002 in your first message.

# Q-002 — Does a mid-move retarget re-plan smoothly, or stop and restart?

gimbal-bench · next · gate none
Freshness: last audit 2026-08-19 · 153 commits unattributed then

## Project context

Firmware and a commissioning bench that can prove, from a record, that the fixture stays a light.

## What this is

D12 settles the safety half and leaves this open, and states plainly that it is **a measurement rather than an argument**: If the motor re-plans its curve smoothly on a new `0xA4` that arrives before deceleration, a follow looks like a Broadway spotlight. If it stops and restarts, it looks like a stuttering security camera.

## Where it stands

No evidence recorded. It cannot be closed until something can be clicked.
Next, from the last handoff: NO HANDOFF RECORDED — nobody wrote down where this was left.

## Already ruled out — read before proposing anything

- **R-018 · "Caliper the 5005 for a raised boss on the output face"**
  ### 1. Is there a raised boss on the output face? — **NO.**
- **R-029 · Replacing the dead-man with a hub-sourced liveness timer**
  Over Zigbee a brief dropout takes **seconds** to recover, not milliseconds, so a 400 ms timer would trip constantly on a healthy system. Loosening it to seconds means seconds of uncommanded …
- **R-030 · Relying on the motors' own comm timeout as the safety net**
  It exists and it is a real backstop, but it removes power. On a brakeless gravity axis that risks a drop rather than a hold.
- **R-064 · Measuring a proxy instead of measuring the tool's output**
  `PROP-0003` proposed twenty `done` items and claimed they would drop group D from **301 to 13**. **The real effect is zero**, and the proposal was queued for a one-sentence yes.

## Work here, not in product-os

Repo: `gimbal-bench`. product-os TRACKS the work; it does not host it. Make the change there and come back only to write the handoff.

## Chats already working on this

- claude-code · work-laptop · Fix stale product-os entry in state/repos.js
  RESUME — last active 2026-08-19; could NOT check whether work landed in its repo — resume, but re-read the brief first
  A verified way back exists on work-laptop, but it names that machine's paths and the session id, so it is not republished. Run `python3 tools/kickoff.py Q-002` there.

## Decisions in force

- **DEC-003** (D3) — Transport is Zigbee, C6 as router, light included
- **DEC-015** (D15) — Zigbee stays parked until the fault ring and the drills are done

## Rules

- Nothing is done without evidence — a commit SHA, a file path, or a
  dated note. If you cannot produce one, it is not done. Say so.
- Say "I couldn't look", never "no changes". An empty result and an
  unreachable repo are different facts.
- Do not write his decided fields: project, gate, machine_affinity,
  parked/dropped, or the evidence rule. Draft into state/drafts/
  instead — never straight into the task.
- Do not reorder state/backlog.md. That file is his judgement, and it
  is the only order there is. Say so once if you disagree, then work
  on what he put at the top.

Cite Q-003 in your first message.

# Q-003 — Does a brownout preserve the RTC domain?

gimbal-bench · next · gate none
Freshness: last audit 2026-08-19 · 153 commits unattributed then

## Project context

Firmware and a commissioning bench that can prove, from a record, that the fixture stays a light.

## What this is

**The brownout case**, unknown in both directions. A brownout may or may not preserve the RTC domain, and nothing here has produced one. The M5 ring distinguishes "the fixture rebooted itself" from "somebody cut the power" using three agreeing signals — reset reason, `lost` flag, and whether the flash mirror had to be restored. A brownout is the case that table has no row for, and a ceiling fixture on household mains will meet one.

## Where it stands

No evidence recorded. It cannot be closed until something can be clicked.
Next, from the last handoff: NO HANDOFF RECORDED — nobody wrote down where this was left.

## Already ruled out — read before proposing anything

- **R-035 · Restoring the fault ring from flash whenever flash has a copy**
  `mirrorRestore()` returns immediately **unless layer one came back empty**.
- **R-034 · Any flash or NVS write on a fault path**
  **No fault path touches flash.** An NVS commit erases a page and can block for tens of milliseconds; the stop budget is 50 ms and does not negotiate.
- **R-039 · Un-parking Zigbee before the fault ring and the drills**
  **Zigbee is ruled (D3) and parked (D15). Not dead, not next.** Both halves matter; either one alone gets the priority wrong in an opposite direction.

## Work here, not in product-os

Repo: `gimbal-bench`. product-os TRACKS the work; it does not host it. Make the change there and come back only to write the handoff.

## Chats already working on this

- claude-code · work-laptop · Fix stale product-os entry in state/repos.js
  RESUME — last active 2026-08-19; could NOT check whether work landed in its repo — resume, but re-read the brief first
  A verified way back exists on work-laptop, but it names that machine's paths and the session id, so it is not republished. Run `python3 tools/kickoff.py Q-003` there.

## Decisions in force

- **DEC-003** (D3) — Transport is Zigbee, C6 as router, light included
- **DEC-015** (D15) — Zigbee stays parked until the fault ring and the drills are done

## Rules

- Nothing is done without evidence — a commit SHA, a file path, or a
  dated note. If you cannot produce one, it is not done. Say so.
- Say "I couldn't look", never "no changes". An empty result and an
  unreachable repo are different facts.
- Do not write his decided fields: project, gate, machine_affinity,
  parked/dropped, or the evidence rule. Draft into state/drafts/
  instead — never straight into the task.
- Do not reorder state/backlog.md. That file is his judgement, and it
  is the only order there is. Say so once if you disagree, then work
  on what he put at the top.

Cite GB-007 in your first message.

# GB-007 — Z-M2 — the rollback ladder, D15's ruled first radio commit

gimbal-bench · next · gate none · machine formd-t1
Freshness: last audit 2026-08-19 · 153 commits unattributed then

## Project context

Firmware and a commissioning bench that can prove, from a record, that the fixture stays a light.

## What this is

**Z-M2** | **The rollback ladder (§8 — D15's ruled first radio commit)** — `verifyRollbackLater()→true`; mark-valid strictly on {`zigbeeJoined`, `twaiReady`, N iterations, no panic} (NOT readyBlocker terms); `ota_reboot_expected`; `joinWasWorking`; park-before-opt-in; **the c-patch signature check runs in the OUTGOING image before handoff**

## Where it stands

No evidence recorded. It cannot be closed until something can be clicked.
Next, from the last handoff: NO HANDOFF RECORDED — nobody wrote down where this was left.

## Already ruled out — read before proposing anything

- **R-027 · R2 in the "c-boot" sub-form**
  Ruled, then overturned by adversarial review **the same day**:
- **R-028 · Secure boot (`CONFIG_SECURE_BOOT_V2`) — rejected for now, not forever**
  Hardware-capable and genuinely stronger — it protects the bootloader too. Rejected because:
- **R-039 · Un-parking Zigbee before the fault ring and the drills**
  **Zigbee is ruled (D3) and parked (D15). Not dead, not next.** Both halves matter; either one alone gets the priority wrong in an opposite direction.
- **R-029 · Replacing the dead-man with a hub-sourced liveness timer**
  Over Zigbee a brief dropout takes **seconds** to recover, not milliseconds, so a 400 ms timer would trip constantly on a healthy system. Loosening it to seconds means seconds of uncommanded …

## Work here, not in product-os

Repo: `gimbal-bench`. product-os TRACKS the work; it does not host it. Make the change there and come back only to write the handoff.
Machine: **formd-t1**. If that is not where you are, the honest answer is "resume on formd-t1" — not a plan you cannot execute.

## Chats already working on this

- claude-code · work-laptop · Fix stale product-os entry in state/repos.js
  RESUME — last active 2026-08-19; could NOT check whether work landed in its repo — resume, but re-read the brief first
  A verified way back exists on work-laptop, but it names that machine's paths and the session id, so it is not republished. Run `python3 tools/kickoff.py GB-007` there.

## Decisions in force

- **DEC-101** (R2) — R2 = c-patch: the outgoing image verifies the new one before handoff
- **DEC-003** (D3) — Transport is Zigbee, C6 as router, light included
- **DEC-015** (D15) — Zigbee stays parked until the fault ring and the drills are done

## Rules

- Nothing is done without evidence — a commit SHA, a file path, or a
  dated note. If you cannot produce one, it is not done. Say so.
- Say "I couldn't look", never "no changes". An empty result and an
  unreachable repo are different facts.
- Do not write his decided fields: project, gate, machine_affinity,
  parked/dropped, or the evidence rule. Draft into state/drafts/
  instead — never straight into the task.
- Do not reorder state/backlog.md. That file is his judgement, and it
  is the only order there is. Say so once if you disagree, then work
  on what he put at the top.

Cite GB-012 in your first message.

# GB-012 — Gate L — the fixture joins and holds as a light

gimbal-bench · next · gate none · machine formd-t1
Freshness: last audit 2026-08-19 · 153 commits unattributed then

## Project context

Firmware and a commissioning bench that can prove, from a record, that the fixture stays a light.

## What this is

**Gate L MET = the fixture joins and holds as a light** (needs the LED path, §5). The radio-live owner session. Two prerequisites are stated by §5 and are modelled as confirmed edges into this item: **Two owner/BoM prerequisites for gate L** [§10 hole 8]: the **LED photometric path** (GPIO10/11/18 ledc — "join as a light" cannot be demonstrated as a *light* without it; today compile-only), and the **HA-side Zigbee OTA server** (Z2M/ZHA OTA provider + image index + the signer→server pipeline — the OTA drill presupposes it).

## Where it stands

No evidence recorded. It cannot be closed until something can be clicked.
Next, from the last handoff: NO HANDOFF RECORDED — nobody wrote down where this was left.

## Already ruled out — read before proposing anything

- **R-039 · Un-parking Zigbee before the fault ring and the drills**
  **Zigbee is ruled (D3) and parked (D15). Not dead, not next.** Both halves matter; either one alone gets the priority wrong in an opposite direction.
- **R-023 · Carrying stage 1's 2.0 A supply limit into stage 6**
  Stage 1 sets 2.0 A for the LED-only stages and the draft never raised it again. At stage 6 the motors join the same rail with 21 tape channels lit:
- **R-029 · Replacing the dead-man with a hub-sourced liveness timer**
  Over Zigbee a brief dropout takes **seconds** to recover, not milliseconds, so a 400 ms timer would trip constantly on a healthy system. Loosening it to seconds means seconds of uncommanded …
- **R-042 · `esp-zigbee-lib` enums in the Z-M0 mailbox**
  The mailbox uses **primitive types (uint16/uint8), not esp-zigbee-lib enums**, so it compiles ahead of the library. Using the library's enums couples the milestone to a dependency the …

## Work here, not in product-os

Repo: `gimbal-bench`. product-os TRACKS the work; it does not host it. Make the change there and come back only to write the handoff.
Machine: **formd-t1**. If that is not where you are, the honest answer is "resume on formd-t1" — not a plan you cannot execute.

## Chats already working on this

- claude-code · work-laptop · Fix stale product-os entry in state/repos.js
  RESUME — last active 2026-08-19; could NOT check whether work landed in its repo — resume, but re-read the brief first
  A verified way back exists on work-laptop, but it names that machine's paths and the session id, so it is not republished. Run `python3 tools/kickoff.py GB-012` there.

## Decisions in force

- **DEC-015** (D15) — Zigbee stays parked until the fault ring and the drills are done
- **DEC-003** (D3) — Transport is Zigbee, C6 as router, light included

## Rules

- Nothing is done without evidence — a commit SHA, a file path, or a
  dated note. If you cannot produce one, it is not done. Say so.
- Say "I couldn't look", never "no changes". An empty result and an
  unreachable repo are different facts.
- Do not write his decided fields: project, gate, machine_affinity,
  parked/dropped, or the evidence rule. Draft into state/drafts/
  instead — never straight into the task.
- Do not reorder state/backlog.md. That file is his judgement, and it
  is the only order there is. Say so once if you disagree, then work
  on what he put at the top.

Cite GB-013 in your first message.

# GB-013 — Stand up the HA-side Zigbee OTA server

gimbal-bench · next · gate none
Freshness: last audit 2026-08-19 · 153 commits unattributed then

## Project context

Firmware and a commissioning bench that can prove, from a record, that the fixture stays a light.

## What this is

The second of §5's two stated gate-L prerequisites: the **HA-side Zigbee OTA server** (Z2M/ZHA OTA provider + image index + the signer→server pipeline — the OTA drill presupposes it) `gate: none` and no `machine_affinity`: this is Home Assistant-side work, not bench work, and the HA install already exists. It is the one item in the Zigbee neighbourhood that can genuinely be started without `formd-t1`.

## Where it stands

No evidence recorded. It cannot be closed until something can be clicked.
Next, from the last handoff: NO HANDOFF RECORDED — nobody wrote down where this was left.

## Already ruled out — read before proposing anything

- **R-027 · R2 in the "c-boot" sub-form**
  Ruled, then overturned by adversarial review **the same day**:
- **R-028 · Secure boot (`CONFIG_SECURE_BOOT_V2`) — rejected for now, not forever**
  Hardware-capable and genuinely stronger — it protects the bootloader too. Rejected because:
- **R-029 · Replacing the dead-man with a hub-sourced liveness timer**
  Over Zigbee a brief dropout takes **seconds** to recover, not milliseconds, so a 400 ms timer would trip constantly on a healthy system. Loosening it to seconds means seconds of uncommanded …
- **R-039 · Un-parking Zigbee before the fault ring and the drills**
  **Zigbee is ruled (D3) and parked (D15). Not dead, not next.** Both halves matter; either one alone gets the priority wrong in an opposite direction.

## Work here, not in product-os

Repo: `gimbal-bench`. product-os TRACKS the work; it does not host it. Make the change there and come back only to write the handoff.

## Chats already working on this

- claude-code · work-laptop · Fix stale product-os entry in state/repos.js
  RESUME — last active 2026-08-19; could NOT check whether work landed in its repo — resume, but re-read the brief first
  A verified way back exists on work-laptop, but it names that machine's paths and the session id, so it is not republished. Run `python3 tools/kickoff.py GB-013` there.

## Decisions in force

- **DEC-015** (D15) — Zigbee stays parked until the fault ring and the drills are done
- **DEC-003** (D3) — Transport is Zigbee, C6 as router, light included

## Rules

- Nothing is done without evidence — a commit SHA, a file path, or a
  dated note. If you cannot produce one, it is not done. Say so.
- Say "I couldn't look", never "no changes". An empty result and an
  unreachable repo are different facts.
- Do not write his decided fields: project, gate, machine_affinity,
  parked/dropped, or the evidence rule. Draft into state/drafts/
  instead — never straight into the task.
- Do not reorder state/backlog.md. That file is his judgement, and it
  is the only order there is. Say so once if you disagree, then work
  on what he put at the top.

Cite Q-004 in your first message.

# Q-004 — Where do 300 liveness taps a second come from?

gimbal-bench · next · gate none
Freshness: last audit 2026-08-19 · 153 commits unattributed then

## Project context

Firmware and a commissioning bench that can prove, from a record, that the fixture stays a light.

## What this is

The liveness tap should go about 5 times a second. Something sends it about **300**, which jams the cable so the genuine tap cannot get through, so the fixture concludes the operator has vanished and disarms. Nobody knows where 300/s comes from. Every known sender caps around 30/s even degraded, so something is retrying in a tight loop and it has never been found.

## Where it stands

No evidence recorded. It cannot be closed until something can be clicked.
Next, from the last handoff: NO HANDOFF RECORDED — nobody wrote down where this was left.

## Already ruled out — read before proposing anything

- **R-036 · Quieting the firmware's logging first when chasing the serial flood**
  Quieting the firmware first would hide the browser bug under a lower volume rather than fixing it.
- **R-025 · Listen-only mode on the CANable `candleLight` tap**
  **It has no working listen-only mode** — the repo verified this directly: `L` is unimplemented and silent mode is doubly broken.
- **R-026 · Reading a pre-2026-08-13 wire capture without asking whether the tap was open**
  An open tap changes three things at once: TX succeeds, the error counters drain (*"CAN error counters fall only on a successful transmission"*), and canonical SAFE becomes reachable on a …
- **R-029 · Replacing the dead-man with a hub-sourced liveness timer**
  Over Zigbee a brief dropout takes **seconds** to recover, not milliseconds, so a 400 ms timer would trip constantly on a healthy system. Loosening it to seconds means seconds of uncommanded …

## Work here, not in product-os

Repo: `gimbal-bench`. product-os TRACKS the work; it does not host it. Make the change there and come back only to write the handoff.

## Chats already working on this

- claude-code · work-laptop · Fix stale product-os entry in state/repos.js
  RESUME — last active 2026-08-19; could NOT check whether work landed in its repo — resume, but re-read the brief first
  A verified way back exists on work-laptop, but it names that machine's paths and the session id, so it is not republished. Run `python3 tools/kickoff.py Q-004` there.

## Decisions in force

- **DEC-003** (D3) — Transport is Zigbee, C6 as router, light included
- **DEC-015** (D15) — Zigbee stays parked until the fault ring and the drills are done

## Rules

- Nothing is done without evidence — a commit SHA, a file path, or a
  dated note. If you cannot produce one, it is not done. Say so.
- Say "I couldn't look", never "no changes". An empty result and an
  unreachable repo are different facts.
- Do not write his decided fields: project, gate, machine_affinity,
  parked/dropped, or the evidence rule. Draft into state/drafts/
  instead — never straight into the task.
- Do not reorder state/backlog.md. That file is his judgement, and it
  is the only order there is. Say so once if you disagree, then work
  on what he put at the top.

Cite GB-009 in your first message.

# GB-009 — Z-M4 — commissioning gesture and the reset-call choice

gimbal-bench · next · gate none · machine formd-t1
Freshness: last audit 2026-08-19 · 153 commits unattributed then

## Project context

Firmware and a commissioning bench that can prove, from a record, that the fixture stays a light.

## What this is

**Z-M4** | **Commissioning gesture + reset-call** — power-on-only counter in app-NVS, breadcrumbs, confirm-blink; the F-A5 reset-call choice explicit. A leaf of the chain, on Z-M3 per §6. The residual fork F-A5 (which reset call) is listed in §2 as inherited and unresolved, which is why `confidence` is proposed at 3 rather than 4.

## Where it stands

No evidence recorded. It cannot be closed until something can be clicked.
Next, from the last handoff: NO HANDOFF RECORDED — nobody wrote down where this was left.

## Already ruled out — read before proposing anything

- **R-039 · Un-parking Zigbee before the fault ring and the drills**
  **Zigbee is ruled (D3) and parked (D15). Not dead, not next.** Both halves matter; either one alone gets the priority wrong in an opposite direction.
- **R-029 · Replacing the dead-man with a hub-sourced liveness timer**
  Over Zigbee a brief dropout takes **seconds** to recover, not milliseconds, so a 400 ms timer would trip constantly on a healthy system. Loosening it to seconds means seconds of uncommanded …
- **R-034 · Any flash or NVS write on a fault path**
  **No fault path touches flash.** An NVS commit erases a page and can block for tens of milliseconds; the stop budget is 50 ms and does not negotiate.
- **R-042 · `esp-zigbee-lib` enums in the Z-M0 mailbox**
  The mailbox uses **primitive types (uint16/uint8), not esp-zigbee-lib enums**, so it compiles ahead of the library. Using the library's enums couples the milestone to a dependency the …

## Work here, not in product-os

Repo: `gimbal-bench`. product-os TRACKS the work; it does not host it. Make the change there and come back only to write the handoff.
Machine: **formd-t1**. If that is not where you are, the honest answer is "resume on formd-t1" — not a plan you cannot execute.

## Chats already working on this

- claude-code · work-laptop · Fix stale product-os entry in state/repos.js
  RESUME — last active 2026-08-19; could NOT check whether work landed in its repo — resume, but re-read the brief first
  A verified way back exists on work-laptop, but it names that machine's paths and the session id, so it is not republished. Run `python3 tools/kickoff.py GB-009` there.

## Decisions in force

- **DEC-015** (D15) — Zigbee stays parked until the fault ring and the drills are done
- **DEC-003** (D3) — Transport is Zigbee, C6 as router, light included

## Rules

- Nothing is done without evidence — a commit SHA, a file path, or a
  dated note. If you cannot produce one, it is not done. Say so.
- Say "I couldn't look", never "no changes". An empty result and an
  unreachable repo are different facts.
- Do not write his decided fields: project, gate, machine_affinity,
  parked/dropped, or the evidence rule. Draft into state/drafts/
  instead — never straight into the task.
- Do not reorder state/backlog.md. That file is his judgement, and it
  is the only order there is. Say so once if you disagree, then work
  on what he put at the top.

Cite GB-010 in your first message.

# GB-010 — Z-M5 — the deployed §4.1 motion predicate

gimbal-bench · next · gate none · machine formd-t1
Freshness: last audit 2026-08-19 · 153 commits unattributed then

## Project context

Firmware and a commissioning bench that can prove, from a record, that the fixture stays a light.

## What this is

**Z-M5** | **The deployed §4.1 motion predicate + `command_unauthenticated`** — realize the authority §4.1 predicate as the deployed+zigbee gate…; the new cause through the **atomic** four-link chain; `ota_in_progress` gets its OWN chain.

## Where it stands

No evidence recorded. It cannot be closed until something can be clicked.
Next, from the last handoff: NO HANDOFF RECORDED — nobody wrote down where this was left.

## Already ruled out — read before proposing anything

- **R-039 · Un-parking Zigbee before the fault ring and the drills**
  **Zigbee is ruled (D3) and parked (D15). Not dead, not next.** Both halves matter; either one alone gets the priority wrong in an opposite direction.
- **R-029 · Replacing the dead-man with a hub-sourced liveness timer**
  Over Zigbee a brief dropout takes **seconds** to recover, not milliseconds, so a 400 ms timer would trip constantly on a healthy system. Loosening it to seconds means seconds of uncommanded …
- **R-042 · `esp-zigbee-lib` enums in the Z-M0 mailbox**
  The mailbox uses **primitive types (uint16/uint8), not esp-zigbee-lib enums**, so it compiles ahead of the library. Using the library's enums couples the milestone to a dependency the …

## Work here, not in product-os

Repo: `gimbal-bench`. product-os TRACKS the work; it does not host it. Make the change there and come back only to write the handoff.
Machine: **formd-t1**. If that is not where you are, the honest answer is "resume on formd-t1" — not a plan you cannot execute.

## Chats already working on this

- claude-code · work-laptop · Fix stale product-os entry in state/repos.js
  RESUME — last active 2026-08-19; could NOT check whether work landed in its repo — resume, but re-read the brief first
  A verified way back exists on work-laptop, but it names that machine's paths and the session id, so it is not republished. Run `python3 tools/kickoff.py GB-010` there.

## Decisions in force

- **DEC-015** (D15) — Zigbee stays parked until the fault ring and the drills are done
- **DEC-003** (D3) — Transport is Zigbee, C6 as router, light included

## Rules

- Nothing is done without evidence — a commit SHA, a file path, or a
  dated note. If you cannot produce one, it is not done. Say so.
- Say "I couldn't look", never "no changes". An empty result and an
  unreachable repo are different facts.
- Do not write his decided fields: project, gate, machine_affinity,
  parked/dropped, or the evidence rule. Draft into state/drafts/
  instead — never straight into the task.
- Do not reorder state/backlog.md. That file is his judgement, and it
  is the only order there is. Say so once if you disagree, then work
  on what he put at the top.

Cite GB-011 in your first message.

# GB-011 — Z-M6 — telemetry attributes and the chunked dump

gimbal-bench · next · gate none · machine formd-t1
Freshness: last audit 2026-08-19 · 153 commits unattributed then

## Project context

Firmware and a commissioning bench that can prove, from a record, that the fixture stays a light.

## What this is

**Z-M6** | **Telemetry attributes + chunked dump over Zigbee** — the §9 attribute set + RTC-ring dump; `snapshotSeq`. The remote read of the M5 fault ring — which is the thing D15 says is missing today: Every recovery behaviour added on 2026-08-14 is currently observable only by somebody watching a serial port — which is the one state a deployed fixture is never in.

## Where it stands

No evidence recorded. It cannot be closed until something can be clicked.
Next, from the last handoff: NO HANDOFF RECORDED — nobody wrote down where this was left.

## Already ruled out — read before proposing anything

- **R-039 · Un-parking Zigbee before the fault ring and the drills**
  **Zigbee is ruled (D3) and parked (D15). Not dead, not next.** Both halves matter; either one alone gets the priority wrong in an opposite direction.
- **R-029 · Replacing the dead-man with a hub-sourced liveness timer**
  Over Zigbee a brief dropout takes **seconds** to recover, not milliseconds, so a 400 ms timer would trip constantly on a healthy system. Loosening it to seconds means seconds of uncommanded …
- **R-034 · Any flash or NVS write on a fault path**
  **No fault path touches flash.** An NVS commit erases a page and can block for tens of milliseconds; the stop budget is 50 ms and does not negotiate.
- **R-035 · Restoring the fault ring from flash whenever flash has a copy**
  `mirrorRestore()` returns immediately **unless layer one came back empty**.

## Work here, not in product-os

Repo: `gimbal-bench`. product-os TRACKS the work; it does not host it. Make the change there and come back only to write the handoff.
Machine: **formd-t1**. If that is not where you are, the honest answer is "resume on formd-t1" — not a plan you cannot execute.

## Chats already working on this

- claude-code · work-laptop · Fix stale product-os entry in state/repos.js
  RESUME — last active 2026-08-19; could NOT check whether work landed in its repo — resume, but re-read the brief first
  A verified way back exists on work-laptop, but it names that machine's paths and the session id, so it is not republished. Run `python3 tools/kickoff.py GB-011` there.

## Decisions in force

- **DEC-015** (D15) — Zigbee stays parked until the fault ring and the drills are done
- **DEC-003** (D3) — Transport is Zigbee, C6 as router, light included

## Rules

- Nothing is done without evidence — a commit SHA, a file path, or a
  dated note. If you cannot produce one, it is not done. Say so.
- Say "I couldn't look", never "no changes". An empty result and an
  unreachable repo are different facts.
- Do not write his decided fields: project, gate, machine_affinity,
  parked/dropped, or the evidence rule. Draft into state/drafts/
  instead — never straight into the task.
- Do not reorder state/backlog.md. That file is his judgement, and it
  is the only order there is. Say so once if you disagree, then work
  on what he put at the top.

Cite HAI-001 in your first message.

# HAI-001 — Rotate the GPU box's Linux password

home-ai-infra · next · gate none
Freshness: last audit 2026-08-19 · 153 commits unattributed then

## Project context

A GPU box the perception stack can be built on without ceremony.

## What this is

The handoff file for the GPU box says, as step 2 of its SSH setup: **Rotate your Linux password** (`passwd` on the box) — it was shared in the chat session on the work computer. — `~/Claude/PICKUP.md:19` That file is dated **2026-06-09**. Today is 2026-08-19.

## Where it stands

No evidence recorded. It cannot be closed until something can be clicked.
Next, from the last handoff: NO HANDOFF RECORDED — nobody wrote down where this was left.

## Already ruled out — read before proposing anything

NOTHING in wiki/ruled-out.md matches this item's keywords. That is not the same as nothing having been ruled out — this section is empty, not clear.

## Work here, not in product-os

**`home-ai-infra` has no repository.** Nothing about this task can be verified from commits, so its status changes only when Marcelo says so. Do not report it as stale, and do not close it on anything but his word or a dated note.

## Chats already working on this

- claude-code · work-laptop · Fix stale product-os entry in state/repos.js
  RESUME — last active 2026-08-19; could NOT check whether work landed in its repo — resume, but re-read the brief first
  A verified way back exists on work-laptop, but it names that machine's paths and the session id, so it is not republished. Run `python3 tools/kickoff.py HAI-001` there.

## Rules

- Nothing is done without evidence — a commit SHA, a file path, or a
  dated note. If you cannot produce one, it is not done. Say so.
- Say "I couldn't look", never "no changes". An empty result and an
  unreachable repo are different facts.
- Do not write his decided fields: project, gate, machine_affinity,
  parked/dropped, or the evidence rule. Draft into state/drafts/
  instead — never straight into the task.
- Do not reorder state/backlog.md. That file is his judgement, and it
  is the only order there is. Say so once if you disagree, then work
  on what he put at the top.

Cite POS-008 in your first message.

# POS-008 — Surface inferred closures, record the public decision

product-os · doing · gate none
Freshness: last audit 2026-08-19 · 153 commits unattributed then

## Project context

Know what to work on next, and never be told progress that cannot be clicked.

## What this is

`R-059` concluded that the durable guarantee against a defeatable `done` guard was the `(inferred)` stamp — permanently legible as a machine's judgement rather than Marcelo's word. That reasoning holds. The problem was where the stamp lived:

## Where it stands

No evidence recorded. It cannot be closed until something can be clicked.
Next, from the last handoff: confirm or reject the five unconfirmed closures — a sentence each.

## Already ruled out — read before proposing anything

- **R-065 · Placing a correction where the consumer does not read it**
  **A correction is only real where it is read.** Writing the fix is not the same act as delivering it, and this portfolio has now got that wrong four times:
- **R-067 · Publishing a line that carries the AGE of something**
  **`publish.py --check` exited 1 on a clean tree, reporting 121 files out of sync, and the entire difference was `(today)` → `(1 day ago)`.** Not one byte of `state/` had changed; the …
- **R-049 · Publishing `gimbal-bench` today**
  **Authorized by the owner and blocked on one narrow, sufficient ground:** a capture names a real third party's personal email address in full, beside an incident on that person's tailnet …
- **R-050 · `product-os` starting public**
  **SUPERSEDED 2026-08-19 by `DEC-201` — product-os is PUBLIC.** This paragraph leads deliberately: `brief.py` and `kickoff.py` excerpt the *first* paragraph of an entry, so a marker at the …

## Work here, not in product-os

This task names no repo, though `product-os` has one (`product-os`). Find out where the work lives before starting.

## Chats already working on this

- claude-code · work-laptop · Tool rebuild around refined model
  RESUME — last active 2026-08-21, and nothing has landed in product-os since
  A verified way back exists on work-laptop, but it names that machine's paths and the session id, so it is not republished. Run `python3 tools/kickoff.py POS-008` there.
- claude-code · work-laptop · BOOTSTRAP.md setup plan
  RESTART — 123 prompts — long enough that its early context is noise
- claude-code · work-laptop · Fix stale product-os entry in state/repos.js
  RESUME — last active 2026-08-19; could NOT check whether work landed in its repo — resume, but re-read the brief first
  A verified way back exists on work-laptop, but it names that machine's paths and the session id, so it is not republished. Run `python3 tools/kickoff.py POS-008` there.
- claude-code · work-laptop · Product-OS slice 1a-minus seed
  RESUME — last active 2026-08-19, and nothing has landed in product-os since
  A verified way back exists on work-laptop, but it names that machine's paths and the session id, so it is not republished. Run `python3 tools/kickoff.py POS-008` there.

## Decisions in force

- **DEC-202** (M2) — Marcelo orders the backlog; the tool stops computing an order

## Rules

- Nothing is done without evidence — a commit SHA, a file path, or a
  dated note. If you cannot produce one, it is not done. Say so.
- Say "I couldn't look", never "no changes". An empty result and an
  unreachable repo are different facts.
- Do not write his decided fields: project, gate, machine_affinity,
  parked/dropped, or the evidence rule. Draft into state/drafts/
  instead — never straight into the task.
- Do not reorder state/backlog.md. That file is his judgement, and it
  is the only order there is. Say so once if you disagree, then work
  on what he put at the top.

Cite POS-010 in your first message.

# POS-010 — Kickoff prompts and thread return paths

product-os · next · gate none
Freshness: last audit 2026-08-19 · 153 commits unattributed then

## Project context

Know what to work on next, and never be told progress that cannot be clicked.

## What this is

<!-- Why this matters. Then ## Acceptance, then ## Handoffs. -->

## Where it stands

No evidence recorded. It cannot be closed until something can be clicked.
Next, from the last handoff: NO HANDOFF RECORDED — nobody wrote down where this was left.

## Already ruled out — read before proposing anything

- **R-071 · Briefs as an artifact separate from the kickoff prompt**
  **Two generated artifacts, one job.** Compared section by section, `kickoff.py`'s output is a superset of `brief.py`'s except for two things — `decisions_in_force()` and the ⚠-unconfirmed …
- **R-073 · Treating the ranked list as the product**
  **The most-used artifact across this entire build was a hand-written, paste-ready prompt — written by hand roughly a dozen times before anyone noticed it was the product.** The ranking, the …
- **R-076 · Closing one route to a public surface and calling it fixed**
  **A private URL had three routes onto a public surface, and untracking one file closed the narrowest of them.** `state/threads/manual.yaml` was tracked, so a chat URL pasted there was …
- **R-050 · `product-os` starting public**
  **SUPERSEDED 2026-08-19 by `DEC-201` — product-os is PUBLIC.** This paragraph leads deliberately: `brief.py` and `kickoff.py` excerpt the *first* paragraph of an entry, so a marker at the …

## Work here, not in product-os

This task names no repo, though `product-os` has one (`product-os`). Find out where the work lives before starting.

## Chats already working on this

- claude-code · work-laptop · Tool rebuild around refined model
  RESUME — last active 2026-08-21, and nothing has landed in product-os since
  A verified way back exists on work-laptop, but it names that machine's paths and the session id, so it is not republished. Run `python3 tools/kickoff.py POS-010` there.
- claude-code · work-laptop · BOOTSTRAP.md setup plan
  RESTART — 123 prompts — long enough that its early context is noise
- claude-code · work-laptop · Fix stale product-os entry in state/repos.js
  RESUME — last active 2026-08-19; could NOT check whether work landed in its repo — resume, but re-read the brief first
  A verified way back exists on work-laptop, but it names that machine's paths and the session id, so it is not republished. Run `python3 tools/kickoff.py POS-010` there.
- claude-code · work-laptop · Product-OS slice 1a-minus seed
  RESUME — last active 2026-08-19, and nothing has landed in product-os since
  A verified way back exists on work-laptop, but it names that machine's paths and the session id, so it is not republished. Run `python3 tools/kickoff.py POS-010` there.

## Decisions in force

- **DEC-202** (M2) — Marcelo orders the backlog; the tool stops computing an order

## Rules

- Nothing is done without evidence — a commit SHA, a file path, or a
  dated note. If you cannot produce one, it is not done. Say so.
- Say "I couldn't look", never "no changes". An empty result and an
  unreachable repo are different facts.
- Do not write his decided fields: project, gate, machine_affinity,
  parked/dropped, or the evidence rule. Draft into state/drafts/
  instead — never straight into the task.
- Do not reorder state/backlog.md. That file is his judgement, and it
  is the only order there is. Say so once if you disagree, then work
  on what he put at the top.

Cite POS-011 in your first message.

# POS-011 — The remaining action artifacts: reconcile, attach, connect-repo, capture

product-os · next · gate none
Freshness: last audit 2026-08-19 · 153 commits unattributed then

## Project context

Know what to work on next, and never be told progress that cannot be clicked.

## What this is

<!-- Why this matters. Then ## Acceptance, then ## Handoffs. --> The five action artifacts are built and each passed a cold test. What those tests left behind is **three things only Marcelo can settle.** They are written here rather than left in a chat because a decision that lives only in a chat gets re-derived by every session that follows — this repo's founding failure, and `DEC-201` exists because it already happened once.

## Where it stands

No evidence recorded. It cannot be closed until something can be clicked.
Next, from the last handoff: nothing from me. He uses the tool for real — `/next`, do the work,

## Already ruled out — read before proposing anything

- **R-063 · Putting a chat URL in a committed file on a public repo**
  `state/threads/manual.yaml` exists so a web chat — which has no transcript on disk — can be pointed at by hand. It was designed while this repo was private. It is now public (`DEC-201`) …
- **R-071 · Briefs as an artifact separate from the kickoff prompt**
  **Two generated artifacts, one job.** Compared section by section, `kickoff.py`'s output is a superset of `brief.py`'s except for two things — `decisions_in_force()` and the ⚠-unconfirmed …
- **R-073 · Treating the ranked list as the product**
  **The most-used artifact across this entire build was a hand-written, paste-ready prompt — written by hand roughly a dozen times before anyone noticed it was the product.** The ranking, the …
- **R-025 · Listen-only mode on the CANable `candleLight` tap**
  **It has no working listen-only mode** — the repo verified this directly: `L` is unimplemented and silent mode is doubly broken.

## Work here, not in product-os

This task names no repo, though `product-os` has one (`product-os`). Find out where the work lives before starting.

## Chats already working on this

- claude-code · work-laptop · Tool rebuild around refined model
  RESUME — last active 2026-08-21, and nothing has landed in product-os since
  A verified way back exists on work-laptop, but it names that machine's paths and the session id, so it is not republished. Run `python3 tools/kickoff.py POS-011` there.
- claude-code · work-laptop · BOOTSTRAP.md setup plan
  RESTART — 123 prompts — long enough that its early context is noise
- claude-code · work-laptop · Fix stale product-os entry in state/repos.js
  RESUME — last active 2026-08-19; could NOT check whether work landed in its repo — resume, but re-read the brief first
  A verified way back exists on work-laptop, but it names that machine's paths and the session id, so it is not republished. Run `python3 tools/kickoff.py POS-011` there.
- claude-code · work-laptop · Product-OS slice 1a-minus seed
  RESUME — last active 2026-08-19, and nothing has landed in product-os since
  A verified way back exists on work-laptop, but it names that machine's paths and the session id, so it is not republished. Run `python3 tools/kickoff.py POS-011` there.

## Decisions in force

- **DEC-202** (M2) — Marcelo orders the backlog; the tool stops computing an order

## Rules

- Nothing is done without evidence — a commit SHA, a file path, or a
  dated note. If you cannot produce one, it is not done. Say so.
- Say "I couldn't look", never "no changes". An empty result and an
  unreachable repo are different facts.
- Do not write his decided fields: project, gate, machine_affinity,
  parked/dropped, or the evidence rule. Draft into state/drafts/
  instead — never straight into the task.
- Do not reorder state/backlog.md. That file is his judgement, and it
  is the only order there is. Say so once if you disagree, then work
  on what he put at the top.

Cite POS-007 in your first message.

# POS-007 — Re-centre on software: kill lead-time, park hardware, briefs and resume verdicts

product-os · next · gate none
Freshness: last audit 2026-08-19 · 153 commits unattributed then

## Project context

Know what to work on next, and never be told progress that cannot be clicked.

## What this is

<!-- Why this matters. Then ## Acceptance, then ## Handoffs. -->

## Where it stands

No evidence recorded. It cannot be closed until something can be clicked.
Next, from the last handoff: NO HANDOFF RECORDED — nobody wrote down where this was left.

## Already ruled out — read before proposing anything

- **R-046 · The spec's urgency formula**
  `lead / effort` counts effort twice — it is already the score's denominator. Two independent reviews flagged the resulting quadratic, and the proposed cap bound at 15.75 days, **below this …
- **R-039 · Un-parking Zigbee before the fault ring and the drills**
  **Zigbee is ruled (D3) and parked (D15). Not dead, not next.** Both halves matter; either one alone gets the priority wrong in an opposite direction.
- **R-052 · Publishing a ratio without its operands**
  One plan version printed a lead-time ranking claim with a **wrong** number; the next printed `27×` with **no operands at all**, which is worse — a wrong number is falsifiable and a bare …
- **R-057 · Treating an item ID as unique across seed generations**
  The thread indexer's first run bound a real transcript to `Q-004`. It was wrong. That transcript's `Q-004` sits in this line:

## Work here, not in product-os

This task names no repo, though `product-os` has one (`product-os`). Find out where the work lives before starting.

## Chats already working on this

- claude-code · work-laptop · Tool rebuild around refined model
  RESUME — last active 2026-08-21, and nothing has landed in product-os since
  A verified way back exists on work-laptop, but it names that machine's paths and the session id, so it is not republished. Run `python3 tools/kickoff.py POS-007` there.
- claude-code · work-laptop · BOOTSTRAP.md setup plan
  RESTART — 123 prompts — long enough that its early context is noise
- claude-code · work-laptop · Fix stale product-os entry in state/repos.js
  RESUME — last active 2026-08-19; could NOT check whether work landed in its repo — resume, but re-read the brief first
  A verified way back exists on work-laptop, but it names that machine's paths and the session id, so it is not republished. Run `python3 tools/kickoff.py POS-007` there.
- claude-code · work-laptop · Product-OS slice 1a-minus seed
  RESUME — last active 2026-08-19, and nothing has landed in product-os since
  A verified way back exists on work-laptop, but it names that machine's paths and the session id, so it is not republished. Run `python3 tools/kickoff.py POS-007` there.

## Decisions in force

- **DEC-202** (M2) — Marcelo orders the backlog; the tool stops computing an order

## Rules

- Nothing is done without evidence — a commit SHA, a file path, or a
  dated note. If you cannot produce one, it is not done. Say so.
- Say "I couldn't look", never "no changes". An empty result and an
  unreachable repo are different facts.
- Do not write his decided fields: project, gate, machine_affinity,
  parked/dropped, or the evidence rule. Draft into state/drafts/
  instead — never straight into the task.
- Do not reorder state/backlog.md. That file is his judgement, and it
  is the only order there is. Say so once if you disagree, then work
  on what he put at the top.

Cite POS-009 in your first message.

# POS-009 — llms.txt and the JSON API: the agent-facing surface

product-os · next · gate none
Freshness: last audit 2026-08-19 · 153 commits unattributed then

## Project context

Know what to work on next, and never be told progress that cannot be clicked.

## What this is

<!-- Why this matters. Then ## Acceptance, then ## Handoffs. -->

## Where it stands

No evidence recorded. It cannot be closed until something can be clicked.
Next, from the last handoff: NO HANDOFF RECORDED — nobody wrote down where this was left.

## Already ruled out — read before proposing anything

- **R-071 · Briefs as an artifact separate from the kickoff prompt**
  **Two generated artifacts, one job.** Compared section by section, `kickoff.py`'s output is a superset of `brief.py`'s except for two things — `decisions_in_force()` and the ⚠-unconfirmed …
- **R-044 · Seeding or auditing from a local clone**
  $ git rev-list --count HEAD..origin/main # in the local clone 0 $ gh api .../compare/90ff98d...main --jq .ahead_by 54
- **R-047 · `sort_keys=True` on entity frontmatter**
  Alphabetical puts `title` 22nd of 24 and scatters `impact`/`confidence`/`effort` across the block. Explicit spec order is what makes a one-field change diff as one line.
- **R-058 · A coverage number that silently caps**
  `audit.py`'s commit query used `per_page=100` with no pagination. For `gimbal-bench` it returned **exactly 100** commits and reported that as the answer; the true count in the same window …

## Work here, not in product-os

This task names no repo, though `product-os` has one (`product-os`). Find out where the work lives before starting.

## Chats already working on this

- claude-code · work-laptop · Tool rebuild around refined model
  RESUME — last active 2026-08-21, and nothing has landed in product-os since
  A verified way back exists on work-laptop, but it names that machine's paths and the session id, so it is not republished. Run `python3 tools/kickoff.py POS-009` there.
- claude-code · work-laptop · BOOTSTRAP.md setup plan
  RESTART — 123 prompts — long enough that its early context is noise
- claude-code · work-laptop · Fix stale product-os entry in state/repos.js
  RESUME — last active 2026-08-19; could NOT check whether work landed in its repo — resume, but re-read the brief first
  A verified way back exists on work-laptop, but it names that machine's paths and the session id, so it is not republished. Run `python3 tools/kickoff.py POS-009` there.
- claude-code · work-laptop · Product-OS slice 1a-minus seed
  RESUME — last active 2026-08-19, and nothing has landed in product-os since
  A verified way back exists on work-laptop, but it names that machine's paths and the session id, so it is not republished. Run `python3 tools/kickoff.py POS-009` there.

## Decisions in force

- **DEC-202** (M2) — Marcelo orders the backlog; the tool stops computing an order

## Rules

- Nothing is done without evidence — a commit SHA, a file path, or a
  dated note. If you cannot produce one, it is not done. Say so.
- Say "I couldn't look", never "no changes". An empty result and an
  unreachable repo are different facts.
- Do not write his decided fields: project, gate, machine_affinity,
  parked/dropped, or the evidence rule. Draft into state/drafts/
  instead — never straight into the task.
- Do not reorder state/backlog.md. That file is his judgement, and it
  is the only order there is. Say so once if you disagree, then work
  on what he put at the top.

Cite POS-012 in your first message.

# POS-012 — A correction is only real where it is read

product-os · doing · gate none
Freshness: last audit 2026-08-19 · 153 commits unattributed then

## Project context

Know what to work on next, and never be told progress that cannot be clicked.

## What this is

A correction that exists but sits outside the window its reader looks through did not happen. This item exists because that failure was found in production on the agent-facing surface, and because it is a *different* class from the one `CLAUDE.md`'s table already covers — different enough that the remedies point in opposite directions.

## Where it stands

Evidence on file: 093dbe9, cdb5eb4.
Next, from the last handoff: NO HANDOFF RECORDED — nobody wrote down where this was left.

## Already ruled out — read before proposing anything

- **R-065 · Placing a correction where the consumer does not read it**
  **A correction is only real where it is read.** Writing the fix is not the same act as delivering it, and this portfolio has now got that wrong four times:
- **R-066 · Two agents writing one working tree**
  The multi-machine design makes **cross-machine** conflict structurally impossible: `state/threads/by-machine/<id>.json` is written by exactly one machine's indexer, so two machines syncing …
- **R-048 · Path-level guards for a field-level authority rule**
  A `PreToolUse` guard sees **a file**, not a field. Human-authority and agent-authority keys live in the same frontmatter block, so no path rule can tell which key moved. `validate.py`'s …
- **R-050 · `product-os` starting public**
  **SUPERSEDED 2026-08-19 by `DEC-201` — product-os is PUBLIC.** This paragraph leads deliberately: `brief.py` and `kickoff.py` excerpt the *first* paragraph of an entry, so a marker at the …

## Work here, not in product-os

This task names no repo, though `product-os` has one (`product-os`). Find out where the work lives before starting.

## Chats already working on this

- claude-code · work-laptop · Tool rebuild around refined model
  RESUME — last active 2026-08-21, and nothing has landed in product-os since
  A verified way back exists on work-laptop, but it names that machine's paths and the session id, so it is not republished. Run `python3 tools/kickoff.py POS-012` there.
- claude-code · work-laptop · BOOTSTRAP.md setup plan
  RESTART — 123 prompts — long enough that its early context is noise
- claude-code · work-laptop · Fix stale product-os entry in state/repos.js
  RESUME — last active 2026-08-19; could NOT check whether work landed in its repo — resume, but re-read the brief first
  A verified way back exists on work-laptop, but it names that machine's paths and the session id, so it is not republished. Run `python3 tools/kickoff.py POS-012` there.
- claude-code · work-laptop · Product-OS slice 1a-minus seed
  RESUME — last active 2026-08-19, and nothing has landed in product-os since
  A verified way back exists on work-laptop, but it names that machine's paths and the session id, so it is not republished. Run `python3 tools/kickoff.py POS-012` there.

## Decisions in force

- **DEC-202** (M2) — Marcelo orders the backlog; the tool stops computing an order

## Rules

- Nothing is done without evidence — a commit SHA, a file path, or a
  dated note. If you cannot produce one, it is not done. Say so.
- Say "I couldn't look", never "no changes". An empty result and an
  unreachable repo are different facts.
- Do not write his decided fields: project, gate, machine_affinity,
  parked/dropped, or the evidence rule. Draft into state/drafts/
  instead — never straight into the task.
- Do not reorder state/backlog.md. That file is his judgement, and it
  is the only order there is. Say so once if you disagree, then work
  on what he put at the top.

Cite POS-006 in your first message.

# POS-006 — Group D coverage: cluster 301 unattributed commits into items

product-os · doing · gate none
Freshness: last audit 2026-08-19 · 153 commits unattributed then

## Project context

Know what to work on next, and never be told progress that cannot be clicked.

## What this is

Group D is a to-do list, not an error log. At the default window it is **301** commits that no item claims, against **29** items — roughly 10% of the portfolio modelled, with the missing 90% concentrated in `gimbal-bench`.

## Where it stands

No evidence recorded. It cannot be closed until something can be clicked.
Next, from the last handoff: one sentence from him; then create the items and re-measure.

## Already ruled out — read before proposing anything

- **R-058 · A coverage number that silently caps**
  `audit.py`'s commit query used `per_page=100` with no pagination. For `gimbal-bench` it returned **exactly 100** commits and reported that as the answer; the true count in the same window …
- **R-064 · Measuring a proxy instead of measuring the tool's output**
  `PROP-0003` proposed twenty `done` items and claimed they would drop group D from **301 to 13**. **The real effect is zero**, and the proposal was queued for a one-sentence yes.
- **R-072 · A backlog the system wrote for itself**
  **The system generated ~30 items from the repos, then asked Marcelo to ratify the scores on work he had never chosen. `PROP-0001` was never answered, and the silence was the finding.** The …
- **R-037 · Proving mute machinery offline**
  M6's first-hour P1 was invisible to

## Work here, not in product-os

This task names no repo, though `product-os` has one (`product-os`). Find out where the work lives before starting.

## Chats already working on this

- claude-code · work-laptop · Tool rebuild around refined model
  RESUME — last active 2026-08-21, and nothing has landed in product-os since
  A verified way back exists on work-laptop, but it names that machine's paths and the session id, so it is not republished. Run `python3 tools/kickoff.py POS-006` there.
- claude-code · work-laptop · BOOTSTRAP.md setup plan
  RESTART — 123 prompts — long enough that its early context is noise
- claude-code · work-laptop · Fix stale product-os entry in state/repos.js
  RESUME — last active 2026-08-19; could NOT check whether work landed in its repo — resume, but re-read the brief first
  A verified way back exists on work-laptop, but it names that machine's paths and the session id, so it is not republished. Run `python3 tools/kickoff.py POS-006` there.
- claude-code · work-laptop · Product-OS slice 1a-minus seed
  RESUME — last active 2026-08-19, and nothing has landed in product-os since
  A verified way back exists on work-laptop, but it names that machine's paths and the session id, so it is not republished. Run `python3 tools/kickoff.py POS-006` there.

## Decisions in force

- **DEC-202** (M2) — Marcelo orders the backlog; the tool stops computing an order

## Rules

- Nothing is done without evidence — a commit SHA, a file path, or a
  dated note. If you cannot produce one, it is not done. Say so.
- Say "I couldn't look", never "no changes". An empty result and an
  unreachable repo are different facts.
- Do not write his decided fields: project, gate, machine_affinity,
  parked/dropped, or the evidence rule. Draft into state/drafts/
  instead — never straight into the task.
- Do not reorder state/backlog.md. That file is his judgement, and it
  is the only order there is. Say so once if you disagree, then work
  on what he put at the top.

Cite POS-001 in your first message.

# POS-001 — Build product-os slice 1a-minus

product-os · doing · gate none · machine work-laptop
Freshness: last audit 2026-08-19 · 153 commits unattributed then

## Project context

Know what to work on next, and never be told progress that cannot be clicked.

## What this is

This repo, being built. `status: doing`. Six tools, three skills, one hook, the seed, and the ruled-out register. **It is not done and will not be marked done here.** The milestone tests are written into the evidence rule above precisely so that a future session cannot close this on a feeling. When they pass, they pass on a run somebody can repeat.

## Where it stands

Evidence on file: 8890b05, 8175094, d04a029.
Next, from the last handoff: NO HANDOFF RECORDED — nobody wrote down where this was left.

## Already ruled out — read before proposing anything

- **R-050 · `product-os` starting public**
  **SUPERSEDED 2026-08-19 by `DEC-201` — product-os is PUBLIC.** This paragraph leads deliberately: `brief.py` and `kickoff.py` excerpt the *first* paragraph of an entry, so a marker at the …
- **R-048 · Path-level guards for a field-level authority rule**
  A `PreToolUse` guard sees **a file**, not a field. Human-authority and agent-authority keys live in the same frontmatter block, so no path rule can tell which key moved. `validate.py`'s …
- **R-057 · Treating an item ID as unique across seed generations**
  The thread indexer's first run bound a real transcript to `Q-004`. It was wrong. That transcript's `Q-004` sits in this line:
- **R-068 · Scoring a solo backlog with impact × confidence ÷ effort**
  **The ranking escalates on the majority of its own decisions.** `CLAUDE.md` says *"if two items score within ~10% of each other — stop and ask."* Measured across the 18 offerable nodes: **9 …

## Work here, not in product-os

Repo: `product-os`. product-os TRACKS the work; it does not host it. Make the change there and come back only to write the handoff.
Machine: **work-laptop**. If that is not where you are, the honest answer is "resume on work-laptop" — not a plan you cannot execute.

## Chats already working on this

- claude-code · work-laptop · Tool rebuild around refined model
  RESUME — last active 2026-08-21, and nothing has landed in product-os since
  A verified way back exists on work-laptop, but it names that machine's paths and the session id, so it is not republished. Run `python3 tools/kickoff.py POS-001` there.
- claude-code · work-laptop · BOOTSTRAP.md setup plan
  RESTART — 123 prompts — long enough that its early context is noise
- claude-code · work-laptop · Fix stale product-os entry in state/repos.js
  RESUME — last active 2026-08-19; could NOT check whether work landed in its repo — resume, but re-read the brief first
  A verified way back exists on work-laptop, but it names that machine's paths and the session id, so it is not republished. Run `python3 tools/kickoff.py POS-001` there.
- claude-code · work-laptop · Product-OS slice 1a-minus seed
  RESUME — last active 2026-08-19, and nothing has landed in product-os since
  A verified way back exists on work-laptop, but it names that machine's paths and the session id, so it is not republished. Run `python3 tools/kickoff.py POS-001` there.
- claude-code · work-laptop · Product-OS slice 1a-minus build
  RESUME — last active 2026-08-19, and nothing has landed in product-os since
  A verified way back exists on work-laptop, but it names that machine's paths and the session id, so it is not republished. Run `python3 tools/kickoff.py POS-001` there.

## Decisions in force

- **DEC-202** (M2) — Marcelo orders the backlog; the tool stops computing an order

## Rules

- Nothing is done without evidence — a commit SHA, a file path, or a
  dated note. If you cannot produce one, it is not done. Say so.
- Say "I couldn't look", never "no changes". An empty result and an
  unreachable repo are different facts.
- Do not write his decided fields: project, gate, machine_affinity,
  parked/dropped, or the evidence rule. Draft into state/drafts/
  instead — never straight into the task.
- Do not reorder state/backlog.md. That file is his judgement, and it
  is the only order there is. Say so once if you disagree, then work
  on what he put at the top.

Cite APP-001 in your first message.

# APP-001 — Give HomeApp an evidence rule that does not depend on git history

home-app · next · gate none
Freshness: last audit 2026-08-19 · 153 commits unattributed then

## Project context

The household's own front end to the house.

## What this is

`hooterjackson/HomeApp` is **one commit**: `b769b30`, 2026-06-12T15:05Z, "Deploy current Home app snapshot". I verified this against the remote — the whole `main` history is that single entry. Every commit-shaped evidence query against this repo therefore returns nothing, forever, and **nothing is not the same as no work happened.** Left alone, this project would quietly report "clean" in every audit while being the one place the system genuinely cannot see.

## Where it stands

No evidence recorded. It cannot be closed until something can be clicked.
Next, from the last handoff: NO HANDOFF RECORDED — nobody wrote down where this was left.

## Already ruled out — read before proposing anything

- **R-044 · Seeding or auditing from a local clone**
  $ git rev-list --count HEAD..origin/main # in the local clone 0 $ gh api .../compare/90ff98d...main --jq .ahead_by 54
- **R-037 · Proving mute machinery offline**
  M6's first-hour P1 was invisible to
- **R-053 · Paraphrasing inside quotation marks**
  A plan shipped a composite quote that existed nowhere — inside a section headed *"edges the evidence states, quoted."*
- **R-056 · Browser-local state as a repo evidence rule**
  `EL-001`'s evidence rule named `docs/bom-checklist.md` and nothing else. That file says of itself:

## Work here, not in product-os

Repo: `HomeApp`. product-os TRACKS the work; it does not host it. Make the change there and come back only to write the handoff.

## Chats already working on this

- claude-code · work-laptop · Fix stale product-os entry in state/repos.js
  RESUME — last active 2026-08-19; could NOT check whether work landed in its repo — resume, but re-read the brief first
  A verified way back exists on work-laptop, but it names that machine's paths and the session id, so it is not republished. Run `python3 tools/kickoff.py APP-001` there.

## Rules

- Nothing is done without evidence — a commit SHA, a file path, or a
  dated note. If you cannot produce one, it is not done. Say so.
- Say "I couldn't look", never "no changes". An empty result and an
  unreachable repo are different facts.
- Do not write his decided fields: project, gate, machine_affinity,
  parked/dropped, or the evidence rule. Draft into state/drafts/
  instead — never straight into the task.
- Do not reorder state/backlog.md. That file is his judgement, and it
  is the only order there is. Say so once if you disagree, then work
  on what he put at the top.