Scheduled subtraction: make the minimalism pass a cycle, not a reaction #194

New issue

Closed

opened 2026-08-16 15:41:14 +00:00 by john · 1 comment

john commented

2026-08-16 15:41:14 +00:00

Owner

The problem

The best releases in this project were subtractions, and every one of them was
reactive.

The record is unambiguous:

v2.2.0 deleted the git-guard parser and git.on_destructive, both rails onto
one ~30-line anchored reader, with the accepted-cost shapes stated (TOK-02).
v3.2.0 turned off or deleted three triggers that blocked nothing, and scoped
risk_surface to the surfaces a project actually has (CST-01, CST-02).
v3.2.0 also deleted the audit's low-severity tail rather than carrying it
(HYG-01).
v3.5.1 deleted the login-matching surface after it FAILed its blocking gate
twice (TRK-01).

Every one of those started as a failure, a cost complaint or a review FAIL.
None started as a scheduled question.

Meanwhile the surface keeps growing: 29 skills, 19 rung agents, references that
cite references, and a self-verify pass that exists because no human can hold the
whole thing in their head anymore. Self-verify is a good control and it is also
the symptom.

The proposal

Make subtraction a cycle rather than a reaction. Once per milestone, before any
new work is scoped, one pass that asks of every surface:

What fires this, and how often? trace.jsonl can answer for anything routed.
What did it catch? If a gate has never changed an outcome, it is prose.
What is its resident byte cost? weight.mjs resident already answers.
If it were deleted, what would silently break, and is that cost statable?

/cad-minimalism-review already exists and produces a ranked delete-list. The
change is not a new command, it is making the pass MANDATORY at a fixed point in
the milestone rhythm, with its output going to the tracker whether or not
anything is cut.

Why it is a philosophy change

Right now growth is the default and subtraction needs a justification. This
inverts it: each milestone, every surface has to re-earn its place, and the
burden of proof sits with keeping rather than cutting.

The obvious objection

A mandatory pass is itself ceremony, which is the thing it exists to fight. The
answer is that it should be cheap and evidence-driven, reading figures the trace
already carries rather than re-reading the tree. If it turns into a review, it
has become the disease.

## The problem The best releases in this project were subtractions, and every one of them was reactive. The record is unambiguous: - `v2.2.0` deleted the git-guard parser and `git.on_destructive`, both rails onto one ~30-line anchored reader, with the accepted-cost shapes stated (TOK-02). - `v3.2.0` turned off or deleted three triggers that blocked nothing, and scoped `risk_surface` to the surfaces a project actually has (CST-01, CST-02). - `v3.2.0` also deleted the audit's low-severity tail rather than carrying it (HYG-01). - `v3.5.1` deleted the login-matching surface after it FAILed its blocking gate twice (TRK-01). Every one of those started as a failure, a cost complaint or a review FAIL. None started as a scheduled question. Meanwhile the surface keeps growing: 29 skills, 19 rung agents, references that cite references, and a self-verify pass that exists because no human can hold the whole thing in their head anymore. Self-verify is a good control and it is also the symptom. ## The proposal Make subtraction a cycle rather than a reaction. Once per milestone, before any new work is scoped, one pass that asks of every surface: - What fires this, and how often? `trace.jsonl` can answer for anything routed. - What did it catch? If a gate has never changed an outcome, it is prose. - What is its resident byte cost? `weight.mjs resident` already answers. - If it were deleted, what would silently break, and is that cost statable? `/cad-minimalism-review` already exists and produces a ranked delete-list. The change is not a new command, it is making the pass MANDATORY at a fixed point in the milestone rhythm, with its output going to the tracker whether or not anything is cut. ## Why it is a philosophy change Right now growth is the default and subtraction needs a justification. This inverts it: each milestone, every surface has to re-earn its place, and the burden of proof sits with keeping rather than cutting. ## The obvious objection A mandatory pass is itself ceremony, which is the thing it exists to fight. The answer is that it should be cheap and evidence-driven, reading figures the trace already carries rather than re-reading the tree. If it turns into a review, it has become the disease.

john added the

needs-decision

proposal

labels

2026-08-16 15:41:14 +00:00

john commented

2026-08-18 00:29:33 +00:00

Author

Owner

Closing as adopted-as-practice, not as a feature. The pass was run manually on 2026-08-17 over the five open needs-decision issues - what fires this, what did it catch, is it prose - and it retired three of them (#191, #194, #197) and shrank a fourth (#189). That is the proposal working. Building it as a scheduled ceremony would add a step to a system whose own stated complaint is that it has too many steps, and the pass costs nothing as a habit at milestone open. The diagnosis stands and is worth re-reading before each milestone is scoped; it does not need code.

Closing as adopted-as-practice, not as a feature. The pass was run manually on 2026-08-17 over the five open `needs-decision` issues - what fires this, what did it catch, is it prose - and it retired three of them (#191, #194, #197) and shrank a fourth (#189). That is the proposal working. Building it as a scheduled ceremony would add a step to a system whose own stated complaint is that it has too many steps, and the pass costs nothing as a habit at milestone open. The diagnosis stands and is worth re-reading before each milestone is scoped; it does not need code.

john closed this issue

2026-08-18 00:29:36 +00:00