[bmad adapter] Derive AC verification markers (vitest:/artifact:) at scan time so source-story ACs are mechanically verifiable

[jackmcintyre]

Summary

BMad source stories are authored without vitest: / artifact: markers on their acceptance criteria, and those source stories are gitignored and live outside the dev's isolated worktree — so the dev physically cannot add the markers from inside the build. At review time runReviewerSession therefore returns manual-check-required for every AC, and the run pauses for a human decision even though the underlying code is correct and fully tested. This is systemic, not a one-off.

Tool area

bmad adapter / source-story scan-time AC marker derivation (scanSources) + BMad planning template

What happens

1. A BMad story is planned/authored. Its acceptance criteria carry no vitest: ./tests/<file>.test.ts or artifact: verification markers — the BMad authoring template does not emit them.
2. scanSources projects the source story into an execution manifest, carrying the un-marked ACs verbatim.
3. The dev runs in an isolated git worktree. The source story is gitignored and lives on the main thread, outside that worktree, so the dev has no way to edit it and add markers.
4. The reviewer calls runReviewerSession, which runs each AC through the applicability classifier. With no marker, every AC resolves to manual-check-required.
5. Because the verdict cannot reach READY FOR MERGE mechanically, the run pauses with a needs-human decision — despite the code being correct and the tests being green.

Current (manual-only) workaround

The operator must, on the main thread, hand-edit the source story to add a marker under each AC:

vitest: ./tests/<file>.test.ts

(the ./ prefix is required), then re-run the reviewer. This is the only remedy today.

Evidence (systemic, not one-off)

This recurred 5× across Epic 1:

• Story 1.3
• Story 1.4
• Story 1.6
• Story 1.7
• Story 1.8

All filed under failure_class: ac-verification-marker-gap. Five recurrences on consecutive stories confirm the gap is in the tool, not the work.

Impact

• Every BMad-sourced story stalls the unattended run on a marker-only gap, defeating the run's purpose (walk-away delivery).
• Forces operator intervention on stories that are otherwise correct and fully tested.
• The workaround is operator-only: the BMad planning template is plugin-owned, and Flow's bmad adapter does not derive AC markers at scan time — so neither side can be fixed in-repo by the user.

Suggested direction

Pick one (or both):

1. Adapter-side (preferred): Have Flow's bmad adapter derive vitest: / artifact: markers for each AC at scanSources time — e.g. infer the test file from the story's cited test-file references / files-touched, and stamp the marker onto the projected manifest AC. This fixes every existing and future story without touching the template.
2. Template-side: Update the plugin-owned BMad planning/authoring template to emit a vitest: marker on every AC by default, so source-story ACs are mechanically verifiable from the start.

Either way, the property we want is: a source-story AC is mechanically verifiable from the moment it is scanned, and the run never stalls on a marker-only gap.

Context

• Trigger: retro-analyst / cycle-end retro
• Raised: 2026-06-27 (finding id 01KW5KGC0J5G0AAG61898ACTRF)
• Cycle: surfaced during the Epic 1 cycle-end retro after stories 1.3–1.8