design-pipeline has no per-child spend or wall-clock bound, and the burn watcher prescribes a remedy for a cause it cannot distinguish

[eumemic]

Observation

lane-child-burn-watch fired on run wfr_01M1WEDVR1E7RRZBAX5NZ7PC3A (workflow design-pipeline v5, trigger design-sweep-15m) reporting a suspended run with a live child.

Measured directly against the usage ledger, not run state:

time	child events	child cost
23:41Z	3,780	$35.04
23:56Z	5,885	$56.42

That is roughly $85/hour and ~2,100 events per 15 minutes, for a grounding pass whose declared output schema is five small arrays (facts, seam_files, substrate_core, half_built_prior_art, thread_directives).

The child is not wedged. Across ~30 sampled tool calls, 22 argument strings were distinct, reading db/queries/events.py, api/routers/sessions.py, api/middleware.py, 2256 and 2254 — the correct surface for the issue it is grounding. The cost shape comes from repeatedly re-fetching large files (db/queries/events.py exceeds 100KB) rather than from a loop.

Defect 1 — no per-child bound

design-pipeline v5 bounds MAX_ISSUES_PER_RUN = 2, MAX_DESIGN_ITERS = 2, MAX_DESIGN_LAPS = 4. Every one of those is a lap count. Nothing bounds an individual grounding child by wall-clock or spend, so a single child can run for hours at unbounded cost while every lap counter still reads healthy.

A lap bound does not bound cost when the expensive thing happens inside one lap.

Defect 2 — the watcher names a cause it cannot distinguish

The alarm's text prescribes: "the aios#2271 recurrence signature. CHECK the PR's required checks for one stuck in_progress — that is what watch_ci waits on forever. Then kill the child."

This run has no PR and no watch_ci call. It is a design sweep. Acting on that prescription would have destroyed roughly an hour of legitimate work.

At the watcher's altitude the two situations are identical: a suspended run with a long-lived child. The 2271 stuck-check case and an expensive-but-progressing grounding pass cannot be told apart from run state alone. Because the prescribed action is destructive, a confident wrong prescription is costly in a way a merely noisy alarm is not.

Suggested direction

For defect 1: a per-child spend and/or wall-clock ceiling that returns partial work rather than running unbounded. The ceiling should be derived from measured healthy grounding durations, not picked round.

For defect 2: have the alarm report the observation — child alive N minutes, $X spent, whether the run has a PR and whether a CI watch is present — and let the reader determine the mechanism. Do not address this by widening the burn threshold: that would blind the watcher to the real 2271 class it was built to catch.

Acceptance

• A grounding child exceeding the ceiling terminates with partial output rather than continuing.
• The bound is proven both ways: a normal-length child completes untouched; an over-budget child is stopped.
• The alarm distinguishes "run has a stuck required check" from "run has no PR at all", and its text does not prescribe a remedy for a mechanism it did not verify.

[eumemic]

Update: that child ran to $204 and I killed it. My earlier "leave it alone" call was wrong.

When I filed this I recorded the grounding child as "$56 and climbing but genuinely progressing (22 of 30 tool calls distinct)" and argued against widening the burn threshold. Holding to the second half; the first half aged badly in two hours.

Final state of sess_0YR60RQ7N020E7VX5YBN2JVBTH (grounding aios#2393 for run wfr_01M1WKHJH2MV2FQVVTMKZTEDX6):

cost	$204.06
events	19,288
wall clock	2h29m (00:16Z → 02:45Z)
own rate at kill	$8.50/hour, still climbing
run status	suspended the whole time — looks idle, is not

Archived at 02:45Z. Verified it actually stopped rather than trusting the 200: status: archived, cost frozen at $204.06 across a 45s recheck.

What this does and does not prove

It does not vindicate the alarm's prescription. The alarm said "kill the child, the PR's required checks have one stuck in_progress" — and there is still no PR and no watch_ci on this run. The reasoning was wrong; the conclusion happened to be right for a different reason. A monitor that cites a signature it has not observed is not a monitor I can trust on the next call, and widening the threshold on that basis still blinds it to the real #2271 class.

What it does prove is the gap this issue names. There is no per-child spend or wall-clock bound anywhere in design-pipeline. The only budget is MAX_DESIGN_LAPS = 4 / MAX_DESIGN_ITERS = 2 — lap counts, which a single child that never returns never reaches. One agent() await inside the ground phase can burn indefinitely and the parent will sit suspended behind it forever, because nothing in the script or the host bounds it.

The three stacked runs on this lane were all waiting behind exactly this shape.

Why "distinct tool calls" was the wrong health metric

I used 22 of 30 tool calls distinct as evidence of progress. That test cannot distinguish grinding from progressing — a child can issue endlessly distinct reads and still never converge on an answer. 19,288 events for a grounding pass on a single issue is not a agent doing research; it is an agent that has lost its exit condition. Distinctness measures variety, not convergence.

A better bound needs no cleverness: an absolute per-child ceiling (spend and wall clock), enforced by the host, that fires regardless of what the child looks like it is doing. $204 on grounding one issue is two orders of magnitude past reasonable, and no progress heuristic should be able to argue it down.

Proposed, unchanged in spirit but now with a number attached

1. Per-child hard spend + wall-clock ceiling on agent() in the design pipeline (suggest ~$10 and ~20min for a ground/author/critic node — the normal case is well under $1).
2. Ceiling breach terminates the CHILD and surfaces the partial as a failed node, so the parent run can recycle the lap rather than suspend forever.
3. Keep the burn watcher's threshold where it is; fix its reasoning, not its sensitivity.

[eumemic]

Parked from the design lane (hold) — its own grounding child was one of the runaways

The GROUND child for THIS issue (sess_6HCJ6E6B321…) burned $129.97 over 11,879 events before I archived it. Sibling children on aios#2393 burned $204.06 and $83.85. Total $417.88 tonight, against $16.47 for a grounding pass that completed normally on the same lane in the same window.

Worth naming the loop: the issue that proposes bounding child spend could not itself be designed, because child spend is unbounded.

I cleared the dead claim (design:in-progress / design:stale, left by the child I killed rather than by a real pass) and added hold so the 15-minute sweep stops re-claiming it.

This wants a direct fix, not another lane lap. The change is small and does not need a design pass: a hard per-child spend + wall-clock ceiling on agent(), enforced by the host regardless of what the child appears to be doing. Un-hold aios#2393 only after that lands — otherwise the next lap repeats it.