fix(state): subagent spend not rolled up to parent until SubagentStop — parent fail-fast can be exceeded mid-flight (paper §5 invariant #2)

[manzil-infinity180]

Problem

Paper §5 invariant #2 ("Accumulation"): "Sub-agent spend counts toward parent totals."

This only fires AT SubagentStop. While a child agent is running concurrently with its parent, the parent's PostToolUse fail-fast check sees only its own cumulative spend.

Concrete: maxSpendUSD=$10, parent at $9, child spending $5 concurrently — parent's next PostToolUse passes ($9 ≤ $10), child stops, merge brings parent total to $14. Policy ceiling exceeded.

Code reality

mergeChildIntoParent (internal/hooks/handler.go:1645) has exactly one callsite — handler.go:1110 inside handleSubagentStop. No push-up from child PostToolUse to parent during runtime.

Options

A — push-rollup (continuous accumulation): child PostToolUse acquires parent lock, loads parent, merges incremental delta, saves parent. Cost: extra lock contention per child tool call. Cleanest realization of paper invariant #2.

B — pull-rollup (parent-side aggregation): parent PostToolUse enumerates all child sessions whose ParentSessionID == parent.SessionID, sums their metrics on the fly. Cheaper when children are rare; correctness depends on enumeration being complete.

C — qualify paper: acknowledge accumulation is "at child completion" not continuous. Document, drop the implied real-time guarantee.

Recommend A or B for a real "fail-fast" guarantee. Pick one before implementation.

Acceptance

• Concurrent parent + child cannot exceed parent.maxSpendUSD by more than one child-tool-call delta (A or B), OR paper §5 invariant #2 updated to "at-completion" (C)
• Test: spawn child, child spends $X via PostToolUse, parent's next PostToolUse gate observes the child spend
• Documented behaviour matches code

References

• Paper §5 invariant #2 ("Accumulation")
• internal/hooks/handler.go:1110 (single mergeChildIntoParent callsite, SubagentStop only)

[Keesan12]

This is the exact place where parent/child spend needs to be live, not only merged at SubagentStop. A fail-fast parent check that cannot see in-flight child spend is not really enforcing the parent invariant.

One approach is to reserve or stream child spend against the parent budget as it accrues. The receipt can then show parent_observed_spend, child_inflight_spend, reserved_spend, and decision.

A good regression test would keep the child running while the parent attempts another tool call. The parent should block as soon as parent + child/reserved spend crosses the limit, before the child stop event arrives.

[Keesan12]

Agree with the invariant shape here. Parent spend needs to roll up before the next admission decision, not only at SubagentStop, otherwise the parent can drift past its intended fail-fast boundary mid-flight. A pre-admission readback of cumulative spend would make this easier to enforce.

[Keesan12]

The parent/child budget boundary needs to be live before the next admission decision, not only at SubagentStop. Otherwise a parent can still drift past its ceiling while the child is running.

A practical way to make this auditable is to stream or reserve child spend against the parent as it accrues, then have the next parent tool gate read that state back before admitting more work.

[Keesan12]

The part that keeps paying off is a receipt for the next attempt, not just a log of the last one. If the loop can say admitted or denied, with budget and halt reason attached, the operator stops guessing.