diff options
Diffstat (limited to 'working/context-engineering-rightsizing/metrics.org')
| -rw-r--r-- | working/context-engineering-rightsizing/metrics.org | 54 |
1 files changed, 49 insertions, 5 deletions
diff --git a/working/context-engineering-rightsizing/metrics.org b/working/context-engineering-rightsizing/metrics.org index 9cced4b..e7ff189 100644 --- a/working/context-engineering-rightsizing/metrics.org +++ b/working/context-engineering-rightsizing/metrics.org @@ -41,13 +41,36 @@ an afternoon instead of a week. *** T2 — Progressive disclosure preserves behavior (context-engineering post) -*Claim.* Moving guidance out of always-loaded context into on-demand skills +*Claim.* Moving guidance out of always-loaded context into on-demand loading doesn't degrade adherence. -*Test.* The Phase 1 pilot. Detailed in Part 2. +*ANSWERED 2026-07-27 for the deterministic half.* =/context= in a live work +session lists 17 generic rules under Memory files, with the three path-scoped +ones absent. Path-scoping is a glob match rather than a model judgment, so it +either fires or doesn't, and it fires. That half needs no trial and no miss-rate +metric. -*Metric.* Miss rate per exposure. Mechanical, since four of the six pilot rules -have a checker. +*Still open for the semantic half.* Rules whose condition can't be a glob +("when a commit is in play") route to skills, where triggering *is* a model +judgment. Everything in Part 2 applies there and only there. + +*A caution the answer doesn't cover.* Path-scoping fires when Claude *reads* a +matching file. A session that writes an org file without reading one first +never triggers =todo-format.md=. Edit requires a prior read, so edits to +existing files are safe; creating a new org file from scratch is the gap. Worth +watching rather than blocking on. + +*** T3a — The token baseline was wrong by 45% [SETTLED] + +Word counts converted at a guessed ~1.3 tokens per word. The live number is +2.28. =commits.md= is 12,800 tokens, not the ~7,000 estimated, and +=claude-rules/= was ~57,800 tokens per session before today rather than the +~33,000 implied. + +The lesson is narrower than "measure better." I had a real measurement +available the whole time — =/context= reports per-file token counts — and used +an estimate instead because the estimate was easier to compute from inside the +repo. Reach for the instrument that reports the actual quantity. *** T3 — Deliverables run long without explicit calibration (Opus 5 guide) @@ -63,7 +86,13 @@ call on whether anything useful was lost, which is the part I can't measure. *Baseline worth taking now,* since it costs one command and the before-number disappears the moment we change anything. -*** T4 — Lower effort holds quality on mechanical passes (Opus 5 guide) +*** T4 — Lower effort holds quality [WITHDRAWN 2026-07-27] + +Dropped with P4. The goal is output quality first, and this claim trades +quality for cost, so testing it would answer a question we've decided not to +act on either way. + +*** T4 (original text, retained for the record) *Claim.* =low= and =medium= produce strong quality at a fraction of the tokens. @@ -212,6 +241,21 @@ Cheap now, impossible to reconstruct later: Item 1 is done. The rest are one session's work and should happen before Phase 0 changes the review skill, since that change contaminates item 4. +* Instrument reliability — the day's second lesson + +The plan weights mechanical detectors over self-report because they have no +stake. Two failed on 2026-07-27, both reporting success while doing damage: +=wrap-org-table.el= reflowed a table into a worse shape and =lint-org= then +certified it clean, and the wrap-teardown hook consumed a two-hour-old sentinel +and killed a live work session that had done nothing wrong. + +Neither invalidates the preference for mechanical detectors, which is still +right. Both narrow the claim: a detector has no stake, but it can be +confidently wrong, and a green check from a guard that never looked at the +thing is indistinguishable from a green check that did. When a detector clears +a moved rule, the useful question is whether it actually evaluated it, not just +whether it reported clean. + * What this can and cannot tell us It can tell us whether on-demand loading fires reliably here, whether |
