CLAUDE.md's Verification section says 'There is no unit suite' while nine shell test suites exist and pass #106

New issue

Open

opened 2026-08-25 14:59:53 +00:00 by jbr870 · 1 comment

jbr870 commented

2026-08-25 14:59:53 +00:00

Owner

Spawned from finding F-PO-47-2-13 (in-scope-deferrable) on issue #47 during decision D-PO-47-2-13.

Original scope note: Found while confirming lane executability, not raised by the panel — plugin/skills/_shared/procedures/test/*.sh (8 suites) and the adapter test/ trees exist and run, and release-flow.sh passes green offline. CLAUDE.md's Verification block names only scripts/lint-conventions.sh and states there is no unit suite, so a reader routing coverage from the project declaration alone would conclude the integration-covered lane has no executor here — the precise misreading that produces a false human-uat lane assignment. Documentation drift in the project's own declaration, outside this feature's file set and belonging to the meta lane. Proposing defer-to-issue.

Disposition rationale: This is checkable and currently wrong: CLAUDE.md's Verification block names only scripts/lint-conventions.sh and states there is no unit suite, while plugin/skills/_shared/procedures/test/ holds eight suites and the adapter test/ trees hold more — release-flow.sh was run during this planning phase and passes green offline. The drift is not cosmetic: 2.6b routes coverage by asking which executors exist in this environment, and a reader taking the project's own declaration at face value would conclude the integration-covered lane has no executor and route mechanically-checkable criteria to human-uat. That is the false-lane facade 2.6b exists to prevent, produced by the project's own documentation. It sits outside this feature's file set and belongs to the meta lane, so it cannot be fixed here. No eligible candidate covers CLAUDE.md accuracy, so this spawns rather than folds. Resolved autonomously under the operator's explicit instruction in this session to resolve every decision with its recommended option.

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-47-2-13` (in-scope-deferrable) on issue #47 during decision D-PO-47-2-13. **Original scope note:** Found while confirming lane executability, not raised by the panel — plugin/skills/_shared/procedures/test/*.sh (8 suites) and the adapter test/ trees exist and run, and release-flow.sh passes green offline. CLAUDE.md's Verification block names only scripts/lint-conventions.sh and states there is no unit suite, so a reader routing coverage from the project declaration alone would conclude the integration-covered lane has no executor here — the precise misreading that produces a false human-uat lane assignment. Documentation drift in the project's own declaration, outside this feature's file set and belonging to the meta lane. Proposing defer-to-issue. **Disposition rationale:** This is checkable and currently wrong: CLAUDE.md's Verification block names only scripts/lint-conventions.sh and states there is no unit suite, while plugin/skills/_shared/procedures/test/ holds eight suites and the adapter test/ trees hold more — release-flow.sh was run during this planning phase and passes green offline. The drift is not cosmetic: 2.6b routes coverage by asking which executors exist in this environment, and a reader taking the project's own declaration at face value would conclude the integration-covered lane has no executor and route mechanically-checkable criteria to human-uat. That is the false-lane facade 2.6b exists to prevent, produced by the project's own documentation. It sits outside this feature's file set and belongs to the meta lane, so it cannot be fixed here. No eligible candidate covers CLAUDE.md accuracy, so this spawns rather than folds. Resolved autonomously under the operator's explicit instruction in this session to resolve every decision with its recommended option. 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.

jbr870 added the

type:docs

priority:low

phase/backlog

labels

2026-08-25 14:59:53 +00:00

jbr870 referenced this issue

2026-08-25 14:59:54 +00:00

release-pipeline-status.sh --ref returns a stale pipeline — a false green immediately before a production tag #47

jbr870 commented

2026-08-31 12:16:01 +00:00

Author

Owner

{"status":"active","from_issue":"47","finding_ref":"F-PO-47-5-4","decision":"D-PO-47-5-1","category":"in-scope-deferrable","summary":"[code CR-6] The transferable finding: 'emitted by a skill' is not the same as 'not executable', and getting that wrong cost this feature two serious regressions","original_scope_note":"QA on #47 twice classified promote/SKILL.md findings as having no executable lane, on the grounds that no harness in this suite executes skill markdown. That is true of the surrounding prose and FALSE of the shell it emits: the pipeline-wait loop is written to a file and run with bash, so it can be extracted from its fence and driven with a stubbed helper, and a documented sequence of helper calls can be driven the same way. Both times a reviewer disproved the classification in minutes by doing exactly that. The cost was measured, not hypothetical: round 1 fixed 14 findings in that file and introduced 2 including a Critical (a guard made every capability-boundary answer unreachable, which would have made every release of this repo escalate instead of tagging); the sweep fixed those and introduced 5 more including a High (two individually-correct fixes interacting to kill the whole branch-pr path on local-fs). Once an executable lane existed the next round found 1 Medium and the one after found nothing in the product code. Two worked examples now exist in-repo: pipeline-identity.sh's wait-loop section (13 assertions driving the extracted fence) and promote-flow.sh (48 assertions over the orchestration seams).","disposition_rationale":"Folded here rather than spawned fresh because #106 is the same defect in the same document. #106 was itself spawned from #47 at technical-plan (D-PO-47-2-13) because CLAUDE.md's Verification section says 'There is no unit suite' while nine shell suites exist and pass, and its scope note already predicts the consequence: 'a reader routing coverage from the project declaration alone would conclude the integration-covered lane has no executor here'. This finding is that prediction coming true twice inside one feature, with a Critical and a High attached. What #106 should now say is the general rule, not just a corrected list of suites: 'emitted by a skill' is not the same as 'not executable' — a fence written to a file and run with bash, and a documented sequence of helper calls, are both testable by extract-and-drive; only the prose around them is not. NOTE FOR TRIAGE: #106 currently carries priority:low and type:docs. That was reasonable when it read as an out-of-date list; this finding is the argument that it is worth more, since the misclassification it describes cost two serious regressions in the feature that spawned it. Re-triage rather than treating this fold as routine backlog."}

```json {"status":"active","from_issue":"47","finding_ref":"F-PO-47-5-4","decision":"D-PO-47-5-1","category":"in-scope-deferrable","summary":"[code CR-6] The transferable finding: 'emitted by a skill' is not the same as 'not executable', and getting that wrong cost this feature two serious regressions","original_scope_note":"QA on #47 twice classified promote/SKILL.md findings as having no executable lane, on the grounds that no harness in this suite executes skill markdown. That is true of the surrounding prose and FALSE of the shell it emits: the pipeline-wait loop is written to a file and run with bash, so it can be extracted from its fence and driven with a stubbed helper, and a documented sequence of helper calls can be driven the same way. Both times a reviewer disproved the classification in minutes by doing exactly that. The cost was measured, not hypothetical: round 1 fixed 14 findings in that file and introduced 2 including a Critical (a guard made every capability-boundary answer unreachable, which would have made every release of this repo escalate instead of tagging); the sweep fixed those and introduced 5 more including a High (two individually-correct fixes interacting to kill the whole branch-pr path on local-fs). Once an executable lane existed the next round found 1 Medium and the one after found nothing in the product code. Two worked examples now exist in-repo: pipeline-identity.sh's wait-loop section (13 assertions driving the extracted fence) and promote-flow.sh (48 assertions over the orchestration seams).","disposition_rationale":"Folded here rather than spawned fresh because #106 is the same defect in the same document. #106 was itself spawned from #47 at technical-plan (D-PO-47-2-13) because CLAUDE.md's Verification section says 'There is no unit suite' while nine shell suites exist and pass, and its scope note already predicts the consequence: 'a reader routing coverage from the project declaration alone would conclude the integration-covered lane has no executor here'. This finding is that prediction coming true twice inside one feature, with a Critical and a High attached. What #106 should now say is the general rule, not just a corrected list of suites: 'emitted by a skill' is not the same as 'not executable' — a fence written to a file and run with bash, and a documented sequence of helper calls, are both testable by extract-and-drive; only the prose around them is not. NOTE FOR TRIAGE: #106 currently carries priority:low and type:docs. That was reasonable when it read as an out-of-date list; this finding is the argument that it is worth more, since the misclassification it describes cost two serious regressions in the feature that spawned it. Re-triage rather than treating this fold as routine backlog."} ```

jbr870 referenced this issue

2026-08-31 12:16:06 +00:00

release-pipeline-status.sh --ref returns a stale pipeline — a false green immediately before a production tag #47

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

jbr870/devwork-skills#106

No description provided.

Rows
Columns