This repository was archived by the owner on Aug 8, 2026. It is now read-only.
Repository navigation
docs: close out the coverage handoff, and measure the lumber split rather than assume it - #28
Merged
Merged
Conversation
…ther than assume it STATUS LINE WAS MISSING A CORRECTION. It read "complete (PR #15), corrected same day (PR #17)". There was a third, PR #19 (7ff5d06), and it is the only one of the three that changed what the module says about ITSELF: the docstring table still claimed 058643 "dies at the price join" when drops_at returns extremity_z and price is 37 of 880 rather than 0. It also settled a contradiction a reader would hit head-on, since B18's "both fail at the SAME rung" is true of the terminal rung and false of drops_at, which is two rungs earlier for 058643. B30: THE RENAME TRAP HAS A MIRROR IMAGE. coverage keys on market_code, which kills the four phantoms (one code, several names). It does not handle one INSTRUMENT carrying several codes, and B26/B27 established after this handoff closed that the two unscoreable markets are the two halves of one migrated contract: 058643 and 058644 overlap in 7 weeks of 1051 and both carry symbol LBR. Nobody re-ran coverage afterwards. So: is "2 of 27 score nothing" real, or an artifact of the split? The suggestive number says artifact. Separately the codes hold 37 and 178 priced weeks; merged they hold 208 CONTIGUOUS priced weeks, twice the 104-week extremity window. Measured end to end, it is real: rung 058643 058644 merged price 37 178 208 extremity_z 0 75 96 illiquidity 0 75 92 crowding 0 0 0 damage_sell 0 0 0 Every rung rises substantially and the verdict does not move. C = pct(z) stacks a second three-year window on the 96 and 96 does not fill it. Lumber is unscoreable because it has four years of prices against a measure needing six, not because its code changed. The headline moves from "2 of 27" to "1 of 26" purely by counting one instrument once. Worth recording because the wrong answer survives one round of checking: merging only the per-category half also returns crowding=0, for the unrelated reason that build() still reads the unmerged store and every per-market rung reports 058644 alone. Two routes to the same number, one meaningless. No code change. Teaching coverage to merge would change the row count and no conclusion, and this handoff's own Scope puts thresholds out of bounds. ALSO FIXED, a breakage I caused. Merging cotdata#93 deleted the function reproduce.py's flow_equivalence block calls, so B29's figures had a reproducer that raised AttributeError. It now detects the removal and prints the figures as historical with the reason, matching what test_flow_equivalence.py already does. A reproducer that crashes once the change it recommended lands reads as a broken measurement rather than a completed one. 433 passed, ruff clean, prior reproducer output byte-identical. The handoff body is preserved verbatim; only the Status line was replaced. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Closes out
docs/handoffs/2026-08-02-coverage-reporting.md. The body is preserved verbatim; only theStatus:line is replaced, per the append-only rule.1. The status line was missing a correction
It read
complete (PR #15), corrected same day (PR #17). There was a third, PR #19 (7ff5d06), and it is the only one of the three that changed what the module says about itself: the docstring table still claimed058643"dies at the price join", whendrops_atreturnsextremity_zandpriceis 37 of 880 rather than 0.It also settled a contradiction a reader would otherwise hit head-on. §B18 says the two lumber codes "fail at the SAME rung" — true of the terminal rung, false of
drops_at, which is two rungs earlier for058643.2. §B30: the rename trap has a mirror image
coveragekeys onmarket_code, which kills the four phantoms (one code, several names). It does not handle the opposite shape, and nothing had checked:coverage, by keying on the codecontinuity,merge_migrated_codes, notcoverage§B26 and §B27 established after this handoff closed that the two unscoreable markets are the two halves of one migrated contract:
058643and058644overlap in 7 weeks of 1051 and both carry contract symbolLBR. Nobody re-ran the coverage report afterwards.So is "2 of 27 score nothing" real, or an artifact of the split? The suggestive number says artifact: separately the codes hold 37 and 178 priced weeks, but merged they hold 208 contiguous priced weeks, twice the 104-week extremity window.
Measured end to end, it is real:
058643058644priceextremity_zilliquiditycrowdingdamage_sellnon-nullEvery rung rises substantially and the verdict does not move.
C = pct(z)stacks a second three-year window on the 96 z values and 96 does not fill it. Lumber is unscoreable because it has four years of prices against a measure needing six, not because its code changed. The headline moves from "2 of 27" to "1 of 26" purely by counting one instrument once.Recorded because the wrong answer survives one round of checking: merging only the per-category half also returns
crowding=0, for the unrelated reason thatbuild()still reads the unmerged store and every per-market rung reports058644alone. Two routes to the same number, one of them meaningless.This also vindicates §B18 on the point it was least sure of:
coverageand the PCA disagreeing about lumber "is correct rather than a contradiction". That was an argument; this is the measurement behind it.No code change follows. Teaching
coverageto merge migrated codes would change the report's row count and no conclusion in it, and this handoff's own Scope puts "changing any window, minimum or threshold" out of bounds. It is a build item for whoever wants it, now backed by a measurement of what it would and would not buy.3. Fixed a breakage I caused
Merging cotdata#93 deleted the function
reproduce.py'sflow_equivalenceblock calls, so §B29's figures had a reproducer that raisedAttributeError. Found by running the full reproducer rather than only the new block.It now detects the removal and prints the figures as historical with the reason, matching what
test_flow_equivalence.pyalready does. A reproducer that crashes once the change it recommended lands reads as a broken measurement rather than a completed one.Both flagged decisions stand
The two decisions the handoff refused to default are unchanged four PRs later: a zero-scoring market still stays in the panel, and
LADDERis still a hand-written list guarded bytest_the_ladder_covers_every_column_the_composite_consumes. That guard has earned its place since: §B18 found the ladder skipping three rungs, and the test now checks the columnsadd_compositecomputes, not only those it emits.Checks
ruffcleanlumber_is_one_instrumentblock is additiveStatus:replaced🤖 Generated with Claude Code