feat(coordination): publish the harness floor where a root authors budgets

[drewstone]

Closes the affordance half of the below-floor story (#685 refuses, #693 made it fire on the bridge path; this makes the floor VISIBLE before a root authors).

Why

Across a clean n=8 live sample, 5 of 6 root-authored child budgets were below the measured pi floor (authored 4,000/4,000/6,000/6,000/12,000 vs a 31,211 floor; one root chose 32,000 correctly). The roots were not careless — nothing anywhere told them the floor. The guard defends; this cures.

What

Both telling surfaces in spawn_agent, generated from WORKER_TOKEN_FLOOR so a future measured harness appears automatically — never hardcoded prose:

1. Budget schema description: names the refusal reason and lists every measured floor (pi=31211); unmeasured harnesses admitted, as before.
2. below-runtime-floor refusal hint, matching the existing usd-unbudgeted pattern: names the declared harness's floor and says to raise maxTokens to at least it — "retrying with a smaller budget will fail identically." No declared harness → hint lists the full census.

Verification

• Implemented and independently adversarially verified (hardcode grep, pattern match vs usd-unbudgeted, kill test on both new tests, gates re-run by the verifier)
• pnpm run typecheck exit 0 · vitest tests/mcp tests/kernel — 78 files, 923 passed / 1 skipped
• docs:api — no export changes

[tangletools]

✅ Auto-approved drewstone PR — e34c56d1

This PR was opened by the trusted drewstone account.
The full PR reviewer audit still runs separately and will publish findings if it detects issues.

_{tangletools · auto-approval · reason: drewstone_author · 2026-08-01T21:08:27Z}

[tangletools]

🟢 Value Audit — sound

Verdict	sound
Concerns	0 (none)
Heuristic	0.0s
Duplication	0.0s
Interrogation	212.4s (2 bridge agents)
Total	212.4s

💰 Value — sound

Publishes the measured token floors to the MCP spawn_agent tool (schema description + refusal hint) so roots stop authoring unsatisfiable child budgets — generated from the existing census, matching the established usd-unbudgeted hint pattern.

• What it does: Adds two presentation surfaces in src/mcp/tools/coordination.ts, both generated from WORKER_TOKEN_FLOOR (src/runtime/supervise/budget-floor.ts:27): (1) appends a sentence to the budget input-schema description (coordination.ts:1303) listing every measured floor and naming the below-runtime-floor refusal; (2) adds a hint field to the below-runtime-floor refusal response (coordination.ts:143
• Goals it achieves: Close the feedback loop the guard opened: across the cited n=8 live sample, 5 of 6 root-authored child budgets were below the pi=31,211 floor because nothing told roots the floor existed. After merge, a root sees every measured floor in the tool schema before it authors, and when the guard fires anyway it gets an actionable hint pointing at the exact number to raise to — instead of a bare `below-r
• Assessment: Clean, in-grain, proportional. It mirrors the existing usd-unbudgeted hint at coordination.ts:1424-1432 verbatim in shape (conditional spread on res.reason, same return envelope, same purpose comment). It generates from the census rather than transcribing prose, so a newly measured harness appears automatically — the test at coordination.test.ts:533-535 explicitly loops over WORKER_TOKEN_FLOOR
• Better / existing approach: none — this is the right approach. Searched for an existing floor-formatting/displayer helper to reuse (grep for WORKER_TOKEN_FLOOR, workerTokenFloor, measuredFloors, belowFloorHint across src/): workerTokenFloor returns a single number and there is no pre-existing 'describe all floors' helper, so the formatting here is new but not duplicative. The only sibling hint pattern is usd-unbudgeted at co
• Model: opencode/zai-coding-plan/glm-5.2
• Bridge attempts: 2
• Bridge warning: opencode/kimi-for-coding/k2p7: opencode: opencode error

🎯 Usefulness — sound

Publishes the measured token floors into spawn_agent's schema description and adds an actionable 'raise, don't shrink' hint on below-runtime-floor refusals, mirroring the established usd-unbudgeted pattern and landing on a live, already-firing path.

• Integration: Reachable and wired correctly. spawn_agent is published by createCoordinationTools, which is consumed by coordination-mcp.ts:138, coordination-driver.ts:341, and mcp/index.ts:163 — the live driver loop. The below-runtime-floor reason this hint keys on is produced in production at scope.ts:577 (the guard landed in PR #693), so the hint fires on real refusals, not just test mocks. WORKER_TOKEN_FLOOR
• Fit with existing patterns: Exactly in the grain of the codebase. The new hint is a structural clone of the usd-unbudgeted hint at coordination.ts:1424-1432 — same conditional-spread shape, same stated purpose (a refusal no smaller retry can clear, so say so). The schema description is GENERATED from WORKER_TOKEN_FLOOR via measuredFloorSentence rather than transcribed, matching how spawnProfileArg() is built from the canonic
• Real-world viability: Holds on the realistic paths. measuredFloorSentence degrades safely to '' when no floor is measured (every entry null), so the description is unchanged for unmeasured harnesses — the admitted-as-before behavior is preserved. belowFloorHint covers both the named-harness case (direct floor) and the no-harness case (full census list, still contains the correct floor since only pi is measured today).
• Model: opencode/zai-coding-plan/glm-5.2
• Bridge attempts: 1

No concerns — sound change, no better or existing approach found. ✅

---

What this audit checks

It judges the change on its merits — not whether it was tasked out in an issue. Unticketed, fast-moving work is fine; the question is whether the change is good and whether a better or existing approach should be used instead.

Pass	What it asks
Heuristic	Vague title? Whitespace-only or cruft-bearing diff? (content signals only)
Duplication	Do added function/class names already exist elsewhere in the repo?
Value Audit	What does it do? What goal does it achieve? Is it good? Better architecture or already-exists?
Usefulness Audit	Does it integrate and fit? Will it hold up in real use and actually get used?

Findings are concerns, not blocks — the human reviewer decides what to do with them.

_{value-audit · 20260801T211218Z}