@metasession.co/devaudit-cli 0.3.14 → 0.3.15

package/package.json

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

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/sdlc-implementer/SKILL.md

@@ -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)
 
@@ -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/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 }}

package/sdlc/files/ci/post-deploy-prod.yml.template

@@ -97,10 +97,18 @@ jobs:
           # release ticket (the same set the dev/UAT pipeline versioned via
           # derive-release-version.sh → REQ-XXX). A bundled develop→main PR
           # carries several; promote ALL of them, not just the first. A manual
-          # dispatch can target one via the `release` input. Fall back to a
-          # bare date for date-versioned (ticketless) releases.
+          # dispatch can target one via the `release` input. A ticketless
+          # main promotion is only valid when its explicit standalone
+          # housekeeping declaration is present and valid.
           if [ -n "${RELEASE_INPUT}" ]; then
             REQS="${RELEASE_INPUT}"
+            if [[ "$REQS" =~ ^v[0-9]{4}\.[0-9]{2}\.[0-9]{2}(\.[0-9]+)?$ ]]; then
+              chmod +x scripts/standalone-housekeeping-release.sh 2>/dev/null || true
+              DECLARATION="compliance/standalone-housekeeping/STANDALONE-HOUSEKEEPING-${REQS}.json"
+              bash scripts/standalone-housekeeping-release.sh validate "$REQS" "$DECLARATION"
+              echo "STANDALONE_DECLARATION=${DECLARATION}" >> "$GITHUB_ENV"
+              echo "TERMINAL_STATUS=released" >> "$GITHUB_ENV"
+            fi
           else
             REQS=""
             if [ -d compliance/pending-releases ]; then
@@ -111,7 +119,20 @@ jobs:
             fi
             REQS=$(echo ${REQS} | tr ' ' '\n' | sort -u | tr '\n' ' ' | sed 's/[[:space:]]*$//')
             if [ -z "${REQS}" ]; then
-              REQS="v$(date +%Y.%m.%d)"
+              chmod +x scripts/derive-release-version.sh scripts/standalone-housekeeping-release.sh 2>/dev/null || true
+              VERSION=$(bash scripts/derive-release-version.sh)
+              DECLARATION="compliance/standalone-housekeeping/STANDALONE-HOUSEKEEPING-${VERSION}.json"
+              if [ -f "$DECLARATION" ]; then
+                bash scripts/standalone-housekeeping-release.sh validate "$VERSION" "$DECLARATION"
+                REQS="$VERSION"
+                echo "STANDALONE_DECLARATION=${DECLARATION}" >> "$GITHUB_ENV"
+                # Standalone housekeeping is reviewed in its GitHub promotion
+                # PR. It does not enter the portal UAT/production queue unless
+                # a project deliberately supplies a tracked REQ instead.
+                echo "TERMINAL_STATUS=released" >> "$GITHUB_ENV"
+              else
+                echo "No tracked release ticket or standalone declaration: ordinary housekeeping has no portal promotion."
+              fi
             fi
           fi
           echo "In-scope releases to promote: ${REQS}"
@@ -413,6 +434,9 @@ jobs:
             # Carry the release ticket into the production environment so the
             # prod-review gate is self-contained.
             TICKET=""
+            if [ -n "${STANDALONE_DECLARATION:-}" ] && [ "$VERSION" = "${REQS}" ]; then
+              TICKET="$STANDALONE_DECLARATION"
+            fi
             for DIR in compliance/pending-releases compliance/approved-releases; do
               if [ -f "${DIR}/RELEASE-TICKET-${VERSION}.md" ]; then
                 TICKET="${DIR}/RELEASE-TICKET-${VERSION}.md"; break
@@ -447,6 +471,11 @@ jobs:
             fi
             # Advance status (idempotent — re-PATCHing an already-promoted release is a no-op).
             if [ -n "$RELEASE_ID" ]; then
+              if [ -n "${STANDALONE_DECLARATION:-}" ] && [ "$VERSION" = "${REQS}" ]; then
+                chmod +x scripts/standalone-housekeeping-release.sh 2>/dev/null || true
+                bash scripts/standalone-housekeeping-release.sh promote \
+                  "$PROJECT_SLUG" "$VERSION" "$STANDALONE_DECLARATION"
+              fi
               curl -s -o /dev/null -w "  ${VERSION} status patch: HTTP %{http_code}\n" \
                 -X PATCH "${BASE}/api/ci/releases/${RELEASE_ID}" \
                 -H "Authorization: Bearer ${DEVAUDIT_API_KEY}" \

package/sdlc/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@metasession.co/devaudit-sdlc",
-  "version": "0.3.14",
+  "version": "0.3.15",
   "description": "DevAudit SDLC CLI Engine — cross-agent terminal-driven SDLC orchestrator.",
   "bin": {
     "devaudit-sdlc": "./src/bin/devaudit-sdlc.js"

package/sdlc/src/blueprints/5-deploy-main.raw.md

@@ -45,13 +45,13 @@ gh pr merge [PR-NUMBER] --merge --delete-branch=false
 
 **Do NOT delete `develop`** — it's the permanent working branch.
 
-### Step 2: Sync Branches
+### Step 2: Preserve GitFlow
 
-```bash
-git checkout main && git pull origin main
-git checkout develop && git pull origin develop
-git merge main --no-edit && git push origin develop
-```
+Normal release synchronization is performed by the portal-dispatched close-out
+PR after the release reaches `released`; do not directly merge the release
+branch into the integration branch. A real hotfix is the exception: after its
+reviewed merge to the release branch, open the mandatory `backmerge/*` PR to the
+integration branch and merge it only after terminal-green checks.
 
 ### Step 3: Verify Production Deployment
 
@@ -149,11 +149,11 @@ The backend stores both with reviewer identity, SHA, and timestamp. This satisfi
 
 #### Steps
 
-1. Wait for `post-deploy-prod.yml` to complete (the workflow's "Advance release status" step prints `Release vYYYY.MM.DD → prod_review` when done).
+1. Wait for `post-deploy-prod.yml` to complete successfully **and** for its host-deployment check to confirm terminal success for the merged SHA.
 2. Open the release in DevAudit: `https://[DEVAUDIT_BASE_URL]/projects/[PROJECT_SLUG]/releases/[releaseId]`.
-3. Review the `prod-smoke-results.json` evidence (uploaded by the workflow) plus any post-deploy actions logged in the release ticket.
+3. Review the production deployment and smoke cycle records, their evidence, and any post-deploy actions logged in the release ticket. Do not approve while either cycle or the host deployment remains queued/in progress.
 4. Click **Approve Production** — status transitions to `prod_approved`.
-5. Click **Mark as Released** — status transitions to `released`. Pipeline lifecycle complete in DevAudit.
+5. Click **Mark as Released** — status transitions to `released`. This dispatches the automated close-out flow.
 
 If the smoke results look wrong or a manual verification fails, click **Reject** on the production approval and follow the Rollback procedure below before retrying.
 
@@ -161,41 +161,21 @@ If the smoke results look wrong or a manual verification fails, click **Reject**
 
 `approval.mode` is checked again here. `dual_actor` means the post-deploy approver must differ from the release creator. `solo_with_gap` accepts self-approval but records the control gap. `auto_low_risk` allows LOW-risk requirements to auto-advance through both transitions on workflow completion; MEDIUM/HIGH always require a human click.
 
-### Step 6: Finalize Compliance (Tracked Requirements Only)
-
-> **Automated path (preferred).** Run the synced helper instead of doing this by hand — it flips the ticket Status → `RELEASED` (+ backlinks the release PR and records the sign-off), flips the matching `RTM.md` row, and `git mv`s the ticket to `approved-releases/`, then stages the changes for you to commit:
->
-> ```bash
-> ./scripts/close-out-release.sh REQ-XXX --release-pr <release-PR-#>
-> git add -A && git commit -m "docs(compliance): close out REQ-XXX release ticket (RELEASED)" && git push origin develop
-> ```
->
-> It is **idempotent** (a no-op if already closed out) and, when `DEVAUDIT_API_KEY` + `DEVAUDIT_BASE_URL` are set, **refuses** unless the portal reports the release as `released` (so you can't flip the local tree ahead of the Production approval). The `close-out-release.yml` workflow runs the same script automatically when the portal marks a release released (and is `workflow_dispatch`-able for catch-up). The manual steps below are the fallback / reference for what the script does.
-
-```bash
-mv compliance/pending-releases/RELEASE-TICKET-REQ-XXX.md compliance/approved-releases/
-```
+### Step 6: Automated Close-out (Tracked Requirements Only)
 
-Update `compliance/RTM.md`:
-```markdown
-| REQ-XXX | Description | [RISK] | files | evidence | APPROVED - DEPLOYED | [Reviewer] | [Date] |
-```
+When the portal status becomes `released`, it dispatches `release-closed` to the
+consumer repository. `close-out-release.yml` then opens a
+`chore/close-out-REQ-XXX` PR to the configured integration branch. That PR is
+the canonical reconciliation record: it updates the RTM, moves the release
+ticket to `approved-releases/`, and moves manifest-listed absorbed predecessors
+to `superseded-releases/`.
 
-Add audit trail to release ticket:
-```markdown
-| [date] | UAT verification passed | [who] | Health + smoke + feature verified on UAT |
-| [date] | PR approved | [reviewer] | PR #[number] |
-| [date] | CI verification | GitHub Actions | All gates passed independently |
-| [date] | Deployed to production | System | Auto-deploy from main |
-| [date] | PROD post-deploy verification | [who] | Health + security checks passed on PROD |
-```
-
-```bash
-git add compliance/RTM.md compliance/approved-releases/ compliance/evidence/REQ-XXX/
-git rm compliance/pending-releases/RELEASE-TICKET-REQ-XXX.md 2>/dev/null
-git commit -m "compliance: [REQ-XXX] approved and deployed - PR #[number]"
-git push origin develop
-```
+Review and merge the close-out PR after its required checks are terminal green
+on its current head SHA. It is an administrative reconciliation PR, not a new
+production release. If the dispatch did not arrive, manually dispatch the
+Release Close-out workflow. Run `scripts/close-out-release.sh` locally only for
+documented recovery or historical catch-up; never create a normal direct
+close-out commit on a protected branch.
 
 ### Step 7: Close the GitHub Issue
 
@@ -207,17 +187,10 @@ gh issue close [ISSUE-NUMBER] --comment "Implemented in PR #[PR-NUMBER] (REQ-XXX
 
 This is the final traceability link: Issue → Requirement → PR → Deployment → Issue closed.
 
-### Step 8: Final Sync
-
-```bash
-git checkout main && git merge develop --no-edit && git push origin main
-git checkout develop
-```
-
 ## Rollback
 
 1. **Hosting dashboard:** Redeploy previous version
-2. **Git:** `git checkout main && git revert HEAD --no-edit && git push origin main`
+2. **Git:** create `hotfix/revert-REQ-XXX` from the release branch, revert the merge, and open a reviewed PR to the release branch. After terminal-green checks and merge, open the mandatory backmerge PR to integration.
 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.