DUNIN7-M4 — INFRASTRUCTURE CHANGE REQUEST

CR-2026-184 — B-37: a failed Shape production is invisible (v0.1)

Version. 0.1 · Date. 2026-08-07 · Author. Claude.ai (drafting) / Marvin Percival (approving). Target. /Users/dunin7/loomworks-engine and /Users/dunin7/loomworks. Baseline. Engine post CR-2026-181 (366102d); surface post CR-2026-182 (852124b). CC confirms both at Step 0. Companion to. inspection-briefs/loomworks-small-work-sweep-step-0-findings-v0_1.md §6; standing-notes/loomworks-development-schedule-v0_1 (decision pre-settled). Charter. Autonomous regime. Status. Ready for CC execution.

1. Summary

When a Shape production job fails, the surface shows nothing that distinguishes it from a job still running. The person waits for something that is never coming.

The schema already has the link column joining a job to its Shape — it is simply never populated at creation.

Design decision, settled in advance: a new field on the existing response, not a new route. A new route would need its own auth and caching story for no benefit; status belongs alongside the thing whose status it is.

2. Scope

Engine.

Populate the job→shape link column at creation, where it is currently left null.
Add a status field to the existing Shape response carrying the production job's state — including failure, distinguishably from in-progress and from never-started.
Failure carries enough for a person to act: at minimum that it failed and when. Whether it carries why is CC's call from what the job record already holds — do not add new failure-capture machinery in this CR; expose what exists.

Surface.

Render the failed state distinctly from in-progress. Plain terms, not codebase shorthand.
Only-show-what-is-available governs any retry affordance: if no retry path exists in the engine today, no retry control appears — and CC reports that rather than building one. Retry is not in this CR's scope.

3. Out of scope

Retry. Surfacing a failure is not the same as offering to fix it. If retry is wanted it is its own item.
New failure-capture. Expose what the job record holds; do not enrich it here.
B-52 and B-55, which also span both repos and have their own CRs.

4. Build steps

| Step | What | Mode | |---|---|---| | 0 | Pre-flight, both repos. | Auto | | 1 | Read: what does the job record already hold on failure? Report before building §2.3. | Auto | | 2 | Populate the link column at creation + test. | Auto | | 3 | Status field on the Shape response + tests covering never-started, running, failed, complete. | Auto | | 4 | Surface rendering of the failed state + tests. | Auto | | 5 | Engine suite + surface sweep; ruff 0; mypy at/below baseline. | Auto | | A | Checkpoint. | Checkpoint | | 6 | Tag cr-2026-184-b37-failed-production-visible in both repos. Push. | Auto |

5. Acceptance gate

A failed production is distinguishable on the surface from one still running — the actual defect.
Link column populated at creation; existing rows with a null link reported (count) and backfilled if unambiguous, reported if not.
No retry control appears unless the engine already supports it.
Both suites green, both gates clean.

6. Kickoff prompt


Execute CR-2026-184 v0.1 at ~/Downloads/cr-2026-184-loomworks-b37-
failed-production-visible-v0_1.md. Confirm the CR number first.

B-37: a failed Shape production looks identical to one still running.
The job→shape link column exists but is never populated at creation.

The design decision is pre-settled: new field on the existing response,
not a new route. Don't reopen it.

Step 1 is a read — report what the job record already holds on failure
before you decide what the status field carries. Do NOT add new
failure-capture machinery; expose what exists.

Retry is out of scope. If no retry path exists in the engine, no retry
control appears on the surface — report that, don't build one.

Baselines: engine 366102d, surface 852124b. Confirm both at Step 0.

DUNIN7 — Done In Seven LLC — Miami, Florida CR-2026-184 — B-37 failed production visible — v0.1 — 2026-08-07