@metasession.co/devaudit-cli 0.3.14 → 0.3.16

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@metasession.co/devaudit-cli",
-  "version": "0.3.14",
+  "version": "0.3.16",
   "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.3.14",
+    "@metasession.co/devaudit-plugin-sdk": "^0.3.16",
     "ajv": "^8.20.0",
     "commander": "^12.1.0",
     "consola": "^3.2.3",

package/sdlc/files/_common/Test_Policy.md

@@ -155,8 +155,8 @@ AI involvement in Medium or High categories raises risk by one level. The Test S
 The MoSCoW prioritisation of acceptance criteria maps onto three E2E gates, each enforced at a different point in the workflow:
 
 - **Must-tier ACs in the smoke subset** must pass on every push to the integration branch. Blocking — a red smoke gate stops the integration hop.
-- **Must-tier ACs in the critical subset** must pass on every PR to the release branch. Blocking — a red critical gate stops the release.
-- **Should/Could-tier ACs (full regression)** must pass on the next post-merge run to the release branch OR a hotfix issue is auto-filed. Not pre-merge blocking — the safety net is post-hoc triage by the operator within working hours.
+- **Must-tier ACs in the critical subset** must pass on every consumer-enabled PR to the release branch. Blocking — a red critical gate stops that release.
+- **Should/Could-tier ACs (full regression)** are not pre-merge blocking. The consumer chooses a post-merge, scheduled, or manual-dispatch safety net and must triage any recorded failure within working hours.
 
 Operator override on a hotfix issue (accept-with-rationale) is logged on the issue itself + carried in the next release's `test-execution-summary.md` design record (devaudit#50). The framework does not permit silently shipping a failing test — every red regression spec ends as either fixed, reverted, or accepted-with-recorded-rationale.
 

package/sdlc/files/_common/Test_Strategy.md

@@ -45,14 +45,14 @@ Full E2E regression on every PR is expensive — a 30+ minute wait per release-P
 | Tier | Location | When it runs | Wall-clock target | Audit role |
 | --- | --- | --- | --- | --- |
 | **smoke** | `e2e/smoke/*.spec.ts` | every push to `$INTEGRATION_BRANCH` (via `ci.yml`) | ~3–5 min | fast feedback on every change |
-| **critical** | `e2e/smoke/` + `e2e/critical/*.spec.ts` | PR-to-`$RELEASE_BRANCH` (via `e2e-regression.yml`) | ~10–15 min | release-readiness Must gate |
-| **regression** | all `e2e/**/*.spec.ts` | nightly + push-to-`$RELEASE_BRANCH` + `workflow_dispatch` | ~35 min (or your project's full pack) | full audit trail + drift catch |
+| **critical** | `e2e/smoke/` + `e2e/critical/*.spec.ts` | PR-to-`$RELEASE_BRANCH` when the consumer enables `e2e-regression.yml` | ~10–15 min | release-readiness Must gate |
+| **regression** | all `e2e/**/*.spec.ts` | `workflow_dispatch` and any consumer-configured post-merge or scheduled run | ~35 min (or your project's full pack) | full audit trail + drift catch |
 
 The mapping to MoSCoW: **Must-priority SRS items live in `e2e/smoke/` (fast feedback) and `e2e/critical/` (release gate); Should/Could items live in `e2e/` and are covered by the regression tier.** The classifier is the developer authoring the spec — see `skills/e2e-test-engineer/SKILL.md` Phase 3 for the decision tree.
 
-**Cost philosophy.** Smoke protects every push from breaking the headline flow. Critical protects every release from a Must-tier regression. Full regression protects the audit trail + catches drift overnight. We accept that a Should/Could-tier regression *can* slip past the PR gate; we catch it on the next post-merge run + auto-file a hotfix issue. The framework prefers this over a 35-min wait on every release because operator velocity matters and the safety net stays intact.
+**Cost philosophy.** Smoke protects every push from breaking the headline flow. Critical protects every release from a Must-tier regression. Full regression protects the audit trail and catches drift when the consumer elects to run it. We accept that a Should/Could-tier regression can sit outside the PR gate; the consumer chooses whether its safety net is post-merge, scheduled, or manual dispatch. The framework does not impose a daily/nightly run.
 
-**Post-merge safety net.** Every push to `$RELEASE_BRANCH` re-runs the full regression. On failure, `e2e-regression.yml` auto-files a `bug, priority:high` issue tagging the merge commit + the failing specs. The operator triages within working hours — hotfix forward, revert the commit, or accept-with-rationale if the failure is environmental. No automated revert (false positives + flakes + UAT-data drift are real classes; an operator triages each individually).
+**Post-merge safety net.** When a consumer enables a post-merge regression run, `e2e-regression.yml` may file a `bug, priority:high` issue tagging the merge commit and failing specs. The operator triages within working hours — hotfix forward, revert the commit, or accept-with-rationale if the failure is environmental. No automated revert: flakes and UAT-data drift require human judgment.
 
 **Reference workflow.** A copy-pasteable `e2e-regression.yml` shape lives at `skills/e2e-test-engineer/references/e2e-regression-3-tier.yml`. Adoption is opt-in per consumer (the framework doesn't currently sync this workflow; consumers own their own `e2e-regression.yml`).
 

package/sdlc/files/_common/scripts/check-release-pr-scope.sh

@@ -73,6 +73,17 @@ if [ "$DECLARED_SCOPE" != "$CURRENT_RELEASE" ]; then
   exit 1
 fi
 
+if [[ "$CURRENT_RELEASE" =~ ^v[0-9]{4}\.[0-9]{2}\.[0-9]{2}(\.[0-9]+)?$ ]]; then
+  DECLARATION="compliance/standalone-housekeeping/STANDALONE-HOUSEKEEPING-${CURRENT_RELEASE}.json"
+  if ! printf '%s\n%s\n' "${PR_TITLE:-}" "${PR_BODY:-}" | grep -Fqi "Standalone housekeeping promotion"; then
+    echo "::error::Bare-date releases may only be promoted with an explicit standalone housekeeping exception."
+    echo "::error::Add 'Standalone housekeeping promotion' to the PR title or body and include ${DECLARATION}."
+    exit 1
+  fi
+  chmod +x scripts/standalone-housekeeping-release.sh 2>/dev/null || true
+  bash scripts/standalone-housekeeping-release.sh validate "$CURRENT_RELEASE" "$DECLARATION"
+fi
+
 if [[ "$CURRENT_RELEASE" =~ ^REQ-[0-9]+$ ]]; then
   if [ ! -x scripts/extract-release-metadata.sh ]; then
     chmod +x scripts/extract-release-metadata.sh 2>/dev/null || true

package/sdlc/files/_common/scripts/check-release-pr-scope.test.sh

@@ -39,9 +39,10 @@ assert_grep() {
 make_fixture() {
   local dir="$1" subject="$2"
   rm -rf "$dir"
-  mkdir -p "$dir/scripts" "$dir/compliance/pending-releases"
+  mkdir -p "$dir/scripts" "$dir/compliance/pending-releases" "$dir/compliance/standalone-housekeeping"
   cp "$SCRIPT_DIR/derive-release-version.sh" "$dir/scripts/derive-release-version.sh"
   cp "$SCRIPT_DIR/extract-release-metadata.sh" "$dir/scripts/extract-release-metadata.sh"
+  cp "$SCRIPT_DIR/standalone-housekeeping-release.sh" "$dir/scripts/standalone-housekeeping-release.sh"
   cp "$HELPER" "$dir/scripts/check-release-pr-scope.sh"
   chmod +x "$dir/scripts/"*.sh
   (
@@ -133,5 +134,45 @@ assert_exit "hotfix branch skips" 0 "$CODE"
 assert_grep "hotfix skip message" 'Hotfix PR detected' "$OUT"
 echo ""
 
+echo "--- Test 5: bare-date releases require an explicit standalone declaration ---"
+make_fixture "$WORK/test5" "chore: standalone housekeeping release"
+cat > "$WORK/test5/compliance/standalone-housekeeping/STANDALONE-HOUSEKEEPING-v2026.07.18.json" <<'EOF'
+{
+  "schemaVersion": 1,
+  "version": "v2026.07.18",
+  "releaseMode": "standalone_housekeeping",
+  "reason": "Urgent operational change cannot wait for the next tracked requirement release."
+}
+EOF
+OUT="$WORK/test5.out"
+if run_check "$WORK/test5" "$OUT" env PR_TITLE="Standalone housekeeping promotion: v2026.07.18" PR_BODY=$'## Release\n- Release: v2026.07.18\n'; then
+  CODE=0
+else
+  CODE=$?
+fi
+assert_exit "declared standalone housekeeping release passes" 0 "$CODE"
+assert_grep "standalone validation is emitted" 'Standalone housekeeping declaration is valid' "$OUT"
+echo ""
+
+echo "--- Test 6: bare-date releases without the exception marker fail ---"
+make_fixture "$WORK/test6" "chore: standalone housekeeping release"
+cat > "$WORK/test6/compliance/standalone-housekeeping/STANDALONE-HOUSEKEEPING-v2026.07.18.json" <<'EOF'
+{
+  "schemaVersion": 1,
+  "version": "v2026.07.18",
+  "releaseMode": "standalone_housekeeping",
+  "reason": "Urgent operational change cannot wait for the next tracked requirement release."
+}
+EOF
+OUT="$WORK/test6.out"
+if run_check "$WORK/test6" "$OUT" env PR_TITLE="Release: v2026.07.18" PR_BODY=$'## Release\n- Release: v2026.07.18\n'; then
+  CODE=0
+else
+  CODE=$?
+fi
+assert_exit "bare-date release without exception marker fails" 1 "$CODE"
+assert_grep "exception marker failure is clear" 'explicit standalone housekeeping exception' "$OUT"
+echo ""
+
 echo "=== check-release-pr-scope.test.sh: $PASS passed, $FAIL failed ==="
 [ "$FAIL" -eq 0 ]

package/sdlc/files/_common/scripts/standalone-housekeeping-release.sh

@@ -0,0 +1,98 @@
+#!/usr/bin/env bash
+# standalone-housekeeping-release.sh — validate and promote an explicit
+# standalone-housekeeping exception after a reviewed, green main promotion.
+#
+# Manifest contract:
+# compliance/standalone-housekeeping/STANDALONE-HOUSEKEEPING-vYYYY.MM.DD.json
+# {
+#   "schemaVersion": 1,
+#   "version": "vYYYY.MM.DD",
+#   "releaseMode": "standalone_housekeeping",
+#   "reason": "Why this cannot wait for the next tracked REQ release."
+# }
+
+set -euo pipefail
+
+COMMAND="${1:-}"
+VERSION="${2:-}"
+MANIFEST_PATH="${3:-}"
+
+usage() {
+  echo "Usage: $0 validate <version> <manifest-path>" >&2
+  echo "       $0 promote <project-slug> <version> <manifest-path>" >&2
+  exit 2
+}
+
+validate_manifest() {
+  local expected_version="$1" path="$2"
+  if ! [[ "$expected_version" =~ ^v[0-9]{4}\.[0-9]{2}\.[0-9]{2}(\.[0-9]+)?$ ]]; then
+    echo "Error: ${expected_version} is not a bare-date housekeeping version." >&2
+    return 1
+  fi
+  if [ ! -f "$path" ]; then
+    echo "Error: standalone-housekeeping declaration not found: ${path}" >&2
+    return 1
+  fi
+  if ! command -v jq >/dev/null 2>&1; then
+    echo "Error: jq is required." >&2
+    return 1
+  fi
+
+  local schema_version manifest_version release_mode reason
+  schema_version=$(jq -r '.schemaVersion // empty' "$path")
+  manifest_version=$(jq -r '.version // empty' "$path")
+  release_mode=$(jq -r '.releaseMode // empty' "$path")
+  reason=$(jq -r '.reason // empty' "$path")
+
+  [ "$schema_version" = "1" ] || { echo "Error: schemaVersion must be 1." >&2; return 1; }
+  [ "$manifest_version" = "$expected_version" ] || { echo "Error: declaration version must exactly match ${expected_version}." >&2; return 1; }
+  [ "$release_mode" = "standalone_housekeeping" ] || { echo "Error: releaseMode must be standalone_housekeeping." >&2; return 1; }
+  if [ "${#reason}" -lt 20 ]; then
+    echo "Error: reason must explain why this cannot wait for the next tracked REQ (minimum 20 characters)." >&2
+    return 1
+  fi
+}
+
+case "$COMMAND" in
+  validate)
+    [ -n "$VERSION" ] && [ -n "$MANIFEST_PATH" ] || usage
+    validate_manifest "$VERSION" "$MANIFEST_PATH"
+    echo "Standalone housekeeping declaration is valid for ${VERSION}."
+    ;;
+  promote)
+    PROJECT_SLUG="${2:-}"
+    VERSION="${3:-}"
+    MANIFEST_PATH="${4:-}"
+    [ -n "$PROJECT_SLUG" ] && [ -n "$VERSION" ] && [ -n "$MANIFEST_PATH" ] || usage
+    validate_manifest "$VERSION" "$MANIFEST_PATH"
+    : "${DEVAUDIT_BASE_URL:?DEVAUDIT_BASE_URL must be set}"
+    : "${DEVAUDIT_API_KEY:?DEVAUDIT_API_KEY must be set}"
+
+    BASE_URL="${DEVAUDIT_BASE_URL%/}"
+    ENCODED_SLUG=$(jq -rn --arg value "$PROJECT_SLUG" '$value|@uri')
+    ENCODED_VERSION=$(jq -rn --arg value "$VERSION" '$value|@uri')
+    RESOLVED=$(curl -fsS -H "Authorization: Bearer ${DEVAUDIT_API_KEY}" \
+      "${BASE_URL}/api/ci/releases/resolve?projectSlug=${ENCODED_SLUG}&versionPrefix=${ENCODED_VERSION}")
+    RELEASE_ID=$(jq -r '.latest.id // empty' <<<"$RESOLVED")
+    RESOLVED_VERSION=$(jq -r '.latest.version // empty' <<<"$RESOLVED")
+    [ -n "$RELEASE_ID" ] || { echo "Error: could not resolve ${VERSION}." >&2; exit 1; }
+    [ "$RESOLVED_VERSION" = "$VERSION" ] || { echo "Error: resolve returned ${RESOLVED_VERSION}, not exact ${VERSION}." >&2; exit 1; }
+
+    REASON=$(jq -r '.reason' "$MANIFEST_PATH")
+    PAYLOAD=$(jq -n --arg releaseMode standalone_housekeeping --arg standaloneReason "$REASON" \
+      '{releaseMode: $releaseMode, standaloneReason: $standaloneReason}')
+    RESPONSE_FILE=$(mktemp)
+    trap 'rm -f "$RESPONSE_FILE"' EXIT
+    HTTP_CODE=$(curl -sS -o "$RESPONSE_FILE" -w '%{http_code}' \
+      -X PATCH "${BASE_URL}/api/ci/releases/${RELEASE_ID}" \
+      -H "Authorization: Bearer ${DEVAUDIT_API_KEY}" \
+      -H 'Content-Type: application/json' --data "$PAYLOAD")
+    if [ "$HTTP_CODE" != "200" ]; then
+      echo "Error: standalone housekeeping promotion failed with HTTP ${HTTP_CODE}." >&2
+      sed 's/^/  /' "$RESPONSE_FILE" >&2
+      exit 1
+    fi
+    echo "Promoted ${VERSION} as standalone housekeeping (release ${RELEASE_ID})."
+    ;;
+  *) usage ;;
+esac

package/sdlc/files/_common/scripts/standalone-housekeeping-release.test.sh

@@ -0,0 +1,45 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
+HELPER="$SCRIPT_DIR/standalone-housekeeping-release.sh"
+WORK=$(mktemp -d)
+trap 'rm -rf "$WORK"' EXIT
+
+MANIFEST="$WORK/standalone.json"
+cat > "$MANIFEST" <<'JSON'
+{"schemaVersion":1,"version":"v2026.07.18","releaseMode":"standalone_housekeeping","reason":"Urgent production CI repair cannot wait for the next tracked requirement."}
+JSON
+
+bash "$HELPER" validate v2026.07.18 "$MANIFEST"
+
+MOCK_BIN="$WORK/bin"
+mkdir -p "$MOCK_BIN"
+cat > "$MOCK_BIN/curl" <<'MOCK'
+#!/usr/bin/env bash
+set -euo pipefail
+if [[ "$*" == *"/resolve?"* ]]; then
+  printf '{"latest":{"id":"rel_123","version":"v2026.07.18"}}'
+  exit 0
+fi
+output_file=""
+for ((i=1; i <= $#; i++)); do
+  if [ "${!i}" = "-o" ]; then
+    next=$((i + 1))
+    output_file="${!next}"
+  fi
+done
+[ -z "$output_file" ] || printf '{"ok":true}' > "$output_file"
+printf '200'
+MOCK
+chmod +x "$MOCK_BIN/curl"
+
+PATH="$MOCK_BIN:$PATH" DEVAUDIT_BASE_URL=https://devaudit.example.test DEVAUDIT_API_KEY=mc_test \
+  bash "$HELPER" promote fixture-project v2026.07.18 "$MANIFEST"
+
+if bash "$HELPER" validate REQ-999 "$MANIFEST" >/dev/null 2>&1; then
+  echo "Expected tracked version validation to fail" >&2
+  exit 1
+fi
+
+echo "standalone-housekeeping-release: PASS"

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

@@ -139,7 +139,7 @@ When designing each scenario, also pick the tier it'll live in. Three tiers map
 | --- | --- | --- |
 | **smoke** | `e2e/smoke/*.spec.ts` | Cross-cutting sanity that proves the app is up: login, basic nav, one canonical CRUD per main domain. Runs on every push to the integration branch. Keep small — total smoke wall-clock target is ~3–5 min. |
 | **critical** | `e2e/critical/*.spec.ts` | Must-priority SRS item that breaks a headline flow if it regresses. Examples: payment authorisation, order completion, admin permission editing, RBAC enforcement on financial surfaces. Runs on PR-to-release-branch. Total critical wall-clock target ~10–15 min (includes smoke). |
-| **regression** | `e2e/<area>/*.spec.ts` | Should/Could-priority SRS item, edge cases, less-load-bearing flows. Runs nightly + post-merge + dispatch. Total full pack can be 30+ min; that's the point of the tier. |
+| **regression** | `e2e/<area>/*.spec.ts` | Should/Could-priority SRS item, edge cases, less-load-bearing flows. Runs by dispatch and any consumer-configured post-merge or scheduled cadence. Total full pack can be 30+ min; that is the point of the tier. |
 
 Decision tree, applied per scenario:
 
@@ -229,6 +229,12 @@ Before running the suite (Phase 6), verify that the evidence traceability wiring
 
    Also verify the import is present: `import { tagTest } from './helpers/test-tags'` (or the correct relative path from the spec's location to `e2e/helpers/test-tags.ts`).
 
+4. **Check release and cycle provenance.** Before handing the work back to `sdlc-implementer`, identify the tracked `REQ-XXX`, the source branch SHA, and the expected SDLC stage/cycle for the run. The CI evidence upload must retain those values so the portal can show the result in the correct numbered cycle for the release that produced it.
+   - A passing local run is not portal evidence by itself. Report it as local verification and let the configured CI workflow upload the resulting report and screenshots.
+   - For a bundled release, evidence remains attributed to its originating REQ and cycle. The absorbing release may reference that source release through bundle lineage, but must not relabel the source E2E run as newly produced by the absorbing REQ.
+   - Confirm the CI invocation has an unambiguous release context (`REQ-XXX` or the documented standalone-housekeeping declaration). A bare-date integration housekeeping run is historical CI only; it must not create an approval-ready E2E evidence set.
+   - If the project workflow cannot provide this context, halt and report a workflow-contract gap. Do not claim that screenshots or E2E results will appear correctly on the portal.
+
 **If any check fails:**
 
 Halt and report the gap to the user:
@@ -241,7 +247,7 @@ Halt and report the gap to the user:
 
 Do **not** proceed to Phase 6 until all gaps are resolved. The user may choose to skip an AC (e.g. API-only, transport-only) — that's valid, but it must be an explicit decision recorded in the test-execution-summary, not an omission.
 
-**Write the evidence-wiring sentinel (devaudit-installer#226).** After all Phase 5½ checks pass (all `@requirement`, `evidenceShot()`, and `tagTest()` calls verified), write a `.e2e-evidence-wired` sentinel file in the repo root so the pre-push hook and `sdlc-implementer` Phase 2 step 5b can verify evidence wiring was validated:
+**Write the evidence-wiring sentinel (devaudit-installer#226).** After all Phase 5½ checks pass (all `@requirement`, `evidenceShot()`, `tagTest()`, and release/cycle provenance checks verified), write a `.e2e-evidence-wired` sentinel file in the repo root so the pre-push hook and `sdlc-implementer` Phase 2 step 5b can verify evidence wiring was validated:
 
 ```bash
 echo "WIRED $(date -u +%Y-%m-%dT%H:%M:%SZ) REQ-XXX" > .e2e-evidence-wired
@@ -442,6 +448,7 @@ Wrap up with a summary the user can drop into the PR or ticket:
 - 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.
+- **Release provenance** — originating `REQ-XXX`, local run result, expected CI workflow/run, and expected portal stage/cycle. For bundled work, state the source REQ explicitly and that the absorbing release will reference it through lineage rather than overwrite its attribution.
 
 **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/e2e-test-engineer/references/e2e-regression-3-tier.yml

@@ -2,8 +2,8 @@
 #
 # Copy this into your consumer-owned .github/workflows/e2e-regression.yml
 # to adopt the 3-tier model: smoke (every develop push, fast) / critical
-# (PR-to-main, ~10-15 min target) / regression (nightly + push-to-main +
-# dispatch, full audit trail with auto-issue on failure).
+# (consumer-enabled release PR, ~10-15 min target) / regression (post-merge
+# or scheduled only when the consumer opts in, plus dispatch).
 #
 # The framework does NOT sync this file automatically — your consumer
 # owns its e2e-regression.yml. Apply the patterns below to your own
@@ -25,8 +25,6 @@ on:
     branches: [main] # critical-tier gate before merge
   push:
     branches: [main] # full regression after merge; auto-issues on failure
-  schedule:
-    - cron: '0 2 * * *' # nightly full regression
   workflow_dispatch:
     inputs:
       specs:
@@ -62,8 +60,8 @@ jobs:
         run: npx playwright install --with-deps chromium
 
       # Decide which Playwright project to run based on the trigger.
-      # PR-to-main uses critical with smoke fall-back; push-to-main and
-      # schedule run the full regression project; workflow_dispatch
+      # PR-to-main uses critical with smoke fall-back; a consumer-enabled
+      # post-merge push runs the full regression project; workflow_dispatch
       # accepts an optional spec filter.
       - name: Determine E2E project + spec selector
         id: select

package/sdlc/files/_common/skills/sdlc-implementer/SKILL.md

@@ -307,7 +307,7 @@ _Test fix surfaced by suite drift_
 > - **Requirement:** none
 > - **Risk:** LOW
 > - **Path:** Lightweight (gates → PR review → merge)
-> - **Gates/evidence:** quality-gates smoke (default CI Gate 4); no full regression on PR (run via `workflow_dispatch` while iterating, full regression on next nightly)
+> - **Gates/evidence:** quality-gates smoke (default CI Gate 4); no full regression on PR (use `workflow_dispatch` while iterating; any post-merge or scheduled regression is consumer-configured)
 > - **Your approvals:** PR review only
 > - **Skipped:** RTM, evidence pack, UAT four-eyes, Production approval
 
@@ -341,8 +341,9 @@ Reached from Phase 0 for non-tracked change-types. The skill drives this end-to-
    - **Post-merge-only CI (older generated workflows — `push: branches: [<integration>]` with no `pull_request:` trigger)** — say so explicitly in the LAST/NEXT sticky: _"no PR-time checks will fire; review + merge is the gate; CI runs post-merge on `$INTEGRATION_BRANCH`."_ Don't poll the PR for checks that won't arrive. The post-merge run (CI Pipeline + Compliance Evidence Upload on the integration branch) is the actual gate; address it via fix-forward if it fails.
 
    Either way, never bypass a gate (no `--no-verify`, no `--admin` merge of a red required check); the only difference is **where** you wait for the gate to fire — before merge vs. after merge.
-8. **Guide review → merge.** A human still reviews the PR (separation of duties). There is **no** portal release approval, no UAT four-eyes, no Production gate, and no close-out. Merge once CI is green and the reviewer approves.
-9. **Done.** A housekeeping push produces at most a bare-date release (`vYYYY.MM.DD`) with no approval gate; a doc-only push attaches its docs to the existing `REQ-XXX` release. No further action required — report completion and stop.
+8. **Guide review -> merge.** A human still reviews the PR. Merge only after all required checks are terminal green on the current PR head SHA; queued, running, stale, cancelled, unexpectedly skipped, or failed checks are not green. There is no portal release approval, UAT four-eyes, Production gate, or standalone close-out on the normal lightweight path.
+9. **Record the correct release meaning.** A housekeeping push produces at most a bare-date release (`vYYYY.MM.DD`) that is integration/history, not an active approval by default. It waits on `$INTEGRATION_BRANCH` until the next tracked release absorbs it through the required bundled-changes markdown/JSON manifest and portal lineage. A doc-only push attaches documents to the existing `REQ-XXX` release.
+10. **Standalone exception.** Only when housekeeping cannot reasonably wait for the next tracked release may the skill prepare a standalone promotion. It must state `Standalone housekeeping promotion` and why in the release PR, add `compliance/standalone-housekeeping/STANDALONE-HOUSEKEEPING-vYYYY.MM.DD.json` with `schemaVersion: 1`, the exact derived bare-date version, `releaseMode: standalone_housekeeping`, and a specific reason. It must obtain terminal-green CI and PR review. The installed release-scope check validates the declaration before merge; post-deploy uploads it as release-ticket evidence and changes the portal row to standalone housekeeping. Use portal approval only if project policy explicitly opts in. If the installed workflow cannot implement that policy, halt and keep the change on the normal integration path.
 
 ### Phase 1 — Plan (SDLC stage 1)
 
@@ -662,8 +663,8 @@ Reached only on the **tracked** route from Phase 0 (the issue is already fetched
 **When an external gate hangs or fails for unrelated reasons.** A required gate may fail for reasons outside the change's scope — flaky infra, an unrelated regression test that hangs at hour-plus runtime with no log activity, a known-failing suite. When this happens:
 
 1. **Verify it's actually unrelated.** Read the failure (or the lack of one). If it's the change's fault, fix it; this section does not apply.
-2. **Document the rationale on the PR.** A sticky comment naming: which gate, what the failure was, why it's unrelated to the change, what the safety net is (nightly run on `$INTEGRATION_BRANCH`, post-deploy verification, etc.).
-3. **Cancel-and-admin-merge is allowed** when **all three** hold: (a) ≥3 other required gates are green, (b) the change has no scope-overlap with the failing gate (e.g. service-layer fix vs hung UI e2e, or an `E2E: N/A by scope` test-plan), and (c) a fallback verification exists (nightly e2e on `$INTEGRATION_BRANCH`, post-deploy smoke, etc.). If any of the three fail, hold the merge and surface the blocker to the operator.
+2. **Document the rationale on the PR.** A sticky comment naming: which gate, what the failure was, why it's unrelated to the change, and what concrete fallback verification is available (for example, a consumer-configured regression run or post-deploy verification).
+3. **Cancel-and-admin-merge is allowed** when **all three** hold: (a) ≥3 other required gates are green, (b) the change has no scope-overlap with the failing gate (e.g. service-layer fix vs hung UI e2e, or an `E2E: N/A by scope` test-plan), and (c) a concrete fallback verification exists (a consumer-configured regression run, manual dispatch, or post-deploy smoke). If any of the three fail, hold the merge and surface the blocker to the operator.
 4. **Record the decision in the release ticket.** The release ticket's `## Verification` section must mention the cancelled gate by run-ID and the fallback that justifies bypassing it. Auditors look here first.
 
 **When the cancel-and-admin-merge conditions are NOT met.** If only one or two of the three conditions hold, the skill cannot bypass the gate. Escalation path:
@@ -699,16 +700,11 @@ Invoked separately by the user after UAT activity on the portal. Trigger: "resum
        - If `released` (Option B): PATCH directly to `released` — `PATCH /releases/<version>` with `{"status": "released"}`.
        - If `prod_review` (Option A, default): after `post-deploy-prod.yml` completes, the release is at `prod_review`. Update the sticky to "Phase 5 — production deployed; awaiting prod approval on portal" and halt. The operator clicks "Approve Production" (`prod_review` → `prod_approved`) then "Mark as Released" (`prod_approved` → `released`) in the portal. On next `resume REQ-XXX`, the skill reads the portal state — if `released`, finalise (close issue, update sticky to terminal). If `prod_approved`, prompt the operator to click "Mark as Released". If still `prod_review`, report "awaiting production approval" and stop.
      - Comment on the issue: "Released. Production smoke evidence: <link>." (only after release status is `released`)
-     - **Phase 5 close-out — mandatory post-merge compliance steps (devaudit-installer#226).** After the release is marked `released` on the portal, perform the close-out:
-       1. **Update RTM status** — change the REQ-XXX row from `TESTED - PENDING SIGN-OFF` to `APPROVED - DEPLOYED` in `compliance/RTM.md`.
-       2. **Move release ticket** — move `compliance/pending-releases/RELEASE-TICKET-REQ-XXX.md` to `compliance/approved-releases/`. This prevents CI's `upload-evidence` job from treating the REQ as in-scope for subsequent releases.
-       3. **Verify portal approval** — confirm the DevAudit portal release record is in `released` status.
-       4. **Commit the close-out** — `git add compliance/RTM.md compliance/pending-releases/ compliance/approved-releases/ && git commit -m "compliance: [REQ-XXX] close out release — RTM updated to APPROVED - DEPLOYED, ticket moved to approved-releases/"`.
-       5. **Push the close-out commit** to `$INTEGRATION_BRANCH`.
-
-       These steps are mandatory — the native agent must not treat "PR merged" or "release marked Released" as completion without performing the close-out. Without moving the release ticket to `approved-releases/`, CI continues uploading evidence for the REQ on every subsequent release, polluting the portal's audit trail.
-     - **Update SDLC status sticky** to the terminal state: `bash scripts/update-sdlc-status.sh "$ISSUE_NUM" "Phase 5 complete — release marked Released; production smoke evidence uploaded; close-out committed (RTM → APPROVED - DEPLOYED, ticket → approved-releases/)" "Done — close issue + retire feature branch (sdlc-implementer halts)"`.
-     - Close the issue.
+     - **Phase 5 close-out — mandatory automated reconciliation.** After the portal release is `released`, wait for the portal's `repository_dispatch('release-closed')` event to open `chore/close-out-REQ-XXX` against `$INTEGRATION_BRANCH`. Verify the PR updates the RTM, moves the ticket to `approved-releases/`, and moves manifest-listed predecessors to `superseded-releases/`. Review and merge the close-out PR only after its required checks are terminal green on its current head SHA. If no PR appears, manually dispatch the Release Close-out workflow. Use `scripts/close-out-release.sh` locally only for documented recovery/catch-up; never make a normal direct close-out commit to a protected branch.
+
+       These steps are mandatory — "PR merged" or "release marked Released" is not complete until the automated close-out PR has merged or a documented fallback reconciliation is complete. Without it, CI can keep uploading evidence against a completed REQ and pollute the audit trail.
+     - **Update SDLC status sticky** to the terminal state: `bash scripts/update-sdlc-status.sh "$ISSUE_NUM" "Phase 5 complete — release marked Released; production smoke evidence uploaded; automated close-out reconciled RTM and release ticket" "Done — close issue + retire feature branch (sdlc-implementer halts)"`.
+     - Close the issue only after close-out reconciliation completes.
      - If production smoke fails: do NOT mark as Released. **Delegate incident filing to `governance-doc-author` (devaudit-installer#210 §6c)** — invoke `Skill(name: "governance-doc-author", args: "Production smoke failure for REQ-XXX. File an incident issue with the `incident` label + `### Framework attribution` section (ISO29119.3.5.4 + SOC2.CC7.2), severity `blocker`. Include the production URL, git SHA, testCycleId (CI run ID), and smoke results in the issue body.")`. Page the on-call per the project's incident playbook, follow the rollback plan from the implementation plan. If the rollback also fails: update the sticky to "Phase 5 CRITICAL — production smoke failed AND rollback failed. Production is in a broken state. Operator action — page on-call immediately, engage hosting platform support, declare incident per the project's incident playbook. This is beyond the skill's scope." Do NOT attempt further automated remediation. **Update the sticky** to reflect the incident state: `… "Phase 5 BLOCKED — production smoke failed; INCIDENT issue #N filed" "Operator action — read INCIDENT #N + execute rollback per plan"`.
 
    - **Changes requested** → run change-request loop:
@@ -769,7 +765,7 @@ The skill re-reads state from the filesystem and continues from where it left of
 
 The native agent must NOT continue to the next phase (Phase 3 → Phase 4, Phase 2 → Phase 3) without re-invoking the skill. The only exception is the skill's own auto-continue steps (Phase 2 step 11) where the skill explicitly says it will continue to the next phase in the same turn.
 
-**PR merged to main ≠ done.** After the release PR is merged to `main`, the native agent must re-invoke the skill for Phase 5 close-out (see Phase 5 step 0 below). The merge is not the end of the workflow — post-merge compliance steps are mandatory.
+**PR merged to main is not done.** After the release PR is merged, Phase 5 waits for deploy/host verification, portal `released`, and the automated close-out PR back to the integration branch. The merge is not the end of the workflow.
 
 ### Commit-history hygiene recovery (devaudit-installer#315)
 

package/sdlc/files/_common/workflows/devaudit-update-install.md

@@ -137,20 +137,20 @@ Key files to expect:
 
 ### 5. Hand off to the sdlc-implementer skill
 
-The changes are staged in the working tree. The remaining steps — invoking the SDLC engine for the sentinel, running local gates, creating a feature branch, committing, pushing, opening a PR, monitoring CI, and handling post-merge housekeeping release stubs — are all owned by the **sdlc-implementer** skill that was synced into `.claude/skills/` by the install/update.
+The changes are staged in the working tree. The remaining steps — invoking the SDLC engine for the sentinel, running local gates, creating a feature branch, committing, pushing, opening a PR, monitoring CI, and recording the correct housekeeping release meaning — are all owned by the **sdlc-implementer** skill that was synced into `.claude/skills/` by the install/update.
 
 Invoke the sdlc-implementer skill and tell it:
 
-> **Housekeeping change.** The working tree has uncommitted changes from `devaudit install` (or `devaudit update`). Commit type is `chore:`, no `REQ-XXX`. Use the SDLC lightweight path: invoke the SDLC engine for the sentinel, run local gates, create a `chore/sync-devaudit-sdlc-{version}` branch, commit, push, open a PR targeting `develop`, monitor CI, and guide merge. After merge, CI will auto-generate housekeeping release stubs (release ticket + security summary) — remind the operator to review and sign off on those.
+> **Housekeeping change.** The working tree has uncommitted changes from `devaudit install` (or `devaudit update`). Commit type is `chore:`, no `REQ-XXX`. Use the SDLC lightweight path: invoke the SDLC engine for the sentinel, run local gates, create a `chore/sync-devaudit-sdlc-{version}` branch, commit, push, open a PR targeting `develop`, wait for terminal-green checks on the current PR SHA, then guide merge. This is normal integration housekeeping: it has PR review only, creates no tracked approval release, and is absorbed into the next tracked REQ through bundled-change lineage. A standalone housekeeping release is allowed only when the `sdlc-implementer` standalone-exception contract is explicitly satisfied.
 
 The skill will:
 1. Invoke `node SDLC/bin/devaudit-sdlc.js --phase=issue --view` to write the `.sdlc-implementer-invoked` sentinel
 2. Run local gates (lint, tsc, test)
 3. Create a `chore/` branch, commit, and push
 4. Open a PR targeting `develop`
-5. Monitor CI checks
+5. Monitor CI checks and wait for terminal green on the current PR SHA
 6. Guide review → merge
-7. Remind the operator about the housekeeping release stub PR that CI auto-opens after merge
+7. Record the merge as integration history to be bundled into the next tracked REQ, unless the explicit standalone-housekeeping exception was used
 
 **Do not** manually run these steps yourself — the skill owns the SDLC ceremony and stays in sync with the framework's evolution. If the skill is not available (e.g. the AI agent doesn't support skills), fall back to the manual steps documented in `SDLC/0-project-setup.md` and the sdlc-implementer skill definition at `.claude/skills/sdlc-implementer/SKILL.md`.
 

package/sdlc/files/ci/ci.yml.template

@@ -336,6 +336,26 @@ jobs:
             --environment uat --category planning \
             --git-sha ${{ github.sha }} --branch ${{ github.ref_name }} || true
 
+      - name: Upload standalone housekeeping declaration
+        if: env.DEVAUDIT_BASE_URL != '' && steps.version.outputs.version != 'skip'
+        run: |
+          VERSION="${{ steps.version.outputs.version }}"
+          if ! [[ "$VERSION" =~ ^v[0-9]{4}\.[0-9]{2}\.[0-9]{2}(\.[0-9]+)?$ ]]; then
+            exit 0
+          fi
+          DECLARATION="compliance/standalone-housekeeping/STANDALONE-HOUSEKEEPING-${VERSION}.json"
+          if [ ! -f "$DECLARATION" ]; then
+            echo "${VERSION} is integration housekeeping; no standalone declaration uploaded."
+            exit 0
+          fi
+          chmod +x scripts/standalone-housekeeping-release.sh scripts/upload-evidence.sh 2>/dev/null || true
+          bash scripts/standalone-housekeeping-release.sh validate "$VERSION" "$DECLARATION"
+          bash scripts/upload-evidence.sh \
+            {{PROJECT_SLUG}} "$VERSION" release_ticket "$DECLARATION" \
+            --release "$VERSION" --create-release-if-missing \
+            --environment uat --category release_artifact --sdlc-stage 2 \
+            --git-sha ${{ github.sha }} --branch ${{ github.ref_name }}
+
       - name: Generate and upload bundled changes (REQ releases only)
         if: env.DEVAUDIT_BASE_URL != '' && steps.version.outputs.version != 'skip'
         run: |

package/sdlc/files/ci/compliance-evidence.yml.template

@@ -49,26 +49,11 @@ jobs:
     # double-upload every compliance doc.
     if: github.event_name != 'workflow_run'
     runs-on: {{RUNNER}}
-    # Permissions are needed because the housekeeping path now does two
-    # GitHub mutations:
-    #   1. pushes a stub branch + opens a PR via `gh pr create`
-    #   2. dispatches `ci.yml` on develop after that stub PR merges, so
-    #      compliance-only housekeeping releases still get the gate evidence
-    #      the portal approval path currently requires (#361)
-    #
-    # Without these the github-actions[bot] token gets HTTP 403 on the push,
-    # PR create, or workflow dispatch and the housekeeping path leaves a red
-    # badge or an unapprovable release behind.
-    #
-    # `DEVAUDIT_USER_TOKEN` is no longer consulted by this workflow (the
-    # auto-stub step now uses `github.token` directly — see the env block
-    # on that step). The permissions below grant everything `gh pr create`
-    # needs; preferring a (potentially stale) PAT was the cause of the
-    # 2026-06-07 401 chain on this issue.
+    # #409: this workflow only uploads evidence. Normal housekeeping is
+    # integration history, so it must not create PRs, dispatch gates, or
+    # receive write-scoped GitHub credentials.
     permissions:
-      actions: write       # gh workflow run ci.yml --ref develop
-      contents: write       # push the auto-PR branch
-      pull-requests: write  # gh pr create
+      contents: read
     env:
       DEVAUDIT_BASE_URL_VAR: ${{ vars.DEVAUDIT_BASE_URL }}
       DEVAUDIT_API_KEY: ${{ secrets.DEVAUDIT_API_KEY }}
@@ -141,28 +126,13 @@ jobs:
           echo "version=${VERSION}" >> "$GITHUB_OUTPUT"
           echo "Release version: ${VERSION}"
 
-      # Housekeeping artefact auto-generation (DevAudit-Installer#116 WS3+WS4)
-      #
-      # Housekeeping releases (bare-date version) need two operator-authored
-      # artefacts to clear the portal's release-completeness checklist:
-      # `RELEASE-TICKET-<version>.md` and `security-summary-<version>.md`.
-      # When the version resolves to a bare-date AND those artefacts don't
-      # already exist on develop, generate stubs from the CI gate JSON and
-      # open a PR that the operator reviews + signs off + merges. Once
-      # merged, the next compliance-evidence.yml run uploads them as
-      # evidence and the matrix flips both items to ✓.
-      #
-      # devaudit#284 — release reconciliation merges (from close-out-release.yml)
-      # carry a `Release-Closeout: REQ-XXX` marker in the commit body.
-      # derive-release-version.sh detects this marker and emits an empty
-      # version, which this workflow converts to the explicit `skip` sentinel.
-      # Reconciliation pushes therefore never create housekeeping stubs and
-      # never attach fresh evidence to an already released tracked record.
-      #
-      # Mirrors the `incident-export.yml` pattern: auto-PR, operator fills
-      # in sign-off, merge to land.
-      - name: Auto-generate housekeeping stubs (if needed)
-        if: steps.resolve.outputs.skip != 'true' && steps.version.outputs.version != 'skip'
+      # #409: normal bare-date changes are integration CI history, not portal
+      # releases awaiting approval. The old auto-generated ticket/security
+      # summary path is deliberately disabled. An independently promoted
+      # exception must carry the reviewed standalone declaration validated by
+      # check-release-pr-scope.sh and post-deploy-prod.yml.
+      - name: Legacy housekeeping approval path (disabled)
+        if: ${{ false }}
         env:
           # Use the workflow's GITHUB_TOKEN directly. The `permissions:`
           # block on the job grants `contents: write` + `pull-requests:
@@ -241,8 +211,8 @@ jobs:
             echo "PR #${EXISTING} already open for ${VERSION} — branch updated in place."
           fi
 
-      - name: Dispatch ci.yml for merged housekeeping stub
-        if: github.event_name == 'push' && steps.resolve.outputs.skip != 'true' && steps.version.outputs.version != 'skip'
+      - name: Legacy housekeeping gate dispatch (disabled)
+        if: ${{ false }}
         env:
           GH_TOKEN: ${{ github.token }}
           VERSION: ${{ steps.version.outputs.version }}