All 17 contract scenarios build synthetic fixture documents instead of copying and mutating the real, already-landed ones. #68

Open
opened 2026-08-25 13:57:47 +00:00 by jbr870 · 0 comments
Owner

Spawned from finding F-PO-43-4-15 (in-scope-deferrable) on issue #43 during decision D-PO-43-4-9.

Original scope note: make_claims_tree and its write_rrc_* helpers hand-author minimal fake versions of seven documents that already exist in the repo with real, much longer prose. None of the 17 scenarios copies-and-mutates the real files the way test-plugin-gates.sh's make_lint_copy does. This is the pattern CLAUDE.md calls the worst case — a fixture standing in for content the repo already holds — and it is exactly the shape that would miss a wrapped anchor in the REAL document, which is this feature's own recorded learning. Partly answered empirically this round: the driver's 20-mutation battery mutated the REAL documents and every check fired correctly with the specific message, so today's fixtures happen to encode the right assumptions. That is evidence about today, not about the design. The existing clean-tree control does run against the real tree, but that protection is coincidental to this design rather than provided by it — and per CR-4 it is one file-deletion from being defeated.

Disposition rationale: [CR-15] Converting 17 scenarios from hand-authored fixtures to copy-and-mutate of the real documents is substantial by inspection, and the recommender never folds substantial work. There is also no urgency: the driver's 20-mutation battery this round mutated the real documents directly and every check fired with its specific message, so the current fixtures demonstrably encode the right assumptions today. The issue is the design's fragility over time, which is exactly what a follow-up issue is for. Resolved under a standing instruction from the operator in this session — asked for /dev:resolve to be run and accepted all recommendations — so this follows the recommender's output rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.

This issue was deferred out of the parent feature's scope; it carries no PREQ yet. Run /dev:requirements --issue={new-number} to flesh it out before planning.

Spawned from finding `F-PO-43-4-15` (in-scope-deferrable) on issue #43 during decision D-PO-43-4-9. **Original scope note:** make_claims_tree and its write_rrc_* helpers hand-author minimal fake versions of seven documents that already exist in the repo with real, much longer prose. None of the 17 scenarios copies-and-mutates the real files the way test-plugin-gates.sh's make_lint_copy does. This is the pattern CLAUDE.md calls the worst case — a fixture standing in for content the repo already holds — and it is exactly the shape that would miss a wrapped anchor in the REAL document, which is this feature's own recorded learning. Partly answered empirically this round: the driver's 20-mutation battery mutated the REAL documents and every check fired correctly with the specific message, so today's fixtures happen to encode the right assumptions. That is evidence about today, not about the design. The existing clean-tree control does run against the real tree, but that protection is coincidental to this design rather than provided by it — and per CR-4 it is one file-deletion from being defeated. **Disposition rationale:** [CR-15] Converting 17 scenarios from hand-authored fixtures to copy-and-mutate of the real documents is substantial by inspection, and the recommender never folds substantial work. There is also no urgency: the driver's 20-mutation battery this round mutated the real documents directly and every check fired with its specific message, so the current fixtures demonstrably encode the right assumptions today. The issue is the design's fragility over time, which is exactly what a follow-up issue is for. Resolved under a standing instruction from the operator in this session — asked for /dev:resolve to be run and accepted all recommendations — so this follows the recommender's output rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category. This issue was deferred out of the parent feature's scope; it carries no PREQ yet. Run `/dev:requirements --issue={new-number}` to flesh it out before planning.
Sign in to join this conversation.
No description provided.