← Back to Daily Builds

Daily build note · August 21, 2026

Agent Proof Pm

**"PM where 'done' requires proof."** Stated design principle (adopted from Cyborgenic, per chaos-goblin): **the agent does not decide whether it is done.** A small team (or solo operator)...

Agent Accountability Pm Phase1 Build note published Live public demo

What shipped

A working, clickably usable local-first PM app in one night: agent_proof_pm (Python 3.11 stdlib only) with seed / verify-task / serve, serving a four-column kanban where agent-task completion is governed by hash-bound receipts from the unchanged Bot Routine Receipt Desk. A live public demo of this exact app runs on Cloud Run: https://agent-proof-pm-demo-930822350118.us-west1.run.app/ (try Verify on T-001 — clean run flips green — versus T-002, which claims done but carries a silent skip and refuses to flip).

**The core invariant is enforced at three layers:** the UI select-box lists Verified only as a disabled option; the API returns 409 on any manual move to verified; and the verifier is the only code path that writes status: verified — and only when the desk receipt shows all steps executed with zero findings. Design principle, stated in the product itself: "the agent does not decide whether it is done."

Architecture

  1. **Receipts are the primitive** — routine / runs / verification are

first-class task fields; the board has a Verified column distinct from Done (Claimed); silent skips surface at board level ("N tasks claim done · M steps unproven").

  1. **Honest agent, no theater** — the "agent teammate" is an imported run

record; verification is the real, unchanged sibling Receipt Desk CLI invoked per verify (verify-run + validate), not a scripted bot.

  1. **Fail closed** — if the desk is missing or errors, verification returns

503 and nothing flips to verified; there is no code path that marks a task verified without a passing receipt.

  1. **Strict closed schema** — board.json rejects duplicate JSON keys, unknown

fields, and bad statuses on load; moves out of Verified are allowed but keep the historical verification block for the receipt trail.

  1. **Allocation-term compliance (weekly-portfolio-director):** receipts as

primitive ✓; no theater ✓; sync/integrations/mobile/Gantt/docs/notifications excluded ✓; demand gate recorded — phase 2 starts only after the $250 outreach uses this app as the demo vehicle or a qualified operator asks to touch it ✓; night ends verify-green ✓.

Trimmed scope

Single-user, single board file, localhost-first; run history lives in-board (no archive growth); no task creation UI (board.json is the editing surface for new tasks this phase); no multi-user sync, integrations, mobile, Gantt/docs/timeline, or notifications infrastructure until the demand gate fires.

Limitations

Desk invocation is synchronous (~1s per verify) and blocks the request; one board per data directory; the demo seeds a fixed synthetic fixture (newsletter-stats routine with clean/silent-skip/failure runs) rather than arbitrary user routines; external attestations have a schema slot but no ingest flow yet.

Verification

  • bash verify.sh → **exit 0**: 16 tests + headless CLI flow.
  • T-001 (clean run): desk receipt brr-2080d43a8106, 5/5 steps executed,

0 findings → **flipped to verified**.

  • T-002 (silent skip): desk receipt brr-26aa9c2ce082, 3 findings, silent

skip on pull-subscriber-stats → **stayed done_claimed**, red flag on the card, board banner reads "1 task(s) claim done · 1 step(s) unproven".

  • Live server smoke: UI served, /api/board correct, illegal move to verified

rejected with 409, fail-closed proven when the desk root is missing (503, nothing flips).

  • Sibling desk untouched: its own bash verify.sh re-run inside this suite,

exit 0.

  • Public Cloud Run demo smoke: UI 200, live verify call returned

verified: true for T-001 against the real in-container desk.

Suggested next steps

Use this board as the demo vehicle for the three held $250 Routine Trust Review DMs: show T-001 flipping green vs T-002 refusing to flip — that screen is the pitch. No further engineering until the demand gate fires. Phase 2 candidates (gated): Grok Bot run-record import as tasks, external attestation ingest alongside brr- receipts.