Development record
2026-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).
2026-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).
Frontmatter
| id | dcn-2609010000000001 |
|---|---|
| type | decision |
| date | 2026-09-01 |
.abcd/work/decisions/dcn-2609010000000001-reading-positions-share-one-pile-by.md
open on GitHub ↗ · commit history ↗
mentions1
- iss-2608311501240566Three 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.