~p: Be Definition of Done

One gate. Not five. Replaces the 5-guard plan with a single enforceable checklist.

Intent

Intent: Prevent work loss across Claude Code sessions by defining what "Done" actually means in Be.

Purpose: A single quality gate — enforced after every work command — that guarantees the artifact trail is complete, the code is committed, and the next session can trust what it finds.

What: A Definition of Done (DoD) added to CLAUDE.md, enforced as the final step of every tilde command's chain reaction. Plus a lightweight Definition of Ready (DoR) as a pre-flight.

The Definition of Done

Every tilde command that produces an artifact (~a, ~u, ~d, ~f, ~b, ~t, ~s, ~r, ~p, ~e, ~i, ~ul) must pass ALL items before the command is considered complete. Only ~h and ~li are exempt (no artifacts, display only).

Code committed — All changes are in a git commit with a descriptive message. No uncommitted work.

Commit hash in telemetry — The telemetry entry for this command has a non-null commit field. Backfilled in the same commit, not later.

Board updated (if applicable) — If a board item was worked, it moved to Done with its commit hash: {item} · pts · ~cmd ✅ (abc1234). Board committed alongside code. Applies to work commands only — planning/inspect commands skip this check.

HTML report saved — The build/test/ship report exists in be/ with the correct datetime filename.

Index updated — be/index.html has an entry linking to the new report.

Pushed to remote — git push succeeded. Work exists on origin, not just locally.

No prior work damaged — Files related to Done board items were not modified unless a new board item explicitly targets them. Stewardship verified.

Additional for chain-final commands (~s, ~r):

Chain complete — Every preceding step in the chain has a telemetry entry with a non-null commit hash. No gaps in the trail.

The Definition of Ready

Before the first edit of a session, read and verify:

Board state — Read be/board.md. Know what's Done, In Progress, Ready. Don't touch Done items.

Last telemetry entry — Was the previous chain completed? If last entry is ~b or ~t without a following ~s, flag it to the user.

Source of truth — If project CLAUDE.md declares canonical files, respect them. Don't edit non-canonical copies.

How This Replaces the 5-Guard Plan

Old Guard	New Home
Guard 1: Pre-Flight Checklist	Definition of Ready (R1–R3)
Guard 2: Single Source of Truth	Definition of Ready (R3) + project convention
Guard 3: Stewardship Rule	DoD item 7 — no prior work damaged
Guard 4: Chain Completion	DoD items 2, 8 — commit hashes + chain complete
Guard 5: Done Means Done	DoD item 3 — board + hash = frozen

Five scattered rules become one gate with 8 checkboxes. Easier to remember, easier to enforce, easier to verify.

Enforcement

Where: The DoD checklist goes in metal CLAUDE.md as part of the chain reaction rules. Every Claude Code session reads it. Every tilde command runs through it.

When: After the work is done, before the command is considered complete. The chain reaction becomes:

do the work → render report → save → update index → log telemetry → commit → push → verify DoD → if fail, fix and re-verify → launch demo

Failure mode: If any DoD item fails, the command is not Done. Fix the failure in-place and re-verify. Don't move on. Don't start the next chain step. The gate holds.

Visible Audit Trail

Every build/test/ship HTML report gets a DoD section at the bottom — a rendered checklist showing pass/fail for each item:

✓ Code committed (abc1234)
✓ Telemetry hash: abc1234
✓ Board: {item} → Done
✓ Report: builds/2026-04-05-xyz.html
✓ Index updated
✓ Pushed to origin/main
✓ No prior Done items modified

The next session reads this and knows the work is complete. No guessing. No assumptions. The checklist is the proof.

Implementation

Phase 1: Add DoD + DoR to metal CLAUDE.md

Add the Definition of Done (7+1 items) and Definition of Ready (3 items) to the chain reaction section. This is the core change — everything else flows from it.

5 pts

Phase 2: Add DoD checklist rendering to HTML reports

Update the HTML template convention so every report includes a DoD section. The checklist is rendered after the report content, before the footer.

3 pts

Phase 3: Add source-of-truth to bahalaka CLAUDE.md

Create or update C:\bahalaka\CLAUDE.md declaring index.html (root) as the canonical file. Add any project-specific DoR items.

3 pts

Phase 4: Test with a GO chain on bahalaka Board 5

Run the first board with the DoD active. Verify every item passes, reports include the checklist, and telemetry has zero nulls.

5 pts

Total: 16 pts across 4 phases. Phases 1–3 are metal work. Phase 4 is bahalaka work.

What This Doesn't Solve

Context window exhaustion. If Claude runs out of context, the DoD can't run. But the next session's DoR (R2) will catch the incomplete chain.
Concurrent sessions. Two sessions editing the same file at the same time will still conflict. The DoD handles sequential sessions. Parallel sessions need a different solution (or just: don't do it).
Human override. If the user says "skip it," the DoD is skipped. That's by design — the user is the authority.

Relationship to Previous Plan

This plan supersedes the 5-guard plan (2026-04-05-plan-work-loss-prevention.html). All 5 guards are absorbed into the DoD/DoR framework. The concepts are the same; the structure is cleaner. One gate, not five.