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. In your product-os clone THERE, run `python3 tools/kickoff.py GB-001`.

## 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. In your product-os clone THERE, run `python3 tools/kickoff.py GB-014`.

## 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 — Prepare the radio build: memory layout, and a stub for signing updates (Z-M1)

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. In your product-os clone THERE, run `python3 tools/kickoff.py GB-005`.

## 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 — Add the single-slot mailbox the radio and the safety loop pass messages through (Z-M0)

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. In your product-os clone THERE, run `python3 tools/kickoff.py GB-006`.

## 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 — Bring the fixture up on the radio and prove it still behaves like a light (Z-M3)

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. In your product-os clone THERE, run `python3 tools/kickoff.py GB-008`.

## 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. In your product-os clone THERE, run `python3 tools/kickoff.py GB-002`.

## 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. In your product-os clone THERE, run `python3 tools/kickoff.py Q-001`.

## 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. In your product-os clone THERE, run `python3 tools/kickoff.py GB-004`.

## 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. In your product-os clone THERE, run `python3 tools/kickoff.py Q-002`.

## 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. In your product-os clone THERE, run `python3 tools/kickoff.py Q-003`.

## 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 — Build the rollback ladder, so a bad radio update can be backed out (Z-M2)

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. In your product-os clone THERE, run `python3 tools/kickoff.py GB-007`.

## 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. In your product-os clone THERE, run `python3 tools/kickoff.py GB-012`.

## 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. In your product-os clone THERE, run `python3 tools/kickoff.py GB-013`.

## 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. In your product-os clone THERE, run `python3 tools/kickoff.py Q-004`.

## 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 — Decide how the fixture is commissioned, and what a reset actually resets (Z-M4)

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. In your product-os clone THERE, run `python3 tools/kickoff.py GB-009`.

## 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 — Prove the deployed fixture only moves when it is meant to (Z-M5)

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. In your product-os clone THERE, run `python3 tools/kickoff.py GB-010`.

## 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 — Report telemetry over the radio, including the long dumps (Z-M6)

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. In your product-os clone THERE, run `python3 tools/kickoff.py GB-011`.

## 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. In your product-os clone THERE, run `python3 tools/kickoff.py HAI-001`.

## 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. In your product-os clone THERE, run `python3 tools/kickoff.py APP-001`.

## 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.