DUNIN7 · LOOMWORKS · RECORD
record.dunin7.com
Status Current
Path session-handoffs/cr-2026-197-execution-checkpoint-report-v0_1.md

CR-2026-197 — execution checkpoint report — v0.1

Version. 0.1 · Date. 2026-08-10 · Author. Claude Code (execution session). Operator: Marvin Percival. CR. change-requests/cr-2026-197-loomworks-b8-slice-two-companion-drafts-v0_1.md — approved to execute 2026-08-10 with §0b's three drafting decisions standing and two riders (both honored, §3 below). Baselines confirmed at Step 0. Engine d85154d, surface 62b2f27, both trees clean at start. State at this checkpoint. Built, tested, eye-tested. Nothing committed in any repository — engine and surface changes sit in working trees awaiting the gate.


1. The numbers, verbatim

| Check | Result | |---|---| | Engine full suite | 3629 passed, 68 skipped, 0 failed — 527.88s (0:08:47), exit 0 | | Engine ruff | All checks passed! | | Engine mypy baseline | 538 error(s), all covered by the baseline (338 entries) — exit 0, 0 new | | CR-197 test file | 19 passed (tests/test_cr_2026_197_companion_drafts.py) | | Surface tsc | clean (npx tsc --noEmit, no output) | | Surface vitest | 765 passed, 0 failed (118 files) |

Zero-failure baseline discipline met on both repositories.

2. What sits in the working trees

Engine (loomworks-engine) — 4 modified, 2 new:

Surface (/Users/dunin7/loomworks) — 2 modified (CR Step 5, smallest fix):

Record (loomworks-record)implementation-notes/cr-2026-197-implementation-notes-v0_1.md (uncommitted; moved out of the engine tree per §5).

3. The two riders, honored

Slice-scoped flag reasoning recorded. In the implementation notes and in register_companion_room_dispatchers' own docstring, positioned where whoever removes the flag will read it: nothing had yet seen the Companion write once, and a standing grant given before that is given blind; loosening later is cheap, the reverse is not. Goes in the completion note verbatim at close.

All three load-bearing checks observed failing first, each against a deliberate break, each failing with a message that names the invariant, each revert re-verified green:

  1. Production registration flag set False → test_pre_authorized_grant_still_cards_and_bypass_not_called failed: "execute_pre_authorized ran for a per_action_only dispatcher."
  2. Fixture made vacuous (grant created per_action) → the test's own guard failed first: "fixture is vacuous: the delegation must resolve as pre_authorized… this test proves nothing" — the B-51 shape, now impossible to reintroduce silently.
  3. Gate made unreachable (own-key agent) → test_spend_refusal_reaches_job_failure_from_dispatch failed: "a completed job here means the gate was never reached from the dispatch path."

4. B-80 — what it is, what decided it, when

B-80 is not filed anywhere yet. It is the label I proposed at the previous checkpoint for a defect found by CR Step 5's verify; it exists only in this report and the implementation notes. It goes on the build list only if you approve the filing. What it would say:

The three specific approval-card components render dead or hidden controls against real wire data. The engine's wire value for a pending card is pending_approval (notifications/schemas.py:62); ProposalApprovalCard, GrantDecisionApprovalCard, and SpendPauseApprovalCard each initialize local state as (approval_status as "pending"|null) ?? "pending" and compute resolved = localStatus !== "pending" — so a real pending card reads as already resolved and each card hides its own wired buttons (including spend-pause's "stop pausing"). After this CR's generic-card fix, the inner NotificationCard now renders Approve/Decline inside those components — with no handlers attached. Observed live during the eye-test: the spend-pause card's visible Decline button no-ops (clicked; job and card state unchanged; declined successfully via the same endpoint the button should call).

What decided it and when: found 2026-08-10 during CR-2026-197 Step 5 ("verify the inbox renders a Tier-1 card"), via two facts: (a) the wire/predicate mismatch read directly from code; (b) playground_dev holds 891 companion_notifications rows with zero non-null approval_status — no approval card had ever existed in the dev database, so this render path had never met real wire data. Another instance of green-because-the-environment-cannot-reach-the-defect: each component's vitest suite hands it the value it expects, not the value the wire sends. Deliberately not fixed in this CR — three pre-existing sites, outside the fence.

5. B-46 — not decided; the notes moved

B-46 is READY-to-scope, undecided; its entry records exactly this drift ("implementation notes land in the code repositories; the filing convention says documents live in the record"). The convention therefore holds and no silent precedent is set: the implementation notes were moved from engine docs/phase-crs/ to loomworks-record/implementation-notes/cr-2026-197-implementation-notes-v0_1.md. Noted for B-46's eventual scoping: engine docs/phase-crs/ holds ~40 prior CRs' notes (including CR-2026-170's) that a decision would either migrate or bless in place.

6. Product eye-test — what I did and what I saw

Method. Dedicated throwaway engagement per the E2E cleanup rule (irreversible ops → test engagement created in setup, torn down after): E0124, "CR-197 EYE-TEST (throwaway)", created in playground_dev via the engine library — seed, Engagement object, spec DST ("application specification", REQ_TABLE grammar), Shaping (AgentExecutor), current Manifestation, and operator membership for Marvin - Test2 (the designated test persona; the primary Operator's personal engagement untouched). Engine restarted so bootstrap registered the agent (the running server predated the change — see §7). Driven through the real UI at localhost:3001 in Chrome, signed in as Test2.

Gate item 3a — no delegation → denied. Asked "Draft an application specification for this project." Reply: "I don't have the authority to draft specifications on this project yet. You can either grant me that standing authority by saying something like 'you can draft specifications,' or you can draft it yourself…" Observed.

Gate item 3b — delegation but no agent spend license → visible refusal. With a per-action delegation and no agent_spend_authorized: ask → card → Approve → dispatch completed (job + pre-allocated shape id in execution_result) → job failed with error_message: "room spend refused: unauthorized (exits: ['authorize agent spend for this engagement', 'supply an API key'])". No debit. Observed — and this also confirms behaviorally that the new dispatchers are what the server runs.

Gate item 2, park half — cap named before any debit. Funded Test2 (200k test credits), authorized agent spend, spend_pause on: ask → card → Approve → job parked pending_approval with spend_pause_cap = 124, and a spend-pause card arrived: "This shaping run will cost up to 124 credits before it runs." Declined → job declined, zero room-tagged consumption flows. Observed. (Screenshot: the cap-named card.)

Gate item 2, produce half — pending shape with companion provenance. spend_pause off: ask → card → Approve → job completed — a real model run. The Shaping room shows Shape #1 "Application Specification", pending, with its Confirm control (and honestly notes no declared render outputs — B-79's fact, correctly surfaced). The persisted ShapeEvent: state = pending_confirmation, triggered_by.kind = "companion", capability_ref = the authorizing delegation's assertion id exactly, approval_mode = "explicit". Metered debit: 2 credits, room=shaping — well under the 124 cap. Observed. (Screenshot: the Shaping room.)

Gate item 4 — pre-authorized still cards. Revoked the per-action grant, created a genuinely pre_authorized one (verified as such), asked again: an approval card was created and no job ran — job count unchanged, execute_pre_authorized demonstrably not taken. Observed. (The reply text for that turn happened to hit a responder-LLM hiccup — "I'm having trouble thinking right now" — while the card was created regardless: the structural write path does not depend on the reply model. The forced-posture wording itself is pinned by the unit tests.)

Also observed working: the Step 5 surface fix — the Tier-1 card rendered in the inbox with functional Approve/Decline, the first time this surface has ever displayed a real approval card; resolved cards show "You approved this." / "You declined this."; the header balance updated live.

Divergences found by the eye-test — all pre-existing, none this CR's build

  1. The conversational grant is not reachable from the in-engagement surface. The denial reply's own suggested sentence — "you can draft specifications" — classified as add_knowledge and was committed as a plain project note in E0124. The grant extraction (extract_delegation_grant, which recognizes the sentence perfectly when called directly) is wired only into the personal remember-about-me path. The CR's acceptance gate item 2 says "granted conversationally" — that clause was not satisfiable in the product; the delegation was created through the service layer (the same seam the conversational path calls). Phase 45 wiring, predates this CR.
  2. A truthfulness violation on the retry. "Remember about me: you can draft specifications" produced the reply "Saved to your personal memory across all projects…"no write occurred anywhere (verified: no new assertion in any engagement). The reply then continued as free conversation. This is the exact class B-11 exists to prevent, on a path it doesn't cover.
  3. Classification is context-sensitive on the draft ask. The same sentence that routed to request_draft in a short conversation routed to general conversation in a longer one, and the unconstrained reply claimed "I'm drafting an application specification … now" — structurally nothing could dispatch (the guarantee held; no card, no job), but the wording overclaims an action.
  4. The dead buttons on the specific cards — §4 above, observed live.

My read: 1 and 2 belong together as one filing (the conversational grant pathway — unreachable in-engagement, and untruthful on the personal path); 3 is adjacent to the same honesty family; 4 is the B-80 proposal. None blocks this CR — the gate's substance (card-before-action, forced per-action, both spend gates, provenance) was observed working in the product end to end. Your call on filings.

Cleanup record

7. Awaiting the gate

On approval, close-out per CR Step 6: engine commit + tag, surface commit, record filings (completion record with the slice-scoped-flag reasoning, build list move, seed-mutability entries under the verbatim heading, implementation notes commit), and whatever filings you rule on from §4 and §6.


DUNIN7 — Done In Seven LLC — Miami, Florida CR-2026-197 execution checkpoint report — v0.1 — 2026-08-10 Every load-bearing check was watched failing before it was believed.