@metasession.co/devaudit-cli 0.1.68 → 0.1.70

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@metasession.co/devaudit-cli",
-  "version": "0.1.68",
+  "version": "0.1.70",
   "description": "DevAudit CLI — installs, syncs, and operates the Metasession SDLC across consumer projects.",
   "type": "module",
   "bin": {
@@ -33,7 +33,7 @@
   },
   "dependencies": {
     "@clack/prompts": "^0.8.2",
-    "@metasession.co/devaudit-plugin-sdk": "^0.1.68",
+    "@metasession.co/devaudit-plugin-sdk": "^0.1.70",
     "ajv": "^8.20.0",
     "commander": "^12.1.0",
     "consola": "^3.2.3",

package/scripts/upload-evidence.sh

@@ -37,6 +37,11 @@
 #                               4 submit-for-review, 5 deploy. Forwarded as
 #                               `sdlcStage`; unknown to older portals (ignored
 #                               server-side, no error).
+#   --test-cycle <id>           Test cycle identifier (typically the CI run
+#                               ID). Forwarded as `testCycleId`; lets the
+#                               portal group evidence by test cycle per
+#                               ISO/IEC/IEEE 29119-3. Optional — older
+#                               portals ignore the field (no error).
 #
 # Required environment variables:
 #   DEVAUDIT_BASE_URL  e.g. https://meta-comply-production.up.railway.app
@@ -78,6 +83,7 @@ RELEASE_TITLE=""
 CHANGE_TYPE=""
 GATE_STATUS=""
 SDLC_STAGE=""
+TEST_CYCLE=""
 # Repeatable `--meta-key key=value` accumulator. Each pair gets merged
 # into the metadata JSON sent to the portal. Used by the screenshot
 # upload loop to pass `origin=feature|regression` from the per-PNG
@@ -103,6 +109,7 @@ while [ "$#" -gt 0 ]; do
     # DevAudit-Installer#96.
     --gate-status) GATE_STATUS="$2"; shift 2 ;;
     --sdlc-stage) SDLC_STAGE="$2"; shift 2 ;;
+    --test-cycle) TEST_CYCLE="$2"; shift 2 ;;
     # --meta-key key=value (repeatable). Merged into the metadata JSON
     # before posting. Validates the `key=value` shape; rejects bare
     # keys without `=`.
@@ -313,7 +320,8 @@ upload_presigned() {
         \"releaseBranch\": \"${BRANCH}\",
         \"environment\": \"${ENVIRONMENT}\",
         \"evidenceCategory\": \"${EVIDENCE_CATEGORY}\",
-        \"sdlcStage\": \"${SDLC_STAGE}\"
+        \"sdlcStage\": \"${SDLC_STAGE}\",
+        \"testCycleId\": \"${TEST_CYCLE}\"
       }") || curl_exit=$?
     curl_exit=${curl_exit:-0}
     if [ "$curl_exit" -eq 0 ] && [ "$http_code" -ge 200 ] && [ "$http_code" -lt 300 ]; then
@@ -464,6 +472,7 @@ for FILE in "${FILES[@]}"; do
   [ -n "$CHANGE_TYPE" ] && CURL_ARGS+=(-F "changeType=${CHANGE_TYPE}")
   [ -n "$GATE_STATUS" ] && CURL_ARGS+=(-F "gateStatus=${GATE_STATUS}")
   [ -n "$SDLC_STAGE" ] && CURL_ARGS+=(-F "sdlcStage=${SDLC_STAGE}")
+  [ -n "$TEST_CYCLE" ] && CURL_ARGS+=(-F "testCycleId=${TEST_CYCLE}")
 
   ATTEMPT=1
   BACKOFF=$INITIAL_BACKOFF_SECONDS

package/sdlc/CLAUDE.md

@@ -25,7 +25,7 @@ Each project follows a **single owner-developer partnered with AI coding agents*
 
 - **Owner-developer** provides direction, judgment, and approval. They are accountable for the project.
 - **AI agent** (Claude Code, Windsurf, Cursor) acts as implementation partner, compliance enforcer, and reviewer. The SDLC process is enforced by the AI on every code change via drop-in rules (`sdlc/ai-rules/`).
-- **Branching is trunk-based** with a permanent `develop` branch — no feature branches. Parallel work is handled by the AI within a single stream, not by multiple developers on separate branches.
+- **Branching is GitFlow** with permanent `main` and `develop` branches plus `feature/*`, `fix/*`, and `hotfix/*` branches. See the Branching Strategy section below for details.
 - **PR reviews** are owner-reviewed with AI-assisted verification. CI provides independent, tamper-resistant evidence. The SDLC workflows and compliance gates replace traditional team ceremonies (standups, sprint planning).
 - **The AI is the second pair of eyes.** It asks which requirement a change is for, blocks implementation until planning is complete, enforces commit conventions, runs compliance gates, and guides evidence compilation.
 
@@ -47,10 +47,33 @@ All templates assume these gates: TypeScript (0 errors), SAST/Semgrep (0 high/cr
 - **Commit format:** Conventional Commits with `Co-Authored-By` tags for AI, `Ref: REQ-XXX` for tracked requirements
 - **Requirement IDs:** `REQ-XXX` format, tracked in `compliance/RTM.md`
 - **Status lifecycle:** DRAFT → IN PROGRESS → TESTED - PENDING SIGN-OFF → APPROVED - DEPLOYED
-- **Branching:** permanent `develop` branch, protected `main` (production), merge commits to preserve audit trail
+- **Branching:** GitFlow — permanent `develop` branch, protected `main` (production), `feature/*` and `fix/*` from `develop`, `hotfix/*` from `main`, merge commits to preserve audit trail
 - **Evidence model:** local testing (comprehensive) + CI testing (independent verification, tamper-resistant)
 - **Placeholders:** Templates use `[BRACKETED_VALUES]` and `# UPDATE` markers for project-specific customization
 
+## Branching Strategy — GitFlow
+
+This repository uses a **GitFlow** branching model. AI agents (Claude Code, Cursor, Windsurf, Gemini CLI) and human contributors must follow these rules.
+
+### Branch roles
+
+| Branch | Purpose | Direct push? |
+|---|---|---|
+| `main` | Production — stable, tagged framework versions | **No** — PR only |
+| `develop` | Integration — active work merges here | **No** — PR only |
+| `feature/*` | New work — branched from `develop` | Yes (to the feature branch) |
+| `fix/*` | Bug fixes — branched from `develop` | Yes (to the fix branch) |
+| `hotfix/*` | Production hotfixes — branched from `main` | Yes (to the hotfix branch) |
+
+### AI agent rules
+
+1. **Never commit directly to `main` or `develop`.** Always use a `feature/`, `fix/`, or `hotfix/` branch.
+2. **Branch naming:** `feature/<issue#>-<short-slug>`, `fix/<issue#>-<short-slug>`, `hotfix/<issue#>-<short-slug>`.
+3. **Workflow:** branch from `develop` → implement → PR into `develop` → merge. Ship: PR `develop` → `main` → merge.
+4. **Conventional Commits** for all commit messages. Reference issue numbers in the body.
+5. **CI must pass on `develop`** before merging to `main`.
+6. **Merge commits** (not squash or rebase) to preserve the audit trail.
+
 ## When Editing These Templates
 
 - Maintain the separation between Tier 1 and Tier 2 — if content applies universally, it belongs in Tier 1; if project-specific, Tier 2.

package/sdlc/SKILLS.md

@@ -96,7 +96,7 @@ node scripts/validate-adapter.cjs sdlc/files/_common/skills/<name>/SKILL.md
 | Skill                   | Location          | Triggers (paraphrased)                                                                                                                                                                                                                                                                             | Additional emissions                                                                                                                                                       |
 | ----------------------- | ----------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | `e2e-test-engineer`     | `_common/skills/` | "add e2e tests", "bootstrap an e2e suite", "update the test pack", "are any tests obsolete", "run e2e tests and file issues"                                                                                                                                                                       | `e2e/helpers/evidence.ts` + `evidence-shot-core.ts` (node-stack consumers)                                                                                                 |
-| `sdlc-implementer`      | `_common/skills/` | "implement issue #N under the SDLC", "run the SDLC for issue #N", "automate REQ-XXX from issue to release", "resume REQ-XXX"                                                                                                                                                                       | — (orchestrator; invokes `e2e-test-engineer`, `governance-doc-author`, and the three SoT-alignment skills)                                                                 |
+| `sdlc-implementer`      | `_common/skills/` | "implement issue #N", "fix issue #N", "do issue #N", "implement #N", "implement issue #N under the SDLC", "run the SDLC for issue #N", "automate REQ-XXX from issue to release", "resume REQ-XXX"                                                                                                                                                                       | — (orchestrator; invokes `e2e-test-engineer`, `governance-doc-author`, and the three SoT-alignment skills)                                                                 |
 | `governance-doc-author` | `_common/skills/` | "create / refresh the RoPA", "write a DPIA", "update the AI disclosure", "set up the periodic review schedule", "GDPR.Art-30 is MISSING on the matrix" (v0.1.37+)                                                                                                                                  | `references/incident-classification.md` (shared with `e2e-test-engineer`)                                                                                                  |
 | `requirements-aligner`  | `_common/skills/` | "align SRS for REQ-XXX", "what SRS items did this REQ need?", "is the SRS in sync with this branch?" (v0.1.42+). Auto-invoked by `sdlc-implementer` at Stage 1 plan-APPROVAL + Stage 3 evidence-pack.                                                                                              | Maintains `docs/SRS.md`; drops `compliance/evidence/REQ-XXX/srs-alignment.md` per cycle.                                                                                   |
 | `adr-author`            | `_common/skills/` | "draft an ADR for REQ-XXX", "does this REQ need an ADR?", "is the architectural decision documented?" (v0.1.43+). Auto-invoked by `sdlc-implementer` at Stage 1 + Stage 3.                                                                                                                         | Maintains `docs/ADR/ADR-NNN-<slug>.md`; drops `compliance/evidence/REQ-XXX/architecture-decision.md` per cycle. Closes `ISO27001.A.8.25`.                                  |

package/sdlc/ai-rules/INSTRUCTIONS-SDLC.md

@@ -21,13 +21,29 @@ The default way to implement a tracked change is the **`sdlc-implementer`** skil
 
 **This is enforced, not just advised.** `feat` / `fix` / `refactor` / `perf` commits that cite no requirement (`[REQ-XXX]` in the subject or a `Ref: REQ-XXX` trailer) are **rejected** locally by the commit-msg hook (commitlint) and at PR CI by `validate-commits.sh` (which `--no-verify` cannot skip). So implementation work cannot reach `develop` without a requirement — which is also what keeps release labels correct (the version-deriver only falls back to a bare date for genuine housekeeping, never for real feature work). Housekeeping commit types remain exempt.
 
+### MANDATORY: `sdlc-implementer` prompt before implementation (devaudit-installer#199)
+
+When the user requests implementation of an issue (e.g. "implement issue #N", "fix issue #N", "do issue #N", "implement #N"), you MUST prompt before writing any code:
+
+> Implementing #N using sdlc-implementer, can I proceed?
+
+Wait for the user's yes/no response. Do NOT begin implementation until they answer.
+
+- **YES** → invoke the `sdlc-implementer` skill immediately. The skill drives Phase 0 (triage) through Phase 4 (PR + UAT review).
+- **NO** → proceed with manual implementation outside the skill. The user has explicitly opted out; respect their choice and do not ask again for the same issue.
+
+This prompt is **mandatory and structural** — it is not advisory. The `sdlc-implementer` is the default entry point; manual implementation is the explicit opt-out. Skipping the prompt and jumping straight into code is the same class of inertia-trap bug as #132 (e2e delegation bypass).
+
+The only exception: if the user's request is clearly housekeeping ("bump a dep", "fix a typo", "update docs") and does not involve `feat`/`fix`/`refactor`/`perf` commit types, skip the prompt and proceed directly.
+
 ### Before ANY Code Change
 
-1. Ask: "Which GitHub Issue is this for?" before writing code. Fetch it with `gh issue view NNN`.
-2. If no issue exists: ask if one should be created. When creating via `gh issue create`, ALWAYS append the SDLC checklist to the body (see below).
-3. If new requirement needed: read `SDLC/1-plan-requirement.md` and follow it BEFORE implementing.
-4. If trivial (typo/formatting): proceed without requirement but use conventional commit format.
-5. Verify `develop` branch: `git branch --show-current` — never implement on `main`.
+1. If the user has NOT been prompted for `sdlc-implementer` and the change is not trivial housekeeping, stop and run the mandatory prompt above before continuing.
+2. Ask: "Which GitHub Issue is this for?" before writing code. Fetch it with `gh issue view NNN`.
+3. If no issue exists: ask if one should be created. When creating via `gh issue create`, ALWAYS append the SDLC checklist to the body (see below).
+4. If new requirement needed: read `SDLC/1-plan-requirement.md` and follow it BEFORE implementing.
+5. If trivial (typo/formatting): proceed without requirement but use conventional commit format.
+6. Verify `develop` branch: `git branch --show-current` — never implement on `main`.
 
 ### For ALL Code Changes (including bug fixes)
 

package/sdlc/files/_common/3-compile-evidence.md

@@ -76,7 +76,7 @@ Housekeeping releases **skip** the per-requirement evidence (no REQ → no `comp
 | Release ticket | `compliance/pending-releases/RELEASE-TICKET-REQ-XXX.md` (Step 8) | `compliance/pending-releases/RELEASE-TICKET-<version>.md` (e.g. `RELEASE-TICKET-v2026.06.04.md`) | **Yes** — `generate-housekeeping-release-ticket.sh` runs after `derive-release-version.sh` and emits a stub the operator reviews + signs off |
 | Security summary | `compliance/evidence/REQ-XXX/security-summary.md` (Step 4) | `compliance/security-summary-<version>.md` at the compliance root (release-scoped, not REQ-scoped) | **Yes** — `generate-security-summary.sh` scrapes the SAST + dep-audit gate JSON and emits a stub with an operator sign-off block |
 
-**The portal evidence check is lenient on filename.** Any file whose name (case-insensitive) starts with `release-ticket` satisfies the release-ticket check, and any file named exactly `security-summary.md` satisfies the security-summary check. The version-suffixed conventions above are recommended for **searchability + audit trail** when a project has many housekeeping releases stacked up — they keep the artefacts distinct per release without needing folder scoping.
+**Filename conventions are enforced.** Release tickets must match `RELEASE-TICKET-REQ-XXX.md` or `RELEASE-TICKET-vYYYY.MM.DD.md` exactly. Security summaries must be named `security-summary.md` exactly. The CI upload pipeline (`compliance-evidence.yml`) routes per-REQ artifacts by basename to specific `evidence_type` values — unrecognized filenames are skipped with a warning (DevAudit-Installer#205). The `validate-compliance-artifacts.sh` PR-time check also warns on unrecognized filenames in `compliance/evidence/REQ-XXX/`. The version-suffixed conventions above are recommended for **searchability + audit trail** when a project has many housekeeping releases stacked up — they keep the artefacts distinct per release without needing folder scoping.
 
 **What housekeeping operators do, end to end:**
 
@@ -163,6 +163,14 @@ Records the design-time decisions before listing run results — what was tested
 | E2E Tests | PASS | [N]/[N] passed |
 | Build | PASS | Production build succeeded |
 
+## Test Cycles
+
+| Cycle | CI Run | Gate Status | E2E Result | Coverage | Date |
+|-------|--------|-------------|------------|----------|------|
+| #1    | [run_id] | [PASS/FAIL] | [N/N]   | [N%]     | [YYYY-MM-DD] |
+
+**Final assessment:** [All cycles passed / N cycles failed — see incidents]
+
 ## Test Changes in This Release
 
 **Added:**
@@ -258,6 +266,59 @@ EOF
 
 For Medium/High risk, add access control and audit log verification to the security summary.
 
+### Step 4b: Nil Incident Report (DevAudit-Installer#210 §8a)
+
+After the test pack re-run passes, check whether any `incident`-labelled issues were closed during this REQ's lifecycle:
+
+```bash
+gh issue list --label incident --state closed --search "REQ-XXX" --json number
+```
+
+If **no** incidents were closed and the test pack re-run passes, generate a nil incident report — a per-release "no incidents" attestation that flips `ISO29119.3.5.4` to COVERED on the portal:
+
+```bash
+cat > compliance/governance/nil-incident-report-<version>.md << 'EOF'
+---
+incident_id: "NIL-<version>"
+severity: "N/A"
+detected_at: "<release date>"
+resolved_at: "N/A"
+status: "nil"
+---
+
+# Nil Incident Report — <version>
+
+## Attestation
+
+No incidents or defects were discovered during the test cycle for release `<version>`.
+
+## Scope
+
+- **Release:** <version>
+- **Test cycle:** <description>
+- **Test cases executed:** <count>
+- **Test cases passed:** <count>
+- **Test cases failed:** 0
+- **Defects filed:** 0
+- **Incidents reported:** 0
+
+## Framework attribution
+
+- [x] `ISO29119.3.5.4` (Test incident report — nil report for this release cycle)
+
+## Sign-off
+
+| Role | Name | Date |
+|---|---|---|
+| Test lead | REPLACE — assign | REPLACE |
+| Engineering lead | REPLACE — assign | REPLACE |
+EOF
+```
+
+Fill in the scope section with actual test counts. Leave the sign-off section with REPLACE markers — the operator fills it in. The nil report uploads as `incident_report` evidence via `compliance-evidence.yml`'s `upload_incident_report` function.
+
+If incidents **were** closed during this REQ's lifecycle, skip nil report generation — the populated incident report(s) from `incident-export.yml` serve as the evidence.
+
 ### Step 5: Save AI Evidence (If Applicable)
 
 Verify `ai-use-note.md` and `ai-prompts.md` exist (if AI was used). If missing, create `ai-use-note.md` with YAML frontmatter (devaudit-installer#197):
@@ -340,7 +401,7 @@ If the AI tool changed mid-implementation (detected by the `prepare-commit-msg`
 - REQ release ticket: compliance/pending-releases/RELEASE-TICKET-REQ-XXX.md
 ```
 
-This file is uploaded as evidence with `evidence_type: compliance_document` and `evidence_category: ai_handoff` so the portal can query for it specifically.
+This file is uploaded as evidence with `evidence_type: ai_agent_handoff` and `evidence_category: ai_governance` so the portal can query for it specifically (DevAudit-Installer#205).
 
 ### Step 6: Verify Test Scope and Implementation Plan
 

package/sdlc/files/_common/4-submit-for-review.md

@@ -93,7 +93,7 @@ git diff origin/main..develop -- package.json | grep '^\+'
 
 ### Step 3: Create the PR
 
-> The `--base main --head develop` below is the develop-first default. The branches are project-configured in `sdlc-config.json` — `release_branch` (default `main`) and `integration_branch` (default `develop`); a trunk-only project sets both to `main` and opens the feature branch directly against `main`.
+> The `--base main --head develop` below is the develop-first default. The branches are project-configured in `sdlc-config.json` — `release_branch` (default `main`) and `integration_branch` (default `develop`).
 
 **For tracked requirements:**
 
@@ -167,6 +167,7 @@ CI runs automatically on this PR. The following gates must pass before merge:
 - [ ] Implementation plan present and matches implementation (MEDIUM/HIGH risk)
 - [ ] Release ticket created
 - [ ] Test evidence saved
+- [ ] Test execution summary includes Test Cycles section (all CI runs for this release listed)
 - [ ] Security evidence saved
 - [ ] AI use documented
 

package/sdlc/files/_common/5-deploy-main.md

@@ -207,6 +207,7 @@ git checkout develop
 1. **Hosting dashboard:** Redeploy previous version
 2. **Git:** `git checkout main && git revert HEAD --no-edit && git push origin main`
 3. **Document:** Add rollback entry to release ticket audit trail
+4. **Correlate with incident (DevAudit-Installer#210 §10a):** If the rollback was triggered by a post-deploy smoke failure, the `post-deploy-prod.yml` workflow files an incident issue with the `incident` label. Reference this incident in the rollback commit message (`Fixes #N` or a comment on the issue) so the incident report captures the containment action. This ensures `incident-export.yml` exports the full incident timeline including the rollback.
 
 ### Environment Summary
 

package/sdlc/files/_common/Test_Plan_TEMPLATE.md

@@ -35,7 +35,7 @@ For tools, patterns, and code standards: Test Architecture.
 
 ## Branching Strategy
 
-Trunk-based with develop branch (per Test Strategy branching patterns):
+Develop-main with develop branch (per Test Strategy branching patterns):
 
 - **`main`** — Production. Auto-deploys to hosting platform. PR approval + all checks required.
 - **`develop`** — Working branch. All implementation here. Permanent, never deleted.

package/sdlc/files/_common/Test_Strategy.md

@@ -256,7 +256,7 @@ Every requirement must be traceable through the complete chain: Requirement →
 
 ### Branching Strategy
 
-Projects may use trunk-based with integration branch or direct trunk-based flow. The specific pattern is defined in each project's Test Plan.
+Projects use a develop-main branching model with a permanent integration branch (`develop`) and a protected release branch (`main`). The specific branch names are defined in each project's `sdlc-config.json`.
 
 **Universal requirements:**
 

package/sdlc/files/_common/governance/nil-incident-report.md.template

@@ -0,0 +1,38 @@
+---
+incident_id: "NIL-<version>"
+severity: "N/A"
+detected_at: "<release date>"
+resolved_at: "N/A"
+status: "nil"
+---
+
+# Nil Incident Report — <version>
+
+## Attestation
+
+No incidents or defects were discovered during the test cycle for release `<version>`.
+
+## Scope
+
+- **Release:** <version>
+- **Test cycle:** <description of test cycle — e.g. "E2E Regression run on <date>", "Phase 6 full suite + Phase 3 re-run">
+- **Test cases executed:** <count>
+- **Test cases passed:** <count>
+- **Test cases failed:** 0
+- **Defects filed:** 0
+- **Incidents reported:** 0
+
+## Framework attribution
+
+- [x] `ISO29119.3.5.4` (Test incident report — nil report for this release cycle)
+
+## Sign-off
+
+| Role | Name | Date |
+|---|---|---|
+| Test lead | REPLACE — assign | REPLACE |
+| Engineering lead | REPLACE — assign | REPLACE |
+
+---
+
+_Source: Generated by `sdlc-implementer` Phase 3 when no `incident`-labelled issues were closed during this REQ's lifecycle and the test pack re-run passes. Upload as `incident_report` evidence to flip `ISO29119.3.5.4` to COVERED._

package/sdlc/files/_common/scripts/validate-compliance-artifacts.sh

@@ -73,6 +73,19 @@ for REQ in $REQUIREMENTS; do
   fi
   echo "  OK: Evidence directory exists"
 
+  # Check for unrecognized .md filenames in the evidence directory
+  # (DevAudit-Installer#205). The CI upload pipeline now skips unknown
+  # filenames with a warning — this check surfaces the issue at PR
+  # time so the operator can rename or add routing before merge.
+  KNOWN_ARTIFACTS="test-scope.md test-plan.md test-execution-summary.md test-summary-report.md implementation-plan.md srs-alignment.md architecture-decision.md risk-assessment.md security-summary.md ai-use-note.md ai-prompts.md ai-agent-handoff.md"
+  for ARTIFACT in compliance/evidence/$REQ/*.md; do
+    [ -f "$ARTIFACT" ] || continue
+    ARTIFACT_BASE=$(basename "$ARTIFACT")
+    if ! echo " $KNOWN_ARTIFACTS " | grep -q " $ARTIFACT_BASE "; then
+      echo "  WARNING: Unrecognized artifact filename: compliance/evidence/$REQ/$ARTIFACT_BASE — CI upload will skip this file. Use a known filename or add routing in compliance-evidence.yml. (DevAudit-Installer#205)"
+    fi
+  done
+
   # Check test-scope.md exists
   if [ ! -f "compliance/evidence/$REQ/test-scope.md" ]; then
     echo "  ERROR: Test scope missing: compliance/evidence/$REQ/test-scope.md"

package/sdlc/files/_common/skills/e2e-test-engineer/SKILL.md

@@ -265,7 +265,14 @@ Then bucket each failure:
 - **Visual diff — intended** — the snapshot changed because the change intentionally changed the UI. Update the baseline and surface it for user approval.
 - **Visual diff — unintended** — a snapshot changed somewhere the change shouldn't have affected. File it as a regression.
 
-**Then check for missed requirements.** For each numbered acceptance criterion from Phase 2, confirm at least one *passing* test covers it. An AC with no passing test — because no test was written, or because the test fails — is a missed requirement. File it.
+**Then check for missed requirements.** For each numbered acceptance criterion from Phase 2, confirm at least one *passing* test covers it. **Classify each missed AC (devaudit-installer#212 Gap 4):**
+
+- **AC not tested** (no test was written) — file a defect as today. The implementation may be correct but untested. This is a testing gap, not a requirements gap.
+- **AC test fails** (test exists but fails) — file a defect as today. The implementation doesn't match the AC. This is a defect.
+- **AC impossible to test** (the test can't be written because the AC is ambiguous, contradictory, or assumes behaviour the system doesn't have) — **do not file a defect**. Return a requirements gap report to `sdlc-implementer`: "AC<N> cannot be tested because <reason>. The AC itself may be wrong." `sdlc-implementer` triggers its [requirements gap flow](../sdlc-implementer/SKILL.md#requirements-gap-flow-devaudit-installer212).
+- **Missing AC** (a scenario is necessary for the feature to work but no AC covers it) — **do not file a defect**. Return a requirements gap report: "Scenario <description> is necessary but not covered by any AC. A new AC may be needed." `sdlc-implementer` triggers its [requirements gap flow](../sdlc-implementer/SKILL.md#requirements-gap-flow-devaudit-installer212).
+
+The classification is: "Is the AC correct but untested/buggy? → defect. Is the AC itself wrong/missing? → requirements gap."
 
 ### Phase 7 — Regression-pack handoff
 
@@ -338,7 +345,9 @@ This defect, once closed with the `incident` label, will be auto-exported as `in
 - [ ] `GDPR.Art-34` — data-subject notification required: <REPLACE — yes/no>
 - [ ] `EUAIA.Art-9 / Art-14 / Art-15` — AI failure: <REPLACE — yes/no, which article(s)>
 
-Once closed, the `incident-export.yml` workflow exports this issue's body to `compliance/governance/incident-report-<N>.md`, auto-files a PR with the GDPR triage + sign-off sections to fill in. Merge that PR → `compliance-evidence.yml` uploads as `incident_report`.
+Once closed, the `incident-export.yml` workflow exports this issue's body to `compliance/governance/incident-report-<N>.md`. Routing depends on the Framework attribution ticks (DevAudit-Installer#200 Fix 1):
+- **Path A (baseline-only — only `ISO29119.3.5.4` ticked):** direct-committed to `develop`, no PR. GDPR triage pre-filled as N/A. Next `compliance-evidence.yml` run uploads as `incident_report`.
+- **Path B (any of SOC2/GDPR/EUAIA ticked):** auto-files a PR with the GDPR triage + sign-off sections to fill in. Merge that PR → `compliance-evidence.yml` uploads as `incident_report`.
 ```
 
 Pre-tick boxes you're confident about. Leave the operator-judgement ones (GDPR triage, AI-failure classification) for the operator to confirm in the export PR.
@@ -375,6 +384,7 @@ Wrap up with a summary the user can drop into the PR or ticket:
 - Tests deleted — count, with rationale.
 - Suite result — passing, failing, flaky.
 - Defects filed — count, with links.
+- Requirements gap reports — count, with details (devaudit-installer#212 Gap 4). These are ACs classified as "impossible to test" or "missing AC" — returned to `sdlc-implementer` for the requirements gap flow, not filed as defects.
 - Missed requirements — count, with links.
 
 **Then feed the test-design record (devaudit#50).** The Stage 3 `test-execution-summary.md` (generated per `3-compile-evidence.md` Step 1a) carries a `## Test design` section at the top. Before Stage 3 finalises the file, populate that section with the design-time decisions this skill made, so the SDLC has a recorded trace that scope was *decided*, not implicit:

package/sdlc/files/_common/skills/requirements-aligner/SKILL.md

@@ -132,7 +132,12 @@ I have reviewed the AC-to-SRS-item traces above and confirm:
 
 **Step 2 — Tag for upload.** The CI's `compliance-evidence.yml` uploads this file as `evidence_type=srs_alignment` (added to META-COMPLY's `EVIDENCE_TYPE_REGISTRY` in the paired sub-PR). The framework-coverage matrix then closes `ISO29119.3.4` (Test Plan — requirements traceability) and `SOC2.CC2.1` (Communication of policies — when paired with INSTRUCTIONS.md) for this REQ.
 
-**Step 3 — Return to the running `sdlc-implementer` context.** The skill's job ends at the artefact + the operator sign-off. The orchestrator immediately continues with the rest of Stage 3 (security summary, evidence upload, release ticket) inline — no pause, no operator nudge needed. (Skills run in the same invocation context; control returns synchronously when this skill exits. See `sdlc-implementer/SKILL.md` § *Sub-skill return semantics*.)
+**Step 3 — Return gap status to the running `sdlc-implementer` context (devaudit-installer#212 Gap 3).** In addition to producing the artefact, the skill returns a **gap status** to `sdlc-implementer`:
+
+- `CLEAN` — all ACs trace to SRS items, no unresolved drift. The orchestrator continues with the rest of Stage 3.
+- `GAPS_FOUND` — one or more ACs don't trace to SRS items, or drift is unresolved (no `@srs-deferred` annotation). Return the gap details (which ACs, what's missing). The orchestrator handles the gap per its [requirements gap flow](../sdlc-implementer/SKILL.md#requirements-gap-flow-devaudit-installer212): if `block_on_stage_3: true`, halt for the operator to resolve; if false, warn and continue.
+
+The `block_on_stage_3` check verifies **artefact content** (no unresolved gaps without `@srs-deferred`), not just artefact existence. A `srs-alignment.md` with unresolved gaps and no `@srs-deferred` annotations fails the block. (Skills run in the same invocation context; control returns synchronously when this skill exits. See `sdlc-implementer/SKILL.md` § *Sub-skill return semantics*.)
 
 ### Phase 3 — Per-REQ ad-hoc audit