feat(implementation): dispatch phase Review: tags to /review:quality-gate at phase boundaries #8331

Parent

Refs #8326 · Source: PLAN Phase 6, topic malleable-design-defaults

Depends on

• refactor(review): let /review:quality-gate take phase-boundary inputs (worktree, base SHA, quality bar, report-only) #8327
• feat(review): add /review:quality-gate code-design mode with bundled criteria and cascade severity #8329

Outcome

A plan phase tagged Review: <concern> now gets that review. At the phase boundary, /implementation:implement and /implementation:implement-dispatch invoke /review:quality-gate <mode> in fresh context for each tag. They pass the phase diff, the tag, the Quality bar: line, the worktree path, the base SHA and the report-only flag, and withhold the rationale. The sequence is: review, fix inside the phase fence, one re-review scoped to the fixed hunks, then the phase-verifier last. If the same finding comes back CRITICAL a second time, it is written to DEVIATIONS.md as a blocker and escalated once; it never loops.

Key interfaces

From the plan's ## Design:

implementation skills/implement, implement-dispatch | phase-boundary dispatch of architecture, security, code-design tags to /review:quality-gate <mode> | reactive trigger

Phase-boundary dispatch: architecture → /review:quality-gate architecture; security → /review:quality-gate security; code-design → /review:quality-gate code-design; concurrency → /review:quality-gate slice concurrency (existing mode; reports nothing when the consumer has no concurrency criteria file). The review receives the phase diff, the tag and the Quality bar: line, with rationale withheld.

Dependency direction: planning cites review and implementation by /plugin:skill only; review never cites planning files; implementation reads the plan's Review: tags and invokes review. No cycle.

Lands before the principle reference so this effort's own tagged phases get reviewed.

Done when

• grep -c "quality-gate code-design" on the implement SKILL.md returns ≥ 1, and implement-dispatch's phase-boundary section covers the same tags.
• Eval cases (case.yaml dirs under the implementation plugin's evals/): a tagged phase dispatches its review before the commit; an untagged phase does not; a repeated CRITICAL escalates once (unattended). /evals:plugin-eval with and without; difference in the PR body.
• After the commit, bash scripts/check-changed-skills.sh origin/main exits 0.
• A changelog fragment for the implementation plugin.

Out of scope

• When /planning:plan writes a Review: tag (plan-time checks item).
• New quality-gate modes.