A budget is a lease carved from its parent, and one module proves the leases fit

The ask. Decide (the maintainer, before the plan is written): adopt the lease as Switchboard's one budget primitive, one module as the owner of every wall-clock number and its derivation, and one fit asserted at verify, at config load and at the fork; build the module (unit one) and the wind-down inside the lease (unit two) from this record; take the grant and renewal (unit three) as the direction, its open terms resolved in its own plan before its default turns on. Reader: an engineer who knows the run loop and the ship pipeline and has not read the budget audit of 2026-09-17 (recorded on #1477). Frame assumed from the maintainer's "pull all our time budgets in the whole system and make sure that they are cohesive" and "these decisions and designs must be principled" on 2026-09-17.

Accepted 2026-09-17 for units one and two, executed from the plan; unit three is held as direction and is not accepted by this record. The wind-down fix and the checks-by-cost rule the record names as in flight merged before acceptance; unit two builds on them.

Success criteria: (1) every wall-clock number in src/ that bounds a run, a round, a wait or a leaf call is a row of one module or derived from it, and verify fails when a number cannot hold what is carved from it at any round of a pipeline; (2) a pipeline that cannot hold its own loop is refused wherever its minutes are set, config load or a clip at the fork, naming the sum; (3) a run's lease covers everything it does, so its total time never exceeds the lease plus its provisioning, its work is pushed and the head recorded, and no model call outlives the credential; (4) a unit that needs more than one lease continues under the same request without a person re-issuing, while its grant holds and each lease recorded progress; (5) an ask, a floor or an allowance changes in one place and the check says what else must move.

TL;DR

Twelve of the 59 ship coding children since 2026-09-16 ended at a 28- or 39-minute budget with their work finished and unpushed, because production set the ship pipeline to 40 minutes while the coding preset asks 45 and nothing compared the two; one of 282 standalone coding runs hit its 45 in the same window. The bet is that a budget is never an absolute number but a lease, a slice of the parent's remaining time minus the floors of every round that must still follow, carved by one module and covering everything the run does, with one fit asserted at verify, at config load and at the fork. It costs one module, the relocation of about twenty constants and three rewritten carve sites in unit one, then in unit two a wind-down the model proxy enforces and a recorded pushed head; unit three, renewal under a grant of cost and approvals, is a direction with three open terms. Decided: the lease, the floors, the module, the three-site fit, the lease covering the write-up and post-steps, and that a multi-day problem is bounded by the grant while each lease is sized by the infrastructure that must outlive it. If we do nothing, every new pipeline or preset adds a number that agrees with the others by luck, and the next disagreement is found in the ledger after a week of lost work.

Today at 6fd2003e5431

You would expect one clock per run. A coding run under ship has six, set in six files; the appendix lists them with proofs, and the design depends on these five facts.

Fact	Proof
The registry declares an ask per preset (coding 45, review 25, research 8, general 5, explore 120, conductor 120, ship 120) and derives one number from it, the turn cap ask × 6 (#1020), with ship's structural 1 exempt.	src/agents/registry.ts:50-63, 613-735; src/agents/registry.test.ts:132-138
Ship carves a child's minutes as max(2, min(ask, floor(remainder − reserve))), reserves 11 / 8 / 0 for a coding, fix and review round, and dispatches any round while 3 minutes remain; the merge wait is 60 minutes of its own. The validator refuses ship.maxMinutes under 14, never against the coding ask; a boundary or budget: clips ship after load with no check.	src/core/ship/coordinator.ts:52-75, 678, 727-745, 880; src/config/validate.ts:489-493; src/config/profile.ts:212-221
The lease starts after provisioning, 0.3 to 2.6 minutes after the row's startedAt in the 14 hits on record. Past the deadline: a write-up of 0.3 to 3.4 minutes, a description turn of up to 5, and a bearer minted before the lease for the budget plus 5, so a slow description turn has no credential.	src/core/dispatcher.ts:581, 864, 957, 1151; src/core/harness/pi/harness.ts:99, 436-439, 994; src/core/dispatch/runLoop.ts:1115-1132; src/core/dispatch/provision.ts:856
Nothing clips pi's shell; the native clip left with the native tool table. The model proxy is the one point a run cannot talk past: it refuses past the turn guard with a typed note and already reads every request body.	execution.md item 12; src/channels/modelProxy.ts:515-531
The row records a typed handoff and, for pushes, only the branch of a pr_opened event; a first push with no description publishes nothing, and no sha of a coding run's push is recorded. Every run starts from a clean tree.	src/core/runRecord.ts:147, 219-226, 243-246; src/core/codingPrPostStep.ts:672-690; resident-repos items 16a, 17

The shape

A budget is a lease: a deadline a run holds, carved by its parent from the parent's own remaining time. A preset keeps an ask, the lease it wants when nothing above is tighter, and a floor, the least lease in which it does useful work. A parent that runs a loop of rounds holds back, before each round, the reserve for that round: the floor plus provisioning of every round that must still follow in the longest loop the config allows, plus the merge wait's floor. A round's lease is the remainder minus its reserve, capped at the ask, refused under the floor. A lease covers everything the run does: the loop, the write-up and the post-steps all end inside it, each with a named allowance. One module, src/core/budgets.ts, owns the asks, floors and allowances and the one carve function; every other file imports a lease and asks what is left. One fit, that a pipeline's minutes hold its first child at its ask and every later round at its floor, is asserted three times over one table: at verify over the registry, at config load over the deployment, at the fork over a clipped request. A pipeline's lease bounds one segment, one pass through its loop; above it sits the grant, what the person authorized for the whole problem as cost and approvals, which decides whether the runner opens another segment when one ends with progress.

The known shape is a scheduler's time slice under a process's quota, and the one difference is that our slice ends only after the run has recorded a pushed head, because the container, the credential and the worktree do not survive to the next slice.

One trace: a three-hour unit under a two-hour pipeline

The case most likely to be wrong is renewal, so the trace runs a unit that cannot fit one segment, in a channel whose grant allows six renewals. Minutes are whole; the carve is min(ask, remainder − reserve), refused under the floor. Asks and floors: coding 45 and 10, review 25 and 5, merge wait 60 and 10; allowances: provision 3, write-up 3, post-step 5; the pipeline allows 3 review rounds. The reserves this gives: before the coding round 3 × (5 + 3) + 2 × (10 + 3) + 10 = 60; before the first review 52; before the first fix 39; before the second review 31.

1. A person posts fix issue #N. The router picks ship; the request carries the channel's grant: the org's cost cap for a ship, six renewals, merge: person.
2. The runner opens segment one with a 120-minute lease. Provisioning takes 2; it carves the coding round min(45, 118 − 60) = 45, and the card reads budget 45 min (carved from ship's 120; holds 60 for three reviews, two fixes and the merge).
3. Inside its 45 the child's loop ends at 37: the proxy refuses any model call after deadline − (3 + 5) that still carries tools, and the harness kills the shell command in flight. At the wind-down note, three minutes before that, the child had committed and pushed a1b2c3d, and its row records the ref and sha; the write-up and the description turn run in the held-back 8. The unit is not done: two follow-ups remain in the handoff.
4. The runner reads the row: a recorded sha newer than the lease's start is progress. The loop has no second coding round, so the segment ends continued, and the runner asks the grant: five renewals remain and spend is under the cap. It opens segment two with a fresh 120-minute lease, card renewal 1 of 6, continues a1b2c3d.
5. Segment two provisions in 2 and carves its coding round, 45 again; the continuation's request is the previous handoff, it starts from a1b2c3d in a clean tree, pushes d4e5f6a at 30 and opens the pull request; the loop ends at 37 and the description turn submits. Remainder 73.
6. The first review is min(25, 73 − 52) = 21; it provisions in 2 and finds one minor in 4. Remainder 67.
7. The fix child is min(45, 67 − 39) = 28, above coding's floor; it provisions in 2 and pushes at 9. Remainder 56.
8. The second review is min(25, 56 − 31) = 25; it provisions in 2 and approves in 3. Remainder 51. The merge is the person's, so the unit ends merge_ready.
9. Variant at step 4: the child recorded no sha newer than its lease start and its handoff is unchanged. The runner does not renew; its card says no progress in the last lease; grant holds 5 renewals; reply continue to spend one.
10. Variant at step 7: the remainder is 46, so the fix child's carve is 46 − 39 = 7, under its floor. The runner ends review pending naming the finding, and the re-issue starts at the fix round; today it dispatches a 2-minute child.
11. Variant at step 2: a channel boundary clips ship to 40. The fork applies the fit, 40 < 3 + 45 + 60 = 108, and refuses with that sum on the card instead of carving a child.

The property the trace proves: no run holds a deadline it did not derive from the parent's remainder, no round is admitted under its floor, a lease ends with its head recorded, and the problem ends only by the grant.

The difficulty map

1. Progress, and who decides renewal (Renewal). Most likely to be wrong: a wrong progress test loops on a stuck unit or stops a slow one, and the grant's transport and cost cap are open.
2. The wind-down inside the lease (The wind-down). The proxy must refuse the right calls and the harness must kill the shell; a mistake here loses a run's answer silently. Most work.
3. The floors and allowances (Fit). Too low re-admits the 3-minute review; too high ends segments review pending with time left. Review's floor and two allowances are measured; the rest are guesses.
4. Three fit sites, one table (Fit). The fork is the site the incident's shape can still reach.

Fit: the module and the check

The constraint is that the registry's numbers were right and production's were not, and nothing compared them: ship 120 holds coding 45 plus 11 with 64 to spare, the deployment knob made it 40, the validator's floor of 14 accepted it, and every layer below treated the resulting 28 as the truth. A number is wrong only relative to another number, so the check must hold both, and the incident's rule alone, ship.maxMinutes ≥ ask(coding) + reserve, needs the coding ask from the registry and the reserve from the coordinator, which is the module in embryo, and says nothing about the rounds after the first.

src/core/budgets.ts declares three tables and one function. Asks per preset, moved from the registry entries; the registry keeps maxMinutes for its 31 readers, filled from the module. Floors per round kind: review 5 (the ledger's 90th percentile of 181 completed reviews is 5.1 minutes, the median 1.8, the longest 8.3), coding 10 and merge wait 10 (guesses, read against the ledger before unit two). Allowances, in minutes: provision 3 (the 0.3 to 2.6 measured), writeUp 3 (13 of 14 write-ups fit), postStep 5 for a coding run's description turn and 3 for a review's verdict turn (today's caps, unmeasured, measured before unit two from the run.description_turn spans), execCall 0.5, bearerGrace 1. The reserve is not a table but a derivation, reserve(round) = Σ (floor + provision) over the rounds that must follow it in the longest loop the config allows + floor(merge), so every reserve moves with maxRounds and the floors and can never describe a different loop than the fit does. The merge wait becomes a round with an ask of 60 and a floor of 10, carved like any other; the 3-minute dispatch gate, the wait margin and the wait chunks become module rows. carve(remainingMs, round, loop) returns { minutes, boundedBy: "ask" | "parent", holds } or refused: under floor and is the only place a round's minutes are computed: the ship coordinator, the conductor's spawn and the fork call it.

The fit is maxMinutes ≥ provision + ask(coding) + reserve(coding), the first child at its ask and every later round at its floor. At the shipped default of 3 rounds: 3 + 45 + 60 = 108 ≤ 120 holds; 4 rounds is 129 and fails naming the sum. The fit proves a pipeline can finish its loop, not that its rounds are generous; how often a segment ends review pending is read from the ledger and tunes the floors, not the rule, and today's rate is measured before unit one as the baseline the floors must not raise. It is asserted at three sites over the one table: src/core/budgets.check.test.ts at verify, over the registry's ship and conductor; validateShip at config load, over the deployment's knob, replacing the floor of 14; and the fork, over a request whose minutes a boundary or a budget: clipped, refusing with the sum on the card. The check also asserts that every floor is at most its ask, that writeUp + postStep + execCall ≤ every ask, and that maxTurns = runawayTurnCap(ask) for every loop-running preset, ship exempt as today. That no minutes literal lives outside the module is a new predicate for the scanner behind clock:check, which today counts wall-clock reads, not durations; it ratchets the same way, over an allowlist that starts at today's files and only shrinks.

Invariants: a round's minutes are a literal nowhere but the module; every lease on a card names what it was carved from and what the parent held back; the three fit sites read one table. Failure modes: a floor or allowance changes and the fit breaks, verify names the sum and the ask; a deployment or a clipped request cannot hold its loop, it is refused with the sum; a new round kind has no floor row, the check fails on the missing declaration.

Why not one validator rule for the incident and stop? It would have caught the 40 and nothing else: not the 3-minute review, not a description turn outliving the bearer, not the clip at the fork, not the next pipeline. Its inputs are the module's tables; writing the rule is writing the module.

The wind-down: the lease covers everything the run does

The constraint is the 14 budget hits on record and what the code says about them. The lease starts after provisioning; the write-up took up to 3.4 minutes past the deadline; a description turn of up to 5 follows it; the bearer, minted before the lease began, dies about 5 past the deadline. One run ended the model call failed: This operation was aborted with nothing pushed (#1477). And nothing bounds pi's shell: a npm run verify issued at minute 43 runs to its own end. Each constant is defensible alone; together, the promise a child makes its parent, "done by 45", is off by the provisioning before it and by up to 8 minutes after it, and a slow description turn has no credential.

The design makes the lease the whole promise. The harness holds back writeUp + postStep from the deadline, so a coding run's loop ends at deadline − 8. The enforcement is the model proxy, the one point a run cannot talk past and the one that already reads every request body: after the loop's end it admits only a request that carries no tools, the write-up turn and the post-step turns, and refuses the rest with a time_budget_exhausted note the way it refuses past the turn guard today. At the loop's end the harness aborts pi and kills the shell command in flight; whether pi's abort ends its own tool's process group is the guess unit two verifies first, and the killed command's leftovers are discarded by the clean-tree rule, since the push happened at the wind-down note three minutes earlier. The bearer's grace past the deadline is one minute, for the last call's tail. The ship child's contract gains one step at the wind-down note: commit and push what compiles, say what does not, then answer; and the harness records the pushed head on the row as a typed event with ref and sha, the fact the row lacks today and renewal reads.

Invariants: a run's total time from the lease's start never exceeds the lease plus the grace, and the row records the lease's start; no call the proxy admits after the loop's end carries tools; the bearer is valid at every call the harness issues. Failure modes: the write-up call is slower than its allowance, the run ends with the wind-down's sentence and the recorded head, and the card says the write-up was cut; the push fails, the answer says so and the row records no head, which renewal reads as no progress.

Why not a longer margin? A margin is the amount by which the promise is false; a 10-minute margin makes every reserve wrong by 10.

Renewal: the grant decides, the lease continues

The constraint is that the problems we want to run last longer than anything a container, a credential or a bot generation is promised to survive: the resident's step ceiling is 30 minutes, its token lives 60 and is refreshed 25 before expiry, the drain window is 15, and a release replaces containers on its own schedule. A lease sized by the problem is a lease the infrastructure will break, so the lease is sized by the infrastructure and the problem is bounded by something else.

A lease is sized by the infrastructure that must outlive it; a grant is sized by the person. The grant is what the request authorizes for the whole problem: a cost cap in dollars (the orchestration plan's cost-budget row, metered per call at the proxy, summed at finish, enforcement not built), a count of renewals, and the approval points that exist (merge: person, record 0044's confirmation). When a segment ends with its unit unfinished, the runner decides whether to open another. It renews when three things hold: the row shows progress, the grant has a renewal left and the session's summed spend is under its cap, and the pipeline's ask still passes the fit. Otherwise it stops and says which failed, and a person's reply spends a renewal by hand.

Progress is a fact the row records after unit two and the runner reads without a model: a pushed sha that differs from the head the lease started at, or a handoff whose follow-ups shrank or whose deviations grew. The guess is that this is too strict for investigation-shaped units, which push nothing for an hour while making progress; the first twenty renewals in production decide it: if more than a quarter of the stops were units a person then continued unchanged, a third clause is added, a handoff naming new evidence.

A continuation is a run, not a resume: it starts in the same thread from the recorded sha in a clean tree, as every run does, and its request is the previous run's handoff, not the person's message. The ledger links the segments as one session, the key that already ties a thread's runs on one agent, and the renewal decision is written as a row keyed by session and segment index, so a runner reclaimed by the ledger between a segment's end and its renewal finds the row and does not renew twice. Renewal never revokes: a child's lease outlives its parent's end, as #1371 made the pipeline behave, and a re-issue while that child lives is refused by the session row that names it. A person sees one thread, one card per lease naming its segment and the sha it continued from, and one stop card when the grant or the progress test ends it.

Invariants: segments under one request never exceed the grant's renewals; spend under one request never exceeds the cap plus one segment, since spend is summed at each run's end; a renewal names the sha it continues from; two segments of one session never run at once. Failure modes: an empty commit fools the progress test, the renewals and the cap bound the damage; the handoff is malformed, the runner reads no progress and stops with the reason.

Why not let the model ask for more time? A run cannot verify its own progress, and asking is what a stuck loop does best. Renewal is the parent's decision from a recorded sha the run cannot fake cheaply.

Why not X

Why not just raise the numbers and move on? The registry's numbers were already right; production overrode one and the system had no way to say the override broke another. Raising is the stopgap (infrastructure #109); the module is what makes the next override visible.

Why not have the child commit and push continuously, so a budget hit is never lossy? It should, and the contract says so; it does not remove the wind-down. Between two pushes there is always unpushed state, the description turn still needs a credential, and continuous pushing tells the parent nothing about when to stop; the recorded head at the wind-down is what renewal reads.

Why not one long clock and let the run manage itself? One clock cannot hold a review after a coding child that used all of it, which is the whole reason the reserves exist; and the clock and the turn guard are what stop a stuck loop's spend today.

Why not put every timeout in config? Config is where the 40 came from. Numbers a person tunes belong in config behind a validator that knows the fit; relations between numbers belong in code, derived.

Boundaries

The cost meter's enforcement and the budget:$N directive stay the orchestration plan's row; this record makes the grant what that row implements. Approval points are record 0044's. The ledger's resume, the ship re-issue at the review round, the clean-tree rule and the session key are used as they are. Not in scope: a lease for a person's reply, and rate limits. Compatibility: maxMinutes stays on AgentDef, filled from the module; budget: keeps its meaning and gains the fork's fit; the one deployment under the fit moved to 120 on 2026-09-17. Reversibility: unit one is a relocation and reverts alone; unit two sits behind the harness's wind-down path; unit three is behind the renewal count, and zero renewals is today's behavior.

Rollout

Three units, each its own pull request off this record's plan. One: the module with its tables, carve and the derived reserve, the fit at its three sites, the registry filled from the module, the merge wait carved, the cards naming the carve, the duration-literal ratchet; no behavior change except a refused config or a refused clip; the review pending baseline read first. Two: the proxy's tool-less admission after the loop's end, the shell kill, the post-steps inside the lease, the pushed-head event on the row, the ship contract's push at the wind-down (absorbing #1477's fix, in flight); floors and the post-step allowance read from the ledger first. Three: the grant on the request with zero renewals by default, the renewal row and decision, the continuation card; renewals on for one channel, twenty segments read, then the default raised.

Open questions

Question	Owner	Resolves it	Needed before
Whether pi's abort ends its tool's process group, or the harness must kill it	the record owner	one live run with a sleep in flight at the loop's end, in unit two's first pull request	unit two
Coding's and the merge wait's floors, and the post-step allowance	the record owner	the ledger's duration distributions of fix children, runner merge waits and description turns	unit two
What counts as progress beyond a new sha or a moved handoff	the maintainer	the first twenty renewals, read from the ledger	unit three's default above zero
How a request expresses a grant, and the default cost cap	the maintainer	record 0044's confirmation surface and the orchestration plan's cost row	unit three

Validation criteria

Proof references use the repository's shape, file::describe::it; every row is [gap] until its unit lands and binds it in the covering spec.

1. verify fails when an ask, a floor, an allowance or the default maxRounds changes so the fit no longer holds, naming the sum and the ask. [gap] plan unit one: src/core/budgets.check.test.ts::the fit::the longest loop the config allows fits inside the pipeline's ask.
2. deploy config refuses a pipeline under the fit, and the fork refuses a clipped ship request under it, both naming the sum. [gap] plan unit two: src/config.test.ts::ship caps block (agent:ship pipeline)::a pipeline that cannot hold its loop is refused with the sum; src/core/dispatch/ship.test.ts::runShipBranch…::a boundary that clips ship under its loop refuses at the fork with the sum.
3. No duration literal outside the module: a second ratchet lists them and only shrinks. [gap] plan unit three: src/core/trace/durationAllowlist.test.ts::the duration ratchet::a minutes literal outside budgets.ts is listed or fails by name.
4. A round whose carve falls under its floor is not dispatched and the unit ends review pending naming the round. [gap] plan unit two: src/core/ship/coordinator.test.ts::…::a round under its floor ends the unit review pending.
5. The proxy refuses a call that carries tools after the loop's end and admits one that does not; a run's time from the lease's start never exceeds the lease plus the grace. [gap] plan units five and six: src/channels/modelProxy.test.ts::the loop's end::a call with tools past the loop's end is 403 time_budget_exhausted; conformance row conversation: the lease covers the write-up and the post-step.
6. A ship child pushes at the wind-down and its row records ref and sha. [gap] plan unit eight: src/core/codingPrPostStep.test.ts::…::a push with no description publishes pushed_head with ref and sha; live receipt human-gated, recorded on the tracker issue for the wind-down abort.
7. A shell command in flight at the loop's end is ended and the harness process is not. [gap] plan unit seven: conformance row survival: a command in flight at the loop's end is ended and the write-up stands.
8. The floors, the post-step allowance and the review pending baseline are read from the ledger before unit two ships. [gap] plan unit four: recorded on the tracker issue with sample sizes; human-gated.

Appendix: the survey at 6fd2003e5431

Clock	Value	Proof
Preset asks; turn guard	coding 45, review 25, research 8, general 5, explore 120, conductor 120, ship 120; ask × 6, ship exempt	src/agents/registry.ts:50-63, 613-735; src/agents/registry.test.ts:132-138
Ship reserves; carve; gate; defaults	round 3, loop 11, fix 8; max(2, min(ask, floor(headroom / min))); dispatched while 3 min remain; 3 rounds, 120 min	src/core/ship/coordinator.ts:52-75, 727-745, 880; src/core/shipPipeline.ts:74-76
Ship waits	child wait bounded by the carved budget plus a 5-minute margin; merge wait 60 its own, chunk 5	src/core/ship/coordinator.ts:665-685, 1255
Child transport; conductor child; resolution	budget: directive; parent's remaining ms as a boundary; a directive narrows, never widens	src/core/dispatch/spawn.ts:163; src/core/dispatch/resolve.ts:164-167; src/config/profile.ts:212-221
Validator floor	ship.maxMinutes ≥ 14	src/config/validate.ts:489-493
Run order; lease start	attach, then bearer mint, then the loop; startedAt = receivedAt; deadline set from the resumed remaining or the ask; abort 3 min into the write-up	src/core/dispatcher.ts:581, 864, 957, 1151; src/core/harness/pi/harness.ts:99, 436-439, 994
Bearer	budget + 5 min from the mint	src/core/dispatch/provision.ts:856; src/core/modelProxy/runBearers.ts:31
Post-steps	description turn min(ask, 5), verdict turn min(ask, 3), after the loop	src/core/dispatch/runLoop.ts:1115-1132; src/core/descriptionTurn.ts:41, 165; src/core/verdictTurn.ts:35, 113
Shell; proxy	pi's own tool, unclipped; bashBudgetWithinRun under attach_file only, its 60-second reserve reused by await_runs; the proxy refuses past the turn guard with a typed note and pins every request body	execution.md item 12; src/tools/attach.ts:136; src/core/dispatch/awaitChildren.ts:140; src/channels/modelProxy.ts:515-531
Resident	step ceiling 30 min; token 60 min refreshed 25 before expiry, 45 as the backstop; worktree released at the run's end, clean tree per run	src/execution/residentInstanceId.ts:182; src/execution/residentCredentials.ts:31, 40; resident-repos items 16a, 17
Drain window	15 min per bot generation	src/core/drain.ts:20
Row facts	typed handoff; pushed branches only from pr_opened, published on a submitted description or an existing pull request; a coding run's head is a branch name, no sha; a review run records its reviewed head	src/core/runRecord.ts:147, 152-154, 219-226, 243-246; src/core/codingPrPostStep.ts:672-690
Wall-clock ratchet	clock:check counts wall-clock reads over an allowlist	package.json:53; src/core/trace/clockScan.mjs:1-3; src/core/trace/clockAllowlist.json
Production pipeline	ship.maxMinutes 40 until 2026-09-17, then 120	the deployment's config document; infrastructure #109
Ledger audit	341 finished coding runs 2026-08-30 to 2026-09-17; 282 standalone, p50 3.4, p95 29.7, 1 hit at 45; 59 children, 12 hits at 39 or 28, work unpushed; 14 hits by 04:10Z, provisioning 0.3 to 2.6, write-up 0.3 to 3.4; 181 completed reviews p10 1.1, p50 1.8, p90 5.1, max 8.3	recorded on #1477

Sources

#1020, #1365, #1371, #1477, infrastructure #109; records 0026, 0029, 0032, 0044; the orchestration plan's cost-budget row; the ledger audit recorded on #1477.

Amended 2026-09-17 — unit three accepted as the renewable lease; a rewrite at the proxy replaces the refusal; a segment ends with its head recorded, never with its work lost

Re-evaluation, as an amendment after acceptance asks. This record was accepted for units one and two on the fourteen budget hits and the arithmetic that explained them: one module owns every wall clock, a run's lease is the whole promise it makes its parent, and one fit is asserted at verify, at config load and at the fork. Record unit three, renewal, was held as direction because two things were open: the progress test and the grant's transport. The plan that executes this record numbers its work in eight units; plan units one, two, four and five (the module, the carve, the measurements, the loop's end inside the lease) have landed and been read live — a 12-minute lease ran its loop for the 4 minutes the lease afforded and closed with 4.7 to spare, and a deployment whose loop could not fit its clock was refused before anything shipped — and the first ship run on the new clocks exposed two defects in the ground renewal stands on. This amendment accepts record unit three with the shape the Renewal section already gives it, changes one mechanism the record assumed, and adds what the incident taught. Each change is checked against the acceptance's reasoning in point 4; none regresses it.

1. Record unit three is accepted: a lease is a renewable slot, and a segment's end is a checkpoint, never a loss. The Renewal section stands as written: the grant sized by the person, progress read off the row without a model, a continuation as a run in the same thread that starts from the recorded sha in a clean tree with the previous handoff as its request, the renewal row keyed by session and segment. One word is sharpened: the write-up is a checkpoint — what is done, what is next, what is unproven — written for the parent that decides the renewal and for the person who reads the thread. The segment then ends as every run ends: its tree is released, its transcript is on the ledger, its recorded head is on the row, and the session key links it to the segment that continues it. Nothing pauses on infrastructure: the shape's premise that the container, the credential and the worktree do not survive to the next slice is exactly why the continuation starts from the recorded head, and this amendment keeps it. A checkpoint that does not arrive inside its allowance loses nothing the renewal needs, because the renewal reads two typed facts on the row and never the checkpoint's text: the recorded head, and the handoff the run submitted through its tool during the loop (the typed deviations, follow-ups and unproven criteria that also become the continuation's request). A cut checkpoint leaves the card saying so and the person reading the last tool results; a run that submitted no handoff and pushed no newer head is the trace's variant 9, and is not renewed. The failure mode the record named is now the stated default, not an exception. The renewal's invariants do not move: segments never exceed the grant's renewals, spend never exceeds the cap plus one segment, two segments of one session never run at once.

2. The checkpoint's mechanism is a rewrite at the proxy, not a refusal. The wind-down section assumed the proxy would refuse any call after the loop's end that still carried tool definitions, admitting only a tool-less write-up. That assumption is false for pi: its tool table is per session and its control protocol has no per-turn tool table, so the write-up request carries the loop's tools, and the refusal would refuse the checkpoint itself. Both providers accept tool_choice: none — the model is shown its tools and may call none — and Anthropic no longer requires the tool list to name every tool an earlier tool_use block used. So after the harness marks the loop's end on the run's entry in the bearer store, the proxy rewrites rather than refuses: the checkpoint turn goes upstream with tool_choice: none, a guaranteed text turn on a provider that honours the flag; a post-step turn, which the harness marks with the tools it may use, goes upstream with the tool list trimmed to those (OpenAI's allowed_tools where the dialect has it, so its cache holds) and the choice left to the model. The harness's gate (item 7 of the pi specification) stays as the belt for a provider that ignores the flag: it answers each tool call the model has already emitted, refusing every one during the wind-down with the reason, so it acts after the model's turn and can never block the checkpoint request itself; a model that keeps trying then ends by the finale bound, no worse than today. Why the proxy and not the harness: neither pi nor OpenCode lets the bot change a turn's tool table without forking it, the proxy is the one point both harnesses pass through, and dropping the tool definitions from the request would invalidate the cached tool and system prefix too, where a tool_choice change invalidates only the conversation's cached blocks. That is the cost: each lease end pays one input turn at full price for the conversation, with the tool definitions and the system prompt still cached; the model.turn span's tools, toolChoice, inputTokens and cacheReadTokens attrs make that cost a number read off the run page, per lease end, before the default renewal count is raised. The time_budget_exhausted refusal of a tool-carrying request is withdrawn from the design; the run_note of that kind stays what the harness publishes when it steers the write-up at the loop's end. Validation criterion 5's first clause reads accordingly: after the loop's end the checkpoint request goes upstream with tool_choice: none and a post-step request with its tool list trimmed, and its proof is the proxy's tests for that rewrite. The eighth key technical decision of the plan changes accordingly, and its unit six becomes this rewrite.

3. What the first ship run on the new clocks taught. A lease is only as good as the tree the run works in while it runs. The resident's reclaim pass evicted a live run's worktree because the run's unpushed branch read as gone and its thinking model left no command in flight; the reclaim now keeps any thread's worktree while a run is registered on that thread, from its attach to its release — within one segment, never across two. The restart that followed re-dispatched the child without the tag the plan runner stamps on its children's rows (the runner's instance and the branch its pull request targets, run-history item 48a), so the child read its own unit branch as the base it must protect; a restart now carries the tag, and a continuation, which is a run the same runner instance spawns, starts as that instance's child. Both are preconditions of renewal, not parts of it.

4. Against the acceptance. The module still owns every number: the loop-end mark and a post-step's allowed tools are facts on the run's bearer-store entry, not clocks, and no new constant appears outside src/core/budgets.ts. The fit is unchanged. The invariant that a lease covers everything the run does is strengthened, since a checkpoint turn can spend no tool time. The cost cap's enforcement stays the orchestration plan's row and the approval points stay record 0044's, as the Boundaries say. Nothing the acceptance relied on is weakened; the shell kill (plan unit seven) and the pushed-head event (plan unit eight) stand.

5. The open question, and a sixth success criterion. The open question this record left before unit three — how a request expresses a grant, and the default cost cap — closes as follows: the grant is a count of renewals and a cost cap in dollars, set by a directive, by the channel's config or by the router, defaulting to zero renewals and to no change of today's cap, which the orchestration plan's cost-budget row still enforces; with the default, nothing renews and today's behavior stands, which is the reversibility the Boundaries promised. (6) A run whose lease ends leaves a recorded head and a checkpoint — or the note that the checkpoint was cut — and a renewal continues it from that head as the same coordinator instance's child in a clean tree; the first twenty renewals in production are read, as the Renewal section asks, before the default renewal count moves off zero.

Rollout: the remaining work is the plan's units six to eleven — the rewrite at the proxy, the shell kill at the loop's end, the pushed-head event, then the grant on the request with zero renewals by default, the renewal row and decision, the continuation card and the reply that spends a renewal by hand.

Amended 2026-09-17 — a continuation a person woke carries the person's words after the handoff

Re-evaluation, as an amendment after acceptance asks. This record was accepted because a lease sized by the problem is a lease the infrastructure will break, so the lease is sized by the infrastructure and the problem is bounded by the grant; a continuation is a run, not a resume, and the Renewal section fixed its request as "the previous run's handoff, not the person's message" — the renewal is the machine's decision from typed facts on the row, and a briefing drawn from a model's words would let a stuck loop talk itself into another lease. The plan that idles a pipeline adds a second way a segment opens: a person wakes an idle unit by replying in its thread, and the reply is the reason the segment exists. This amendment splits the sentence in two: a continuation the machine renews is briefed with the previous handoff alone, exactly as accepted; a continuation a person woke carries the person's words after the handoff, each unconsumed text attributed to its sender, so the coding child reads the checkpoint first and the new instruction second.

Against the acceptance: the renewal decision itself still reads only the row — the person's words never enter progressOf or renewalDecision, they enter the request the next segment runs, after the decision (or the person's spent renewal) has already opened it. The invariants do not move: segments never exceed the grant's renewals, a wake spends one where the lease or the cap ended the segment, spend never exceeds the cap plus one segment, and two segments of one session never run at once. What the acceptance guarded against — a model asking for more time — stays guarded: the words that extend the session are a person's, in the thread, under the grant that person's request carries. The card names the senders whose texts the segment folded, so the thread shows whose words the child was given.

Amended 2026-09-17 — the coding lease asks 90, the fix floor is 15 and ship asks 240: the asks are sized on the ship children the ledger now holds

Re-evaluation, as an amendment after acceptance asks. This record was accepted because one module owns every wall clock as a lease carved from its parent, the leases are proven to fit at verify, at config load and at the fork, and a number is wrong only relative to another number. The asks it moved into that module were the registry's, and the coding ask of 45 was kept on the ledger's standalone runs: none of 282 hit it (p95 29.7). It was never measured on the ship children of real plan units, which were clipped to 28 and 39 at the time and hit those clips twelve times in a day. Since the 45-minute regime went live the ledger holds eighteen hours of it: 17 ship coding children, p50 13.4, p90 31.5, max 39.3 — the one hit pushed at minute 29 and was cut inside the repo's full gate, which takes seven to ten minutes on the resident; and 7 standalone coding runs, one hit at 37.9. Two hits in 24 coding runs is one in twelve, not a tail. Reviews stay where the record measured them: 232 runs, p99 8.1, max 10.7, under the 25 they ask.

What moves. Coding's ask 45 → 90, double the children's 90th percentile with the gate inside it; the fix round takes the same ask through roundAskMinutes, as it always has. Coding's floor 10 → 15, and the fix floor with it: a fix round under 15 minutes cannot run the gate its contract requires and finishes nothing, which is what a floor exists to refuse. Ship's ask 120 → 240, so the default holds its own loop with a fix round at its ask rather than at its floor. Explore and conductor stay at 120; the conductor's ask still holds a provisioned coding child (3 + 90 = 93). GRANT_RENEWALS_MAX stays 12: it bounds a count a person types or a scope holds, and every grant configured is a count of segments; thirteen segments are now two days rather than one, and a day's hand-over is renewals: 5. Nothing else in the table moves, and everything derived — the turn guard (540 for coding), the reserves, the fit's sums, the card and refusal texts — moves by derivation.

The arithmetic. At three review rounds the reserve before the coding round is 3 × (5 + 3) + 2 × (15 + 3) + 10 = 70 and the fit is 3 + 90 + 70 = 163 ≤ 240; at four rounds the reserve is 96 and the fit 189, which the default also holds. The reserves before the later rounds at three are 62, 44, 36, 18, 10 and 0.

Against the acceptance. (1) The module still owns every number; this change touches its rows and nothing outside them but the tests, specs and comments that spell them. (2) The fit is unchanged as a rule and its three sites hold the new sums: verify asserts 163 and 189 against the ask; validateShip refuses a deployment whose ship.maxMinutes is under 189 at four rounds — a deployment at 180 with four rounds passed the old fit at 129 and passes the new one only at three rounds, so its knob moves before or with the release that carries this table, exactly the refusal the record built for the purpose; the fork refuses a clipped request under 163. (3) The lease still covers everything the run does; a longer lease changes no allowance and the wind-down is untouched. (4) The grant's invariants do not move: segments never exceed the count, spend never exceeds the cap plus one segment — a segment twice as long is the one cost, and the cap bounds it in dollars, not minutes. (5) The floors were guesses the record said the ledger would set; this is the ledger setting coding's. Nothing regresses for anyone: a standalone coding run that finished in 30 finishes in 30, a channel bounded under 90 is clipped exactly as before, and a review's lease is unchanged.

Amended 2026-09-20 — a concluded round is not renewed

Re-evaluation, as an amendment after acceptance asks. This record was accepted because a lease sized by the infrastructure will end mid-work, and renewal exists so that end is a checkpoint, never a loss: the grant decides, off progress read from the row. The first amendment already named the boundary case — "a run that submitted no handoff and pushed no newer head is the trace's variant 9, and is not renewed" — but the runner read only progress, not the round's own ending, and a run in production exposed the gap (#2086): a coding child that stopped on purpose — a plan's stop condition held, so it recorded one deviation in its handoff, pushed nothing over the base and opened no pull request — was renewed as a second segment eleven seconds later. The second child restarted from the same brief with no memory of the first child's answer, spent a second lease's budget and began implementing the very unit the first child had refused, until a person's steer stopped it.

The rule. The round's ending is read before any renewal. A child that submitted a handoff recording a deviation has concluded its round — a stop condition, a precondition that does not hold, a question it could not resolve is an answer, not a lapsed lease — and a concluded round is not renewed: the unit ends held with the deviations as its reason and waits for the person's word (under the idle flag it idles, the one held cause that does, because the person's word is exactly what the wake carries). Renewal stays what this record built it for: a child that stopped without an ending of its own — the lease ran out mid-work, the container was replaced, the harness failed — where the checkpoint (a pushed head, a handoff carrying follow-ups and unproven criteria but no deviation) is progress to continue from.

Against the acceptance. The renewal decision still reads only typed facts off the row — the deviation list is the handoff the first amendment already named as one of the two facts, never the child's prose — and no model's words open a segment. The invariants do not move: segments never exceed the grant's renewals, spend never exceeds the cap plus one segment, and a concluded round spends nothing at all. One clause narrows: a handoff's deviations growing no longer counts as progress, because a handoff carrying a deviation now ends the unit held before the decision is asked; a checkpoint handoff's shrinking follow-ups still count. What the acceptance guarded against — a stuck loop talking itself into another lease — is guarded more tightly: a round with an answer cannot be re-run at all.