Development record
Three of the four reading positions receive a byte-identical item set. Comparing the manifests of a real assembly at one commit, widening, comparative and detection each carry the same 951 items with the same fields, and only entailment differs, by the 346 draft and planned items the drafts asymmetry admits. That asymmetry is itd-183's and it works exactly as designed. The other three do not. The definitions state four distinct objects: widening reads the brief, glossary, disciplines, specs and shipped tree; comparative reads the candidate set, which is the widening reading's pre-admission output, against the declared selection criteria; detection reads the shipped tree against the claim record. What the assembler actually passes at comparative and at detection is the widening object unchanged. The comparative case is the sharper one, because its object is not a subset of the repository at all but the output of a previous reading, and the assembler has no channel for it -- spc-64 says as much in passing, that the in-cycle candidate set arrives by whatever channel spc-61 defines and the eval makes no claim about it, but nothing states that the position therefore receives the wrong object. No criterion measures cross-position differentiation, and the evals run on a fixture too small for the difference to show.
Three of the four reading positions receive a byte-identical item set. Comparing the manifests of a real assembly at one commit, widening, comparative and detection each carry the same 951 items with the same fields, and only entailment differs, by the 346 draft and planned items the drafts asymmetry admits. That asymmetry is itd-183's and it works exactly as designed. The other three do not. The definitions state four distinct objects: widening reads the brief, glossary, disciplines, specs and shipped tree; comparative reads the candidate set, which is the widening reading's pre-admission output, against the declared selection criteria; detection reads the shipped tree against the claim record. What the assembler actually passes at comparative and at detection is the widening object unchanged. The comparative case is the sharper one, because its object is not a subset of the repository at all but the output of a previous reading, and the assembler has no channel for it -- spc-64 says as much in passing, that the in-cycle candidate set arrives by whatever channel spc-61 defines and the eval makes no claim about it, but nothing states that the position therefore receives the wrong object. No criterion measures cross-position differentiation, and the evals run on a fixture too small for the difference to show.
Grounds
- pursued: we expect one committed entry per position, carrying that position's own object set and kinds, to give each position an item set of its own, because the byte-identical sets came from one admission serving four near-identical rows; two positions whose pinned digests coincided again, or a digest that moved without a commit to the entry, would show it wrong.
Frontmatter
| id | iss-2608311501240566 |
|---|---|
| type | issue |
| lifecycle | resolved |
| severity | major |
.abcd/work/issues/resolved/iss-2608311501240566-three-of-the-four-reading-positions.md
open on GitHub ↗ · commit history ↗
mentions10
- adr-58A reading is commissioned about something, so the invocation takes a scope
- dcn-26090100000000012026-09-01 — Reading positions share one pile by default, and a position can be given its own (maintainer, ruling on iss-2608311501240566). Three of the four positions receive a byte-identical item set today although each is defined over a different object. The default stays one shared assembly, because the readers' definitions already tell each position what to attend to and a shared pile keeps the four readings comparable; a per-position include table is added as configuration so a position can be handed only its own object (the comparative position only the widening output, for instance) when a run needs it. Rejected: making per-position piles the default (four assemblies per run, and the comparability the closing run relies on is lost by default); waiting for a real run to show harm (the record already shows the definitions and the delivery disagree).
- dcn-26090200000000182026-09-02 — The per-position configuration the 2026-09-01 ruling asked for ("one shared pile by default, and a per-position include table as configuration when a run needs a position handed only its own object", recorded against iss-2608311501240566) is delivered by the per-position preset entry of the object-set ruling of this day, which carries each position's object set, kinds and window, applied with no operand. One configuration surface, not two: a per-position include-table section beside the preset entry would be a second answer to one question, and the change carrying it is reconciled to the preset entry or waits for the maintainer.
- itd-183The cold reading sees exactly what the assembler passes — positive inclusion, field projection, and a per-run manifest
- itd-196A capability is rehearsed end to end before it ships, over a real tree, in a throwaway snapshot
- itd-199A reading is about something narrower than everything, and its scope is a committed, adjustable choice
- itd-2609020625400445A committed preset declares the window it was calibrated for, and the record holds every preset to its declaration
- spc-61The cold-reading input assembler: positive inclusion at field granularity, a pathless bundle, and a hashed per-run manifest
- spc-64The read-block eval falsifies the firewall
- spc-2609020626048722One committed entry per position, in three parts: the object set, the kinds within it and the window it measures at, held by an eval that re-measures every entry on every committed change