Repository navigation
Conversation
The planner forecasts the size of the whole change right after its steps, in one plain line: Size forecast: files a-b, added a-b, removed a-b, commits a-b. The steps row of Phase 10 defines the shape once. Gate 2, the artifact's Implementation Plan item and the run report only name it. The artifact keeps the latest Plan run's line when it fits the shape and leaves it out otherwise, and the report says why it is absent. The full-level synthesis keeps the line in place of the file estimate. docs/commands.md documents the format and the reading rule. A guard pins the shape, its sample range swaps, the doc literal and the sites that must not name it, in all four plan builds, with known-bad probes. The four /plan size ceilings rise by the measured 542 bytes each, with no headroom. Part of #771.
The plan document step now takes the Implementation Plan without its Size forecast line, so no Code, Test or Evaluate agent reads the forecast as a limit. The four implement goldens copy that line byte for byte and change in this commit. The four implement ceilings rise by 33 bytes each to the measured size. A guard pins the strip in all four implement builds, with a removal probe. Part of #771
The planning synthesis template gives no Size forecast line when the steps report has none, so Synthesize does not make one up. A guard pins the slot as the last line of the Implementation Plan, with probes.
The shape was only in the steps row of the focus table, so the single Plan agent at standard and lean could lose it. It now sits in the Phase 10 instruction that each Plan prompt is built from, scoped to the agent that reports the steps, as one plain line right after them. Gate 2 shows the steps report's line only when it fits the shape, else its absence; the artifact keeps the one line Gate 2 showed (latest Plan run) and no other copy, or none. The guard pins the shape's location, counts the plain literal as well as the backticked span, and has one known-bad probe per new check. The four plan ceilings follow the measured sizes. Refs #771
The plan document step leaves the Size forecast line out of EXECUTION_PLAN, but Phase 2 named the whole plan document as setup context, and the Code spawns take their plan from setup context. The forecast could reach a Code agent as a budget. Setup context is now EXECUTION_PLAN, else the issue body or conversation. PR_DESCRIPTION_GUIDANCE and TEST_PLAN reach their readers through their own captures, so no Code agent loses an input. The plan-facts guard pins the new sentence once in all four implement builds, with one removal probe. The four implement goldens and ceilings move by 6 bytes each (41,855 / 39,993 / 43,904 / 42,042). The eight #771 ratchet descriptions now state the current rule: a value may move either way, and its description and the PR give the old value, the new value and the reason. The implement descriptions carry the new numbers. Task: resolve-batch-b
Owner
Author
Review and resolutionHead: 37fffcd. This comment is edited in place for each new head. Since 1f0368d: the changelog entry states the final ceiling raises (+690 and +39), from an independent intent check. ReviewThis change is prompt text, a format guard and byte ceilings. An independent two-lens audit replaced a full code review: one lens read the prompt text as an agent runs it, and one lens read the format test and the ratchets.
Resolution
Final byte growth: /plan +690 per build, /implement +39 per build. The PR body table gives each ceiling. Verification
|
dean0x
marked this pull request as ready for review
November 6, 2026 23:13
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
/plangives no size forecast, so the user does not see the expected scope of a change before/implementstarts. This change adds one plain, script-readable forecast line to the plan's Implementation Plan section, so the expected scope is visible before implementation begins.Changes
Size forecast: files a-b, added a-b, removed a-b, commits a-b./implementtakesEXECUTION_PLANas its setup context and leaves the line out of it, so no agent reads it as a limit.docs/commands.mddocuments the format and the reading rule. One guard pins it in every build: one shape, on the Phase 10 instruction line, with plain copies counted too.Breaking Changes
None expected.
Known Limits
/planand/implementprompts grow by the measured bytes. The ceilings rise, with the reason recorded below.Byte Ceilings
No safe cut exists: the Cancel line of Error Handling is a stop rule that is never cut, and the Closes rendering line is a pinned output contract. A ceiling may move either way; each description gives the old value, the new value and the reason.
Planning Notes
Testing
Related Issues
Closes #771