Nothing bounds the bytes a plan's files: frontmatter hands its executor #245

New issue

Closed

opened 2026-08-23 20:43:26 +00:00 by john · 0 comments

john commented

2026-08-23 20:43:26 +00:00

Owner

workflow.max_plan_tasks bounds a plan by TASK COUNT. Nothing bounds it by the bytes its files: frontmatter declares, and that declared source is the large majority of what a dispatch actually costs.

Measured

On one phase's PLAN-1.md: the executor's fixed prefix (contract skill plus rung file) and the shared reads together accounted for roughly 15k of a 70,554-token dispatch. The other ~55k was the four files the plan declared - 252,473 B, about 63,000 estimated tokens. The declared source was ~90% of the bill and nothing measured it.

The failure mode this permits: a plan can pass the task ceiling at 5 tasks while declaring 15 files totalling 812,591 B (~203,000 estimated tokens), which is larger than the context window. That executor cannot read what it was told to read, and no gate says so.

Why this repo hits it hardest

Two files dominate: cadence-core/bin/planning.test.mjs (245,774 B) and cadence-core/bin/planning.mjs (151,958 B). Every plan touching either pays it in full just to orient.

The asymmetry is exact: cadence-core/bin/weight.mjs plus weight-budgets.json enforce per-surface BYTE budgets on Cadence's own shipped docs through self-verify, while the one number that decides executor spend is unmeasured.

Three-part fix, in order of cost

A declared-weight rail. Sum the plan's files: bytes at plan time, estimate tokens, and refuse over a workflow.max_plan_tokens budget the same way the task ceiling refuses a 9-task plan. planning.mjs plan-overlap already parses that exact frontmatter, so a sibling plan-weight --phase <N> is the natural seam and cad-plan-checker the natural gate.
Planner discipline. A files: entry carries a symbol or line anchor rather than a bare path, so the executor greps to the ~200 lines that matter instead of reading 6,000. Most of the win, none of the refactor risk, no code change.
Executor discipline. The contract should prefer targeted grep/sed over a whole-file Read above some byte threshold.

Not the problem

Reviewer payloads. A plan fire mails 8-17 KB. A large risk_surface payload is a large DIFF, which is plan size again one layer downstream.

Moved to GitHub: https://github.com/crenshawdev/cadence/issues/94

This project's tracker is now GitHub; this repository remains the public archive. Closed here as migrated, not as resolved.

`workflow.max_plan_tasks` bounds a plan by TASK COUNT. Nothing bounds it by the bytes its `files:` frontmatter declares, and that declared source is the large majority of what a dispatch actually costs. ## Measured On one phase's `PLAN-1.md`: the executor's fixed prefix (contract skill plus rung file) and the shared reads together accounted for roughly 15k of a 70,554-token dispatch. The other ~55k was the four files the plan declared - 252,473 B, about 63,000 estimated tokens. The declared source was ~90% of the bill and nothing measured it. The failure mode this permits: a plan can pass the task ceiling at 5 tasks while declaring 15 files totalling 812,591 B (~203,000 estimated tokens), which is larger than the context window. That executor cannot read what it was told to read, and no gate says so. ## Why this repo hits it hardest Two files dominate: `cadence-core/bin/planning.test.mjs` (245,774 B) and `cadence-core/bin/planning.mjs` (151,958 B). Every plan touching either pays it in full just to orient. The asymmetry is exact: `cadence-core/bin/weight.mjs` plus `weight-budgets.json` enforce per-surface BYTE budgets on Cadence's own shipped docs through self-verify, while the one number that decides executor spend is unmeasured. ## Three-part fix, in order of cost 1. **A declared-weight rail.** Sum the plan's `files:` bytes at plan time, estimate tokens, and refuse over a `workflow.max_plan_tokens` budget the same way the task ceiling refuses a 9-task plan. `planning.mjs plan-overlap` already parses that exact frontmatter, so a sibling `plan-weight --phase <N>` is the natural seam and `cad-plan-checker` the natural gate. 2. **Planner discipline.** A `files:` entry carries a symbol or line anchor rather than a bare path, so the executor greps to the ~200 lines that matter instead of reading 6,000. Most of the win, none of the refactor risk, no code change. 3. **Executor discipline.** The contract should prefer targeted `grep`/`sed` over a whole-file `Read` above some byte threshold. ## Not the problem Reviewer payloads. A `plan` fire mails 8-17 KB. A large `risk_surface` payload is a large DIFF, which is plan size again one layer downstream. --- **Moved to GitHub: https://github.com/crenshawdev/cadence/issues/94** This project's tracker is now GitHub; this repository remains the public archive. Closed here as migrated, not as resolved.