All 17 contract scenarios build synthetic fixture documents instead of copying and mutating the real, already-landed ones. #68
Labels
No labels
component:adapters
component:lifecycle
component:qa
component:setup
component:shared
component:worktrees
phase/accepted
phase/backlog
phase/deployed
phase/developing
phase/integrating
phase/planning
phase/qa
phase/requirements
phase/uat
priority:critical
priority:critical
priority:high
priority:high
priority:low
priority:low
priority:medium
priority:medium
type:bug
type:chore
type:docs
type:feature
type:infra
type:tech-debt
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
jbr870/devwork-skills#68
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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.