re: finish the --help audit -- a stale percentage and a missing noun, both shipped

The METHOD entry I wrote an hour ago says to read your tool's own --help as if a
stranger wrote it. I had done that for ONE of sixteen leaf commands, which is the
"a rule written down is not a rule applied" failure this corpus already records
twice. Finished it across the whole surface.

One survivor, and it fails in two ways at once. `screen render --settle` said a
narrow window means the bundle never settles, "(42 % of them, mostly loop*
fragments)".

MISSING NOUN: inside `screen render`, "them" reads as the builds you would render.
The 42 % is over composable bundles -- a different and much larger set including
~1 700 two-element fragments a user of that flag never renders. ui-settle-time.md
states its population precisely; the help inherited the number without it.

STALE: recomputed under the corrected reader, the composable figure is 862/2211 =
39 %, not 731/1758 = 42 %. The POPULATION GREW BY 453, which is the keyframe
record-layout fix's signature -- it times a group's final pose, so bundles that
previously showed one timed keyframe now show two and qualify. Third consequence
of that fix not being swept, after fade_quads.py and screen-transitions.md's
0.87-4.08 s fade-in.

And the share a --settle user actually faces is 38 %: 185 of 491 screen builds.

Corrected in the help text with all three numbers and their populations, and in
ui-settle-time.md, whose three-row table is marked pre-fix and superseded rather
than edited in place. Verified by artifact -- the tool's --help output is quoted,
not merely recompiled.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
This commit is contained in:
sylph-decoder
2026-08-30 17:45:43 +00:00
parent 0d1e0ae8b7
commit 22846bf30e
4 changed files with 97 additions and 4 deletions

View File

@@ -127,7 +127,25 @@ Of the **1 758** composable bundles carrying two or more keyframe times:
| settle window < 10 units | 731 | 42 % |
| mean window | 49 units | — |
The 42 % are mostly `loop*` animation fragments, which are **meant** to be in
🔴 **These three rows are PRE-FIX and are superseded (2026-08-30).** They were
computed before the keyframe record-layout fix, which times a group's **final**
pose — so bundles that previously showed one timed keyframe now show two and enter
the population. Recomputed under the corrected reader
([`data/settle-narrow-rate.txt`](../data/settle-narrow-rate.txt)):
| population, ≥2 keyframe times | n | narrow (<10 u) | share |
|---|---|---|---|
| **screen builds** (`is_build` — what `screen render` renders) | 491 | 185 | **38 %** |
| composable bundles (`is_composable` — what `--all` admits) | **2 211** | 862 | **39 %** |
| *the pre-fix figures above* | *1 758* | *731* | *42 %* |
⚠️ The **population grew by 453**, which is the fix's signature and the reason the
share moved. And the share a user of `--settle` actually faces is **38 %**, over
screen builds — not 42 % over a wider set that includes ~1 700 fragments they will
never render. The tool's own help said "42 % of them" without saying of *what*;
corrected there too.
The narrow ones are mostly `loop*` animation fragments, which are **meant** to be in
motion and have no settled pose to find. **Check the window width before trusting
the midpoint.** A narrow window is the data saying "this bundle never settles",
not a settle time with a small error bar.