Repository navigation
v0.41 — 2026-09-15
A module-status budget that scales with the module, and compaction instead of a finding
module-status.md carried a flat ~250 words, which a large module cannot meet honestly and which said nothing about what to cut — so the file grew, /b-index reported it, and the report became a review finding routed to /b-feature, a gated command opened to delete a paragraph from an agent-owned file. Two rules replace the number: density (~30 words per ## Build order entry plus the integration and review lines) as an inspection heuristic, and the file's shape as the test of what may be removed. Content outside the shape is a candidate, not a verdict — known duplication or history is deleted, anything else is left in place and reported. Compaction happens in the pass where a command is already writing the file, takes no gate, and over-budget is never a finding. Shape, semantics and the list of compacting commands: _bower/framework-reference.md → Compaction.
_bower/framework-reference.md— module-status.md carries the density heuristic and a new Compaction block: the complete shape (including the headings and the optionalPending verification:line), candidate-not-verdict deletion semantics, the rule that nothing inside the shape is ever touched, which four commands compact and which writers do not, and over-budget-is-never-a-finding. The pull-forward annotation no longer cites a shared word ceiling._bower/framework.md— Document Authority row formodules/**/module-status.md.skills-src/commands/b-feature.md(Step 6.9),b-module.md(Step 5.10),b-integration.md(Step 5.1),b-review.md(closeout) — one clause each, pointing at the reference for the shape.skills-src/commands/b-index.md— reports shape violations as their own run-summary line; word count alone is not reportable. It still writes nothing.skills-src/agents/bower-reviewer.md,_bower/review-schema.md— document length is not a finding, in any dimension or class; a matching failure mode.skills-src/agents/bower-analyst.md— drops the~250 wordsaside._bower/roadmap.md— whether compaction belongs inline or in a subagent, with its revisit trigger.
Migration
Judgement. For each docs/modules/<module>/module-status.md in the project:
- Read the file. Its shape is three headings and the lines under them:
## Module integrationwith aTest:line, a one-lineNotes:line and — only while module-level manual checks are outstanding — aPending verification:line;## Build orderwith numbered entries, each a feature name, a status marker and optionally a pull-forward clause carryingRemaining:;## Module reviewwith aReview:line. - Delete what is outside that shape and is known duplication or history — a restatement of what a feature does, a copy of acceptance criteria, a table whose data is maintained in another document, narrative recounting how the module got here, a record of what a line used to say. Being a table or a paragraph does not qualify content: you must be able to name where its content is already kept, or that it describes the past. If you cannot, it goes to step 3. Do not summarise what you delete;
plan.md(feature behaviour),architecture.md## Software architecture(module purpose, boundary, dependencies) andstatus.md(verification) already hold their own copy. - Leave everything else outside the shape exactly as it is — content that says something no other document says, or that you cannot confidently classify. Do not move it to another document as part of this upgrade. List each one for the operator: the file, what the content is, and why you left it.
- Change nothing inside the shape. Not a marker, a feature name, a
Remaining:clause, aPending verification:line or theReview:line. Compaction removes prose; it never removes state.
Report per module: the file, its approximate word count before and after, and anything left in place under step 3. Nothing needs to be run afterwards — no markers changed, so docs/index.md is unaffected.