diff --git a/instructions/r3/core/workflows/api-aqa-flow-api-spec-analysis.md b/instructions/r3/core/workflows/api-aqa-flow-api-spec-analysis.md
index be7e68c6..f1dfef12 100644
--- a/instructions/r3/core/workflows/api-aqa-flow-api-spec-analysis.md
+++ b/instructions/r3/core/workflows/api-aqa-flow-api-spec-analysis.md
@@ -10,22 +10,22 @@ baseSchema: docs/schemas/phase.md
 <api_aqa_flow_api_spec_analysis>
 
 <description_and_purpose>
-Analyze Swagger/OpenAPI specification or codebase API definitions to extract endpoint contracts, auth requirements, and data dependencies.
+Analyze Swagger/OpenAPI spec or codebase API definitions to extract endpoint contracts, auth requirements, and data dependencies.
 </description_and_purpose>
 
 <workflow_context>
 - Phase 2 of 8 in `api-aqa-flow`
-- Input: raw data from Phase 1 + project config (Swagger URL if available)
-- Output artifact path (single SSoT — referenced by other sections): `plans/api-aqa-{IDENTIFIER}/api-analysis.md` (resolve `{IDENTIFIER}` from `agents/TEMP/<FEATURE>/api-aqa-state.md`)
+- Input: Phase 1 raw data + project config (API spec URL if available)
+- Output: `plans/api-aqa-{IDENTIFIER}/api-analysis.md` (resolve `{IDENTIFIER}` from `agents/TEMP/<FEATURE>/api-aqa-state.md`)
 - Prerequisite: Phase 1 complete, `raw-data.md` exists with identified endpoints
-- Read-only scope: locate spec/source, extract contracts, reconcile, write the analysis artifact. NO edits to backend source or product code.
-- Required skills: `qa-knowledge` (`code_analysis` mode — API-contract extraction; supplies the api-analysis skeleton), `reverse-engineering` (extraction engine of that mode), `sensitive-data` (redaction), `qa-structure` (`{IDENTIFIER}` + artifact path)
+- Read-only: locate spec/source, extract contracts, reconcile, write analysis. NO edits to backend source or product code.
+- Required skills: `qa-knowledge` (`code_analysis` mode), `reverse-engineering`, `sensitive-data`, `qa-structure`
 </workflow_context>
 
 <input_contract>
-The phase supplies the skill two required inputs; the skill GATEs on both before any spec-location logic:
-- **Target-endpoint list** — non-empty, derived from Phase 1 test cases (or explicit user list). The skill never fabricates the target set. Empty/absent → stop, report back, ask the user.
-- **Spec/source path** — Swagger/OpenAPI URL OR file path OR backend source path with route definitions (determined in step 2.1). Neither supplied → stop; do NOT scan the whole codebase as a silent fallback unless the user explicitly requested it.
+Two required inputs; skill GATEs on both before any spec-location logic:
+- **Target-endpoint list** — non-empty, from Phase 1 test cases or explicit user list. NEVER fabricate. Empty/absent → stop, ask user.
+- **Spec/source path** — Swagger/OpenAPI URL, file path, or backend source path (step 2.1). Neither supplied → stop; DO NOT scan whole codebase as silent fallback without explicit user request.
 </input_contract>
 
 <phase_steps>
@@ -37,58 +37,48 @@ The phase supplies the skill two required inputs; the skill GATEs on both before
 
 <determine_spec_source step="2.1">
 
-Determine `{backend-source-path}` from Phase 1 raw data "Backend Source Code Analysis" section, or from project config "Backend Source Code" section, or from Rosetta docs at `refsrc/{project-name}/docs/` (the backend-source scan lives in the data-collection phase's **Backend Source Code Analysis** section). If Rosetta docs exist for the backend project, read `ARCHITECTURE.md` and `CODEMAP.md` from `refsrc/{project-name}/docs/` to understand API architecture before searching source code.
+`{backend-source-path}` source: Phase 1 "Backend Source Code Analysis", project config "Backend Source Code", or `refsrc/{project-name}/docs/`. If `refsrc/{project-name}/docs/` exists, read `ARCHITECTURE.md` and `CODEMAP.md` first.
+
+If `{backend-source-path}` NOT configured, search entire codebase for items 2–3 below.
 
 Determine spec source in order:
 
 1. **Swagger URL from project config** (`api-aqa-project-config.md`)
-2. **Swagger/OpenAPI in backend source** (if `{backend-source-path}` configured):
-   - Search within `{backend-source-path}` for: `swagger.json`, `swagger.yaml`, `openapi.json`, `openapi.yaml`, `api-docs`
-   - If `{backend-source-path}` is NOT configured, search entire codebase instead.
-3. **API route definitions in backend source** (if `{backend-source-path}` configured):
-   - Search within `{backend-source-path}` for framework-specific route patterns
-   - If `{backend-source-path}` is NOT configured, search entire codebase instead.
-4. **If none found**: Proceed with documentation from Phase 1 only; ask user for endpoint details. **Zero-source fallback:** if the user is unavailable, refuses, or supplies only partial info: mark each missing template field (request schema, response schema, auth, data dependencies) as `TBD` and add an explicit `## Assumptions` section in `api-analysis.md` listing every unknown field and the reason it is unknown. Flag Phase 2 as `partial — N/M endpoints fully analyzed` in `agents/TEMP/<FEATURE>/api-aqa-state.md` so downstream phases know not to treat the analysis as authoritative.
-
-Decision point: Swagger available -> full spec analysis. No Swagger -> code-based analysis + user input.
+2. **Swagger/OpenAPI in backend source**: search `{backend-source-path}` for `swagger.json`, `swagger.yaml`, `openapi.json`, `openapi.yaml`, `api-docs`
+3. **API route definitions in backend source**: search `{backend-source-path}` for framework-specific route patterns
+4. **No source found**: use Phase 1 docs only; ask user for endpoint details.
+   - **Zero-source fallback** (user unavailable, refuses, or supplies partial info): mark `request schema`, `response schema`, `auth`, `data dependencies` → `TBD`; add `## Assumptions` section (each unknown + reason); flag Phase 2 as `partial — N/M endpoints fully analyzed` in `agents/TEMP/<FEATURE>/api-aqa-state.md`.
 
 </determine_spec_source>
 
 <execute_analysis step="2.2" subagent="discoverer" role="API spec analyst">
 
-1. USE SKILL `reverse-engineering` and USE SKILL `qa-knowledge` (`code_analysis` mode — API-contract extraction) with the phase-supplied bindings: target-endpoint list (Phase 1 test cases) + spec source (step 2.1) = `<input_contract>`; per-endpoint output shape + Analysis Summary metrics = `qa-knowledge`'s api-analysis template (the skill loads its own asset); validation = `<validation_checklist>`; output path = `plans/api-aqa-{IDENTIFIER}/api-analysis.md`. The mode GATEs on the two required inputs before locating the spec. USE SKILL `sensitive-data` to redact before writing.
-2. The mode extracts per endpoint: contracts, auth requirements, data dependencies, and reconciles spec-vs-code when both sources are read.
-3. Coverage is mandatory: every target endpoint gets a contract entry OR is flagged back as a gap with reason — no silent drop. Do not fabricate schemas, status codes, or auth requirements without a source.
+1. USE SKILL `reverse-engineering`, USE SKILL `qa-knowledge` (`code_analysis` mode) with target-endpoint list + spec source (step 2.1); output to `plans/api-aqa-{IDENTIFIER}/api-analysis.md`. Mode GATEs on `<input_contract>` before spec-location. USE SKILL `sensitive-data` before writing.
+2. Mode extracts per endpoint: contracts, auth, data deps; reconciles spec-vs-code when both available.
+3. Coverage MANDATORY: every endpoint → contract entry OR gap with reason — no silent drop. Never fabricate schemas, status codes, or auth without a source.
 
 </execute_analysis>
 
 <produce_output step="2.3">
 
-Create `plans/api-aqa-{IDENTIFIER}/api-analysis.md`. The phase owns the document **section list** below; the verbatim per-endpoint contract entry and the Analysis Summary metrics are `qa-knowledge`'s api-analysis template. The skill EMITS into these, the phase ASSERTS them.
+Create `plans/api-aqa-{IDENTIFIER}/api-analysis.md`. Per-endpoint contract entry + Analysis Summary metrics use `qa-knowledge`'s api-analysis template.
 
-**Required section list** (in order; every section must be present-or-`N/A — <reason>`):
+**Required sections** (ordered; each must be present or `N/A — <reason>`):
 
 1. **Header** — `# API Analysis - [IDENTIFIER]` + Analyzed / Phase / Spec Source.
 2. **API Overview** — Base URL, API Version, Auth Mechanism, Content Type.
-3. **Endpoints Under Test** — one entry per target endpoint using the template's per-endpoint contract entry (canonical — single source of truth; other sections reference, do not restate).
+3. **Endpoints Under Test** — one entry per endpoint per template (canonical SSoT; other sections reference, do not restate).
 4. **Authentication Details** — Auth Mechanism (Token Endpoint, Token Type, Token Location, Header Name) + Auth for Tests (Strategy, Existing Pattern from Phase 1, Setup Required). One block; no per-endpoint restatement.
 5. **Data Dependencies** — Preconditions, Creation Order (numbered list), Cleanup Considerations. Document-level only; per-endpoint preconditions live inside each endpoint entry.
-6. **Analysis Summary** — the metric block from the template's "Analysis Summary metrics".
+6. **Analysis Summary** — metric block from the template's "Analysis Summary metrics".
 
 </produce_output>
 
 <redaction_contract>
-`api-analysis.md` is **tracked + downstream-fed** — PUBLIC by default. USE SKILL `sensitive-data`: scan the rendered artifact BEFORE writing, **fail-closed** (no scan → no emit); record each redaction in the entry's `Notes / Discrepancies`. Swagger specs and code routinely embed real secrets in `securitySchemes`, example bodies, and citation snippets.
+`api-analysis.md` is **tracked + downstream-fed** — PUBLIC by default. USE SKILL `sensitive-data`: scan rendered artifact BEFORE writing, **fail-closed** (no scan → no emit); record each redaction in `Notes / Discrepancies`. Scan `securitySchemes`, example bodies, citation snippets — specs and code embed real secrets there.
 </redaction_contract>
 
-<validate_findings step="2.4">
-1. Confirm all endpoints from test cases analyzed
-2. Confirm request/response schemas documented
-3. Confirm auth requirements identified
-4. Confirm data dependencies mapped
-</validate_findings>
-
-<update_state step="2.5">
+<update_state step="2.4">
 1. Update `agents/TEMP/<FEATURE>/api-aqa-state.md`:
    - Endpoints Analyzed: [count]
    - HTTP Methods: [GET/POST/PUT/DELETE/PATCH counts]
@@ -100,16 +90,16 @@ Create `plans/api-aqa-{IDENTIFIER}/api-analysis.md`. The phase owns the document
 </update_state>
 
 <validation_checklist>
-- **Coverage:** every target endpoint has a contract entry OR is flagged back as a gap with reason — no silent drops
-- **Source Citations:** every entry has ≥1 citation (Swagger JSONPath OR code `file:line`); citation-less entries are gaps, not entries
-- **No fabricated content:** every field traces to spec, to code, or is `N/A — <reason>` / `Gap: <reason>` — no invented schema fields, status codes, or auth
-- **Reconciliation evidence:** every `Source: hybrid` entry has a non-empty `Notes / Discrepancies` (recorded mismatch OR explicit `None.`)
-- **Undocumented error responses surfaced:** a `200`-only entry is acceptable only when both sources truly lack other codes; otherwise missing `401`/`403`/`404`/`500` recorded in Notes as a gap
-- **N/A discipline:** every `N/A` has a one-line reason; bare `N/A` forbidden
-- **Redaction pre-emit gate ran** — the `sensitive-data` scan executed against the rendered artifact; no literal credentials/tokens/PII remain
-- Request/response schemas, auth requirements, and data dependencies documented (from spec or code)
-- Backend source analyzed for route definitions (if path configured)
-- `api-analysis.md` created with all `<produce_output>` sections, each endpoint per the api-analysis template, plus the Analysis Summary metrics
+- **Coverage:** every endpoint → contract entry OR gap with reason; no silent drop
+- **Source citations:** every entry ≥1 citation (Swagger JSONPath OR `file:line`); citation-less → gap
+- **No fabrication:** every field → spec/code, `N/A — <reason>`, or `Gap: <reason>`; no invented schemas, codes, or auth
+- **Reconciliation:** every `Source: hybrid` entry → non-empty `Notes / Discrepancies` (mismatch OR `None.`)
+- **Error coverage:** `200`-only requires both sources lack others; else missing `401`/`403`/`404`/`500` → Notes gap
+- **N/A discipline:** every `N/A` one-line reason; bare `N/A` forbidden
+- **Redaction gate:** `sensitive-data` scan ran against rendered artifact; no credentials/tokens/PII remain
+- **Contract fields:** request/response schemas, auth, data dependencies documented from spec/code (or `TBD` + `## Assumptions` per zero-source fallback)
+- **Backend source:** `{backend-source-path}` configured → route definitions analyzed; not analyzed → reason recorded
+- **Artifact complete:** `api-analysis.md` exists with all 6 `<produce_output>` sections populated, none blank; endpoints per template + Analysis Summary metrics
 </validation_checklist>
 
 </api_aqa_flow_api_spec_analysis>
diff --git a/instructions/r3/core/workflows/api-aqa-flow-data-collection.md b/instructions/r3/core/workflows/api-aqa-flow-data-collection.md
index 2aae3b19..a1d34df4 100644
--- a/instructions/r3/core/workflows/api-aqa-flow-data-collection.md
+++ b/instructions/r3/core/workflows/api-aqa-flow-data-collection.md
@@ -10,7 +10,7 @@ baseSchema: docs/schemas/phase.md
 <api_aqa_flow_data_collection>
 
 <description_and_purpose>
-Gather test case details from the configured TMS, search the configured Wiki, and discover existing API test patterns in the codebase to establish baseline for automation.
+Gather TMS test-case details, Wiki docs, and existing API test patterns → automation baseline.
 </description_and_purpose>
 
 <workflow_context>
@@ -18,59 +18,62 @@ Gather test case details from the configured TMS, search the configured Wiki, an
 - Input: project config + initial data from Phase 0
 - Output: `plans/api-aqa-{IDENTIFIER}/raw-data.md` with test cases, documentation, and existing test patterns
 - Prerequisite: Phase 0 complete, `api-aqa-project-config.md` and `initial-data.md` exist
-- Collection skill: `data-collection` (single canonical collector for TMS + Wiki sources) — this phase resolves each in-scope provider and passes its role + provider to the skill; the skill loads the role-named binding. Existing-test-pattern scan: `qa-knowledge` (`code_analysis` mode, via `reverse-engineering`). This phase OWNS the raw-data aggregation contract (`<raw_data_contract>`) — the skills EMIT into the sections this phase asserts.
-- **Provider resolution (merge evidence; providers are NOT hardcoded).** Providers were resolved in Phase 0 and recorded in `api-aqa-project-config.md` (`tms_provider`, `wiki_provider` + base URLs, prefilled from `gain.json` `sdlc.*`). Reconcile with explicit user names/handles (which win for this run), recognizable provider URLs (valid evidence when unambiguous), and available integrations. If evidence conflicts or remains ambiguous, ask only about the unresolved provider/input; never silently choose between conflicting systems.
-- Optional **Wiki collection** when in scope — signals in `<config_binding>`; procedure in `<execute_collection>` step **1.2b**.
+- Collectors: `data-collection` (pass role + resolved provider); pattern scan: `qa-knowledge` (`code_analysis` mode, via `reverse-engineering`). Contract: `<raw_data_contract>`.
+- **Provider resolution** (NOT hardcoded): Phase 0 → `api-aqa-project-config.md` (`tms_provider`, `wiki_provider`, base URLs, `gain.json` `sdlc.*`). Merge evidence:
+  - Explicit user names/handles → win for this run.
+  - Recognizable provider URLs → valid evidence. Available integrations → evidence.
+  - Conflicts/ambiguity → ask only about unresolved; NEVER silently choose.
+- Optional Wiki → scope in `<config_binding>`; procedure in step **1.2b**.
 - Required skills: `data-collection` (TMS + Wiki collector), `qa-knowledge` (`code_analysis` mode — existing-test + backend-source scan), `reverse-engineering`, `qa-structure` (`{IDENTIFIER}` + raw-data path)
 </workflow_context>
 
 <config_binding>
-Wiki scope comes from **`api-aqa-project-config.md`** (Phase 0, prefilled from `gain.json`) plus run evidence per `<workflow_context>`. This phase OWNS the resolution + collection inline (step 1.2b) — there is no separate sub-flow.
-- **In-scope signals ("is a Wiki in scope?"):** `wiki_provider` holds a real provider (not `none`/`N/A`), `wiki_base_url` / Location is set, the user supplied Wiki pages/URLs, or `gain.json` `sdlc.wiki` names one — treat absent values as absent. The collection skill is ALWAYS `data-collection` with role `Wiki` + the resolved provider (Confluence is the canonical example; any Wiki backend maps the same way).
-- **Raw-data heading (fixed):** `## Documentation / Wiki` under `plans/api-aqa-{IDENTIFIER}/raw-data.md`. Do not invent a different heading unless `api-aqa-project-config.md` explicitly instructs a rename (then write under the configured heading and note the mapping once).
+Wiki scope: `api-aqa-project-config.md` + run evidence per `<workflow_context>`. Collection inline (step 1.2b); no sub-flow.
+- **In-scope signals:** `wiki_provider` real (not `none`/`N/A`) · `wiki_base_url`/Location set · user supplied pages/URLs · `gain.json` `sdlc.wiki` named. Treat absent as absent. Skill: ALWAYS `data-collection`, role `Wiki` + resolved provider. Canonical examples (TestRail · Jira · Confluence) adapt to the resolved provider; any backend maps the same way.
+- **Raw-data heading (fixed):** `## Documentation / Wiki` in `plans/api-aqa-{IDENTIFIER}/raw-data.md`. `api-aqa-project-config.md` rename instruction → use configured heading; note mapping once.
 </config_binding>
 
 <raw_data_contract>
-This phase owns the raw-data aggregation artifact `plans/api-aqa-{IDENTIFIER}/raw-data.md` and its sections — `data-collection` and `qa-knowledge` emit into these, they do not define them. Required sections (empty → `N/A — <reason>`, never blank):
+`plans/api-aqa-{IDENTIFIER}/raw-data.md` — assemble here. Required sections (empty → `N/A — <reason>`, never blank):
 - **Test Case Data** — from `data-collection` (role `TMS`, resolved provider); ≥1 test-case source required.
-- **Documentation / Wiki** — from `data-collection` (role `Wiki`, resolved provider) via step 1.2b when scoped; else the `SKIPPED_NO_CONFIG` outcome row (per `<wiki_outcomes>`).
-- **Existing Test Patterns** — from `qa-knowledge` (`code_analysis` mode — test-automation architecture analysis, via `reverse-engineering`); framework, HTTP client, structure/assertion/auth conventions, reusable utilities. Record env-file **path + variable names only**, never literal values.
-- **Backend Source Code Analysis** — backend path from config or discoverable `refsrc/` docs; framework, route patterns, key dirs (or `N/A` when no path).
-- **API Endpoints Identified** — every row has Method + Source populated; partial rows tagged as gaps.
-- **Data Collection Summary** — counts + gap notes; a delegated-skill stop is recorded verbatim as `Gap: <skill> stopped — <message>`, never fabricated over.
+- **Documentation / Wiki** — from `data-collection` (role `Wiki`, resolved provider) via step 1.2b when scoped; else `SKIPPED_NO_CONFIG` outcome row (per `<wiki_outcomes>`).
+- **Existing Test Patterns** — from `qa-knowledge` (`code_analysis` via `reverse-engineering`); framework, HTTP client, structure/assertion/auth conventions, utilities. Env-file: **path + variable names only**, never literal values.
+- **Backend Source Code Analysis** — path from config or `refsrc/`; framework, routes, key dirs (else `N/A`).
+- **API Endpoints Identified** — every row has Method + Source; partial rows tagged as gaps.
+- **Data Collection Summary** — counts + gap notes; delegated-skill stop → `Gap: <skill> stopped — <message>`, never fabricated over.
 
 Redaction of every captured value runs inside `data-collection` via `sensitive-data` before write; `raw-data.md` is PUBLIC by default.
 </raw_data_contract>
 
 <phase_steps>
 1. Confirm data sources from project config
-2. Execute data collection — see `<execute_collection>`: **1.2a** core collection (`data-collection` TMS role + `qa-knowledge` existing-test scan → `<raw_data_contract>`), **1.2b** optional Wiki collection when scoped
+2. Execute data collection per `<execute_collection>`
 3. Validate and update state
 </phase_steps>
 
 <confirm_inputs step="1.1">
-1. Verify project config loaded with data source information
-2. Verify initial data file exists with test case reference
-3. Identify TMS, Wiki, and codebase sources to query
-4. **Failure path:** if (1) or (2) is missing, stop Phase 1, record `Phase 1 blocked: missing prerequisite [config | initial-data]` in `agents/TEMP/<FEATURE>/api-aqa-state.md`, and ask the user to re-run Phase 0. If (3) finds no usable sources, record the gap and ask the user to confirm proceeding with empty data sources before continuing.
+1. Verify project config loaded
+2. Verify initial-data file exists with test case reference
+3. Identify TMS, Wiki, codebase sources
+4. **Failure path:** (1)/(2) missing → record `Phase 1 blocked: missing prerequisite [config | initial-data]` in `agents/TEMP/<FEATURE>/api-aqa-state.md` → ask re-run Phase 0. (3) no usable sources → record gap → ask user to confirm empty-source proceed.
 </confirm_inputs>
 
 <execute_collection step="1.2" subagent="discoverer" role="AQA data collector">
 
 <verify_primary_raw_data step="1.2a">
-1. Resolve the **TMS provider** per `<workflow_context>` (Jira tickets are a valid TMS source when the project stores test cases there). If no TMS source is resolvable, ask the user once; if still missing, stop Phase 1 and record `Phase 1 blocked: no resolvable test-case source` in `agents/TEMP/<FEATURE>/api-aqa-state.md` — do NOT invent an ID.
-2. USE SKILL `data-collection` with role `TMS`, the resolved provider, the test-case input handle, and the **Test Case Data** + **API Endpoints Identified** sections of `<raw_data_contract>`; the skill loads its TMS binding and adapts the canonical TestRail/Jira examples to the target system. A delegated stop is recorded verbatim per `<raw_data_contract>`; if the failed source was the only test-case source, stop the phase.
-3. USE SKILL `reverse-engineering` and USE SKILL `qa-knowledge` (`code_analysis` mode — test-automation architecture analysis) over the existing test project to populate the **Existing Test Patterns** (and **Backend Source Code Analysis** where backend source is discoverable) sections of `<raw_data_contract>` — read-only scan of framework, HTTP client, structure/assertion/auth conventions, reusable utilities; env-file path + var names only.
-4. Assemble `plans/api-aqa-{IDENTIFIER}/raw-data.md` per `<raw_data_contract>` from the emitted sections. Verify it exists. If missing, **re-run steps 2–4 once**; if still missing, stop Phase 1, record the gap in `agents/TEMP/<FEATURE>/api-aqa-state.md`, and notify the user — **do not** run `<wiki_collection_optional>` until the primary raw-data artifact exists.
+1. Resolve **TMS provider** per `<workflow_context>` (Jira tickets valid when project stores cases there). No source → ask once; still missing → record `Phase 1 blocked: no resolvable test-case source` in `agents/TEMP/<FEATURE>/api-aqa-state.md`; do NOT invent an ID.
+2. USE SKILL `data-collection`: role `TMS`, resolved provider, test-case handle → **Test Case Data** + **API Endpoints Identified** per `<raw_data_contract>`. Delegated stop → record verbatim; if it was the only test-case source → stop phase.
+3. USE SKILL `reverse-engineering`; USE SKILL `qa-knowledge` (`code_analysis` mode) → **Existing Test Patterns** + **Backend Source Code Analysis** sections; env-file path + var names only.
+4. Assemble `plans/api-aqa-{IDENTIFIER}/raw-data.md` per `<raw_data_contract>`. Verify exists. Missing → **re-run steps 2–4 once**; still missing → record gap in `agents/TEMP/<FEATURE>/api-aqa-state.md` + notify user; **do not** run `<wiki_collection_optional>` until artifact exists.
 </verify_primary_raw_data>
 
 <wiki_collection_optional step="1.2b">
-This phase runs the Wiki collection **inline** (no sub-flow). Provider resolution + in-scope signals per `<config_binding>`; record **exactly one** outcome line per `<wiki_outcomes>`.
+Provider + scope per `<config_binding>`; record **exactly one** outcome line per `<wiki_outcomes>`.
 
-1.2b.1. **Scope check.** If no in-scope Wiki signal is present (per `<config_binding>`), apply **SKIPPED_NO_CONFIG** and skip the rest of this sub-block.
-1.2b.2. **Resolve the provider.** Take the Wiki provider from `<config_binding>` signals. If signals are active but no provider is named, re-read `api-aqa-project-config.md` + Phase 0 evidence; if still none, apply **SKIPPED_NO_CONFIG** and skip.
-1.2b.3. **Collect.** USE SKILL `data-collection` with role `Wiki`, the resolved provider, the input handle(s), and the fixed `## Documentation / Wiki` heading as the output target; the skill loads its Wiki binding (adapting the canonical Confluence examples) and runs harvest → redact (via `sensitive-data`) → write internally. If the skill cannot be loaded → apply **LOAD_FAILED** (skill = `data-collection`) and skip. No harvestable sources after search + user fallback → apply **EMPTY_HARVEST**; otherwise apply **COMPLETED**.
-1.2b.4. **Verify.** Confirm the `## Documentation / Wiki` heading holds **exactly one** outcome line matching the branch taken (per `<wiki_outcomes>`). On mismatch: zero rows → append the branch row; duplicate rows → keep only the most recent (latest by `agents/TEMP/<FEATURE>/api-aqa-state.md` Phase 1 timestamp); heading missing → create it, then append. After three failed re-verifies, stop and record `Phase 1 blocked: Wiki-collection verification failed after remediation` in `agents/TEMP/<FEATURE>/api-aqa-state.md`; ask the user to inspect `raw-data.md`.
+1.2b.1. **Scope check:** no Wiki signal (per `<config_binding>`) → **SKIPPED_NO_CONFIG**, skip rest.
+1.2b.2. **Resolve provider:** from `<config_binding>` signals. Active but no provider → re-read `api-aqa-project-config.md`; still none → **SKIPPED_NO_CONFIG**, skip.
+1.2b.3. **Collect:** USE SKILL `data-collection`: role `Wiki`, resolved provider, input handle(s) → `## Documentation / Wiki` heading. Cannot load → **LOAD_FAILED** (`data-collection`), skip. No sources after search + user fallback → **EMPTY_HARVEST**; else → **COMPLETED**.
+1.2b.4. **Verify:** `## Documentation / Wiki` holds **exactly one** outcome line per `<wiki_outcomes>`. Mismatch: zero rows → append; duplicate → keep most recent (by `agents/TEMP/<FEATURE>/api-aqa-state.md` Phase 1 timestamp); heading missing → create + append. Three failed re-verifies → record `Phase 1 blocked: Wiki-collection verification failed after remediation` in `agents/TEMP/<FEATURE>/api-aqa-state.md`; ask user to inspect `raw-data.md`.
 </wiki_collection_optional>
 
 <wiki_outcomes>
@@ -97,14 +100,12 @@ Literal examples: `**Outcome:** collected via data-collection (Wiki: confluence)
    - Backend Source: [path or N/A]
    - Phase 1 completion timestamp
 2. Mark Phase 1 complete, Phase 2 current
-3. **Failure path:** if `agents/TEMP/<FEATURE>/api-aqa-state.md` cannot be written (permission denied, disk full, file locked), do not mark Phase 1 complete; record the write error in chat output, ask the user to resolve the filesystem issue, and pause before Phase 2.
+3. **Failure path:** `agents/TEMP/<FEATURE>/api-aqa-state.md` unwritable → do NOT mark Phase 1 complete; record error in chat; ask user to resolve; pause before Phase 2.
 </update_state>
 
 <validation_checklist>
-- Test case data retrieved and documented
-- `plans/api-aqa-{IDENTIFIER}/raw-data.md` exists (verified in step 1.2a) with core collection sections populated per `<raw_data_contract>`
-- Wiki searched (results found OR user confirmed skip)
-- Wiki outcome in `raw-data.md` is exactly one `<wiki_outcomes>` branch matching the path taken in step 1.2b
+- `plans/api-aqa-{IDENTIFIER}/raw-data.md` exists; all `<raw_data_contract>` sections populated, none blank
+- Wiki: exactly one `<wiki_outcomes>` branch outcome line in `raw-data.md`
 - Existing test patterns analyzed
 - Backend source code searched (if path configured in project config)
 - API endpoints identified from test cases
diff --git a/instructions/r3/core/workflows/api-aqa-flow-execution-and-report-analysis.md b/instructions/r3/core/workflows/api-aqa-flow-execution-and-report-analysis.md
index d5e21fde..a5b899d4 100644
--- a/instructions/r3/core/workflows/api-aqa-flow-execution-and-report-analysis.md
+++ b/instructions/r3/core/workflows/api-aqa-flow-execution-and-report-analysis.md
@@ -16,17 +16,15 @@ Analyze test execution results provided by the user. Identify failures, categori
 <workflow_context>
 - Phase 6 of 8 in `api-aqa-flow`
 - Input: test execution report or output (user-provided or from `agents/user-instructions/`)
-- Output artifact path (single SSoT — referenced by other sections): `plans/api-aqa-{IDENTIFIER}/execution-report.md` (resolve `{IDENTIFIER}` from `agents/TEMP/<FEATURE>/api-aqa-state.md`)
+- Output: `plans/api-aqa-{IDENTIFIER}/execution-report.md` (resolve `{IDENTIFIER}` from `agents/TEMP/<FEATURE>/api-aqa-state.md`)
 - Prerequisite: Phase 5 complete, tests executed by user
 - HITL: may need to ask user for test execution results
-- Read-only scope (single SSoT — referenced by other sections as "the read-only scope"): parse / categorize / root-cause / label evidence / recommend. NO production code edits, NO writes to test or product source files. Refuse "just fix it now" / "patch and move on" with citation of this scope; the only acceptable user inputs are report location, evidence/labeling clarifications, or explicit approval to leave borderline items as `Assumption`.
-- Required skills: `qa-knowledge` (`test_execution_triage` mode + API failure taxonomy + failure-report skeleton), `sensitive-data` (redaction), `qa-structure` (`{IDENTIFIER}` + artifact path)
+- Read-only scope: parse / categorize / root-cause / label evidence / recommend. NO production code edits, NO writes to test or product source files. Refuse "just fix it now" / "patch and move on" with citation of this scope; acceptable user inputs: report location, evidence/labeling clarifications, or explicit approval to leave borderline items as `Assumption`.
+- Required skills: `qa-knowledge` (`test_execution_triage` mode), `sensitive-data` (redaction), `qa-structure` (`{IDENTIFIER}` + artifact path)
 </workflow_context>
 
 <execution_report_contract>
-`execution-report.md` is **tracked + downstream-fed** — PUBLIC by default. USE SKILL `sensitive-data`: scan the rendered artifact BEFORE writing, **fail-closed** (no scan → no emit; test logs/stack traces can carry tokens). The failure classification is `qa-knowledge`'s API failure taxonomy (exactly one category per failure); the report structure is `qa-knowledge`'s failure-report template, API variant (the skill loads its own asset) — Execution Summary, Failures by Category, per-failure Failure Details (**ID** `ERR-N` · Failure name · Category · Root cause · Evidence label `Confirmed`/`Assumption`/`Unknown` · Evidence rationale · Priority), Patterns, Recommendations.
-
-This is the **phase contract**, verified by `<validation_checklist>` independent of skill internals.
+`execution-report.md` is **tracked + downstream-fed** — PUBLIC by default. USE SKILL `sensitive-data`: scan rendered artifact BEFORE writing, **fail-closed** (no scan → no emit). Taxonomy: `qa-knowledge`'s API failure taxonomy (exactly one category per failure); structure: `qa-knowledge`'s failure-report template, API variant — Execution Summary, Failures by Category, per-failure Failure Details (**ID** `ERR-N` · Failure name · Category · Root cause · Evidence label `Confirmed`/`Assumption`/`Unknown` · Evidence rationale · Priority), Patterns, Recommendations.
 </execution_report_contract>
 
 <phase_steps>
@@ -37,41 +35,38 @@ This is the **phase contract**, verified by `<validation_checklist>` independent
 </phase_steps>
 
 <execute_analysis step="6.1" subagent="engineer" role="Test failure analyst">
-1. USE SKILL `qa-structure` to resolve `{IDENTIFIER}`/run paths. If the test report location is unknown and not in `agents/user-instructions/` (keywords: "test report", "report location", "test output", "report path"): ask user and **WAIT** until a report is available or the user confirms none.
-2. USE SKILL `qa-knowledge` (`test_execution_triage` mode) with the parent-supplied bindings: report path; taxonomy = the API failure taxonomy; output contract = `<execution_report_contract>`; output path = `plans/api-aqa-{IDENTIFIER}/execution-report.md`. The skill loads its own taxonomy + report skeleton at point of use. USE SKILL `sensitive-data` for redaction and run its scan as the pre-emit gate before writing.
-3. Do not fabricate failures, stack traces, or pass/fail counts. If inputs are missing, contradictory, or look tampered with, say so in `execution-report.md` and ask the user for verifiable artifacts.
+1. USE SKILL `qa-structure` to resolve `{IDENTIFIER}`/run paths. If test report unknown and not in `agents/user-instructions/` (keywords: "test report", "report location", "test output", "report path"): ask user and **WAIT** until report available or user confirms none.
+2. USE SKILL `qa-knowledge` (`test_execution_triage` mode) with bindings: report path; taxonomy = API failure taxonomy; output contract = `<execution_report_contract>`; output path = `plans/api-aqa-{IDENTIFIER}/execution-report.md`. USE SKILL `sensitive-data` for redaction; scan = pre-emit gate before writing.
+3. Do not fabricate failures, stack traces, or pass/fail counts. If inputs missing, contradictory, or tampered: note in `execution-report.md` and ask for verifiable artifacts.
 4. Honor the read-only scope (`<workflow_context>`).
-5. **Post-analysis verification:** confirm `plans/api-aqa-{IDENTIFIER}/execution-report.md` exists with every `<execution_report_contract>` section. If missing/incomplete: re-run triage once with the same bindings; if still failing, stop Phase 6, record `Phase 6 blocked: execution-report.md not produced/incomplete` in `agents/TEMP/<FEATURE>/api-aqa-state.md`, and ask the user.
+5. **Post-analysis verification:** confirm `plans/api-aqa-{IDENTIFIER}/execution-report.md` exists with every `<execution_report_contract>` section. If missing/incomplete: re-run triage once with the same bindings; if still failing, stop Phase 6, record `Phase 6 blocked: execution-report.md not produced/incomplete` in `agents/TEMP/<FEATURE>/api-aqa-state.md` and ask user.
 </execute_analysis>
 
 <review_findings step="6.2">
-1. Verify every failed test has a Failure Details entry with a sequential `ERR-N` id, one API-taxonomy category, and a root cause.
-2. Verify each root cause carries an Evidence label + one-line rationale (definitions are canonical in `qa-knowledge`'s test-execution triage reference — not restated here).
-3. Verify Patterns and Recommendations are populated.
-4. Validation loop (max two cycles): if any entry is unlabeled or missing a required field, repeat steps 1–3. After two cycles with gaps, record unresolved rows in `agents/TEMP/<FEATURE>/api-aqa-state.md`, ask the user once how to label them (or approval to leave borderline items as `Assumption`), then continue only after the user responds.
+1. Verify each failure has a Failure Details entry: sequential `ERR-N`, one API-taxonomy category, root cause.
+2. Verify each root cause has evidence label + one-line rationale.
+3. Verify Patterns and Recommendations populated.
+4. Validation loop (max two cycles): if any entry unlabeled or missing a required field, repeat steps 1–3. After two cycles with gaps: record unresolved rows in `agents/TEMP/<FEATURE>/api-aqa-state.md`; ask user once to label them or approve leaving borderline items as `Assumption`; continue only after user responds.
 </review_findings>
 
 <update_state step="6.3">
-1. Update `agents/TEMP/<FEATURE>/api-aqa-state.md`: Tests Executed / Passed / Failed counts; Root Causes by category; Phase 6 completion timestamp.
+1. Update `agents/TEMP/<FEATURE>/api-aqa-state.md`: Tests Executed/Passed/Failed; root causes by category; Phase 6 completion timestamp.
 2. Mark Phase 6 complete, Phase 7 current.
 </update_state>
 
 <failure_handling>
-- **Report present but unreadable/corrupt:** retry parsing once, then stop, record the evidence gap in `api-aqa-state.md`, and ask for readable output or a re-run.
-- **User confirms no report exists:** accept an explicit pass/fail result only when it is actual Phase 5 execution evidence; otherwise remain blocked at the execution gate.
-- **`qa-structure`, `qa-knowledge`, or `sensitive-data` load/scan failure:** retry once, then stop and do not emit the analysis artifact; record the failure in `api-aqa-state.md` and ask the user.
+- **Unreadable/corrupt report:** retry parsing once → stop → record evidence gap in `api-aqa-state.md` → ask for readable output or re-run.
+- **User confirms no report:** accept pass/fail only with actual Phase 5 evidence; otherwise remain blocked.
+- **Skill load/scan failure** (`qa-structure`, `qa-knowledge`, `sensitive-data`): retry once → stop; do not emit analysis artifact; record failure in `api-aqa-state.md` → ask user.
 - **Redaction scan unavailable:** fail closed — do not quote, summarize, or write captured report values.
 </failure_handling>
 
 <validation_checklist>
-- Test execution results obtained from user
-- All results parsed and categorized per `qa-knowledge`'s API failure taxonomy
-- Every failure entry has all seven contract fields with a unique sequential `ERR-N`
-- Patterns identified across failures (or explicit none)
-- Redaction pre-emit gate ran — the `sensitive-data` scan was executed against the artifact before writing
+- All results parsed/categorized per `qa-knowledge`'s API failure taxonomy
+- Every failure entry has all seven contract fields with unique sequential `ERR-N`
+- Redaction pre-emit gate ran — `sensitive-data` scan executed before writing
 - `execution-report.md` written with all `<execution_report_contract>` sections and non-empty
 - No source files modified outside the analysis artifact (read-only scope)
-- Clear recommendations for Phase 7
 </validation_checklist>
 
 </api_aqa_flow_execution_and_report_analysis>
diff --git a/instructions/r3/core/workflows/api-aqa-flow-gap-and-requirements-clarification.md b/instructions/r3/core/workflows/api-aqa-flow-gap-and-requirements-clarification.md
index fbcc37df..a29ca773 100644
--- a/instructions/r3/core/workflows/api-aqa-flow-gap-and-requirements-clarification.md
+++ b/instructions/r3/core/workflows/api-aqa-flow-gap-and-requirements-clarification.md
@@ -31,43 +31,41 @@ Cross-reference test cases, documentation, and API spec to identify gaps, contra
 
 <execute_gap_analysis step="3.1" subagent="architect" role="Test requirements analyst">
 
-1. USE SKILL `qa-knowledge` (`gap_analysis` mode). Run all three variants against the inputs and EMIT findings into the phase-owned sections of `<analysis_md_contract>`; the mode is analysis-only and never invents the artifact shape:
+1. USE SKILL `qa-knowledge` (`gap_analysis` mode). Run all three variants; EMIT findings into `<analysis_md_contract>` sections:
    - **Test-cases-vs-API-spec variant** → **Gaps** (`G[N]` entries; test step vs API analysis cross-reference).
-   - **General multi-source variant** → **Contradictions** (`C[N]`; cross-source disagreements between raw-data, api-analysis, docs) + **Ambiguities** (`A[N]`; vague statements).
-2. Finding-entry shapes (`G[N]` / `C[N]` / `A[N]`, each with verbatim source quote + citation + impact + suggested question) are `qa-knowledge`'s gap-finding templates — the skill loads its own asset at point of use.
-3. If a finding fits more than one bucket, record it once under the section that owns its emit shape (G/C/A) and add a cross-reference note rather than duplicating.
-4. Prepare a prioritized list of gaps, contradictions, ambiguities for step 3.2.
+   - **General multi-source variant** → **Contradictions** (`C[N]`; cross-source: raw-data · api-analysis · docs) + **Ambiguities** (`A[N]`; vague statements).
+2. Multi-bucket finding → record once (primary G/C/A section) + cross-ref; no duplication.
+3. Prepare prioritized list for step 3.2.
 
 </execute_gap_analysis>
 
 <ask_user step="3.2">
 1. USE SKILL `questioning`
-2. Present structured questions to user (Critical / Important / Optional)
+2. Present structured questions (Critical / Important / Optional)
 3. **STOP AND WAIT** for user to provide all answers
 4. **Unknown-answer branches by priority:**
-   - **Critical unknown:** mark as `BLOCKING ASSUMPTION` in `analysis.md`, stop Phase 3, do not advance to Phase 4 until the user provides an answer or explicitly approves proceeding with the assumption.
-   - **Important unknown:** mark as `ASSUMPTION` with rationale, flag in `agents/TEMP/<FEATURE>/api-aqa-state.md` under Open Assumptions, proceed.
-   - **Optional unknown:** mark as `SKIPPED` with reason, proceed.
-   - **Partial answer:** record what was answered; treat the unanswered portion per the matching priority branch above.
-   - **User defers / marks out-of-scope:** record as `DEFERRED — user out-of-scope` and treat as Optional (proceed).
+   - **Critical unknown:** mark as `BLOCKING ASSUMPTION` in `analysis.md`; stop Phase 3; do not advance to Phase 4 until user answers or explicitly approves the assumption.
+   - **Important unknown:** mark as `ASSUMPTION` with rationale; flag in `agents/TEMP/<FEATURE>/api-aqa-state.md` under Open Assumptions; proceed.
+   - **Optional unknown:** mark as `SKIPPED` with reason; proceed.
+   - **Partial answer:** record answered portion; treat remainder per matching priority branch.
+   - **User defers / marks out-of-scope:** record `DEFERRED — user out-of-scope`; treat as Optional → proceed.
 </ask_user>
 
 <update_plan step="3.3">
-1. Process user answers
-2. Update analysis document with questions, answers, and resolved items
-3. Verify `plans/api-aqa-{IDENTIFIER}/analysis.md` created with **all required sections** (see `<analysis_md_contract>` below)
+1. Update `plans/api-aqa-{IDENTIFIER}/analysis.md` with questions, answers, resolutions.
+2. Verify all required sections per `<analysis_md_contract>`.
 </update_plan>
 
 <analysis_md_contract>
-`analysis.md` must include these sections in order; missing or empty sections fail validation:
+`analysis.md` required sections in order; missing/empty → fail validation:
 
-1. **Gaps** — items not covered by raw-data or API analysis (one bullet per gap, with source citation)
-2. **Contradictions** — places where raw-data and api-analysis disagree (with both sources cited)
-3. **Ambiguities** — wording or behavior open to interpretation
-4. **Questions** — full list of structured questions asked (with priority tag: Critical / Important / Optional)
-5. **Answers** — user responses; for each, indicate ANSWERED / ASSUMPTION / BLOCKING ASSUMPTION / SKIPPED / DEFERRED per `<ask_user>` step 4
-6. **Resolutions** — final disposition for each gap/contradiction/ambiguity (resolved, accepted as assumption, deferred to a later phase)
-7. **Open Assumptions** — explicit list of every unresolved item carried forward (mirrors the count in `api-aqa-state.md`)
+1. **Gaps** — uncovered items; one bullet/gap; source cited
+2. **Contradictions** — raw-data/api-analysis disagreements; both sources cited
+3. **Ambiguities** — vague wording or behavior
+4. **Questions** — structured; tagged Critical/Important/Optional
+5. **Answers** — per answer: ANSWERED/ASSUMPTION/BLOCKING ASSUMPTION/SKIPPED/DEFERRED (→ `<ask_user>` step 4)
+6. **Resolutions** — per G/C/A: resolved / assumption / deferred
+7. **Open Assumptions** — unresolved items carried forward; count matches `agents/TEMP/<FEATURE>/api-aqa-state.md`
 </analysis_md_contract>
 
 <update_state step="3.4">
@@ -84,18 +82,14 @@ Cross-reference test cases, documentation, and API spec to identify gaps, contra
 </update_state>
 
 <validation_checklist>
-- Cross-reference analysis completed
-- All gaps, contradictions, and ambiguities documented
-- Questions presented to user
-- User answers received and documented
-- `analysis.md` created with all 7 sections per `<analysis_md_contract>`
+- `analysis.md` exists with all 7 sections per `<analysis_md_contract>`
 - **Completion invariants (all must hold):** `Questions Asked == Answers Received + Open Assumptions + Skipped + Deferred`; **no Critical question remains in BLOCKING ASSUMPTION state** (any Critical-blocker forces Phase 3 to stay open); `Open Assumptions` count matches the size of the Open Assumptions section in `analysis.md`.
 </validation_checklist>
 
 <failure_handling>
-- **Missing prerequisite artifact** (`raw-data.md` or `api-analysis.md` absent or empty): stop Phase 3, record `Phase 3 blocked: missing [artifact]` in `agents/TEMP/<FEATURE>/api-aqa-state.md`, and ask the user to re-run the producing phase.
-- **Skill load failure** for any of `qa-knowledge`, `questioning`: apply the parent `api-aqa-flow.md` `<failure_handling>` load-failure rule (retry once, stop, record, ask user).
-- **HITL stall** (user unresponsive after Critical question, or refuses to answer a Critical): do **not** auto-promote to assumption. Record `Phase 3 blocked: user-unresponsive on Critical question(s)` in `agents/TEMP/<FEATURE>/api-aqa-state.md` and pause; the agent must not advance to Phase 4 silently. Resume only after the user answers, explicitly approves proceeding with a BLOCKING ASSUMPTION, or downgrades the question.
+- **Missing prerequisite** (`raw-data.md` or `api-analysis.md` absent/empty): stop Phase 3, record `Phase 3 blocked: missing [artifact]` in `agents/TEMP/<FEATURE>/api-aqa-state.md` → ask user to re-run producing phase.
+- **Skill load failure** (`qa-knowledge`, `questioning`): apply `api-aqa-flow.md` `<failure_handling>` load-failure rule.
+- **HITL stall** (user unresponsive / refuses Critical): do **not** auto-promote to assumption. Record `Phase 3 blocked: user-unresponsive on Critical question(s)` in `agents/TEMP/<FEATURE>/api-aqa-state.md`; pause. Resume only after: user answers, explicitly approves BLOCKING ASSUMPTION, or downgrades.
 </failure_handling>
 
 </api_aqa_flow_gap_and_requirements_clarification>
diff --git a/instructions/r3/core/workflows/api-aqa-flow-project-config-loading.md b/instructions/r3/core/workflows/api-aqa-flow-project-config-loading.md
index 70d3bc5e..a53cd908 100644
--- a/instructions/r3/core/workflows/api-aqa-flow-project-config-loading.md
+++ b/instructions/r3/core/workflows/api-aqa-flow-project-config-loading.md
@@ -10,37 +10,37 @@ baseSchema: docs/schemas/phase.md
 <api_aqa_flow_project_config_loading>
 
 <description_and_purpose>
-Initialize the AQA session directory, load the existing project config or collect project-specific information from the user, and seed the workflow state file for backend API test automation. Canonical paths, the `{IDENTIFIER}` derivation rule, the config-key schema, and the state-file shape are owned by USE SKILL `qa-structure` — this phase binds to them and does not restate them.
+Initialize AQA session directory, load or collect project config, seed state file. Canonical paths, `{IDENTIFIER}` derivation, config-key schema, and state-file shape owned by USE SKILL `qa-structure`.
 </description_and_purpose>
 
 <workflow_context>
 - Phase 0 of 8 in `api-aqa-flow`
-- Input (REQUIRED): user request with test case reference (TMS case ID, Issue Tracker ticket, or direct description — e.g. TestRail `C1234`, Jira `PROJ-123`)
-- Input (OPTIONAL, when provided by user): repository-root `gain.json` `sdlc.*` providers, Swagger/OpenAPI spec URL or path, Wiki/docs page URLs, backend source code locations
-- Output (paths owned by `qa-structure`): per-session `plans/api-aqa-{IDENTIFIER}/api-aqa-project-config.md` and `plans/api-aqa-{IDENTIFIER}/initial-data.md`; shared workflow state `agents/TEMP/<FEATURE>/api-aqa-state.md`.
-- Prerequisite: starting new AQA flow
-- HITL: conditional — user is questioned ONLY if the project config does not already exist
+- Input (REQUIRED): test case reference (TMS case ID, Issue Tracker ticket, or direct description — e.g. TestRail `C1234`, Jira `PROJ-123`)
+- Input (OPTIONAL): repository-root `gain.json` `sdlc.*` providers, Swagger/OpenAPI spec URL or path, Wiki/docs page URLs, backend source code locations
+- Output: `plans/api-aqa-{IDENTIFIER}/api-aqa-project-config.md`, `plans/api-aqa-{IDENTIFIER}/initial-data.md`, `agents/TEMP/<FEATURE>/api-aqa-state.md`
+- Prerequisite: new AQA run
+- HITL: conditional — only if config absent
 - Required skills: `qa-structure` (paths / `{IDENTIFIER}` / config schema / state shape), `sensitive-data` (redaction at intake)
 - Recommended skills: `questioning` (config-missing interview)
 </workflow_context>
 
 <phase_steps>
-1. Parse user input, resolve providers from `gain.json` + evidence, derive `{IDENTIFIER}`, and create the session directory + state-file stub.
-2. Load this session's config if present, or collect the still-missing project info from the user and create it.
-3. Create the initial-data file and mark Phase 0 complete.
+1. Parse input, resolve providers, derive `{IDENTIFIER}`, seed session.
+2. Load or collect project config from `gain.json`.
+3. Write initial-data; mark Phase 0 complete.
 </phase_steps>
 
 <execute_config step="0.1" subagent="discoverer" role="AQA project config loader">
 
-USE SKILL `qa-structure` for the session layout, `{IDENTIFIER}` derivation, and the config-key schema — the skill routes on those topics and loads its own files. This phase performs session initialization DIRECTLY (no dedicated init skill); it delegates only user-questioning to `questioning`. On the config-missing branch it performs a bounded set of loads (layout, config schema, then the interview + config template at step 0.1.5) — load each at its step via the owning skill; never write an artifact from memory.
+USE SKILL `qa-structure` for session layout, `{IDENTIFIER}` derivation, and config-key schema. Load each at its step; never write an artifact from memory.
 
-1. **Parse initial user input.** Extract:
-   - **Test case reference** (REQUIRED): TMS case ID, Issue Tracker key/URL, or direct test-case description.
-   - **Additional context** (OPTIONAL): Swagger URL, Wiki pages, API documentation links.
-   - Supported phrasings: `"Write API tests for TC-1234"`, `"Automate backend tests for PROJ-123"`, `"Create API tests for the user registration endpoint"`, `"Automate TC-1234 with Swagger: https://api.example.com/swagger"`.
-2. **Resolve providers (merge evidence; do not force one source).** Read repository-root `gain.json`; use `sdlc.test_management(_project)`, `sdlc.wiki(_project)`, and `sdlc.issue_tracker(_project)` when populated. Explicit user names/handles win for this run; a recognizable provider URL or handle is valid evidence (a Confluence URL implies Confluence). If evidence conflicts or stays ambiguous, ask only about the unresolved provider; a missing `gain.json` never blocks a direct-description run.
-3. **Derive `{IDENTIFIER}`** per the `qa-structure` rule (Issue Tracker key → TMS case ID → kebab-case feature). On multiple candidates, first non-empty wins; record the chosen value + rejected candidates in `initial-data.md`.
-4. **Create the session directory** `plans/api-aqa-{IDENTIFIER}/` and write the **state-file stub** below to `agents/TEMP/<FEATURE>/api-aqa-state.md`. The full per-phase update schema is owned by `api-aqa-flow.md` `<state_file>`; this stub is only the seed:
+1. **Parse input.** Extract:
+   - **Test case reference** (REQUIRED): TMS case ID, Issue Tracker key/URL, or description.
+   - **Additional context** (OPTIONAL): Swagger URL, Wiki pages, API docs.
+   - Phrasings: `"Write API tests for TC-1234"`, `"Automate backend tests for PROJ-123"`, `"Create API tests for the user registration endpoint"`.
+2. **Resolve providers (merge evidence; do not force one source).** Read `gain.json`; use `sdlc.test_management(_project)`, `sdlc.wiki(_project)`, `sdlc.issue_tracker(_project)` when populated. Explicit user input wins for this run; URL/handle is valid evidence (Confluence URL → Confluence). Conflicts → ask only unresolved provider. Missing `gain.json` ≠ block.
+3. **Derive `{IDENTIFIER}`** per `qa-structure` (Issue Tracker key → TMS case ID → kebab-case). First non-empty wins; record chosen + rejected in `initial-data.md`.
+4. **Create** `plans/api-aqa-{IDENTIFIER}/`; write **state-file stub** to `agents/TEMP/<FEATURE>/api-aqa-state.md`:
 
    ```markdown
    # API AQA State - <Test Name / Feature>
@@ -63,25 +63,25 @@ USE SKILL `qa-structure` for the session layout, `{IDENTIFIER}` derivation, and
    - [ ] Phase 6: Execution & Report Analysis
    - [ ] Phase 7: Test Corrections
    ```
-5. **Load or create the project config** at `plans/api-aqa-{IDENTIFIER}/api-aqa-project-config.md` (per-session, inside the feature plan folder): if the file exists AND is non-empty → `<config_exists>`; if it is missing OR empty → `<config_missing>`.
-6. **Verify** the feature plan folder `plans/api-aqa-{IDENTIFIER}/` exists and the config is non-empty before proceeding.
+5. **Load or create** `plans/api-aqa-{IDENTIFIER}/api-aqa-project-config.md`: exists AND non-empty → `<config_exists>`; missing OR empty → `<config_missing>`.
+6. **Verify** `plans/api-aqa-{IDENTIFIER}/` exists and config non-empty.
 
 </execute_config>
 
 <config_exists step="0.1.5a">
-1. Reuse the existing config as-is; skip to step 0.2 — nothing to collect, no user interaction.
-2. Still confirm every required key from `qa-structure`'s config-key schema is present; a malformed / incomplete existing config is handled per `<failure_handling>` (the config-incomplete branch).
+1. Reuse existing config; skip to step 0.2.
+2. Confirm all required config keys present per `qa-structure` schema; malformed → `<failure_handling>` config-incomplete.
 </config_exists>
 
 <config_missing step="0.1.5b">
-1. Pre-fill every key already resolved by step 0.1.2 provider evidence (`gain.json` + user input); then collect ONLY the still-unresolved project info from the user — USE SKILL `questioning` asking the config-missing interview prompt owned by `qa-structure`, trimmed to the missing keys.
-2. Validate the answers + prefill cover at minimum: Wiki/document storage, Swagger/OpenAPI availability, and the test-case source (TMS). If a required field is missing, ask ONE follow-up naming exactly the missing fields — cap 2 rounds total.
-3. Write the populated config using `qa-structure`'s config template, applying `<safety_boundaries>` redaction at intake.
-4. Required keys + accepted `N/A` forms are in `qa-structure`'s config-key schema.
+1. Pre-fill resolved keys; USE SKILL `questioning` for missing keys (config-missing prompt from `qa-structure`, trimmed to gaps).
+2. Validate at minimum: Wiki storage, Swagger availability, TMS source. ONE follow-up naming exactly the missing fields — 2 rounds max.
+3. Write populated config using `qa-structure`'s config template, applying `<safety_boundaries>` redaction at intake.
+4. Required keys + accepted `N/A` forms in `qa-structure`'s config-key schema.
 </config_missing>
 
 <create_initial_data step="0.2">
-Write `plans/api-aqa-{IDENTIFIER}/initial-data.md` using the template below; all four fields populated from the parsed input (`None` only for additional-links):
+Write `plans/api-aqa-{IDENTIFIER}/initial-data.md`; all four fields from parsed input (`None` only for additional-links):
 
 ```markdown
 # Initial Data — [IDENTIFIER]
@@ -105,33 +105,33 @@ Write `plans/api-aqa-{IDENTIFIER}/initial-data.md` using the template below; all
 
 <safety_boundaries>
 
-`plans/api-aqa-{IDENTIFIER}/api-aqa-project-config.md` is **tracked** — PUBLIC by default; user answers can carry credential-shaped values. **Auth fields record scheme + strategy + source** (e.g. `Bearer JWT from AuthHelper; credentials in env vars E2E_USER + E2E_PASS`), **never literal** tokens/passwords/keys/`client_secret` — regardless of "test"/"throwaway" labels; TMS / Issue Tracker access tokens (e.g. TestRail API key, Jira PAT) → `MCP-managed` or `env var <NAME>`.
+`plans/api-aqa-{IDENTIFIER}/api-aqa-project-config.md` is **tracked** — PUBLIC by default. **Auth fields record scheme + strategy + source** (e.g. `Bearer JWT from AuthHelper; credentials in env vars E2E_USER + E2E_PASS`), **never literal** tokens/passwords/keys/`client_secret` — regardless of "test"/"throwaway" labels; TMS / Issue Tracker access tokens (e.g. TestRail API key, Jira PAT) → `MCP-managed` or `env var <NAME>`.
 
-**Redaction at intake (pre-write gate, fail-closed):** USE SKILL `sensitive-data` and run its scan against the populated config BEFORE writing — no scan (skill unavailable included) → STOP, never write unscanned. On a hit, replace the literal with mechanism+source and add to `## Additional Notes`: `Original auth answer included a literal <kind> — redacted; request mechanism+source from user if env var name is unknown.` Structure (endpoint paths, framework names, credential-free URLs, project keys) stays verbatim; redaction targets sensitive VALUES only.
+**Redaction at intake (pre-write gate, fail-closed):** USE SKILL `sensitive-data`, scan config BEFORE writing — no scan (skill unavailable included) → STOP, never write unscanned. Hit → replace with mechanism+source; add to `## Additional Notes`: `Original auth answer included a literal <kind> — redacted; request mechanism+source from user if env var name is unknown.` Structure (endpoint paths, framework names, credential-free URLs, project keys) verbatim; redact VALUES only.
 
 </safety_boundaries>
 
 <failure_handling>
 
-- **Test case reference missing or unparseable** (step 0.1 cannot extract a TMS case ID, Issue Tracker key, or feature description): stop, record `Phase 0 blocked: test case reference unresolvable from initial prompt "<prompt>"` in `agents/TEMP/<FEATURE>/api-aqa-state.md`, and ask the user for a TMS case ID, Issue Tracker key, or kebab-case feature name. Do NOT fabricate an `{IDENTIFIER}` — every downstream path depends on it.
-- **`{IDENTIFIER}` underivable / ambiguous** (no Issue Tracker key, no TMS case ID, no usable feature name — or several): apply the `qa-structure` precedence (Issue Tracker key → TMS case ID → kebab-case; first non-empty wins) and record chosen + rejected candidates in `initial-data.md`. If still none, ask the user once (naming the three preference levels). After one unsuccessful re-ask, record `Phase 0 blocked: IDENTIFIER unresolvable — awaiting user supply` and stop. Do NOT pick a default like `unknown` or `tmp-N` — `{IDENTIFIER}` is referenced in every downstream phase's paths and a guess pollutes the entire AQA session.
-- **User questioning still incomplete after follow-up** (a required field — Wiki/doc storage, Swagger availability, or TMS test-case source — is still missing after the 2-round cap): stop, record `Phase 0 blocked: minimum project info not obtained after follow-up — missing: <list>` in `agents/TEMP/<FEATURE>/api-aqa-state.md`. Do NOT silently fall back to TBD for fields the user actually declined. (`TBD — will discover from codebase/spec` is acceptable only when the user explicitly opts into discovery.)
-- **User-pasted literal credential in an answer:** apply `<safety_boundaries>` Redaction-at-intake. If the env-var name is unknown, ask once.
-- **Existing config file malformed / missing required config-schema keys:** treat as `config-incomplete` — re-run only the collect-from-user branch (`questioning`) for the missing keys, then re-write the config preserving clean sections, and re-verify. Surface the corruption in `initial-data.md` notes. Do NOT advance to Phase 1 with an incomplete config — Phase 1's Wiki collection will silently degrade if `wiki_provider` is absent rather than `N/A`-tagged.
-- **`agents/TEMP/<FEATURE>/api-aqa-state.md` or `api-aqa-project-config.md` unwritable** (permission denied, file locked, disk full): pause, report the filesystem error with the path; do not mark Phase 0 complete.
-- **Session directory `plans/api-aqa-{IDENTIFIER}/` not created:** create it directly (simple mkdir), then re-run verification. If the create fails, stop and report the filesystem error.
+- **Test case reference missing or unparseable** (step 0.1 cannot extract TMS case ID, Issue Tracker key, or feature description): stop, record `Phase 0 blocked: test case reference unresolvable from initial prompt "<prompt>"` in `agents/TEMP/<FEATURE>/api-aqa-state.md`; ask for TMS case ID, Issue Tracker key, or kebab-case feature name. Do NOT fabricate `{IDENTIFIER}`.
+- **`{IDENTIFIER}` underivable / ambiguous:** apply `qa-structure` precedence (Issue Tracker key → TMS case ID → kebab-case; first non-empty wins); record chosen + rejected in `initial-data.md`. If still none, ask once (naming three preference levels). After one re-ask, record `Phase 0 blocked: IDENTIFIER unresolvable — awaiting user supply` → stop. Do NOT default to `unknown` or `tmp-N`.
+- **User questioning incomplete after follow-up** (Wiki storage, Swagger availability, or TMS source still missing after 2-round cap): stop, record `Phase 0 blocked: minimum project info not obtained after follow-up — missing: <list>` in `agents/TEMP/<FEATURE>/api-aqa-state.md`. Do NOT silently fall back to TBD. (`TBD — will discover from codebase/spec` only if user explicitly opts in.)
+- **User-pasted literal credential:** apply `<safety_boundaries>` redaction. If env-var name unknown, ask once.
+- **Existing config malformed / missing required keys:** `config-incomplete` — re-run collect-from-user branch (`questioning`) for missing keys, re-write preserving clean sections, re-verify. Surface corruption in `initial-data.md`. Do NOT advance to Phase 1 with incomplete config.
+- **`agents/TEMP/<FEATURE>/api-aqa-state.md` or `api-aqa-project-config.md` unwritable** (permission denied, file locked, disk full): pause, report filesystem error with path; do not mark Phase 0 complete.
+- **Session directory `plans/api-aqa-{IDENTIFIER}/` not created:** create directly, re-run verification. Create failure → stop, report filesystem error.
 
 </failure_handling>
 
 <validation_checklist>
-- `plans/api-aqa-{IDENTIFIER}/` directory exists
-- `api-aqa-project-config.md` exists in the feature plan folder (per `qa-structure`) with non-empty content — either pre-existing or freshly written
-- **Every required key from `qa-structure`'s config-key schema is present** — populated with a real value OR explicitly marked `N/A — <reason>`; no key absent / blank / `TBD` without a documented next-step
-- `initial-data.md` created per the inline initial-data template (step 0.2) with all four required fields populated
-- `agents/TEMP/<FEATURE>/api-aqa-state.md` created with Phase 0 marked complete and `IDENTIFIER:` field matching the `plans/api-aqa-{IDENTIFIER}/` directory name
-- `{IDENTIFIER}` value identical across (a) directory name, (b) api-aqa-state.md IDENTIFIER field, (c) initial-data.md path; no fabricated `{IDENTIFIER}`
-- Redaction pre-write gate ran — `sensitive-data` scan executed against the config before write; no literal credential persisted; any redaction noted in `## Additional Notes`
-- No failure-handling condition from `<failure_handling>` is currently active — every listed scenario has either not been triggered or has been remediated
+- `plans/api-aqa-{IDENTIFIER}/` exists
+- `api-aqa-project-config.md` in `plans/api-aqa-{IDENTIFIER}/` exists + non-empty (per `qa-structure`)
+- Every required config key (per `qa-structure`) present — real value OR `N/A — <reason>`; none absent/blank/`TBD` without documented next-step
+- `initial-data.md` exists; all four fields populated
+- `agents/TEMP/<FEATURE>/api-aqa-state.md` created; Phase 0 complete; `IDENTIFIER:` matches `plans/api-aqa-{IDENTIFIER}/` directory name
+- `{IDENTIFIER}` identical across: (a) directory name, (b) `api-aqa-state.md` IDENTIFIER field, (c) `initial-data.md` path; no fabricated `{IDENTIFIER}`
+- Redaction gate ran: `sensitive-data` scan complete, no literals persisted, redactions in `## Additional Notes`
+- No unremediated `<failure_handling>` condition remains
 </validation_checklist>
 
 </api_aqa_flow_project_config_loading>
diff --git a/instructions/r3/core/workflows/api-aqa-flow-test-case-specification.md b/instructions/r3/core/workflows/api-aqa-flow-test-case-specification.md
index 60998081..2b303ef2 100644
--- a/instructions/r3/core/workflows/api-aqa-flow-test-case-specification.md
+++ b/instructions/r3/core/workflows/api-aqa-flow-test-case-specification.md
@@ -10,16 +10,16 @@ baseSchema: docs/schemas/phase.md
 <api_aqa_flow_test_case_specification>
 
 <description_and_purpose>
-Convert test cases into detailed, implementation-ready API test specifications using Given-When-Then format. User approval required before implementation.
+Convert test cases to implementation-ready Given-When-Then API test specs. User approval required before implementation.
 </description_and_purpose>
 
 <workflow_context>
 - Phase 4 of 8 in `api-aqa-flow`
-- Input: all phase 1-3 outputs (raw data, API analysis, gap analysis)
+- Input: phase 1-3 outputs (raw data, API analysis, gap analysis)
 - Output: `plans/api-aqa-{IDENTIFIER}/test-specs.md` with Given-When-Then scenarios, file mapping, shared utilities
-- Prerequisite: Phase 3 complete, all user clarifications received
+- Prerequisite: Phase 3 complete, clarifications received
 - HITL: explicit user approval required before Phase 5
-- Required skills: `qa-knowledge` (`scenario_design` mode + test-specs skeleton + ATC conventions), `sensitive-data` (redaction), `qa-structure` (`{IDENTIFIER}` + artifact path)
+- Required skills: `qa-knowledge` (`scenario_design`·test-specs skeleton·ATC conventions), `sensitive-data` (redaction), `qa-structure` (`{IDENTIFIER}`·artifact path)
 - Recommended skills: `hitl` (explicit approval)
 </workflow_context>
 
@@ -34,36 +34,43 @@ Convert test cases into detailed, implementation-ready API test specifications u
 <load_inputs step="4.1">
 
 Read completely:
-1. `plans/api-aqa-{IDENTIFIER}/raw-data.md` — original test cases and patterns
+1. `plans/api-aqa-{IDENTIFIER}/raw-data.md` — test cases & patterns
 2. `plans/api-aqa-{IDENTIFIER}/api-analysis.md` — endpoint contracts
-3. `plans/api-aqa-{IDENTIFIER}/analysis.md` — clarifications and resolved gaps
+3. `plans/api-aqa-{IDENTIFIER}/analysis.md` — clarifications & resolved gaps
 
 </load_inputs>
 
 <execute_authoring step="4.2" subagent="architect" role="Test specification author">
 
-1. USE SKILL `qa-knowledge` (`scenario_design` mode) with all loaded inputs from step 4.1. This phase OWNS the output contract — the spec artifact shape is `qa-knowledge`'s test-spec template (the skill loads its own asset) plus the file-mapping / shared-utilities / execution-order sections; the mode EMITS Given-When-Then ATC entries into them per its GWT-spec taxonomy and process.
-2. Redact any captured credentials, tokens, PII, or credentialed URLs in the emitted spec → USE SKILL `sensitive-data`.
-3. The mode produces: test scenarios, GWT specs, file mapping, shared utilities, execution order.
+1. USE SKILL `qa-knowledge` (`scenario_design`); all inputs from step 4.1.
+2. Redact credentials, tokens, PII, credentialed URLs → USE SKILL `sensitive-data`.
 
 </execute_authoring>
 
 <produce_output step="4.3">
 
-**Before presenting:** every item in `<validation_checklist>` below must be satisfied for the produced file. Items that are not yet verifiable at this step (e.g., user approval) are checked at step 4.5.
-
-Create `plans/api-aqa-{IDENTIFIER}/test-specs.md` per `qa-knowledge`'s test-spec template — it carries the full skeleton: Summary, Test Scenarios (per-endpoint `ATC-NNN` Given-When-Then with a worked example), Test File Mapping, Shared Utilities, Execution Order, Assumptions.
+Create `plans/api-aqa-{IDENTIFIER}/test-specs.md` per `qa-knowledge`'s test-spec template.
+Sections: Summary · Test Scenarios · Test File Mapping · Shared Utilities · Execution Order · Assumptions.
 
 </produce_output>
 
 <present_for_approval step="4.4">
-1. Present summary to user: total scenarios, priority breakdown, endpoints covered.
-2. **Approval gate:** USE SKILL `qa-knowledge` to run its shared approval gate; USE SKILL `hitl`. Approval = an exact token from the closed list `approved` / `approve` / `yes` (case-insensitive), scoped to the presented specs — no `"or equivalent"` / `"or similar"` phrasing extends it. Comments, questions, suggestions, edits, and partial review are REVIEW, not approval. Bindings: re-present step = 4.3; full-reject revisit target = Phase 3. Treat partial approve as a change request that drops the rejected scenarios.
+1. Present summary: total scenarios, priority breakdown, endpoints covered.
+2. **Approval gate:** USE SKILL `qa-knowledge` (approval gate); USE SKILL `hitl`.
+   Approval = exact token: `approved` / `approve` / `yes` (case-insensitive), scoped to specs.
+   No `"or equivalent"` / `"or similar"` extends it.
+   Comments, questions, suggestions, edits, partial review = REVIEW ≠ approval.
+   Bindings: re-present step = 4.3; full-reject revisit target = Phase 3.
+   Partial approve = change request; drop rejected scenarios.
 3. **DO NOT PROCEED** to Phase 5 without explicit approval.
 </present_for_approval>
 
 <update_state step="4.5">
-1. **GATE — before marking complete:** re-run `<validation_checklist>` and confirm every item is checked off — **in particular that every `ATC-NNN` traces to a Phase 3 source** (`test-specs.md` is Phase 5's contract; an untraceable ATC means Phase 5 implements unverifiable tests). Report `Phase 4 checklist: N/N items satisfied` in chat. Do NOT mark complete if any item fails.
+1. **GATE — before marking complete:**
+   Re-run `<validation_checklist>`; confirm every item passes.
+   **Every `ATC-NNN` traces to a Phase 3 source.**
+   Report `Phase 4 checklist: N/N items satisfied` in chat.
+   Do NOT mark complete if any item fails.
 2. Update `agents/TEMP/<FEATURE>/api-aqa-state.md`:
    - Test Cases Specified: [count]
    - Priority Breakdown: P0: [N], P1: [N], P2: [N], P3: [N]
@@ -74,22 +81,22 @@ Create `plans/api-aqa-{IDENTIFIER}/test-specs.md` per `qa-knowledge`'s test-spec
 </update_state>
 
 <validation_checklist>
-- All source test cases converted to detailed specifications
-- Given-When-Then format used for every scenario
 - **Every `ATC-NNN` traces to a Phase 3 source** — its `**Source:**` line cites a `raw-data.md` test case (`TC-NNN`) and/or an `analysis.md` finding (`G[N]`/`C[N]`/`A[N]`); no untraceable ATC
 - Exact request values specified (no placeholders)
 - Exact response assertions defined
 - Auth and error scenarios covered
-- Test file mapping defined
-- Shared utilities identified
 - Explicit user approval received (comments, questions, or suggestions are not approval)
 </validation_checklist>
 
 <failure_handling>
-- **Missing input file** (`raw-data.md`, `api-analysis.md`, or `analysis.md` absent or empty): stop Phase 4, record `Phase 4 blocked: missing [artifact]` in `agents/TEMP/<FEATURE>/api-aqa-state.md`, ask user to re-run the producing phase.
-- **Unresolved Phase 3 gaps** (analysis.md still has `BLOCKING ASSUMPTION` entries): stop, record `Phase 4 blocked: Phase 3 has open Critical questions`, send user back to Phase 3.
-- **Mode produces zero scenarios** (`qa-knowledge` scenario_design returns empty): stop, record the failure, ask user to verify inputs and re-run.
-- **Repeated rejection cycle:** after the 3rd cycle of reject-and-re-present per `<present_for_approval>` step 3, stop and ask the user whether to re-open Phase 3 or escalate scope.
+- **Missing input** (`raw-data.md`, `api-analysis.md`, `analysis.md` absent/empty):
+  record `Phase 4 blocked: missing [artifact]` → `agents/TEMP/<FEATURE>/api-aqa-state.md`; stop, ask re-run producing phase.
+- **Unresolved Phase 3 gaps** (`BLOCKING ASSUMPTION` in analysis.md):
+  record `Phase 4 blocked: Phase 3 has open Critical questions`; send user to Phase 3.
+- **Zero scenarios** (`qa-knowledge` `scenario_design` empty):
+  record failure; stop, ask verify inputs, re-run.
+- **Repeated rejection (3rd cycle):**
+  stop → ask: re-open Phase 3 or escalate scope.
 </failure_handling>
 
 </api_aqa_flow_test_case_specification>
diff --git a/instructions/r3/core/workflows/api-aqa-flow-test-correction.md b/instructions/r3/core/workflows/api-aqa-flow-test-correction.md
index e6d1c984..d9cf948c 100644
--- a/instructions/r3/core/workflows/api-aqa-flow-test-correction.md
+++ b/instructions/r3/core/workflows/api-aqa-flow-test-correction.md
@@ -10,22 +10,22 @@ baseSchema: docs/schemas/phase.md
 <api_aqa_flow_test_correction>
 
 <description_and_purpose>
-Fix identified API test failures based on the Phase 6 execution report. Prepares proposed changes, requires explicit user approval before applying, then applies them incrementally with lint checks and hands re-testing back to the user.
+Fix Phase 6 API test failures: prepare proposed changes, gate on explicit user approval, apply incrementally with lint checks, hand re-testing back.
 </description_and_purpose>
 
 <workflow_context>
 - Phase 7 of 8 in `api-aqa-flow`
-- Input: execution report from Phase 6 (`plans/api-aqa-{IDENTIFIER}/execution-report.md`; resolve `{IDENTIFIER}` from `agents/TEMP/<FEATURE>/api-aqa-state.md`)
+- Input: `plans/api-aqa-{IDENTIFIER}/execution-report.md`; resolve `{IDENTIFIER}` from `agents/TEMP/<FEATURE>/api-aqa-state.md`
 - Output: corrected test code, ready for re-testing
 - Prerequisite: Phase 6 complete
-- HITL: explicit user approval required before applying any change (a domain-specific specialization of `hitl`)
-- In-scope file set (single SSoT): test files + shared test-utility files only. Writes outside this set are refused and escalated.
-- Required skills: `qa-knowledge` (`correction` mode — proposed-change block + approval gate + correction discipline), `qa-structure` (run paths + `api-aqa-state.md`)
-- Recommended skills: `coding` (authors the proposed/applied edits), `debugging` (root-cause alignment), `hitl` (explicit approval)
+- HITL: explicit user approval required before applying any change
+- In-scope file set (single SSoT): test files + shared test-utility files only; writes outside refused and escalated.
+- Required skills: `qa-knowledge` (`correction` mode), `qa-structure`
+- Recommended skills: `coding`, `debugging`, `hitl`
 </workflow_context>
 
 <correction_contract>
-The phase OWNS the iteration cap and the escalation contract. The proposed-change approval block is `qa-knowledge`'s shared proposed-change template (the skill loads its own asset at step 7.1) — present one block per change BEFORE any write. Flow parameters for the template: **change-type enum** = `assertion-fix | auth-fix | data-setup | request-shape | wait-strategy | other`; **root-cause reference** = execution-report entry id (e.g. `ERR-3`); **state file** = `agents/TEMP/<FEATURE>/api-aqa-state.md`; on retry-cap, loop back to Phase 6. Verified by `<validation_checklist>` independent of skill internals.
+One proposed-change block per fix BEFORE any write (USE SKILL `qa-knowledge` template). Flow params: **change-type enum** = `assertion-fix | auth-fix | data-setup | request-shape | wait-strategy | other`; **root-cause ref** = execution-report entry id (e.g. `ERR-3`); **state file** = `agents/TEMP/<FEATURE>/api-aqa-state.md`; retry-cap → return to Phase 6.
 </correction_contract>
 
 <phase_steps>
@@ -36,22 +36,22 @@ The phase OWNS the iteration cap and the escalation contract. The proposed-chang
 </phase_steps>
 
 <execute_corrections step="7.1" subagent="engineer" role="Test correction engineer">
-**Preparation-only:** nothing in this block modifies workspace files until step 7.3 after explicit approval in 7.2. "Preparation-only" means proposed edits paired with before/after evidence — no writes to test or product source files.
-1. USE SKILL `qa-structure` to resolve run paths/`api-aqa-state.md`. USE SKILL `debugging` to align each proposed edit with a confirmed Phase 6 root cause (no symptom-only fixes).
-2. USE SKILL `qa-knowledge` (`correction` mode) and USE SKILL `coding` to author each proposed edit (preparation-only — before/after evidence, no writes). The present → approve → apply discipline is owned by this phase: `<present_for_approval>` (7.2) + `<apply_changes>` (7.3). Bindings grouped by owner: proposed-change source = `plans/api-aqa-{IDENTIFIER}/execution-report.md`; proposed-change template + state file + iteration cap + loop target = `<correction_contract>`; in-scope file set = `<workflow_context>`; approval-token set = step 7.2.
-3. Produce one Proposed Change record per fix per the `<correction_contract>` template, citing the matching execution-report entry id (e.g. `ERR-3`). Do NOT apply anything yet.
+**Preparation-only:** no writes until step 7.3 (after explicit approval in 7.2); proposed edits = before/after evidence — no writes to test or product source files.
+1. USE SKILL `qa-structure` → resolve run paths/`api-aqa-state.md`. USE SKILL `debugging` → align each edit to confirmed Phase 6 root cause; no symptom-only fixes.
+2. USE SKILL `qa-knowledge` (`correction` mode) + USE SKILL `coding` → author each proposed edit. Source: `plans/api-aqa-{IDENTIFIER}/execution-report.md`. Discipline: `<present_for_approval>` (7.2) + `<apply_changes>` (7.3).
+3. Produce one Proposed Change record per fix (per `<correction_contract>`), citing entry id (e.g. `ERR-3`). DO NOT apply anything yet.
 </execute_corrections>
 
 <present_for_approval step="7.2">
-1. Present all proposed changes with before/after code per the template.
-2. **Approval gate:** USE SKILL `qa-knowledge` to run its shared approval gate; USE SKILL `hitl`. Approval = an exact token from the closed list `approved` / `approve` / `yes` (case-insensitive), scoped to the named changes — no `"or equivalent"` / `"or similar"` phrasing extends it. Comments, questions, suggestions, edits, and partial review are REVIEW, not approval. Partial approval applies only to named changes/hunks; re-present changed proposals (re-present step = 7.2); full rejection returns to Phase 6.
+1. Present all proposed changes with before/after code.
+2. **Approval gate:** USE SKILL `qa-knowledge` (approval gate); USE SKILL `hitl`. Approval = exact token `approved` / `approve` / `yes` (case-insensitive), scoped to named changes — no `"or equivalent"` / `"or similar"` extends it. Comments, questions, suggestions, edits, and partial review are REVIEW, not approval. Partial approval → named changes/hunks only; re-present at 7.2. Full rejection → Phase 6.
 </present_for_approval>
 
 <apply_changes step="7.3">
 1. Apply approved changes one at a time (or in named approved batches).
-2. Validate linting/format after each change. On lint failure: revert that change (never leave the file broken), re-prepare a corrected version, and re-present that single change via `<present_for_approval>`.
-3. Verify each applied change addresses its root cause by cross-referencing it to the matching entry in `plans/api-aqa-{IDENTIFIER}/execution-report.md` (cite the entry id, e.g. `ERR-3`). On root-cause mismatch: return to step 7.1 with a note in `agents/TEMP/<FEATURE>/api-aqa-state.md`; do not leave unmapped changes applied.
-4. **Max retries:** apply the `<correction_contract>` iteration cap — on the 3rd failed cycle for the same change, stop, record `Phase 7 blocked: in-phase apply retry cap reached` in `api-aqa-state.md`, escalate to the user.
+2. Validate lint/format after each change. Lint failure → revert that change (never leave the file broken), re-prepare, re-present that single change via `<present_for_approval>`.
+3. Cross-reference each change to `plans/api-aqa-{IDENTIFIER}/execution-report.md` (cite id, e.g. `ERR-3`). Root-cause mismatch → return to 7.1 with note in `agents/TEMP/<FEATURE>/api-aqa-state.md`; do not leave unmapped changes applied.
+4. **Max retries:** `<correction_contract>` cap — 3rd failed cycle → stop, record `Phase 7 blocked: in-phase apply retry cap reached` in `api-aqa-state.md`, escalate to user.
 </apply_changes>
 
 <update_state step="7.4">
@@ -63,25 +63,24 @@ The phase OWNS the iteration cap and the escalation contract. The proposed-chang
    - Status: Ready for re-testing
    - Phase 7 completion timestamp
 2. Mark Phase 7 complete.
-3. Inform the user to re-run tests (provide the exact command).
+3. Tell user to re-run tests (provide exact command).
 4. If tests still fail: return to Phase 6.
 </update_state>
 
 <validation_checklist>
-- Phase 6 analysis reviewed; each proposed change linked to a confirmed root cause (execution-report entry id cited)
-- Proposed changes prepared with before/after code per the `<correction_contract>` template
-- User approval explicitly received per `<present_for_approval>` (no inferred approval); partial approval applied only to named changes/hunks
-- All approved changes applied; only in-scope files touched
-- Linting/format checked and fixed after each change (lint failure reverted + re-presented, never left broken)
-- Changes address identified root causes; iteration cap honored, escalation recorded if reached
-- State updated without auto-looping; re-run instruction provided
+- Each change record cites an ERR-N root cause.
+- Approval in state: datetime + token + approved IDs/hunks.
+- `Files Modified` contains only test/shared-utility files.
+- Each modified file passes lint.
+- If cap hit: `Phase 7 blocked: in-phase apply retry cap reached` recorded in state.
+- Phase 7 timestamp + re-run command in state.
 </validation_checklist>
 
 <failure_handling>
-- **Execution report absent/empty:** if `plans/api-aqa-{IDENTIFIER}/execution-report.md` does not exist or has no failure entries, stop Phase 7, record `Phase 7 blocked: Phase 6 execution report missing/empty` in `agents/TEMP/<FEATURE>/api-aqa-state.md`, and return to Phase 6 — never fabricate proposed changes against a missing report.
-- **`agents/TEMP/<FEATURE>/api-aqa-state.md` missing or `{IDENTIFIER}` unresolvable:** stop Phase 7, record the failure in chat output, ask the user to restore the state file; do not auto-recreate it and do not guess `{IDENTIFIER}` (every input/output path depends on it).
-- **Required skill, approval gate, or proposed-change template unavailable** (`qa-structure`, `debugging`, `qa-knowledge`, `coding`, or `hitl` fails to load at step 7.1/7.2): retry once, then stop — do NOT present a correction block or run the approval gate from memory. Report the failed load and ask the user to fix Rosetta access.
-- **No change maps to a confirmed root cause:** if `debugging` (step 7.1.1) cannot align a proposed edit to a confirmed Phase 6 root cause, do not propose it; record the unmapped failure and return to Phase 6 for deeper analysis rather than applying a symptom-only fix.
+- **Execution report absent/empty:** `plans/api-aqa-{IDENTIFIER}/execution-report.md` missing/empty → record `Phase 7 blocked: Phase 6 execution report missing/empty` in `agents/TEMP/<FEATURE>/api-aqa-state.md`, return to Phase 6; never fabricate changes against a missing report.
+- **`agents/TEMP/<FEATURE>/api-aqa-state.md` missing or `{IDENTIFIER}` unresolvable:** record failure in chat, ask user to restore; do not auto-recreate; do not guess `{IDENTIFIER}`.
+- **Required skill/gate/template unavailable** (`qa-structure`, `debugging`, `qa-knowledge`, `coding`, or `hitl` fails to load at 7.1/7.2): retry once, then stop — do NOT present a correction block or run the approval gate from memory; report, ask user to fix Rosetta access.
+- **No change maps to confirmed root cause:** `debugging` (step 7.1 item 1) cannot align edit to Phase 6 root cause → do not propose; record, return to Phase 6; no symptom-only fixes.
 </failure_handling>
 
 </api_aqa_flow_test_correction>
diff --git a/instructions/r3/core/workflows/api-aqa-flow-test-implementation.md b/instructions/r3/core/workflows/api-aqa-flow-test-implementation.md
index c8e6414a..a8a6f4f8 100644
--- a/instructions/r3/core/workflows/api-aqa-flow-test-implementation.md
+++ b/instructions/r3/core/workflows/api-aqa-flow-test-implementation.md
@@ -10,56 +10,49 @@ baseSchema: docs/schemas/phase.md
 <api_aqa_flow_test_implementation>
 
 <description_and_purpose>
-Implement all approved API test specifications as executable automated tests with shared utilities (auth, data factories, response validation), validate locally (lint-clean), then hand execution off to the user. The phase implements → validates → hands off → updates state without closing the workflow.
+Implement approved API specs → executable tests + shared utilities (auth, factories, validators); validate locally (lint-clean); hand execution to user; update state without closing workflow.
 </description_and_purpose>
 
 <workflow_context>
 - Phase 5 of 8 in `api-aqa-flow`
-- Input: approved test specs `plans/api-aqa-{IDENTIFIER}/test-specs.md` + existing patterns + API analysis (`api-analysis.md`); resolve `{IDENTIFIER}` from `agents/TEMP/<FEATURE>/api-aqa-state.md`
-- Output: implemented test files + shared utilities, lint-clean; state updated; user given an execution command
-- Prerequisite: Phase 4 complete with recorded user approval of the specs
-- HITL: must stop and wait for the user to execute the tests (this phase does not run them)
-- Write boundary (single SSoT — referenced by other sections): writes test files + shared test-utility files only; synthetic data only — no hardcoded credentials, URLs, or production data.
+- Input: `plans/api-aqa-{IDENTIFIER}/test-specs.md` + existing patterns + `api-analysis.md`; resolve `{IDENTIFIER}` from `agents/TEMP/<FEATURE>/api-aqa-state.md`
+- Output: test files + shared utilities, lint-clean; state updated; execution command given
+- Prerequisite: Phase 4 complete with recorded user approval of specs
+- HITL: stop and wait for user to execute tests; phase does not run them
+- Write boundary: test files + shared test-utility files only; synthetic data only — no hardcoded credentials, URLs, or production data
 - Required skills: `qa-knowledge` (`implementation_modes` — API impl + hand-off record fields), `qa-structure` (`{IDENTIFIER}` + artifact path)
 - Recommended skills: `testing` (test quality discipline), `coding` (repo conventions)
 </workflow_context>
 
 <implementation_handoff_contract>
-This phase OWNS the implement → validate-locally → hand-off-execution → update-state-without-closing contract. Verified by `<validation_checklist>` independent of skill internals.
-
-- **Implement** — author tests + shared utilities via `qa-knowledge` `implementation_modes` (API impl) against the approved specs; USE SKILL `testing` for general test quality; use `coding` for repo conventions (read repo standards as authority; repo docs win).
-- **Validate locally** — lint/format clean on touched files; every ATC implemented OR surfaced as a Gap (no silent ATC drop); tests isolated + idempotent; test-data lifecycle (create + cleanup) verified.
-- **Hand off execution** — provide the exact project test-execution command; STOP and WAIT for the user to run it (`<stop_for_execution>`). The phase never executes the tests itself.
-- **Update state without closing** — record outcome in `agents/TEMP/<FEATURE>/api-aqa-state.md`, mark Phase 5 complete, set Phase 6 current; do NOT mark the overall AQA workflow COMPLETE.
-
-**Hand-off summary fields** (returned by the implementing skill, verified by this phase) → `qa-knowledge`'s test-implementation record (the skill loads its own asset) — the ordered field list (framework, file counts, `### Files`, `### ATC → test mapping`, `### Assumptions made`, `### Gaps surfaced`, `### Lint / format status`, `### Validation scope & waivers`, `### Ready for re-test`).
+**Hand-off summary fields** → `qa-knowledge`'s test-implementation record: `framework`, file counts, `### Files`, `### ATC → test mapping`, `### Assumptions made`, `### Gaps surfaced`, `### Lint / format status`, `### Validation scope & waivers`, `### Ready for re-test`.
 </implementation_handoff_contract>
 
 <phase_steps>
-1. Implement and validate the tests locally (step 5.1)
-2. Validate against requirements (step 5.2)
-3. Stop for user test execution (step 5.3)
-4. Update state (step 5.4)
+1. Implement + validate tests locally (5.1)
+2. Run validation checklist (5.2)
+3. Stop for user execution (5.3)
+4. Update state (5.4)
 </phase_steps>
 
 <execute_implementation step="5.1" subagent="engineer" role="Test automation engineer">
-1. USE SKILL `qa-structure` to resolve `{IDENTIFIER}`/run paths. GATE: confirm `plans/api-aqa-{IDENTIFIER}/test-specs.md` exists, is non-empty, and `User Approval` is set in `agents/TEMP/<FEATURE>/api-aqa-state.md`; confirm `api-analysis.md` and discoverable existing patterns are present. On any failure apply `<failure_handling>` — never author from unapproved or incomplete inputs.
-2. USE SKILL `coding` to read the repository standards as authority before authoring; repo docs beat model defaults.
-3. USE SKILL `qa-knowledge` (`implementation_modes` — API impl) and USE SKILL `testing` with the parent-supplied bindings: approved-specs path + the recorded approval signal; API-contract path; existing-patterns source; write boundary = test + shared-utility files only (`<workflow_context>`); output = the hand-off summary fields per `<implementation_handoff_contract>`.
-4. Implement shared utilities (auth helper, data factory, response validator) — prefer EXTENDING existing helpers over parallel ones; record any extension. Every test name/docstring carries its ATC-NNN id.
-5. Record assumptions as `[ASSUMED: <field>=<value>]` (code + summary) and surface any unimplementable ATC as a Gap — no silent ATC drop.
-6. Validate locally: run the project lint/format command on touched files and resolve issues; emit the hand-off summary.
+1. USE SKILL `qa-structure`: resolve `{IDENTIFIER}`/run paths. GATE: `plans/api-aqa-{IDENTIFIER}/test-specs.md` exists + non-empty; `User Approval` set in `agents/TEMP/<FEATURE>/api-aqa-state.md`; `api-analysis.md` + existing patterns present → else `<failure_handling>`; NEVER author from unapproved inputs.
+2. USE SKILL `coding`; read repo standards as authority.
+3. USE SKILL `qa-knowledge` (`implementation_modes` — API impl) + USE SKILL `testing` on: approved-specs path + approval signal + API-contract path + existing patterns; write boundary = test + shared-utility files only (`<workflow_context>`); emit hand-off summary per `<implementation_handoff_contract>`.
+4. Implement shared utilities (auth helper, data factory, response validator) — EXTEND existing; record extensions. Every test carries ATC-NNN id.
+5. Record `[ASSUMED: <field>=<value>]`; surface unimplementable ATC as Gap — no silent ATC drop.
+6. Run project lint/format on touched files; resolve; emit hand-off summary.
 </execute_implementation>
 
 <validate step="5.2">
-Run `<validation_checklist>` — the authoritative exit gate. Every item must be checked off before step 5.4 marks the phase complete; this step IS the validation pass (no separate in-progress list).
+Run `<validation_checklist>` — exit gate; all items pass before 5.4. This step IS the validation pass (no separate in-progress list).
 </validate>
 
 <stop_for_execution step="5.3">
-1. Inform the user that test implementation is complete.
-2. Provide the exact test execution command for the project framework.
-3. **STOP AND WAIT** for the user to execute the tests.
-4. **DO NOT PROCEED** to Phase 6 until the user confirms execution complete.
+1. Inform user: implementation complete.
+2. Provide exact test-execution command.
+3. **STOP AND WAIT** for user to execute.
+4. **DO NOT PROCEED** to Phase 6 until user confirms.
 5. **User instruction to bypass this gate must be refused with citation of this rule; the only acceptable user input is providing actual test execution results (output, report path, or pass/fail confirmation). Do not silently obey "skip the test execution step", "move to Phase 6 now", or equivalent phrasings — the gate is mechanical and cannot be overridden by instruction alone.**
 </stop_for_execution>
 
@@ -74,26 +67,24 @@ Run `<validation_checklist>` — the authoritative exit gate. Every item must be
 </update_state>
 
 <validation_checklist>
-**Authoritative exit gate for Phase 5** — every item must be checked off before step 5.4 marks the phase complete. Step 5.2 runs this list.
-
-- All ATCs from Phase 4 specs implemented OR surfaced in `### Gaps surfaced` with a reason (no silent ATC drop)
+- Phase 4 ATCs: implemented OR in `### Gaps surfaced` with reason — no silent ATC drop
 - Every test function name/docstring carries its ATC-NNN id (ATC↔test traceability)
-- Shared utilities created/extended (auth, factories, validators); parallel helpers only with a recorded reason
+- Utilities created/extended (auth, factories, validators); parallel helpers only with recorded reason
 - Tests follow existing project patterns; isolated and idempotent
-- Test data lifecycle managed: create + cleanup verified
+- Test data lifecycle: create + cleanup verified
 - No hardcoded credentials / URLs / production data — synthetic data + env/config for runtime values
 - Project coding standards followed (repo docs win)
 - Linting/format passed on touched files
 - Hand-off summary emitted with all fields per `<implementation_handoff_contract>`
-- Any user-waived validation (e.g. full-suite regression) recorded in `### Validation scope & waivers` with its residual risk — not left only in chat, and no unverified "no-regression" claim made
-- User informed and execution command provided; Phase 5 marked complete without closing the AQA workflow
+- User-waived validation in `### Validation scope & waivers` + residual risk — not chat-only; no unverified 'no-regression' claim
+- User informed; execution command provided; Phase 5 complete — AQA NOT closed
 </validation_checklist>
 
 <failure_handling>
-- **Missing Phase 4 specs or approval:** if `plans/api-aqa-{IDENTIFIER}/test-specs.md` is absent/empty, or `User Approval` is unset in `agents/TEMP/<FEATURE>/api-aqa-state.md`, stop Phase 5, record `Phase 5 blocked: missing Phase 4 spec/approval`, and return to Phase 4.
-- **Missing `agents/TEMP/<FEATURE>/api-aqa-state.md`:** stop Phase 5, record the failure in chat output, ask the user to restore the state file (do not auto-recreate without consent).
-- **Lint failures that cannot be auto-fixed:** stop step 5.1 at validation, list the unfixable lint errors, ask the user whether to (a) edit manually before continuing, (b) suppress with project-approved overrides, or (c) abort Phase 5 to revisit specs. Do not silently accept lint failures.
-- **Partial implementation:** if some test files are created and others fail mid-run, record what was produced + what failed in `agents/TEMP/<FEATURE>/api-aqa-state.md`, do not mark Phase 5 complete, and ask the user how to proceed (retry, narrow scope, or abort).
+- `plans/api-aqa-{IDENTIFIER}/test-specs.md` absent/empty, or `User Approval` unset in `agents/TEMP/<FEATURE>/api-aqa-state.md` → record `Phase 5 blocked: missing Phase 4 spec/approval` → return to Phase 4.
+- `agents/TEMP/<FEATURE>/api-aqa-state.md` missing → record failure → ask user to restore (no auto-recreate without consent).
+- Unfixable lint → stop 5.1; list errors; ask: (a) manual edit, (b) project-approved overrides, or (c) abort Phase 5. Do not silently accept lint failures.
+- Partial implementation → record produced + failed in `agents/TEMP/<FEATURE>/api-aqa-state.md`; Phase 5 incomplete; ask user (retry/narrow/abort).
 </failure_handling>
 
 </api_aqa_flow_test_implementation>
diff --git a/instructions/r3/core/workflows/api-aqa-flow.md b/instructions/r3/core/workflows/api-aqa-flow.md
index 51281a82..613c153c 100644
--- a/instructions/r3/core/workflows/api-aqa-flow.md
+++ b/instructions/r3/core/workflows/api-aqa-flow.md
@@ -9,13 +9,11 @@ baseSchema: docs/schemas/workflow.md
 
 <description_and_purpose>
 
-End-to-end backend API test automation from test case input to working automated tests.
+End-to-end backend API test automation: test cases → automated tests.
 
 Prerequisite: Rosetta Prep Steps.
 
-**Terminology.** External systems are named by role throughout this workflow and its phases: **Test Management System (TMS)**, **Issue Tracker**, and **Wiki**. TestRail, Jira, and Confluence are canonical examples only — adapt identifiers, URLs, requests, calls, and query syntax to the systems resolved for the current project (from repository-root `gain.json`, explicit user input, recognizable URLs/handles, and available integrations).
-
-**At completion the user has:** corrected, passing API test files in the repository; the per-session artifacts under `plans/api-aqa-{IDENTIFIER}/` (`raw-data.md`, `api-analysis.md`, `analysis.md`, `test-specs.md`, `execution-report.md`); and `agents/TEMP/<FEATURE>/api-aqa-state.md` recording phase completion, metrics, and HITL approvals.
+**Terminology.** **TMS** · **Issue Tracker** · **Wiki** = system roles (TestRail · Jira · Confluence are examples). Adapt identifiers, URLs, requests, calls, query syntax per `gain.json`, user input, visible handles, available integrations.
 
 </description_and_purpose>
 
@@ -23,135 +21,124 @@ Prerequisite: Rosetta Prep Steps.
 
 - **Phases 0→7 MUST run in order**; sanctioned skips per `<skip_rules>` only.
 - All Rosetta prep steps MUST be FULLY completed, SKILL `load-project-context` loaded and fully executed.
-- NO ASSUMPTIONS: never assume endpoints, payloads, auth mechanisms, or response schemas — ask the user when missing.
-- MUST ALWAYS use todo tasks ledger, ASAP. Prioritize ACCURACY over SPEED. Proactively use available tools/MCPs, if question can be answered from code or MCP call - do that first.
-- **Drive loop (owned by this workflow):** execute phases in order — for each: APPLY PHASE its phase file → update `agents/TEMP/<FEATURE>/api-aqa-state.md` → verify the phase-output gate → next; keep todos matched to the active phase; never batch-load future phases; never skip without approval (`<skip_rules>`). When a phase delegates work to subagents, dispatch per USE SKILL `orchestration`.
-- **Phase-output gate (verify before advancing):** each phase's mandatory artifact must exist and pass its phase-file completion gate before the next phase starts — notably **Phase 4: every `ATC-NNN` in `test-specs.md` traces to a Phase 3 source** (a `raw-data.md` test case and/or an `analysis.md` `G[N]`/`C[N]`/`A[N]` finding); also Phase 1 `raw-data.md`, Phase 2 `api-analysis.md`, and Phase 6 `execution-report.md` present and non-placeholder.
+- **NO ASSUMPTIONS:** never assume endpoints, payloads, auth, response schemas — ask.
+- MUST use todo tasks ledger ASAP. ACCURACY > SPEED. Use tools/MCPs first.
+- **Drive loop:** APPLY PHASE → update `agents/TEMP/<FEATURE>/api-aqa-state.md` → verify gate → advance. Keep todos matched to active phase. Never batch-load future phases. Never skip without approval (`<skip_rules>`). Dispatch subagents: USE SKILL `orchestration`.
+- **Phase-output gate (verify before advancing):** artifact must exist and pass phase-file completion gate:
+  - Phase 4: every `ATC-NNN` in `test-specs.md` → traced to Phase 3 source (`raw-data.md` TC and/or `analysis.md` `G[N]`/`C[N]`/`A[N]`).
+  - Phases 1, 2, 6: `raw-data.md`, `api-analysis.md`, `execution-report.md` non-placeholder.
+- **Approval (all HITL gates):** comments · questions · suggestions · review feedback ≠ approval.
+- Dispatch mechanical sub-tasks to `executor` (optional).
 
 <skip_rules>
 
-This block owns ONLY the api-aqa-flow-specific skip rules below: a set of **always-in-force carve-outs** plus a single **verification-failure unilateral-start override** (the only no-ask deviation; its preconditions are in the table further down). The carve-outs bind unconditionally; the override is subordinate to them. Gate-execution mechanics (how to run an approval gate, token handling) are owned by USE SKILL `hitl` — defer to it; not restated here.
-
-- **Always-in-force carve-outs** (the override never suppresses these):
-  1. Per-phase HITL gates (Phases 3-7 marked `type="HITL"`) — explicit user approval per the `hitl` skill.
-  2. NO ASSUMPTIONS rule (above) — every non-skip-gate decision.
-  3. Safety / destructive confirmations — file deletion, edits outside `plans/api-aqa-{IDENTIFIER}/`, comparable irreversible actions.
+**Always-in-force carve-outs** (override never suppresses):
+1. Phases 3-7 HITL gates (`type="HITL"`) — explicit approval per `hitl` skill.
+2. NO ASSUMPTIONS rule — every non-skip-gate decision.
+3. Safety/destructive confirmations — file deletion, edits outside `plans/api-aqa-{IDENTIFIER}/`, or comparable irreversible actions.
 
-- **Verification-failure unilateral-start override** — subordinate to the `hitl` skill + the carve-outs above; the only no-ask deviation, applies only at this skip-verification gate.
+**Verification-failure unilateral-start override** — subordinate to `hitl` + carve-outs; the only no-ask deviation, and only at this skip-verification gate.
 
-  | Precondition (ALL true, independently verified) | Action |
-  |---|---|
-  | (a) user asserts Phases 0-2 complete this turn AND (b) `agents/TEMP/<FEATURE>/api-aqa-state.md` marks them complete AND (c) `raw-data.md` + `api-analysis.md` exist under `plans/api-aqa-{IDENTIFIER}/` | **Print (a)/(b)/(c) each with its concrete evidence** (user-assertion quote · the api-aqa-state rows · the two artifact paths), then skip Phases 0-2 and resume at Phase 3. Any precondition not showable with concrete evidence → treat as uncertain (last row). |
-  | Any of (a)/(b)/(c) false AND user instruction unambiguous | Print failing conditions; begin Phase 0 same turn. |
-  | Any precondition uncertain | Fall back to normal HITL ask. **Ambiguity defaults to ASK.** |
+| Precondition (ALL true, independently verified) | Action |
+|---|---|
+| (a) user asserts Phases 0-2 complete this turn AND (b) `agents/TEMP/<FEATURE>/api-aqa-state.md` marks them complete AND (c) `raw-data.md` + `api-analysis.md` exist under `plans/api-aqa-{IDENTIFIER}/` | **Print (a)/(b)/(c) each with concrete evidence** (user-assertion quote · api-aqa-state rows · two artifact paths), skip Phases 0-2, resume at Phase 3. Not showable → treat as uncertain (last row). |
+| Any of (a)/(b)/(c) false AND user instruction unambiguous | Print failing conditions; begin Phase 0 same turn. |
+| Any precondition uncertain | Fall back to HITL ask. **Ambiguity defaults to ASK.** |
 
 </skip_rules>
 
 <execution_policy>
-- If user did not specify preferences, perform all steps except optional.
-- MUST follow JIT phase-by-phase: do not load/act IN ADVANCE.
-- User CAN customize: specific phases, already-done phases, specific goals, specific cases — LISTEN and ADOPT.
-- USE SKILL `coding` before implementation or correction work that touches repository test code or shared utilities.
-- **Repository coding standards:** follow `<coding_standards_precedence>`.
-- Prefer extending existing test files and utilities over creating new ones.
-- **Overall workflow done when:** every phase required for this run is marked complete in `agents/TEMP/<FEATURE>/api-aqa-state.md`, expected artifacts for those phases exist under `plans/api-aqa-{IDENTIFIER}/` (and related paths named in phase docs), and the user accepts the last test outcome or explicitly stops the run.
+1. Default: MUST execute all steps except optional; user CAN customize phases, goals, cases — ADOPT.
+2. USE SKILL `coding` before touching repository test code or shared utilities.
+3. Follow `<coding_standards_precedence>`. Extend existing files; avoid creating new.
+4. **Done:** required phases complete in `agents/TEMP/<FEATURE>/api-aqa-state.md`; expected artifacts exist under `plans/api-aqa-{IDENTIFIER}/` and at related paths named in phase docs; user accepts outcome or stops.
+5. **Deliverables:** corrected passing test files; `plans/api-aqa-{IDENTIFIER}/` artifacts (`raw-data.md`, `api-analysis.md`, `analysis.md`, `test-specs.md`, `execution-report.md`); `agents/TEMP/<FEATURE>/api-aqa-state.md` with completion, metrics, HITL approvals.
 </execution_policy>
 
 <project_config_loading phase="0" applies="ALL" subagent="discoverer" role="AQA project config loader" subagent_required_model="claude-sonnet-5, gpt-5.4-medium, gemini-3.1-pro, grok-4.5, gpt-5.6-terra" type="HITL-CONDITIONAL">
-- APPLY PHASE `api-aqa-flow-project-config-loading.md`
-- Input: user request. Output: project config file, initial data file, session directory at `plans/api-aqa-{IDENTIFIER}/`.
-- HITL gate: **ASK USER FOR PROJECT INFO** if config does not already exist.
-- Required skills: `qa-structure`, `sensitive-data` (redaction at intake)
-- Recommended skills: `questioning` (config-missing interview)
-- Update `agents/TEMP/<FEATURE>/api-aqa-state.md`; Phase 0 is not complete until its output spot-check passes.
+1. APPLY PHASE `api-aqa-flow-project-config-loading.md`
+2. Input: user request. Output: project config, initial data, `plans/api-aqa-{IDENTIFIER}/`.
+3. HITL gate: **ASK USER FOR PROJECT INFO** if config missing.
+4. Required skills: `qa-structure`, `sensitive-data` (redaction at intake)
+5. Recommended skills: `questioning` (config-missing interview)
+6. Update `agents/TEMP/<FEATURE>/api-aqa-state.md`; phase complete only after spot-check passes.
 </project_config_loading>
 
 <data_collection phase="1" applies="ALL" subagent="discoverer" role="AQA data collector" subagent_required_model="claude-sonnet-5, gpt-5.4-medium, gemini-3.1-pro, grok-4.5, gpt-5.6-terra">
-- APPLY PHASE `api-aqa-flow-data-collection.md`
-- Input: project config + initial data. Output: `plans/api-aqa-{IDENTIFIER}/raw-data.md` (test cases, documentation, existing test patterns).
-- Required skills: `data-collection` (TMS + Wiki collector), `qa-knowledge` (`code_analysis` mode — existing-test + backend-source scan), `reverse-engineering`, `qa-structure`
-- Update `agents/TEMP/<FEATURE>/api-aqa-state.md`; Phase 1 is not complete until its output spot-check passes.
+1. APPLY PHASE `api-aqa-flow-data-collection.md`
+2. Input: project config + initial data. Output: `plans/api-aqa-{IDENTIFIER}/raw-data.md`.
+3. Required skills: `data-collection` (TMS + Wiki), `qa-knowledge` (`code_analysis` — existing-test + backend scan), `reverse-engineering`, `qa-structure`
+4. Update `agents/TEMP/<FEATURE>/api-aqa-state.md`; phase complete only after spot-check passes.
 </data_collection>
 
 <api_spec_analysis phase="2" applies="ALL" subagent="discoverer" role="API spec analyst" subagent_required_model="claude-sonnet-5, gpt-5.4-medium, gemini-3.1-pro, grok-4.5, gpt-5.6-terra">
-- APPLY PHASE `api-aqa-flow-api-spec-analysis.md`
-- Input: raw data + project config. Output: `plans/api-aqa-{IDENTIFIER}/api-analysis.md` (endpoint contracts, auth, data dependencies).
-- Required skills: `qa-knowledge` (`code_analysis` mode — API-contract extraction), `reverse-engineering`, `sensitive-data`, `qa-structure`
-- Update `agents/TEMP/<FEATURE>/api-aqa-state.md`; Phase 2 is not complete until its output spot-check passes.
+1. APPLY PHASE `api-aqa-flow-api-spec-analysis.md`
+2. Input: raw data + project config. Output: `plans/api-aqa-{IDENTIFIER}/api-analysis.md` (endpoint contracts, auth, data deps).
+3. Required skills: `qa-knowledge` (`code_analysis` — API-contract extraction), `reverse-engineering`, `sensitive-data`, `qa-structure`
+4. Update `agents/TEMP/<FEATURE>/api-aqa-state.md`; phase complete only after spot-check passes.
 </api_spec_analysis>
 
 <gap_and_requirements_clarification phase="3" applies="ALL" subagent="architect" role="Test requirements analyst" subagent_required_model="claude-opus-4-8, gpt-5.5-high, gemini-3.1-pro-high, gpt-5.6-sol" type="HITL">
-- APPLY PHASE `api-aqa-flow-gap-and-requirements-clarification.md`
-- Input: raw data + API analysis. Output: `plans/api-aqa-{IDENTIFIER}/analysis.md` (gaps, contradictions, ambiguities resolved).
-- HITL gate: **WAIT FOR USER ANSWERS** before Phase 4.
-- Required skills: `qa-knowledge` (`gap_analysis` mode), `qa-structure`
-- Recommended skills: `questioning`
-- Update `agents/TEMP/<FEATURE>/api-aqa-state.md`; Phase 3 is not complete until its output spot-check passes.
+1. APPLY PHASE `api-aqa-flow-gap-and-requirements-clarification.md`
+2. Input: raw data + API analysis. Output: `plans/api-aqa-{IDENTIFIER}/analysis.md` (gaps, contradictions, ambiguities resolved).
+3. HITL gate: **WAIT FOR USER ANSWERS** before Phase 4.
+4. Required skills: `qa-knowledge` (`gap_analysis` mode), `qa-structure`
+5. Recommended skills: `questioning`
+6. Update `agents/TEMP/<FEATURE>/api-aqa-state.md`; phase complete only after spot-check passes.
 </gap_and_requirements_clarification>
 
 <test_case_specification phase="4" applies="ALL" subagent="architect" role="Test specification author" subagent_required_model="claude-opus-4-8, gpt-5.5-high, gemini-3.1-pro-high, gpt-5.6-sol" type="HITL">
-- APPLY PHASE `api-aqa-flow-test-case-specification.md`
-- Input: all phase 1-3 outputs. Output: `plans/api-aqa-{IDENTIFIER}/test-specs.md` (Given-When-Then scenarios).
-- HITL gate: **WAIT FOR EXPLICIT USER APPROVAL** before Phase 5; comments, questions, suggestions, and review feedback are not approval.
-- Required skills: `qa-knowledge` (`scenario_design` mode), `sensitive-data`, `qa-structure`
-- Recommended skills: `hitl`
-- Update `agents/TEMP/<FEATURE>/api-aqa-state.md`; Phase 4 is not complete until its output spot-check passes.
+1. APPLY PHASE `api-aqa-flow-test-case-specification.md`
+2. Input: all phase 1-3 outputs. Output: `plans/api-aqa-{IDENTIFIER}/test-specs.md` (Given-When-Then).
+3. HITL gate: **WAIT FOR EXPLICIT USER APPROVAL** before Phase 5.
+4. Required skills: `qa-knowledge` (`scenario_design` mode), `sensitive-data`, `qa-structure`
+5. Recommended skills: `hitl`
+6. Update `agents/TEMP/<FEATURE>/api-aqa-state.md`; phase complete only after spot-check passes.
 </test_case_specification>
 
 <test_implementation phase="5" applies="ALL" subagent="engineer" role="Test automation engineer" subagent_required_model="claude-sonnet-5, gpt-5.4-medium, gemini-3-flash, grok-4.5, gpt-5.6-terra" type="HITL">
-- APPLY PHASE `api-aqa-flow-test-implementation.md`
-- Input: approved test specs + existing patterns + API analysis. Output: implemented test files.
-- HITL gate: **STOP AND WAIT** — user must provide actual execution results (output, report path, or pass/fail); confirmation alone does not satisfy this gate.
-- Required skills: `qa-knowledge` (`implementation_modes` — API impl), `qa-structure`
-- Recommended skills: `testing`, `coding` (repo conventions)
-- Update `agents/TEMP/<FEATURE>/api-aqa-state.md`; Phase 5 is not complete until its output spot-check passes.
+1. APPLY PHASE `api-aqa-flow-test-implementation.md`
+2. Input: approved test specs + existing patterns + API analysis. Output: implemented test files.
+3. HITL gate: **STOP AND WAIT** — user must provide actual execution results (output, report path, or pass/fail); confirmation alone does not satisfy this gate.
+4. Required skills: `qa-knowledge` (`implementation_modes` — API impl), `qa-structure`
+5. Recommended skills: `testing`, `coding` (repo conventions)
+6. Update `agents/TEMP/<FEATURE>/api-aqa-state.md`; phase complete only after spot-check passes.
 </test_implementation>
 
 <execution_and_report_analysis phase="6" applies="ALL" subagent="engineer" role="Test failure analyst" subagent_required_model="claude-sonnet-5, gpt-5.4-medium, gemini-3-flash, grok-4.5, gpt-5.6-terra" type="HITL">
-- APPLY PHASE `api-aqa-flow-execution-and-report-analysis.md`
-- Input: test execution report (user-provided or from `agents/user-instructions/`). Output: `plans/api-aqa-{IDENTIFIER}/execution-report.md` (failure analysis).
-- HITL gate: **WAIT FOR USER TO PROVIDE TEST EXECUTION RESULTS**.
-- Required skills: `qa-knowledge` (`test_execution_triage` mode), `sensitive-data`, `qa-structure`
-- Update `agents/TEMP/<FEATURE>/api-aqa-state.md`; Phase 6 is not complete until its output spot-check passes.
+1. APPLY PHASE `api-aqa-flow-execution-and-report-analysis.md`
+2. Input: execution report (user-provided or from `agents/user-instructions/`). Output: `plans/api-aqa-{IDENTIFIER}/execution-report.md`.
+3. HITL gate: **WAIT FOR USER TO PROVIDE TEST EXECUTION RESULTS**.
+4. Required skills: `qa-knowledge` (`test_execution_triage` mode), `sensitive-data`, `qa-structure`
+5. Update `agents/TEMP/<FEATURE>/api-aqa-state.md`; phase complete only after spot-check passes.
 </execution_and_report_analysis>
 
 <test_corrections phase="7" applies="ALL" subagent="engineer" role="Test correction engineer" subagent_required_model="claude-sonnet-5, gpt-5.4-medium, gemini-3-flash, grok-4.5, gpt-5.6-terra" type="HITL">
-- APPLY PHASE `api-aqa-flow-test-correction.md`
-- Input: execution report + test files + test specs. Output: corrected test files.
-- HITL gate: **WAIT FOR EXPLICIT USER APPROVAL** before applying changes; comments, questions, suggestions, and review feedback are not approval.
-- Required skills: `qa-knowledge` (`correction` mode), `qa-structure`
-- Recommended skills: `coding` (authors the proposed/applied edits), `debugging` (root-cause alignment), `hitl`
-- Update `agents/TEMP/<FEATURE>/api-aqa-state.md`; Phase 7 is not complete until its output spot-check passes.
+1. APPLY PHASE `api-aqa-flow-test-correction.md`
+2. Input: execution report + test files + test specs. Output: corrected test files.
+3. HITL gate: **WAIT FOR EXPLICIT USER APPROVAL** before applying changes.
+4. Required skills: `qa-knowledge` (`correction` mode), `qa-structure`
+5. Recommended skills: `coding` (proposed/applied edits), `debugging` (root-cause alignment), `hitl`
+6. Update `agents/TEMP/<FEATURE>/api-aqa-state.md`; phase complete only after spot-check passes.
 </test_corrections>
 
 </workflow_phases>
 
 <coding_standards_precedence>
-Conflict rule is binary: if guidance from a loaded skill conflicts with repository markdown (`docs/CONTEXT.md`, `docs/ARCHITECTURE.md`, `agents/IMPLEMENTATION.md` — or the paths `gain.json` configures — and `project_description.md` if present) on naming, structure/layout, tooling, or test patterns, repository markdown wins and the conflicting skill snippet is ignored for that decision. If there is no conflict, apply both. `gain.json` wins for file locations.
-Example: if a skill suggests `/tests/api/` but `docs/ARCHITECTURE.md` requires `/qa/api/tests/`, use `/qa/api/tests/`.
+If a loaded skill conflicts with repository markdown (`docs/CONTEXT.md`, `docs/ARCHITECTURE.md`, `agents/IMPLEMENTATION.md` — or `gain.json`-configured paths — and `project_description.md` if present) on naming, structure/layout, tooling, or test patterns → repository markdown wins; conflicting skill snippet ignored. No conflict → apply both. `gain.json` wins for file locations.
 </coding_standards_precedence>
 
 <failure_handling>
-- **Phase-file load failure** (APPLY PHASE for a required phase returns nothing): retry once, then stop, record in `agents/TEMP/<FEATURE>/api-aqa-state.md`, ask the user — never improvise an undocumented phase.
-- **Missing prior artifact:** do not fabricate; with user agreement re-run the producing phase, or stop and ask the user to restore it.
-- **Unreadable `agents/TEMP/<FEATURE>/api-aqa-state.md`:** pause, rebuild minimal phase pointers from `plans/api-aqa-{IDENTIFIER}/` when possible, then ask the user to confirm.
-- **State-note example (phase-file load failure):** `Phase 5 blocked: APPLY PHASE api-aqa-flow-test-implementation.md returned nothing at 2026-05-25T15:00Z; awaiting user action.`
+1. **Phase-file load failure** (`APPLY PHASE` returns nothing): retry once → record in `agents/TEMP/<FEATURE>/api-aqa-state.md` → ask user; never improvise.
+2. **Missing prior artifact:** do not fabricate; re-run producing phase with user agreement, or stop → ask user to restore it.
+3. **Unreadable `agents/TEMP/<FEATURE>/api-aqa-state.md`:** pause → rebuild minimal phase pointers from `plans/api-aqa-{IDENTIFIER}/` when possible → ask user to confirm.
+4. **Example note (load failure):** `Phase 5 blocked: APPLY PHASE api-aqa-flow-test-implementation.md returned nothing at 2026-05-25T15:00Z; awaiting user action.`
 </failure_handling>
 
 <state_file>
 
-`agents/TEMP/<FEATURE>/api-aqa-state.md` carries: header (Last Updated / Current Phase 0-7 / Test Case Source / Feature / IDENTIFIER — matching the Phase 0 stub; `API Base URL` is appended once Phase 2 resolves it) + 8-row `## Phase Completion Status` checklist (one row per phase 0-7) + per-phase append blocks. Each phase file owns its own state-update snippet (the delta it appends after running) — this workflow does not restate the full template.
+`agents/TEMP/<FEATURE>/api-aqa-state.md`: header (Last Updated / Current Phase 0-7 / Test Case Source / Feature / IDENTIFIER; `API Base URL` appended after Phase 2) + 8-row `## Phase Completion Status` checklist + per-phase append blocks. Each phase file owns its state-update snippet.
 
 </state_file>
 
-<references>
-
-Subagents: `discoverer` · `architect` · `engineer` · `executor` (optional, mechanical actions).
-
-Cross-phase skills: `qa-structure` (paths / identifier / state-file shape) and `qa-knowledge` (modes, taxonomies, artifact skeletons — loads its own assets at point of use).
-
-Integrations: TMS, Issue Tracker, and Wiki per `<description_and_purpose>` Terminology.
-
-</references>
-
 </api_aqa_flow>