docs(phase-4): add <action> blocks to checkpoint tasks for structure validation

.planning/phases/04-adaptive-specialty-engines-spike-first/04-01-PLAN.md

@@ -286,6 +286,11 @@ class OmniVoiceGGUFBackend(TTSBackend):
     - Flip "Status:" from "Proposed (research-supported)" to "Accepted" (or "Accepted with reduced scope" per the macOS call above).
     - Under "Consequences" append a "Verified on:" line listing the date, the 3 hardware classes tested, and the human reviewer initials.
   </how-to-verify>
+  <action>Human-verification checkpoint — pause execution and surface the resume-signal prompt to the user. The human reviewer (1) runs `scripts/smoke-gguf.sh` across the three hardware classes (CPU-only Linux, 8 GB VRAM mid-tier, 16+ GB VRAM high-tier) plus a macOS Apple Silicon box, listens to each output WAV, and confirms intelligibility + quant selection matches `quant_map.json`; (2) opens `https://github.com/ServeurpersoCom/omnivoice.cpp/commit/<runtime_commit_sha>` in a browser and skims the diff for unreviewed network code, debug/wip markers, or unexpected deps, then cross-checks `bin/checksums.sha256` against the binary shipped from Task 2; (3) makes the macOS Metal GO/NO-GO call based on whether Task 2's `macos-14` CI slot produced a working `bin/omnivoice-tts-darwin-arm64` (GO = GGUF default on Apple Silicon; NO-GO = fall back to in-process `OmniVoiceBackend` per Pitfall 1 mitigation); (4) edits `.planning/decisions/SPIKE-01-gguf.md` to flip the "Status:" line from "Proposed (research-supported)" to either "Accepted" or "Accepted with reduced scope: macOS Apple Silicon falls back to in-process OmniVoiceBackend per Pitfall 1" and appends a "Verified on:" line under "Consequences" with the date, the 3 hardware classes tested, and reviewer initials. No automated action; the executor MUST stop and wait for the resume-signal before proceeding to plan 04-02.</action>
+  <verify>
+    <human-check>Reviewer confirms intelligible output on all 3 hardware classes (or documents regression), confirms omnivoice.cpp pinned-commit review passed (or files concerns), states macOS Metal GO or NO-GO, and the SPIKE-01 ADR "Status:" line is updated accordingly with a "Verified on:" stamp.</human-check>
+  </verify>
+  <done>SPIKE-01 ADR "Status:" is "Accepted" or "Accepted with reduced scope" with the "Verified on:" line filled. `bin/checksums.sha256` matches the binary shipped. The macOS default engine is recorded (GGUF or in-process fallback). Resume-signal "approved" received.</done>
   <resume-signal>Type "approved" to flip the ADR to Accepted and proceed to plan 04-02 (Singing). If the cross-hardware smoke produces audibly-worse-than-baseline output on any class, type "regression" and describe which class — the executor will revise `quant_map.json` thresholds before proceeding. If the omnivoice.cpp commit review surfaces concerns, type "block" with details.</resume-signal>
 </task>
 

.planning/phases/04-adaptive-specialty-engines-spike-first/04-02-PLAN.md

@@ -182,6 +182,12 @@ def detect_singing_segments(
       <cons>Mixed-content dubs need the user to split source manually; SING-03 heuristic ships as a standalone utility rather than wired in; SING-02 acceptance line "vocal-isolation output routes through the singing engine while instrumental stem is preserved" is met but per-segment intelligence is descoped.</cons>
     </option>
   </options>
+  <files>backend/services/dub_pipeline.py, .planning/decisions/SPIKE-02-singing.md</files>
+  <action>Decision checkpoint — pause execution and surface the resume-signal prompt to the user. The human decision-maker (1) reads `backend/services/dub_pipeline.py` end-to-end (or the equivalent dub orchestration module — search for `demucs`, `vocal_stem`, and `tts_backend` references if the path has moved) and identifies the three landmarks listed in `<context>` above (Demucs invocation + stem split, vocal-stem-to-TTS handoff loop structure, final-mix reassembly); (2) sizes the LOC budget for option-a (per-segment routing) vs option-b (whole-job toggle) based on the current loop structure; (3) selects option-a or option-b; (4) records the decision plus a 2-3 sentence rationale in `.planning/decisions/SPIKE-02-singing.md` under the "Decision:" line (e.g., "SING-02 scope: option-a per-segment routing — dub_pipeline.py already loops over Demucs-segmented chunks at line N, ≤50 LOC change to route by kind"). No automated action; the executor MUST stop and wait for the resume-signal before sizing Task 2.</action>
+  <verify>
+    <human-check>Decision-maker reports "option-a" or "option-b" (or "block" if a third option surfaces). The SPIKE-02 ADR's "Decision:" line records the choice plus rationale referencing specific line numbers / structures in `dub_pipeline.py`.</human-check>
+  </verify>
+  <done>Resume-signal "option-a" or "option-b" received and recorded in `.planning/decisions/SPIKE-02-singing.md`. Task 2's `<action>` block is interpreted against the chosen option.</done>
   <resume-signal>Select: option-a or option-b. Record the decision in `.planning/decisions/SPIKE-02-singing.md` under "Decision:" and update the next task's action block accordingly. If the code-read surfaces a third option (e.g., dub_pipeline.py needs a larger refactor than either option assumes), type "block" with details.</resume-signal>
 </task>
 
@@ -261,6 +267,11 @@ def detect_singing_segments(
        - Append under "Consequences" a "Verified on:" line: date, clip duration, segment count + speech/sing breakdown, reviewer initials, and a one-line verdict ("intelligible across spoken+sung; consistent voice identity; instrumental preserved").
        - If cross-language singing was tested and produced lower quality, note it under "Negative / risk" as confirmed empirically.
   </how-to-verify>
+  <action>Human-verification checkpoint — pause execution and surface the resume-signal prompt to the user. The human reviewer (1) supplies or creates `tests/fixtures/mixed-30s.wav` (≈15s speech + ≈15s singing, same speaker if possible); (2) runs `scripts/smoke-singing.sh tests/fixtures/mixed-30s.wav` and listens to `tmp/smoke-singing-out.wav` end-to-end; (3) verifies the four acceptance criteria — spoken segments render as intelligible speech, sung segments render as melodic singing (NOT speech-like — the Pitfall 4 regression signal), voice identity stays consistent across both segment types, and the Demucs instrumental stem is preserved bit-identically in the final mix (A/B against the Demucs output); (4) verifies the license gate by clearing `singing_license_accepted`, attempting a dub, confirming the block + acceptance prompt, accepting, and confirming the gate is sticky; (5) if option-a was chosen in Task 1, exercises per-segment override by flipping one auto-detected segment kind in the dub-job UI and confirming the re-run routes that segment differently; (6) edits `.planning/decisions/SPIKE-02-singing.md` to flip the "Status:" line from "Proposed (research-supported)" to "Accepted" (or "Accepted with reduced scope: per-segment routing deferred to v0.4" for option-b, or "Accepted (native-language only)" if cross-language was the only failure mode) and appends a "Verified on:" line under "Consequences" with date, clip duration, segment count + speech/sing breakdown, reviewer initials, and the one-line verdict. No automated action; the executor MUST stop and wait for the resume-signal before treating SPIKE-02 as ratified.</action>
+  <verify>
+    <human-check>Reviewer confirms intelligible speech + melodic singing + consistent voice identity + bit-identical instrumental stem on the 30-second mixed clip, license gate blocks until accepted, per-segment override works (option-a) or `scripts/detect-singing.py` runs cleanly (option-b), and the SPIKE-02 ADR "Status:" line is updated with a "Verified on:" stamp.</human-check>
+  </verify>
+  <done>SPIKE-02 ADR "Status:" is "Accepted" or "Accepted with reduced scope" with the "Verified on:" line filled including segment breakdown + verdict. The 30-second smoke produced acceptable output on all 4 acceptance criteria. License gate verified. Resume-signal "approved" (or "approved-native-only") received.</done>
   <resume-signal>Type "approved" to flip the ADR to Accepted. If the singing engine produces speech-like output (Pitfall 4 — tag injection broken) or the instrumental stem is altered, type "regression" with details. If cross-language singing quality is the only failure, type "approved-native-only" — the executor records the reduced scope in the ADR and the smoke is considered passing for the native-language acceptance bar.</resume-signal>
 </task>