qa(advisoryai): verify orchestrator, guardrails, and action-policy features

docs/qa/feature-checks/FLOW.md

@@ -21,6 +21,26 @@ All agents in the pipeline MUST read this document before taking any action.
 >
 > **Skipping Tier 2 is a verification failure, not a verification pass.**
 
+> **EXECUTION ORDER IS PROBLEMS-FIRST (MANDATORY).**
+>
+> Agents MUST resolve in-progress/problem states before starting any new `queued` feature.
+> A "problem/in-progress" state is any of:
+> `checking`, `failed`, `triaged`, `confirmed`, `fixing`, `retesting`.
+>
+> If any feature exists in those states, starting a new `queued` feature is a FLOW violation.
+> Only after all such features reach a terminal state (`done`, `blocked`, `skipped`, `not_implemented`)
+> may the pipeline continue with `queued` features.
+
+## 0. Execution Preflight (Mandatory Checklist)
+
+Before selecting any feature, run this checklist in order:
+
+1. Scan every state file in `docs/qa/feature-checks/state/*.json`.
+2. If any feature is in `checking`, `failed`, `triaged`, `confirmed`, `fixing`, or `retesting`, pick from those problem features only.
+3. Do not start any `queued` feature until all problem features are terminal (`done`, `blocked`, `skipped`, `not_implemented`).
+4. Record the selected feature transition in state notes before running Tier 0.
+5. Create a fresh run directory (`run-XYZ`) before collecting any tier artifacts.
+
 ---
 
 ## 1. Directory Layout
@@ -471,11 +491,41 @@ When selecting the next feature to process, the orchestrator follows this priori
 5. **`failed`** (retryCount < 3) - Failed features ready for triage
 6. **`queued`** - New features not yet checked
 
+### Failure-First Enforcement (Hard Rule)
+
+- If the current feature enters `failed`, `triaged`, `confirmed`, `fixing`, or `retesting`, agents MUST complete that failure loop for the same feature before starting any next `queued` feature.
+- A sprint batch task MUST NOT advance to the next feature while the current feature still has unresolved failures.
+- The only exception is an explicit human instruction to pause or reorder.
+
 Within the same priority level, prefer:
 - Features in smaller modules first (faster to clear a module completely)
 - Features with lower `retryCount`
 - Alphabetical by feature slug (deterministic ordering)
 
+### 6.1 Problem-First Lock (MANDATORY)
+
+- If any feature exists in `checking`, `retesting`, `fixing`, `confirmed`, `triaged`, or `failed`, the orchestrator MUST NOT start a `queued` feature.
+- This lock is cross-module: do not start or continue another module while the current module has an unresolved feature in `checking`/`failed`/`triaged`/`confirmed`/`fixing`/`retesting`.
+- The orchestrator MUST pick the highest-priority problem feature and keep working that same feature through the chain (`failed -> triaged -> confirmed -> fixing -> retesting`) until it reaches a terminal state (`done` or `blocked`) for that cycle.
+- "Touch one problem then switch to another" is forbidden unless the current feature is explicitly moved to `blocked` with a recorded reason.
+- This rule is strict and exists to prevent problem backlog growth while new work is started.
+
+### 6.2 Deterministic Selection Algorithm (MUST FOLLOW)
+
+Before selecting a next feature:
+
+1. Scan all module state files under `docs/qa/feature-checks/state/*.json`.
+2. If any feature is in `checking`, `retesting`, `fixing`, `confirmed`, `triaged`, or `failed`, select from those only.
+3. Selection order MUST be:
+   `retesting` > `fixing` > `confirmed` > `triaged` > `failed` > `checking`.
+4. Within the same status:
+   - lower `retryCount` first
+   - then alphabetical by `module`
+   - then alphabetical by `feature` slug
+5. Only when no features are in those statuses may the orchestrator select `queued`.
+
+This algorithm is mandatory and overrides ad-hoc feature picking.
+
 ---
 
 ## 7. File Movement Rules