008 Planning

008 Planning

Status: Draft — may change (2026-10-19)

1. The question

What team and cast does the project need, what is a backlog to TeamCLI, how does a seat pull agreed work without taking what it was not agreed to take, how are order, time and budget decided, and what is recorded, with no capability of this module’s own and no refusal the Kernel does not name?

2. What we propose

The module registers no capability (Kernel §13): the Runtime hosts the commands and acts, and the Kernel owns the resource envelope, disclosure and broker refusals. BCP 14 keywords mark promises; Today lines state facts. The original says six chapters but has A–G; every original letter is retained, with H, I and J added by owner decisions. Commitments 1–22 retain their wording and numbers; 23–27 add the project analysis and casting. Chapter K adds commitments 28–33 for settled owner answers, qualifying earlier budget wording as stated there.

A. The source and the record

1. A team declares one task source, in its team file. A team MUST declare its sole task source and how it is read, pulled and ordered. No declaration means no inferred backlog; several sources remain deferred.

   Spec: tasks-and-broker §3.1. Proof: test/issues.test.ts. Today (v0.5.0). Built: one file or broker source with strict section validation, contained path and optional pull, fallback and cadence. Source: src/file/sections/tasks.ts.

2. The task record is a typed set of fields, and a missing field is absent. A task record MUST contain its identity and title and preserve missing optional information as absent. Invalid records and repeated accepted identities are refused with their source position and reason, never silently dropped.

   Spec: tasks-and-broker §3.2. Proof: test/issues.test.ts; test/linear.test.ts; test/broker.test.ts. Today (v0.5.0). Built: typed records and indexed refusals; no lifecycle state or estimate. File/policy spelling and wire spelling differ for blockers, as the spec records. Source: src/tasks/adapter.ts; src/tasks/file.ts; src/tasks/linear.ts; src/broker/server.ts.

3. The adapter hides the source; the record is the same whatever the source. Adapters MUST return the same typed record independently of the source. The file adapter is read-only; a tracker adapter runs inside the broker, bounds its read, withholds the credential and reports any incomplete page.

   Spec: tasks-and-broker §3.5. Proof: test/linear.test.ts. Today (v0.5.0). Built: file and Linear reads; the tracker query is bounded, read-only and reports an additional page without reading it. A nonpositive numeric tracker priority becomes absent. Source: src/tasks/linear.ts; src/tasks/file.ts.

B. The intake and the pull

4. Authority to take an item is an owner-set intake rule, not the tracker's fields. A seat MUST take only work covered by the owner-set intake agreement; out-of-scope repositories and unavailable required skills escalate instead of granting new scope. Source metadata confers no authority (Kernel §10; 009 required skills).

   Spec: tasks-and-broker §7. Proof: test/next.test.ts. Today (v0.5.0). Not built as an intake rule: the file or filtered tracker page supplies the set. Nonempty blockers, repositories or needs prevent every seat taking the item; no scope resolution or escalation runs. Source: src/commands/next.ts.

5. A seat pulls; it is not pushed, and it never pulls what is another's. A declared seat MUST pull under the team’s pull rule and its recorded placement, preserving another seat’s assignment unless the owner selected the broader rule. Any seat may pull, not only the lead; this is the round’s acknowledgement until receipts exist, and an empty queue is reported once (010 commitments 13 and 15).

   Spec: tasks-and-broker §5. Proof: test/next.test.ts. Today (v0.5.0). Built: declared-seat/recorded-pane placement, own/all assignment rule and own-only option; waiting polls at declared cadence and stops on signal or a nonadvancing clock. Source: src/commands/next.ts.

6. team plan shows the queue; team issues lists the source. The plan MUST show the ordered queue a claim would consider without claiming or writing; the source listing preserves source order and confers no claim or intake agreement. Chapter H extends the proposal to goal planning against the budget (commitment 18), without changing what exists today.

   Spec: tasks-and-broker §4. Proof: test/plan.test.ts; test/issues.test.ts. Today (v0.5.0). Built as a queue display and file listing. The plan uses the pull gate and broker read, shows held items, and marks passed deadlines without acting; source listing refuses broker sources. Goal decomposition is not built. Source: src/commands/plan.ts; src/commands/issues.ts.

C. The lease

7. A seat holds an item by a lease, and two live leases never cover one item. A claim MUST hold a bounded lease before work so two live leases never cover one item within the declared local boundary. The holder renews or releases it; expiry returns the item, allowing duplicate or retried work, which needs safe idempotent recording and untorn renewal.

   Spec: tasks-and-broker §3.3. Proof: test/next.test.ts. Today (v0.5.0). Partial: local unsigned leases, renewed by re-running the pull; no background renewal, remote exclusion or tracker claim. A missing held record keeps its lease and prevents taking another. Release records no progress. Source: src/tasks/lease.ts.

D. The broker

8. A vendor seat never holds the tracker's credential. The broker MUST withhold its tracker credential and API access from every returned field, hosting the Kernel’s refusal (§11, §13). Task prose remains a person’s text and is not scrubbed for a secret they typed; the Kernel’s operation vocabulary stands, while the implemented wire subset lives in the spec.

   Spec: tasks-and-broker §3.4. Proof: test/broker.test.ts; test/broker-contract.test.ts. Today (v0.5.0). Built for the bounded read only: interactive owner start, credential in memory and one header, strict request and response, stale-socket safeguards, and error details kept at the broker terminal. Nothing supervises the process. Source: src/broker/server.ts; src/broker/protocol.ts; src/tasks/linear.ts.

9. The broker isolates nothing: it is integrity, not authenticity. The text MUST state that broker placement guards integrity rather than authenticating a hostile process of the same user. A separate principal or sandbox is needed for isolation (Kernel §11, §12, §14).

   Spec: tasks-and-broker §3.4. Proof: test/broker.test.ts. Today (v0.5.0). As stated: placement and filesystem permissions, no operational capability gate or same-user isolation. Source: src/broker/server.ts; src/permissions/map.ts.

E. The policy

10. The team says which fields cross, per field, and the broker applies it before the bytes cross. The broker MUST apply the team’s field policy before serialization, preserving the record’s identity and title and omitting excluded fields rather than blanking them. Source-reference transformation happens before final validation; filtering after delivery would be too late.

Spec: tasks-and-broker §3.5. Proof: test/broker.test.ts. Today (v0.5.0). Built: explicit allow/omit and identity transform, default omission of description, final-id and duplicate checks before bytes cross. File sources have no policy. Source: src/broker/policy.ts; src/broker/server.ts.

F. Order, time and the plan

11. The order is priority first, then the team's fallback. The tool MUST order by priority, then by the team’s fallback, without judging the item’s worth. The lead sets priority; the implementation’s narrower fallback behavior is stated in Today and remains an editorial question.

Spec: tasks-and-broker §5. Proof: test/next.test.ts; test/plan.test.ts. Today (v0.5.0). Built with a narrower fallback: equal numeric/text priorities keep input order; the id fallback applies only to absent priority. Both plan and pull use that order. Source: src/commands/next.ts.

12. Time is the module's to keep: cadence, back-off, deadlines, quiet hours. The module MUST surface missed deadlines and retain each estimate beside what happened, with idle back-off and owner-set quiet hours. Chapter H names the estimate’s currencies and the re-plan on budget events; cadence alone does not fulfill this promise (010 commitment 5).

Spec: tasks-and-broker §5. Proof: test/next.test.ts; test/plan.test.ts. Today (v0.5.0). Cadence for waiting only, plus printed deadlines and an overdue mark. No estimate, back-off, quiet hours, notification or budget-driven reschedule. Source: src/commands/next.ts; src/commands/plan.ts.

G. What stays human, and what is recorded

13. Direction, priority, assignment and acceptance stay human, or a named delegate's. Direction, priority, assignment and acceptance MUST remain the owner’s or a named delegate’s. Selection among agreed eligible items is not another agreement; done is a report, and closing the source needs an owner rule or delegation (Kernel §9).

Spec: tasks-and-broker §7. Proof: test/linear.test.ts. Today (v0.5.0). As stated, with no tracker writes at all: holder comments, state moves and closing comments are made by a person or the owner’s connector. Source: src/tasks/linear.ts; src/commands/next.ts.

14. Every pull, release and expiry is a record the team can read. Pulls, releases, expiries and broker answers/refusals MUST leave a team-readable record of who, what, when, source and rule in the Runtime store, for the daily report; Kernel §15 applies to gated acts.

Spec: tasks-and-broker §7. Proof: none yet for the promised history. Today (v0.5.0). Not built: only the lease file records a take, release removes it, and failed reads are printed at the broker terminal. Round pulls depend on seat reports. Source: src/tasks/lease.ts; src/broker/server.ts.

H. The budget, planning’s input

The cost-accounting extension follows an owner decision. It extends commitments 18 and 22; the pinned Today readings remain implementation facts, not claims that the extension has shipped.

15. Every account's figures are read from what the tool can observe, and nothing else. Budget figures MUST come only from observed and owner-declared sources, naming the account, lab, window, used and remaining resource, reset, measurement time and provenance. Preferred sources fall back in order; no reporting path opens a credential, key or CLI session file (Kernel §11; Budgets source §§3–5 and §8).

Spec: budgets §3.1. Proof: test/usage-quota.test.ts; test/budget-run.test.ts. Today (int/0.5.1 8acb470b, unreleased). Built at int/0.5.1 8acb470b, unreleased: usage reporting, quota view, machine observations and approved check figures; the cited budget and observation formats are unchanged from the release tag. Source: src/information/usage.ts; src/information/quota.ts; src/information/machine-readings.ts; src/budgets/run.ts.

16. A figure the tool cannot read or trust is unknown, never plenty; its pace is "not known". Unknown or stale figures MUST remain unknown rather than room, and unavailable pace is said. A single screen sight is unconfirmed until change or independent agreement; the Kernel’s spend envelope fails closed while the subscription rule and any future owner policy stay distinct.

Spec: budgets §5. Proof: test/readings.test.ts; test/budget-refusals.test.ts. Today (int/0.5.1 8acb470b, unreleased). Built at int/0.5.1 8acb470b, unreleased, as reading states and unknown wording. No unknown-accounting policy or spend envelope is built; quota clock margin and two-point budget slope are separate measures. Source: src/budgets/readings.ts; src/budgets/gate.ts; src/information/quota.ts.

17. The marks are the owner's policies: warn, tighten and floor, per account and per lab, tightening only. Budget marks MUST be owner-set policies in the inheritance chain, tightening only and never widening the Kernel’s resource envelope (§8). A lower level may move a mark earlier; a mark nearer zero is tighter. Marks announce and act at a boundary; their units and proposed defaults are in the spec.

Spec: budgets §7.1. Proof: none yet for the proposed policies. Today (int/0.5.1 8acb470b, unreleased). Not built at int/0.5.1 8acb470b as policies: used marks, reserve and floor remain an owner-controlled file section; pace alerts remain a separately run script. Source: src/file/sections/budgets.ts; src/policy/types.ts.

18. The plan is cut against the budget, and the trade-offs are said in plain words. A plan MUST break a goal into estimated items, read account headroom first, propose assignment and timing within the budget, and explain timing/cost alternatives in plain words. Estimates MUST draw on recorded past costs, preserving the distinction between an estimate and an observed outcome; unavailable history is unknown, never zero (an owner decision). It writes the source queue only after the owner or a named delegate approves, keeps estimates beside outcomes, and never becomes an intake rule or a pull by itself (an owner decision).

Spec: budgets §7.1 and §7.3. Proof: none yet. Today (int/0.5.1 8acb470b, unreleased). Not built at int/0.5.1 8acb470b: the plan still takes no goal, reads no budget and stores no estimate. Leads cut the plan by hand from reporting and owner rules. Source: src/commands/plan.ts; src/tasks/adapter.ts.

19. Budget events are raised on the bus, and the owner hears the floor at once. Five budget kinds MUST be raised once per crossing with provenance, rearmed on reset or recovery, to the recipients the spec preserves; the separate action record remains in the spec. A floor needing the owner reaches the owner, lead and operator at once as a privileged decision; delegated owner-notice rule (an owner decision) remains the owner’s to revise.

Spec: budgets §6. Proof: test/watch-budget.test.ts; test/provider-error-check.test.ts. Today (int/0.5.1 8acb470b, unreleased). Not built at int/0.5.1 8acb470b for budget kinds. The bus exists there, unreleased, but no quota kind is in its closed vocabulary; budget and provider-error watch reports remain the substitutes. Source: src/bus/kinds.ts; src/watch/checks/budget.ts; src/watch/checks/provider-error.ts.

20. The circuit breaker: four automatic actions, each a Runtime act under an owner policy, logged and reversible, loosening nothing. Automatic budget actions MUST remain owner-policy-controlled Runtime acts, recorded with before, after and reversal; an action that cannot be recorded does not happen (Kernel §15). Swaps preserve identity, grants, lease and work, wait for idle, respect independent review and declared accounts, and are not automatically swapped back; launch refusal, report batching and holding non-release pulls loosen no limit, and only the owner’s answer lifts the floor hold or widens it.

Spec: budgets §7.1. Proof: test/budget-refusals.test.ts; none yet for the other actions. Today (int/0.5.1 8acb470b, unreleased). Partial at int/0.5.1 8acb470b, unreleased: launch reserve/spend-floor refusals, with the prior-approval limitation on up. No pace/wall gate, automatic swap, batching or budget-driven hold; the pull reads no budget. Source: src/budgets/gate.ts; src/commands/up.ts; src/commands/next.ts.

21. All of it is the owner's to set, and the actions are off until the owner turns them on. The owner MUST control these settings through the policy chain, allowing lower levels only to tighten and turn actions off; for a pace mark, nearer zero is tighter. Unknown is never plenty; no action loosens a limit; the owner hears the floor immediately; a credential is never read by the reporting path. The proposed action default advises until the owner enables acting.

Spec: budgets §7.1. Proof: none yet. Today (int/0.5.1 8acb470b, unreleased). Not built at int/0.5.1 8acb470b: budget settings remain the file section, with none of the proposed policy names in the policy catalogue. Source: src/policy/types.ts; src/file/sections/budgets.ts.

22. Costs are real, and a subscription's cost is what it actually lands. Costs MUST report actual spend per seat, model and team from provider billing/usage or measured tokens at real prices, and a subscription’s billed and effective amortized cost plus quota consumed. Estimates and outcomes use matching units so they can be compared (the owner’s real-cost requirement of 2026-10-14; 004; 010 commitment 18).

Each turn's observed cost MUST be recorded and rolled up along agent (the occupant's session) → seat → team → project → entity, in input, output and cache tokens and money where known, by day, week and release. Sources MUST be the CLI's own usage output or the turn runner's usage record, with provenance retained and unverified CLI support said explicitly. An unexposed figure MUST remain unknown and MUST NOT count as zero. Records MUST live in the registry under the usual grants; money MUST identify the entity account's subscription or API-price basis. Views MUST expose each hierarchy level, task cost through its handover record, release cost, and top spenders with what they spent on. The planner uses this history under commitment 18 (an owner decision).

Spec: budgets §7.1 and §7.3. Proof: none yet for real-cost accounting, hierarchical roll-ups or historical-cost estimates; per-CLI verification and the staged plan are in §7.3. Today (int/0.5.1 8acb470b, unreleased). Not built at int/0.5.1 8acb470b: tokens and percentages by an owner decision, plus a spend-account balance compared with its floor; no token price or amortized fee. Source: src/information/usage.ts; src/budgets/gate.ts.

Editorial clarification (architect, 2026-10-18): commitments 17 and 21 both use nearer zero as tighter; the source’s “four kinds” is corrected to five, with all five crossings and the separate action record preserved. This corrects wording and decides nothing further.

I. The project analysis, planning's other input

The project analysis joins account headroom as an input to planning under an owner decision. It carries 004's original commitment 1; 004 Measurement keeps the measurements and comparison with outcomes. The starting point, costs and reversal are in §§3–5; the two entrance questions carried from 007 remain open in §10.

23. The project is examined before a team is proposed. Planning MUST examine what the project is, its size, how it is tested and released, its open work and what can and cannot be done by several agents, together with the available agents and their remaining resources. It MUST propose how many agents, of what kinds, led or not, and give its reasons to the principal authorized to create the team. The proposal MUST NOT create a team or confer authority to read the project. An owner or previously authorized agent names the first reader within existing scope; how that first request is made remains §10 question 23.

Spec: setup and team models §§3–5 carries detection, role-model fit and the explained proposal/preview contract; detailed project-analysis input serialization remains open there. Authority stays with the Kernel and team creation with the Runtime. Proof: none yet. Today (v0.5.0). Not built at v0.5.0: init writes a one-seat starter, without analysing the project; plan displays the claim queue, without a goal or team proposal. Source: src/commands/init.ts; src/commands/plan.ts.

J. Casting

A team is like a ship: seats are its stations, and agents stand their watches. Casting proposes who stands each seat for the plan, with a reason for each choice.

24. A cast is an explained output of a plan. TeamCLI MUST propose and explain a cast for a team or plan, identifying the lab, model, version and effort for each seat. It MUST weigh model abilities and benchmarks from the Models data; cost, quota and pace left per account; lab diversity, including a reviewer from another lab than the writer; which labs the project's visibility permits; and the owner's rules. Once the session registry exists, it MUST also use Measurement's recorded rounds to pass, work returned and cost per task. Missing measurements remain unknown, never an invented result. This is the optimisation of an owner decision, reading 004 Measurement and chapter H's budget input.

Spec: casting carries casting inputs and the cast record (§12). Proof: none yet. Today (v0.5.0). Not built at v0.5.0: plan is a queue display and no cast command is registered. Source: src/commands/plan.ts; contract/cli.json.

25. The universe gives the names; casting explains their fit. A casting MUST map each seat's function and proposed lab/model to one universe entry with a stated reason, coherently across the set: a consistent era and the relevant relations recorded. The universe's canon MUST identify canonical titles and when they apply, relevant relations and traits, and a source read and dated for every claim; an unsourced claim MUST be marked unverified rather than guessed. 009 Roles and skills owns the universe, names, titles and role names; this chapter uses its naming method, with the vocabulary of an owner decision. An owner decision supplies the coherence and source requirement.

Spec: casting carries canon and seat-to-entry mapping formats (§12). Proof: none yet. Today (v0.5.0). Not built at v0.5.0: no casting or canon verification command is registered. Source: contract/cli.json.

26. Every casting is reviewed before it is applied. Every casting MUST be reviewed against its sources by the configured minimum number of distinct labs other than its author's, default two. The same entity/project/team setting governs the naming method and each casting; the method MUST pass its review before use for a new casting or a rename under a new universe. Applying a reviewed casting to a team file MUST remain the file owner's step, with the owner's go wherever a policy requires it. This follows an owner decision and 005 Quality; this draft records no new review or acceptance.

Spec: casting carries the casting review record (§12); the review minimum is a proposed policy, not a new built gate. Proof: none yet. Today (v0.5.0). Not built at v0.5.0: no cast command or casting review gate is registered. Source: contract/cli.json.

27. A re-cast is applied through the Runtime's swap queue. TeamCLI MUST propose a new cast when quota runs out, a seat keeps failing or the plan changes. The planned team cast [--team|--plan] MUST show the cast and each reason, and team cast --propose MUST suggest improvements; applying a change MUST go through team config, the existing authority rules and the Runtime's swap queue. A healthy working seat MUST take no new task while the swap waits for the task boundary marked by TeamCLI; a broken seat MUST swap at once. A bounded wait is a setting, after which the next pause between turns permits the logged swap; an owner-forced immediate swap is logged. The Runtime MUST try resuming the conversation when the CLI stays the same, without promising that untested behaviour works; when the CLI changes, the handover file is required as the task's last step. Hand-opened panes are flagged, never closed automatically. These rules refine commitment 20's older idle wording under two owner decisions; the Runtime owns execution and 010 Workflow owns the task boundary. Casting follows the owner's model rule (an owner decision), never widening grants, visibility or account scope.

Spec: casting carries the planned cast command and application interface (§12); queue execution stays with the Runtime. Proof: none yet. Today (v0.5.0). Not built at v0.5.0: team cast is absent from the command contract; casting, its queue integration and conversation-resume behaviour are proposals. Source: contract/cli.json.

K. Settled budget choices and the universe library

The following rulings settle the six owner questions listed in §10. Their later, explicit qualifications govern the earlier wording of commitments 20 and 21; all other earlier promises retain their text.

28. The account is the default unit of a budget mark. Budget policy MUST use the account as its default unit; a mark on a lab MUST expand to every account its seats draw on. This settles commitment 17's default without removing lab-wide rules (an owner decision).

Spec: budgets §7.1; the owner's decision supplies the settled policy choice. Proof: none at the tag for this promise. Today (v0.5.0). Not built at v0.5.0: file accounts exist, but no inherited account/lab mark policy or lab expansion is implemented. Source: src/file/sections/budgets.ts; src/policy/types.ts.

29. The last call is a notice, not a fourth mark. The last call MUST notify the floor's approach and MUST NOT introduce a fourth budget mark; warn, tighten and floor remain the three policy marks (an owner decision).

Spec: budgets §7.1; the owner's decision supplies the settled policy choice. Proof: none at the tag for this promise. Today (v0.5.0). Not built at v0.5.0: the three policy marks and last-call notice remain proposed. Source: src/watch/checks/budget.ts; src/policy/types.ts.

30. Recovery offers a return; acting waits for the task boundary. quota.recovered MUST offer swap-back as a proposal; under an enabled act policy, the Runtime MUST make the return only at the seat's task boundary. The owner or a valid delegate supplies that authority; recovery alone does not. This qualifies commitment 20's older no-automatic-swap-back wording and retains commitment 27's queue and scope rules (an owner decision).

Spec: budgets §7.1; the owner's decision supplies the settled policy choice. Proof: none at the tag for this promise. Today (v0.5.0). Not built at v0.5.0: no quota.recovered bus kind or budget-driven return swap exists. Source: src/commands/next.ts; src/budgets/gate.ts.

31. Release-critical is the owner’s item label, with delegated marking only. Release-critical work MUST be identified by the owner's label on the item. A lead MAY mark an item during a run only under a delegation record; only the owner MAY unmark it. Neither the open round nor a lead's unrecorded choice confers the status (an owner decision).

Spec: budgets §7.1; the owner's decision supplies the settled policy choice. Proof: none at the tag for this promise. Today (v0.5.0). Not built at v0.5.0: no release-critical item label gate or delegated marking/unmarking rule is implemented. Source: src/tasks/adapter.ts; src/commands/next.ts.

32. The owner enables acting above the team; a delegated lead may enable its own team. Only the owner MAY set act at entity and project levels; a lead MAY set it for its own team only under a delegation record of the Kernel's Lifecycle delegation section and within the entity's envelope. This qualifies commitment 21's older lower-level-off-only wording without widening the resource envelope or making actions default-on (an owner decision).

Spec: budgets §7.1; the owner's decision supplies the settled policy choice. Proof: none at the tag for this promise. Today (v0.5.0). Not built at v0.5.0: neither act policy inheritance nor the planned lifecycle delegation record is implemented. Source: src/policy/types.ts; src/file/sections/budgets.ts.

33. The universe library begins with a free public-domain API. The universe library MUST begin with a free API serving public-domain universes and MUST NOT offer a paid tier now. A later paid tier for curated or verified universes and private hosting MUST wait for both legal advice and ten public-domain universes in real use; this sets no price or licence and preserves the rights limits of an owner decision.

Spec: casting; the owner's decision supplies the settled policy choice. Proof: none at the tag for this promise. Today (v0.5.0). Not built at v0.5.0: no universe-library API or paid tier is implemented. Source: contract/cli.json.

3. Why

RFC 008’s live gap on 2026-10-08 was a team that could run its engineering loop but could neither read nor record a tracker item. Reads and pulls now exist; writes still need a person or the owner’s connector. The owner’s 2026-10-16 rule was that a finished seat pulls again rather than waiting for redispatch (010 commitment 15). The broker answers the credential question narrowly, with filtering before disclosure and the same-principal limit explicit. Round checks and liveness work exposed leases expiring under working seats (two owner decisions).

The project before the team

004's starting point was a team shaped by guess: a lead, two builders and a reviewer because that was the last project's shape, before anyone looked at this one. Its habit story makes the cost concrete: one project left a lead doing the operator's work while the operator waited; another had three agents review the same change in turn. Neither team had examined its project. Commitment 23 asks for that examination before a proposed team, not a more persuasive guess after it has been created. The public audit's RFC 004 rows assign this starting point and story to Planning.

The budget placement and flow

An owner decision closes the separate-module question: budget is Planning’s core input. A plan promises who does what by when, and the budget makes that promise honest before assignments are proposed and again when events require a re-plan. The Kernel owns how much may be spent and by whom; the Runtime reads and acts; Communication carries events; Planning chooses work, order, account and pace. Workflow reports the day, Quality measures checking costs, and Measurement compares estimates with outcomes.

The earlier Budgets source, approved 2026-10-04 with the owner’s real-cost requirement of 2026-10-14, supplied mechanics and goals. Its source copy stays unchanged. The reading mechanics now live in the budget spec; its goals become commitments 15–22. RFC 008’s existing promises stand, with commitments 6 and 12 extended, not replaced.

The requested flow keeps its six steps: (1) propose items, roles, estimates and dependencies from the goal, never silently pull them; (2) read every account’s remaining resource, reset, pace, age and source, saying when pace is unknown; (3) propose assignments and timing, favoring scarce labs where their work pays, deferring to resets and placing heavy work in machine capacity; (4) explain timing and budget alternatives in plain words; (5) obtain the owner’s or named delegate’s approval before creating the queue; (6) re-plan on warnings, carry work through a walled-seat swap, and take the floor decision to the owner while release-critical work alone continues on that account. Exact currencies, synopsis and example figures are in the budget spec §7.1. Steps 1, 3 and 4 are planning, 2 the Runtime’s read, 5 the owner’s act and intake agreement, and 6 the bus and circuit breaker.

Budget incidents retained from the chapter

• On 2026-10-03 a weekly limit went up from 45% to 80% when long sessions spent the global quota that had been mistaken for a model-specific one. A mark on the correct account could have warned earlier (Budgets source §1).
• The restore bug ran seats on the higher-cost model all day on 2026-10-14 and took the weekly quota to 87%; token pricing alone would have missed it. Commitment 22 counts quota as a real cost.
• Cursor builders stopped on a cap on 2026-10-14 that no token count predicted; this motivates the wall notice and swap.
• On 2026-10-17 at 12:54 the margin was −10.8% against a −14 floor; the lead was told manually to keep turns lean, move reviews and summaries to other labs and run no Claude sub-agents. That is batching applied by a person.
• On 2026-10-18 two seats faced a 118-hour wall and were moved from the Antigravity pool to DeepSeek and GLM by a file edit and relaunch. It was manual, under the owner’s rule that an out-of-token seat is replaced at once and told after.
• The owner’s night watch used alert points against a floor read from a seat’s status line. Those proposed defaults and the source’s last-call question moved to the budget spec; the script remains external practice.

4. What it costs, and what it does not cover

• A first project analysis can be wrong and still be believed: numbers and reasons may look more certain than a guess. With little evidence, it says so and proposes a small team that can grow. Reading the whole project also spends lab budget, potentially more than the work it is sizing; the analysis states its cost and starts small (004's project-analysis costs).
• Reading a project sends that project to the lab doing the analysis. The potentially broad read remains within the Kernel's scope and disclosure rules; a request for a proposal grants no additional read (004 §4; Kernel §§3, 6 and 11).
• An adapter needs product-specific API code. The tracker read is deliberately one bounded page and says when the project is larger.
• The owner keeps the broker process alive. An unavailable broker means no claim, after the bounded client deadline specified in tasks-and-broker §3.4.
• A lease expiring under a working seat permits duplicate work until renewal is automatic.
• A reading describes a shared account others, including the owner’s sessions, can spend between reads. Its age matters, and a plan needs re-cutting when events arrive.
• An estimate is a guess with units, retained beside the outcome; the timing promise must state that trade-off. The budget spec names those currencies.
• Automatic acts cost trust: a swap changes which declared lab sees the work and a hold stops intended work. Advice precedes opt-in action; every act and reversal is recorded; the floor remains a decision.
• Printed margin is believed as printed. Computed margin assumes flat spend, which bursts violate; the policy leaves room for that approximation.
• Machine capacity is a separate currency under the Runtime’s gate slots and an owner decision. The chapter schedules within capacity and introduces no further machine mark.
• The owner’s rule is never replaced by a reading or a plan; a spoken change becomes an owner-set setting.

Not covered: done and review (005), result acceptance (Kernel gate/merge), the round and daily report (010), delivery and acknowledgement (002), resolved skills (009), registry/placement/store and launch accounts (Runtime, including an owner decision).

What this release must not pretend

• Project analysis and casting are not built at v0.5.0. A starter file is not a project examination, and a queue display is not a cast or reviewed team proposal.
• Leases are local and unsigned; another clone or machine is outside exclusion. A seat may unknowingly outlive its lease.
• The broker isolates no same-user process. Its name and pane are checked claims, not authentication, and it does not enforce the operational broker capability.
• The owner-set intake rule and escalation are unbuilt. Task fields filter candidates; no right, repository scope, skill resolution or blocker lifecycle is read. Some listed tasks are hidden from the plan and untakeable by everyone.
• No tracker write or pull history exists. The current deadline mark decides nothing.
• Usage is a report and advice, acted on by a person. Pace policy and automatic quota reactions are not built; swaps, batching and holds remain manual.
• The launch gate reads counted reserves and spend floors. It has no pace-floor or wall refusal, unknown refuses nothing, and the team-start path reaches it only under a verified earlier approval; the budget spec gives the exact command boundary.
• The current plan takes no goal, estimates nothing and reads no budget. Tokens and percentages are not token prices, billed spend or amortized fees. The cost hierarchy, per-turn registry records, task/release costs, top-spender views and history-based estimates remain proposed; their staged plan is in budgets §7.3.
• A bus is built at int/0.5.1 8acb470b, unreleased, but no budget event kinds are in it. The budget source’s no-bus statement describes v0.5.0 only.

5. What would change our mind

• If teams proposed from project analysis work no better than teams shaped by habit, commitment 23 is ceremony and good starting shapes are worth more (004's first reversal; public audit, RFC 004).
• If a minimal typed record leaks source references in practice, the field set shrinks and the description is dropped by default (RFC 008).
• If same-principal isolation proves too weak for the teams that need the broker, a separate principal becomes required, not optional (RFC 008).
• If the teams that run rounds never use team plan, the order is the lead's and the plan is ceremony: then the module keeps the pull and the lease and drops the planning.
• If the tracker is given write access to seats of their own (010's "what would change our mind"), the holder comment and the state move become the seat's, and the broker's operation list grows by the Kernel's claim.

6. What is true today

Today is v0.5.0 (52db9b75) for commitments 1–14 and 23–33; chapter H is read at int/0.5.1 8acb470b, unreleased. The budget-format comparison is in the budget spec. Historical manual practice is not implementation.

#	Commitment	Today
1	A team declares one task source, in its team file	Built: one file or broker source with strict section validation, contained path and optional pull, fallback and cadence.
2	The task record is a typed set of fields, and a missing field is absent	Built: typed records and indexed refusals; no lifecycle state or estimate. File/policy spelling and wire spelling differ for blockers, as the spec records.
3	The adapter hides the source; the record is the same whatever the source	Built: file and Linear reads; the tracker query is bounded, read-only and reports an additional page without reading it. A nonpositive numeric tracker priority becomes absent.
4	Authority to take an item is an owner-set intake rule, not the tracker's fields	Not built as an intake rule: the file or filtered tracker page supplies the set. Nonempty blockers, repositories or needs prevent every seat taking the item; no scope resolution or escalation runs.
5	A seat pulls; it is not pushed, and it never pulls what is another's	Built: declared-seat/recorded-pane placement, own/all assignment rule and own-only option; waiting polls at declared cadence and stops on signal or a nonadvancing clock.
6	team plan shows the queue; team issues lists the source	Built as a queue display and file listing. The plan uses the pull gate and broker read, shows held items, and marks passed deadlines without acting; source listing refuses broker sources. Goal decomposition is not built.
7	A seat holds an item by a lease, and two live leases never cover one item	Partial: local unsigned leases, renewed by re-running the pull; no background renewal, remote exclusion or tracker claim. A missing held record keeps its lease and prevents taking another. Release records no progress.
8	A vendor seat never holds the tracker's credential	Built for the bounded read only: interactive owner start, credential in memory and one header, strict request and response, stale-socket safeguards, and error details kept at the broker terminal. Nothing supervises the process.
9	The broker isolates nothing: it is integrity, not authenticity	As stated: placement and filesystem permissions, no operational capability gate or same-user isolation.
10	The team says which fields cross, per field, and the broker applies it before the bytes cross	Built: explicit allow/omit and identity transform, default omission of description, final-id and duplicate checks before bytes cross. File sources have no policy.
11	The order is priority first, then the team's fallback	Built with a narrower fallback: equal numeric/text priorities keep input order; the id fallback applies only to absent priority. Both plan and pull use that order.
12	Time is the module's to keep: cadence, back-off, deadlines, quiet hours	Cadence for waiting only, plus printed deadlines and an overdue mark. No estimate, back-off, quiet hours, notification or budget-driven reschedule.
13	Direction, priority, assignment and acceptance stay human, or a named delegate's	As stated, with no tracker writes at all: holder comments, state moves and closing comments are made by a person or the owner’s connector.
14	Every pull, release and expiry is a record the team can read	Not built: only the lease file records a take, release removes it, and failed reads are printed at the broker terminal. Round pulls depend on seat reports.
15	Every account's figures are read from what the tool can observe, and nothing else	Built at int/0.5.1 8acb470b, unreleased: usage reporting, quota view, machine observations and approved check figures; the cited budget and observation formats are unchanged from the release tag.
16	A figure the tool cannot read or trust is unknown, never plenty; its pace is "not known"	Built at int/0.5.1 8acb470b, unreleased, as reading states and unknown wording. No unknown-accounting policy or spend envelope is built; quota clock margin and two-point budget slope are separate measures.
17	The marks are the owner's policies: warn, tighten and floor, per account and per lab, tightening only	Not built at int/0.5.1 8acb470b as policies: used marks, reserve and floor remain an owner-controlled file section; pace alerts remain a separately run script.
18	The plan is cut against the budget, and the trade-offs are said in plain words	Not built at int/0.5.1 8acb470b: the plan still takes no goal, reads no budget and stores no estimate. Leads cut the plan by hand from reporting and owner rules.
19	Budget events are raised on the bus, and the owner hears the floor at once	Not built at int/0.5.1 8acb470b for budget kinds. The bus exists there, unreleased, but no quota kind is in its closed vocabulary; budget and provider-error watch reports remain the substitutes.
20	The circuit breaker: four automatic actions, each a Runtime act under an owner policy, logged and reversible, loosening nothing	Partial at int/0.5.1 8acb470b, unreleased: launch reserve/spend-floor refusals, with the prior-approval limitation on up. No pace/wall gate, automatic swap, batching or budget-driven hold; the pull reads no budget.
21	All of it is the owner's to set, and the actions are off until the owner turns them on	Not built at int/0.5.1 8acb470b: budget settings remain the file section, with none of the proposed policy names in the policy catalogue.
22	Costs are real, and a subscription's cost is what it actually lands	Not built at int/0.5.1 8acb470b: tokens and percentages by an owner decision, plus a spend-account balance compared with its floor; no token price or amortized fee.
23	The project is examined before a team is proposed	Not built at v0.5.0: init writes a one-seat starter; plan displays the queue, without project analysis or a team proposal.
24	A cast is an explained output of a plan	Not built at v0.5.0: no casting optimisation or cast command.
25	The universe gives the names; casting explains their fit	Not built at v0.5.0: no casting or canon verification command.
26	Every casting is reviewed before it is applied	Not built at v0.5.0: no casting review gate.
27	A re-cast is applied through the Runtime's swap queue	Not built at v0.5.0: cast command, queue integration and resume behaviour remain proposed.
28	The account is the default unit of a budget mark	Not built at v0.5.0: file accounts exist, but no inherited account/lab mark policy or lab expansion is implemented.
29	The last call is a notice, not a fourth mark	Not built at v0.5.0: the three policy marks and last-call notice remain proposed.
30	Recovery offers a return; acting waits for the task boundary	Not built at v0.5.0: no quota.recovered bus kind or budget-driven return swap exists.
31	Release-critical is the owner’s item label, with delegated marking only	Not built at v0.5.0: no release-critical item label gate or delegated marking/unmarking rule is implemented.
32	The owner enables acting above the team; a delegated lead may enable its own team	Not built at v0.5.0: neither act policy inheritance nor the planned lifecycle delegation record is implemented.
33	The universe library begins with a free public-domain API	Not built at v0.5.0: no universe-library API or paid tier is implemented.

7. The security boundary

Credential withholding is the Kernel’s refusal, hosted here (Kernel §§11 and 13). The broker reads its credential once into memory, sends it in one header to the fixed host, follows no redirect and filters before serialization. Task prose may still contain a secret a person typed. Tests inject a credential and show it absent from the seat’s files, output and answer line; the design’s environment claim has no test that reads that environment.

Declared-seat and recorded-pane checks refuse mistaken placement; a request or answer from an unknown protocol shape is refused whole so an older broker cannot mislead the client. Socket, start-lock and takeover writes preserve the non-socket boundary; private temporary files identify their writer. The exact wire, paths, limits, defaults and takeover contract moved to tasks-and-broker §§3.4–3.5.

Budget reporting opens no credential or session file. An approved check owns its credential and returns only figures; its constrained environment, timeout, approval hash and dropped raw output are in budgets §3.4. Screen overrides can loosen a refusal, as the Budgets source §8 warns. A future swap carries a key-store reference, never a key (Runtime commitment 50 and the historical security/source section, accepted Runtime amendment 01 §7).

Cost records follow the registry's existing grants (an owner decision). Collection through a CLI's own usage output or the turn runner grants no new right to read another scope's records or a credential/session file.

A wrong reading may report, refuse, batch or hold, never spend, open an account, raise a limit, type into a human pane or interrupt a turn. A hold stops the next pull. Swaps wait for idle and stay within already declared accounts. Neither a plan’s proposed budget increase nor a mark supplies the owner’s word. Unknown and stale are never room.

Chapter J qualifies the older idle wording above and in commitment 20: the Runtime's bounded task-boundary queue and broken-seat exception apply under owner decisions. A reading supplies no new authority for a swap. Project analysis and casting MUST stay within already authorized reads, project visibility, owner model rules and grants; proposing a team or a different lab never permits disclosure by itself.

Marks are owner-set and only tighten; a seat cannot loosen its own limit, and lower levels may turn automatic acts off, never on — except a lead setting act for its own team under commitment 32's delegation record in the Kernel's Lifecycle delegation section and within the entity's envelope. The floor is a privileged notice whose owner recipient cannot be removed or self-subscribed to. A wrong reading never widens the resource envelope.

The same-user limit is Kernel §14: unsigned leases, the local socket, reading stores and policy files protect against mistakes, not a hostile sibling process, until containment. The broker dev-mode question is settled by an owner decision and implemented at v0.5.0: broker remains outside gate lifting (src/policy/types.ts).

8. Where it sits, and what it leaves to others

Tier 3, the sixth module in the reading order, after 004 Measurement and 005 Quality and before 009 and 010, which lean on it: 010's round takes its items through team next (010 commitment 15) and writes its holder and closing comments to the tracker this module reads (commitments 2, 4, 7); the Runtime runs the commands, the lease and the broker process (Runtime chapter H) and keeps the records (Runtime chapter I); the Kernel owns the intake agreement (§10), the use-broker operations and the broker's refusal (§11, §13), the declared task resources (§8) and the read of every disclosure (§3). What makes an item done is 005's; whether its result is accepted is the Kernel's gate; how the seat hears of it and acknowledges it is 002's; what the seat is able to do is 009's.

The Kernel owns the resource envelope (§8); the Runtime owns the readings, launch accounts and acts (including Runtime amendment 01), 002 the bus, 010 the queue’s round and daily report, 005 checking costs, and 004 the comparison of estimates with outcomes. The rejected separate budget module remains a placement alternative, settled by an owner decision.

A plan is what the owner calls a journey; 010 Workflow owns the workflow run that carries out the work. Planning owns the proposed team from the project analysis and its cast; Measurement supplies observations and comparisons, 009 Roles and skills supplies the universe and naming method, and the Runtime owns registry, configuration and swap execution. Building casting depends on the session registry and configuration support; its release is still to set, not promised here (an owner decision).

9. Prior art and alternatives

The original’s concrete alternatives are a push versus autonomous pull, a separate principal versus same-user broker, filtering before versus after crossing, and a separate budget module versus Planning chapter H. The reasons are retained in §§2, 3 and 7; no additional precedent is introduced.

10. Open questions

1. For the build: Repositories, needs and blockers. RFC 008 §4: a task naming a repository outside the agreed scope, or a need the seat is not agreed to receive, is escalated, not worked; a blocked item waits. The code makes any record carrying repos, needs or blocked-by untakeable by every seat and escalates nothing. Decide the check (the declared roots of Kernel §6 for repos, the seat's resolved skills of 009 for needs, the blocker's own state for blocked-by) and the escalation path (to the lead, recorded).

2. For the build: The intake rule's shape. RFC 008 §1's owner-set rule (which items are eligible, within what limits, what escalates) does not exist as a thing in the file or the policy object. A policy of the Kernel's Policies section, or an owner-controlled intake section of the team file? Proposed spellings are retained in tasks-and-broker §7. And whether a file source needs one at all, the file being the owner's list.

3. For the build: The lease. The spec’s fixed local duration, renewed only by another pull, expires under a seat that works longer. Decide the duration as a setting, an automatic renewal (the seat's own hooks, or the watch, which already reads the seat's state), and the idempotent record the RFC asked for; and whether the lease should reach the registry, where the seat's identity lives, rather than the clone.

4. use-broker and the per-seat check. Kernel §11 names one principal for a broker call, the requesting seat, checked by its own scope and deny; 0.5.0 gates no capability and the broker checks placement alone. When use-broker is gated by the resolver, does the broker read the resolver, and is team issues's ungated listing a read disclosure (§3) of a file the seat could read anyway?

5. For the build: The record has no state. The Linear read selects no state field and no filter, so a completed issue of the project (one not yet archived: the tracker omits archived issues by default, the code sends no filter) is read and takeable like an open one; the file record has no state either. Decide the canonical lifecycle states (RFC 008 §8.4: asked, taken, waiting, checked, done, the Runtime's item lifecycle) and each adapter's mapping, and filter the read on them. A must-fix before a team pulls from a tracker with closed items.

6. For the build: Time. Cadence alone exists. Decide the minimum: a passed deadline told to the lead (the watch already reports by kind), the ETA of 010 commitment 5 kept beside the lease, back-off on an empty queue, quiet hours as a setting of the Kernel's Policies section's shape.

7. For the build: The records. A pull leaves a lease file and no line anywhere; a release leaves nothing. Decide the first record: one history line per take, release and expiry in the Runtime's store, so the round's daily report can read who took what.

8. Tracker writes. Nothing writes the tracker; 010 has the In Progress move, the holder comment and the closing comment typed by a person or the owner's connector. Decide the first write (the claim as a comment, the state move) and its authority: the Kernel's claim a task operation of use-broker is the natural home, and it needs the capability gated first (question 4).

9. Dev mode and the broker. Settled by an owner decision and built at v0.5.0: broker is outside caller-gate lifting. The earlier proposed removal has landed; this is a Today fact (Runtime original §10, question 1).

10. Several sources, and the empty backlog. Deferred by RFC 008; the code stands down with one answer, or polls at the cadence under --wait, which matches 010 commitment 15 (a seat with nothing says so once and stops). Nothing to decide yet; said so that the round does not reopen it.

11. The budget placement and decision id. Settled by an owner decision: the budget is chapter H, not another module; the flow and commitments 15–22 are folded here. This also preserves budget-source §8 question 1; the source’s old question 11 is the same placement question.

12. Account or lab as the unit of a mark — settled by an owner decision: the account is the default unit; a mark on a lab expands to every account its seats draw on.

13. The last call — settled by an owner decision: it is a notice of the floor’s approach, not a fourth mark.

14. Swap-back — settled by an owner decision: quota.recovered offers a return as a proposal; under act the move is made only at the seat’s task boundary.

15. Release-critical — settled by an owner decision: the owner’s item label is the mark; a lead may mark during a run under a delegation record, and only the owner may unmark.

16. For the build: The hysteresis. The recovery count and mark in budgets §7.1 are guesses and should be settings.

17. Who turns act on — settled by an owner decision: the owner sets act at entity/project level; a lead may set it for its own team under a delegation record of the Kernel's Lifecycle delegation section within the entity envelope.

18. For the build: The estimate's units. Tokens per model class, machine time and heavy slots remain distinct. An owner decision settles that costs include input/output/cache tokens and money where known, using the entity's subscription or API-price basis, and that the planner estimates from recorded costs. Price versioning, subscription allocation and comparison when history is incomplete remain to specify; the cost-record and period questions are in budgets §7.3.

19. The Kernel's reservation per dispatch (§8: a dispatch reserves the per-dispatch maximum against the remainder) is not built and this chapter does not build it; the plan's estimate is the natural reservation. Decide whether the plan's approval reserves.

20. 0003's own open questions (suggest an account only in a refusal; no direct vendor API; no per-task budget; a grok profile), as the code answers them today: a refusal and the advice line name accounts; the CLI's own usage print is read where it exists; nothing is per task; the grok profile exists.

21. The two entrances. Should a person typing one command and an agent asked in a conversation reach the same result, or should the agent entrance do more, and what would be lost by making them equal? This remains 007 §6 question 1, carried by the public audit's RFC 007 row; no entrance is chosen here.

22. The first proposing agent. Is it the current conversational agent, or a new agent given the conversation's substance? 007 §6 question 2 leans toward a new agent with a handover that works across labs, but leaves the choice open; the same audit row carries it here.

23. The first project reader. Before a team exists, the owner or a previously authorized agent must name a reader; there is no analysis before authorization. How is that first analysis asked for without a formality or a wall? This is 004 §6 question 1, assigned to Planning by the public audit's RFC 004 row, not settled by moving commitment 23.

24. The universe library’s business model — settled by an owner decision: there is no paid tier now; a free API serves public-domain universes first, with a later paid tier for curated or verified universes and private hosting only after legal advice and ten public-domain universes in real use.

25. Round-1 proposals, pending decisions. The proposals below are questions; no commitment or implementation is added by carrying them here.

    Existing question	Proposal to decide
    §10.1	Should repository roots be checked per seat/team, missing skills escalate once, blockers wait until done, and escalation be recorded once per item/reason to lead or owner?
    §10.2	Should intake use an inherited owner policy, with team-local tightening and no separate file-source filter by default, while preserving scope/skill checks?
    §10.3	Should lease-duration default to 30 minutes, renew through hooks and watch while working, stop on unreachable/dead/over-threshold idle, and live in a shared Runtime store keyed by task/seat/agent/epoch, signed and atomically renewed with idempotent claims?
    §10.4	Should the broker call the capability resolver per requesting seat for backlog/claim, local file listing use scoped read, and tracker listing require use-broker and field policy?
    §10.5	Should the task record add state defaulting to asked, map tracker triage/backlog/unstarted to asked, started to taken or checked, completed to done, exclude canceled, and permit claims only for asked items with done blockers?
    §10.6	Should the minimum include one deadline notice to the lead, ETA beside the lease, capped empty-queue back-off waking on bus events, and inherited quiet-hours?
    §10.7	Should signed take/release/expiry records carry task, seat, agent, action, time, source and admitting rule in the shared Runtime store for Measurement and Workflow?
    §10.8	Should an authorized claim move the tracker item to In Progress and write a holder comment with seat, agent and lease-until, while closure requires the owner's or delegated gate/merge/lead rule?
    §10.16	Should recovery count and margin become budget policy settings using the spec's initial defaults until measured?
    §10.18	Should price tables have effective-from versions, subscription money be amortized per billing window as fee/tokens, and sparse comparable history produce unknown/low confidence with N, while resource currencies stay distinct?
    §10.19	Should plan approval create a soft earmark while each dispatch makes and reconciles the Kernel hard reservation?
    §10.21	Should both entrances produce the same explained proposal and preview/approval gate, differing only in preference gathering?
    §10.22	Should a fresh bounded invocation with goal, constraints, approved repositories and visibility be default, with in-place use only for an already authorized session?
    §10.23	Should local detection precede a one-screen first-reader preview naming path, visibility, lab and model, then one scoped read authorization, unless already covered?

26. Round-1 housekeeping requests. The round-1 review, lines 83 and 85, asks to refresh four brief quotations and remove the done/review sidecars outside the brief's scope. What replacement brief and archival disposition should the organiser record? These requests do not give an exact in-text/spec correction and are referred rather than applied.

12. Links to the spec

• Tasks and broker §§3.1–3.5: source, records, lease, wire and filtering.

• Tasks and broker §§4–7: commands, behavior, registry rows and unbuilt obligations.

• Budgets §§3–5: configuration, readings, check contracts, quota view, gate and marks.

• Budgets §§6–7: planned policy and event entries, defaults and unresolved interfaces.

• Budgets §7.3: cost hierarchy, logical records, per-CLI sources, usage/task/release/top-spender views and historical-cost estimates; all proposed.

• Registries: event kinds, policy names, operations, exit codes.

• For seat-state-and-watch: the existing budget check reports marks to the operator, reserve/floor to the owner, unknown active accounts to the operator, with per-window rearming; no budget action. Source src/watch/checks/budget.ts; proof test/watch-budget.test.ts.

• For events: all quota names in the budget spec §6 are planned, absent from the integration revision’s closed list; quota.action is an action record with event status unresolved.

• For policies: the budget spec §6 preserves every proposed budget policy plus pace-conduct; none is a current catalogue entry.

• Setup and team models: detection, nullable facts, read-only check search, role-based presets and fit, guide, first-run proposal and grant/create preview safeguards; the interfaces remain proposed at v0.5.0.

• Casting: cast inputs and record, canon, seat-to-entry reasons, review record and planned command/application interface (three owner decisions). The Runtime retains the session registry and swap queue; existing configuration and policy specs retain their own interfaces.

• Budget policy choices in commitments 28–32 read budgets §7.1 with an owner decision that answers 22–26; commitment 33 supplies an owner decision’s library constraints. These rulings are promises, not implementation claims.