@metasession.co/devaudit-cli 0.1.28 → 0.1.30

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@metasession.co/devaudit-cli",
-  "version": "0.1.28",
+  "version": "0.1.30",
   "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.28",
+    "@metasession.co/devaudit-plugin-sdk": "^0.1.30",
     "commander": "^12.1.0",
     "consola": "^3.2.3",
     "env-paths": "^3.0.0",

package/scripts/upload-evidence.sh

@@ -26,6 +26,12 @@
 #                               build / test / compliance / revert) for
 #                               the release row. Unknown values are
 #                               silently dropped server-side.
+#   --gate-status <status>      `passed` / `failed` / `skipped`. Lets the
+#                               portal distinguish a gate that ran-and-
+#                               failed from one that never ran. Forwarded
+#                               as `gateStatus`; unknown values are
+#                               silently dropped server-side.
+#                               DevAudit-Installer#96.
 #
 # Required environment variables:
 #   DEVAUDIT_BASE_URL  e.g. https://meta-comply-production.up.railway.app
@@ -65,6 +71,7 @@ ENVIRONMENT=""
 EVIDENCE_CATEGORY=""
 RELEASE_TITLE=""
 CHANGE_TYPE=""
+GATE_STATUS=""
 
 while [ "$#" -gt 0 ]; do
   case "$1" in
@@ -80,6 +87,10 @@ while [ "$#" -gt 0 ]; do
     # unknown change-type values are dropped server-side, not 400'd.
     --release-title) RELEASE_TITLE="$2"; shift 2 ;;
     --change-type) CHANGE_TYPE="$2"; shift 2 ;;
+    # passed/failed/skipped — surfaces failed gates on the portal so
+    # ran-and-failed != never-ran. Unknown values dropped server-side.
+    # DevAudit-Installer#96.
+    --gate-status) GATE_STATUS="$2"; shift 2 ;;
     *) echo "Unknown option: $1"; exit 1 ;;
   esac
 done
@@ -181,6 +192,7 @@ for FILE in "${FILES[@]}"; do
   [ -n "$EVIDENCE_CATEGORY" ] && CURL_ARGS+=(-F "evidenceCategory=${EVIDENCE_CATEGORY}")
   [ -n "$RELEASE_TITLE" ] && CURL_ARGS+=(-F "releaseTitle=${RELEASE_TITLE}")
   [ -n "$CHANGE_TYPE" ] && CURL_ARGS+=(-F "changeType=${CHANGE_TYPE}")
+  [ -n "$GATE_STATUS" ] && CURL_ARGS+=(-F "gateStatus=${GATE_STATUS}")
 
   ATTEMPT=1
   BACKOFF=$INITIAL_BACKOFF_SECONDS

package/sdlc/files/_common/governance/ai-disclosure.md.template

@@ -0,0 +1,91 @@
+---
+title: "AI Use Disclosure (deployer-facing)"
+provider: "REPLACE — legal name of the AI system provider"
+intended_purpose: "REPLACE — one-line description of intended use"
+last_reviewed_at: "REPLACE — YYYY-MM-DD"
+review_cadence_days: 180
+risk_class: "REPLACE — minimal | limited | high | unacceptable"
+---
+
+> ⚠️ **STARTER TEMPLATE — REPLACE BEFORE GOING TO PRODUCTION.**
+> This file was auto-installed by `devaudit install` as a starting point.
+> It does **not** describe your project's actual AI use. Edit and commit.
+> Auditors will reject unedited stubs. See `docs/governance-templates.md` for guidance.
+
+# AI Use Disclosure — Provision of information to deployers
+
+**Framework coverage:** `EUAIA.Art-13` (Transparency and provision of information to deployers)
+
+**Evidence type:** `ai_disclosure` · **Cadence:** refresh every 180 days, or whenever an AI tool / model / prompt-class is added or substantively changed.
+
+> The EU AI Act requires providers to give deployers (the people who put the AI system into use in their professional activity) **clear, comprehensive, accurate and unambiguous** information about the system's capabilities, limitations, and intended use. This file is that disclosure for our project — both for AI we develop and for third-party AI we incorporate.
+
+## 1. Intended purpose
+
+- **What the AI system does:** REPLACE
+- **Intended use cases:** REPLACE
+- **Foreseeable misuse / out-of-scope use cases:** REPLACE
+
+## 2. Risk classification
+
+- **Annex III high-risk category match:** REPLACE — none / list applicable categories
+- **Final risk class (per Title III):** REPLACE — minimal / limited / high / unacceptable
+- **Reasoning:** REPLACE
+
+## 3. AI tools and models in use
+
+Add one row per AI tool / model / API. Delete this template row before your first audit.
+
+| Tool / model | Vendor | Use case | Inputs (data classes) | Outputs | Risk class | Provider docs |
+|---|---|---|---|---|---|---|
+| REPLACE — e.g. GPT-4o | OpenAI | Code suggestion in IDE | Source code, no PII | Code suggestions | Limited | https://… |
+| REPLACE | | | | | | |
+
+## 4. Human oversight (Art. 14)
+
+- **Where humans intervene in the AI loop:** REPLACE — e.g. "Every AI-suggested change goes through a four-eyes code review before merge"
+- **Authority of the human reviewer:** REPLACE — can they reject / override / stop the system? Document the path
+- **Cross-reference to four-eyes release approval:** all releases require an approved-by audit event in the portal (closes `EUAIA.Art-14`)
+
+## 5. Capabilities and limitations
+
+- **Known limitations:** REPLACE — failure modes, training data cut-off, hallucination risk
+- **Accuracy / robustness metrics:** REPLACE — link to test reports / benchmark results
+- **Conditions under which performance degrades:** REPLACE
+
+## 6. Data, training, validation
+
+- **Training data provenance (if we train):** REPLACE — sources, licensing, consent
+- **Fine-tuning, RAG, prompt engineering used:** REPLACE
+- **Data flowing to third-party AI providers:** REPLACE — list each provider + what's sent + DPA / SCC reference (cross-link to ROPA)
+
+## 7. Logging and traceability (Art. 12)
+
+- **What we log:** REPLACE — prompts, completions, user/agent identity, timestamp
+- **Where logs live:** REPLACE — link to portal `audit_log` evidence pipeline
+- **Retention:** REPLACE
+- **Closes `EUAIA.Art-12` via the `audit_log` snapshot uploaded each release.**
+
+## 8. Deployer obligations
+
+- **What deployers must do to use the system safely:** REPLACE — link to operator runbook
+- **Notification of substantial modifications:** REPLACE — process
+
+## 9. Sign-off
+
+| Role | Name | Date |
+|---|---|---|
+| Provider responsible | REPLACE | REPLACE |
+| AI compliance reviewer | REPLACE | REPLACE |
+
+## Sources
+
+- [EU AI Act (Regulation 2024/1689)](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) — especially Art. 9–15 (high-risk requirements) and Title IV (transparency)
+- [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework)
+- [Anthropic Responsible Scaling Policy](https://www.anthropic.com/news/anthropics-responsible-scaling-policy) (example provider disclosure)
+
+## Review log
+
+| Date | Reviewer | Changes |
+|---|---|---|
+| REPLACE — YYYY-MM-DD | REPLACE | Initial AI disclosure authored from starter template |

package/sdlc/files/_common/governance/dpia.md.template

@@ -0,0 +1,78 @@
+---
+title: "Data Protection Impact Assessment (DPIA)"
+processing_activity: "REPLACE — short name of the activity assessed"
+controller: "REPLACE — legal name of the controller"
+last_reviewed_at: "REPLACE — YYYY-MM-DD"
+review_cadence_days: 365
+risk_level: "REPLACE — low | medium | high"
+---
+
+> ⚠️ **STARTER TEMPLATE — REPLACE BEFORE GOING TO PRODUCTION.**
+> This file was auto-installed by `devaudit install` as a starting point.
+> It does **not** describe your project's actual data protection risks. Edit and commit.
+> Auditors will reject unedited stubs. See `docs/governance-templates.md` for guidance.
+
+# Data Protection Impact Assessment
+
+**Framework coverage:** `GDPR.Art-35` (Data protection impact assessment)
+
+**Evidence type:** `dpia` · **Cadence:** refresh every 365 days, or whenever the processing materially changes.
+
+> A DPIA is **mandatory** for processing likely to result in high risk to data subjects: large-scale special-category data, systematic monitoring, automated decision-making with legal effect, etc. See Art. 35(3) and your supervisory authority's "blacklist" guidance.
+
+## 1. Description of the processing
+
+- **Activity name:** REPLACE
+- **Nature, scope, context, purposes:** REPLACE — what data is processed, how, why, for whom, at what scale
+- **Data flow diagram or reference:** REPLACE — link to architecture doc / threat model
+- **Cross-reference to ROPA:** `compliance/governance/ropa.md` activity REPLACE
+
+## 2. Necessity and proportionality
+
+- **Lawful basis (Art. 6):** REPLACE
+- **Special-category basis (Art. 9), if applicable:** REPLACE
+- **Less-intrusive alternatives considered:** REPLACE
+- **Data minimisation:** REPLACE — what's not collected and why
+- **Retention justification:** REPLACE
+- **Data subject rights — how exercised:** REPLACE — link to SAR procedure, rectification, erasure, portability
+
+## 3. Risks to rights and freedoms
+
+For each risk, populate one row. Add or remove rows to fit your assessment.
+
+| # | Risk | Likelihood (1–3) | Severity (1–3) | Inherent risk | Existing controls | Residual risk | Acceptable? |
+|---|---|---|---|---|---|---|---|
+| 1 | REPLACE — e.g. unauthorised access to user accounts | REPLACE | REPLACE | REPLACE | REPLACE — MFA, RBAC, encryption-at-rest | REPLACE | REPLACE Y/N |
+| 2 | REPLACE | | | | | | |
+
+## 4. Measures to address the risks
+
+- **Technical measures:** REPLACE — encryption, pseudonymisation, access controls, logging
+- **Organisational measures:** REPLACE — training, policies, contractual safeguards
+- **Residual high risk?** REPLACE — if YES, you must consult the supervisory authority (Art. 36) **before** processing begins. Document the consultation outcome.
+
+## 5. Consultation
+
+- **DPO opinion:** REPLACE — name, date, conclusion
+- **Data subjects / representatives consulted:** REPLACE — describe or document why not
+- **Supervisory authority prior consultation:** REPLACE — required only when residual high risk remains
+
+## 6. Sign-off
+
+| Role | Name | Date | Decision |
+|---|---|---|---|
+| Controller | REPLACE | REPLACE | REPLACE — approved / rejected / conditional |
+| DPO | REPLACE | REPLACE | REPLACE |
+| Technical lead | REPLACE | REPLACE | REPLACE |
+
+## Sources
+
+- [EDPB DPIA guidelines (WP248 rev.01)](https://edpb.europa.eu/our-work-tools/our-documents/guidelines/)
+- [ICO DPIA template](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/data-protection-impact-assessments-dpias/)
+- [CNIL PIA software](https://www.cnil.fr/en/open-source-pia-software-helps-carry-out-data-protection-impact-assessment)
+
+## Review log
+
+| Date | Reviewer | Changes |
+|---|---|---|
+| REPLACE — YYYY-MM-DD | REPLACE | Initial DPIA authored from starter template |

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

@@ -0,0 +1,111 @@
+---
+title: "Incident Report"
+incident_id: "REPLACE — e.g. INC-2026-001"
+severity: "REPLACE — low | medium | high | critical"
+detected_at: "REPLACE — ISO-8601 with timezone"
+resolved_at: "REPLACE — ISO-8601 or 'ongoing'"
+involves_personal_data: "REPLACE — true | false"
+reported_to_supervisory_authority: "REPLACE — true | false | n/a"
+notification_window_72h: "REPLACE — within | outside | n/a"
+last_reviewed_at: "REPLACE — YYYY-MM-DD"
+---
+
+> ⚠️ **STARTER TEMPLATE — REPLACE BEFORE GOING TO PRODUCTION.**
+> This file was auto-installed by `devaudit install` as a starting point.
+> If you reach for this file it's because something **happened** — replace this banner
+> with the actual incident details. One incident per file (rename to
+> `incident-report-<id>.md` if you keep multiple). Auditors will reject unedited stubs.
+
+# Incident Report
+
+**Framework coverage:**
+
+- `ISO29119.3.5.4` (Test incident report)
+- `SOC2.CC7.2` (System monitoring and incident response)
+- `GDPR.Art-33` (Notification of a personal data breach to the supervisory authority — 72h)
+- `GDPR.Art-34` (Communication of a personal data breach to the data subject)
+
+**Evidence type:** `incident_report` · One artefact can satisfy multiple clauses depending on its scope (test defect, ops incident, personal-data breach).
+
+## 1. Summary
+
+- **Incident ID:** REPLACE
+- **Severity:** REPLACE — low / medium / high / critical
+- **One-line description:** REPLACE
+- **Detected at:** REPLACE — when was it first noticed
+- **Resolved at:** REPLACE — or "ongoing"
+- **Duration:** REPLACE
+
+## 2. Personal data scope (GDPR triage)
+
+| Question | Answer |
+|---|---|
+| Did the incident involve personal data? | REPLACE — Y / N |
+| If Y: estimated number of data subjects affected | REPLACE |
+| If Y: categories of personal data involved | REPLACE |
+| If Y: likely consequences for data subjects | REPLACE |
+| **Notify supervisory authority (Art. 33)?** | REPLACE — required if Y and risk to rights/freedoms |
+| **Notify data subjects (Art. 34)?** | REPLACE — required if high risk to rights/freedoms |
+| 72-hour notification window: | REPLACE — within / outside / n/a; if outside, explain delay |
+
+## 3. Timeline
+
+| Time (UTC) | Event |
+|---|---|
+| REPLACE — ISO-8601 | REPLACE — first signal observed |
+| REPLACE | REPLACE — detection escalated to on-call |
+| REPLACE | REPLACE — incident channel opened, IC assigned |
+| REPLACE | REPLACE — mitigation deployed |
+| REPLACE | REPLACE — incident declared resolved |
+| REPLACE | REPLACE — supervisory authority notified (if applicable) |
+| REPLACE | REPLACE — data subjects notified (if applicable) |
+
+## 4. Root cause
+
+- **What happened:** REPLACE — technical narrative
+- **Why it happened:** REPLACE — 5-whys or equivalent
+- **Why it wasn't caught earlier:** REPLACE — gap in monitoring / testing / review
+
+## 5. Impact
+
+- **Users affected:** REPLACE — count + segment
+- **Data confidentiality / integrity / availability impact:** REPLACE
+- **Financial / reputational:** REPLACE
+- **Regulatory:** REPLACE
+
+## 6. Containment, mitigation, and recovery
+
+- **Containment actions:** REPLACE
+- **Mitigation deployed (link PRs):** REPLACE
+- **Recovery actions:** REPLACE
+- **Verification that the incident is resolved:** REPLACE
+
+## 7. Communications
+
+- **Internal:** REPLACE — who was notified, when
+- **Customer / data subjects:** REPLACE — channel, content (attach), timing
+- **Supervisory authority:** REPLACE — body, reference number, content (attach)
+- **Public statement:** REPLACE — link if any
+
+## 8. Lessons learned and follow-ups
+
+- **What worked well:** REPLACE
+- **What didn't:** REPLACE
+- **Follow-up actions (issue links, owners, due dates):** REPLACE — file GitHub issues; one row per action
+  - [ ] REPLACE — owner @REPLACE — due REPLACE
+  - [ ] REPLACE — owner @REPLACE — due REPLACE
+
+## 9. Sign-off
+
+| Role | Name | Date |
+|---|---|---|
+| Incident Commander | REPLACE | REPLACE |
+| Engineering lead | REPLACE | REPLACE |
+| DPO (if personal data involved) | REPLACE | REPLACE |
+| Security lead | REPLACE | REPLACE |
+
+## Sources
+
+- [ICO breach reporting guidance](https://ico.org.uk/for-organisations/report-a-breach/personal-data-breach/) (UK)
+- [EDPB Guidelines 9/2022 on personal data breach notification](https://edpb.europa.eu/our-work-tools/our-documents/guidelines/)
+- [SOC 2 Trust Services Criteria — CC7 (System Operations)](https://www.aicpa-cima.com/topic/audit-assurance/trust-services-criteria)

package/sdlc/files/_common/governance/periodic-review.md.template

@@ -0,0 +1,107 @@
+---
+title: "Periodic Review of Internal Controls"
+period_start: "REPLACE — YYYY-MM-DD"
+period_end: "REPLACE — YYYY-MM-DD"
+reviewer: "REPLACE — name + role"
+last_reviewed_at: "REPLACE — YYYY-MM-DD"
+review_cadence_days: 90
+---
+
+> ⚠️ **STARTER TEMPLATE — REPLACE BEFORE GOING TO PRODUCTION.**
+> This file was auto-installed by `devaudit install` as a starting point.
+> Once Workstream 3 ships (`.github/workflows/periodic-review.yml`), this file will be
+> auto-regenerated quarterly with portal metrics. Until then — and to add the human
+> attestation the auto-generator can't produce — edit this file yourself. Auditors
+> will reject unedited stubs. See `docs/governance-templates.md` for guidance.
+
+# Periodic Review of Internal Controls
+
+**Framework coverage:**
+
+- `SOC2.CC4.1` (Monitoring of internal controls)
+- `ISO27001.A.12.1` (Operational procedures and responsibilities)
+
+**Evidence type:** `periodic_review` · **Cadence:** every 90 days (quarterly). The portal flags this evidence as `expired` after 365 days — but a 90-day cadence is the practical minimum.
+
+## 1. Review period
+
+- **From:** REPLACE — YYYY-MM-DD
+- **To:** REPLACE — YYYY-MM-DD
+- **Reviewer:** REPLACE — name + role
+- **Approver (different person, if dual-actor required):** REPLACE
+
+## 2. Activity summary (CI-derived, auto-fill when WS3 lands)
+
+| Metric | Value | Notes |
+|---|---|---|
+| Releases shipped this period | REPLACE | Tracked + housekeeping combined |
+| Tracked releases (REQ-XXX) | REPLACE | |
+| Quality-gate pass rate | REPLACE — % | % of CI runs where every gate passed |
+| SAST findings net change | REPLACE | +/- vs. previous period |
+| Dependency-audit unaccepted high/critical | REPLACE | Current count |
+| Audit-log entries | REPLACE | Total in period |
+| Open SDLC issues at period end | REPLACE | From `gh issue list --label requirement --state open` |
+
+## 3. Control-effectiveness review
+
+For each control area, document evidence + reviewer judgement.
+
+### 3a. Access control (ISO 27001 A.5.15)
+
+- **Active access grants reviewed:** REPLACE — list or attach export
+- **Grants revoked this period:** REPLACE — count + reason
+- **Anomalies:** REPLACE — or "none"
+- **Effective?** REPLACE — Y / N (if N, follow-up action below)
+
+### 3b. Change management (ISO 27001 A.8.32 / SOC 2 CC8.1)
+
+- **Releases approved via four-eyes flow:** REPLACE — N of M
+- **Self-approval blocked on MEDIUM/HIGH risk?** REPLACE — confirm enforcement
+- **Effective?** REPLACE
+
+### 3c. Security testing (ISO 27001 A.8.29)
+
+- **SAST gate pass rate:** REPLACE
+- **Dependency-audit gate pass rate:** REPLACE
+- **E2E gate pass rate:** REPLACE
+- **Effective?** REPLACE
+
+### 3d. Logging and monitoring (ISO 27001 A.8.16 / EUAIA Art. 12)
+
+- **Audit-log entries reviewed:** REPLACE — sample size + method
+- **Anomalies escalated:** REPLACE — count
+- **Effective?** REPLACE
+
+### 3e. Operational procedures (ISO 27001 A.12.1)
+
+- **Procedures reviewed this period:** REPLACE — list (link `Periodic_Security_Review_Schedule.md` items completed)
+- **Stale / out-of-date docs:** REPLACE
+- **Effective?** REPLACE
+
+## 4. Incidents this period
+
+- **Total incidents:** REPLACE — link each `compliance/governance/incident-report-*.md`
+- **Personal-data breaches:** REPLACE — count
+- **Mean time to detection (MTTD):** REPLACE
+- **Mean time to resolution (MTTR):** REPLACE
+
+## 5. Findings and follow-up actions
+
+| # | Finding | Severity | Owner | Due | Issue link |
+|---|---|---|---|---|---|
+| 1 | REPLACE | REPLACE | REPLACE | REPLACE | REPLACE |
+| 2 | REPLACE | | | | |
+
+## 6. Sign-off
+
+| Role | Name | Date |
+|---|---|---|
+| Reviewer | REPLACE | REPLACE |
+| Approver (dual-actor) | REPLACE | REPLACE |
+| Decision | REPLACE — controls effective / partially effective / not effective |
+
+## Sources
+
+- [SOC 2 Trust Services Criteria — CC4 (Monitoring)](https://www.aicpa-cima.com/topic/audit-assurance/trust-services-criteria)
+- [ISO/IEC 27001:2022 Annex A.12 — Operational security](https://www.iso.org/standard/82875.html)
+- Your project's `Periodic_Security_Review_Schedule.md`

package/sdlc/files/_common/governance/ropa.md.template

@@ -0,0 +1,59 @@
+---
+title: "Records of Processing Activities (ROPA)"
+controller: "REPLACE — legal name of the controller"
+controller_contact: "REPLACE — DPO email or controller contact"
+last_reviewed_at: "REPLACE — YYYY-MM-DD"
+review_cadence_days: 365
+processing_activities: []
+---
+
+> ⚠️ **STARTER TEMPLATE — REPLACE BEFORE GOING TO PRODUCTION.**
+> This file was auto-installed by `devaudit install` as a starting point.
+> It does **not** describe your project's actual processing activities. Edit and commit.
+> Auditors will reject unedited stubs. See `docs/governance-templates.md` for guidance.
+
+# Records of Processing Activities
+
+**Framework coverage:** `GDPR.Art-30` (Records of processing activities)
+
+**Evidence type:** `ropa` · **Cadence:** refresh every 365 days (portal flags as `expired` after)
+
+## Controller
+
+- **Legal name:** REPLACE
+- **Address:** REPLACE
+- **Contact / DPO:** REPLACE
+- **Joint controllers / representatives:** REPLACE (or "none")
+
+## Processing activities
+
+For each distinct processing activity your project performs, add one section below. Delete this template row before your first audit.
+
+### Activity 1 — REPLACE (e.g. "User authentication and session management")
+
+| Field | Value |
+|---|---|
+| **Purpose(s) of processing** | REPLACE — why you process this data; lawful basis (Art. 6) |
+| **Categories of data subjects** | REPLACE — e.g. customers, employees, prospects |
+| **Categories of personal data** | REPLACE — e.g. name, email, IP address, hashed password |
+| **Special categories (Art. 9)** | REPLACE — none / specify (health, biometric, etc.) |
+| **Recipients / categories of recipients** | REPLACE — internal teams + named processors |
+| **Third-country transfers** | REPLACE — none / list countries + safeguard (SCCs, adequacy) |
+| **Retention period** | REPLACE — e.g. "duration of customer relationship + 7 years" |
+| **Technical and organisational security measures** | REPLACE — link to ISO 27001 controls / Test_Policy.md / encryption details |
+
+### Activity 2 — REPLACE
+
+(repeat the table above)
+
+## Sources
+
+- [ICO ROPA template (UK)](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/documentation/records-of-processing/)
+- [EDPB Guidelines on Article 30](https://edpb.europa.eu/our-work-tools/our-documents/guidelines/)
+- Your privacy policy + DPIA (`compliance/governance/dpia.md`) should describe the same activities.
+
+## Review log
+
+| Date | Reviewer | Changes |
+|---|---|---|
+| REPLACE — YYYY-MM-DD | REPLACE | Initial ROPA authored from starter template |

package/sdlc/files/_common/scripts/derive-release-version.sh

@@ -13,6 +13,9 @@
 #   4. Pending release ticket on disk: exactly one
 #                                      compliance/pending-releases/RELEASE-TICKET-REQ-XXX.md
 #                                                                    -> REQ-XXX
+#   4-bis. RTM.md IN PROGRESS row:    exactly one tracked REQ marked
+#                                      IN PROGRESS in compliance/RTM.md
+#                                                                    -> REQ-XXX
 #   5. Fallback:                      bare date                      -> v2026.05.17
 #
 # Step 4 (DevAudit-Installer#92) handles `chore:` / `docs:` / `ci:`
@@ -23,6 +26,12 @@
 # bare date — when exactly one ticket is open, attribute to it.
 # Multiple open tickets stays ambiguous → bare-date fallback.
 #
+# Step 4-bis (DevAudit-Installer#95) is the zero-ceremony equivalent:
+# RTM.md is the file the operator already maintains as the source of
+# truth for release state. When step 4 finds no ticket and exactly one
+# RTM row is IN PROGRESS, attribute to it. RTM_PATH defaults to
+# compliance/RTM.md and is overridable via env.
+#
 # The id is taken from a bracketed [REQ-XXX] tag (subject or body) or the
 # `Ref:` line — NOT from unbracketed prose (e.g. "target close: REQ-002" must
 # not win over "Ref: REQ-001"). Step 3 exists because a "Merge pull request"
@@ -83,5 +92,32 @@ if [ -d compliance/pending-releases ]; then
   fi
 fi
 
+# 4-bis. RTM.md IN PROGRESS row: when exactly one REQ row in
+# compliance/RTM.md (or $RTM_PATH) is marked IN PROGRESS, attribute the
+# in-flight release to it. Reads the file the operator already
+# maintains so chore/docs/ci sync commits don't need a manually-dropped
+# pending-tickets file. Same exactly-one guard as step 4 — zero or
+# multiple IN PROGRESS rows → ambiguous, fall through.
+# DevAudit-Installer#95.
+RTM_PATH="${RTM_PATH:-compliance/RTM.md}"
+if [ -f "$RTM_PATH" ]; then
+  # Match REQ rows whose status column starts with `IN PROGRESS`.
+  # `\|[[:space:]]+IN PROGRESS` requires a pipe followed by whitespace,
+  # so legend rows (`| \`IN PROGRESS\``) and prose mentions don't match.
+  # Variable padding between REQ-ID and Status (Issue/Risk/Evidence
+  # columns) is fine — only the leading REQ-XXX and the status-cell
+  # marker matter.
+  IN_PROGRESS_REQS=$(grep -E '\|[[:space:]]+IN PROGRESS' "$RTM_PATH" 2>/dev/null \
+    | grep -oE '^\|[[:space:]]*REQ-[0-9]+' \
+    | grep -oE 'REQ-[0-9]+' | sort -u || true)
+  if [ -n "$IN_PROGRESS_REQS" ]; then
+    IN_PROGRESS_COUNT=$(echo "$IN_PROGRESS_REQS" | grep -c .)
+    if [ "$IN_PROGRESS_COUNT" = "1" ]; then
+      echo "$IN_PROGRESS_REQS"
+      exit 0
+    fi
+  fi
+fi
+
 # 5. Fallback: bare date in UTC
 echo "v$(date -u +%Y.%m.%d)"

package/sdlc/files/_common/scripts/derive-release-version.test.sh

@@ -154,6 +154,89 @@ cat > compliance/pending-releases/RELEASE-TICKET-REQ-051.md <<'TICKET'
 TICKET
 assert_eq "subject [REQ-099] beats pending REQ-051 -> REQ-099" "REQ-099" "$(run_helper)"
 
+# Case 13 (DevAudit-Installer#95): step-4-bis. No subject/body tag,
+# no pending ticket, but RTM.md has exactly one IN PROGRESS row.
+# Attribute to that REQ. Tests the zero-ceremony fallback that
+# survives chore/docs/ci sync commits when no operator state file
+# has been dropped.
+make_fixture "$WORK/c13" "chore: devaudit update to 0.1.29"
+mkdir -p compliance
+cat > compliance/RTM.md <<'RTM'
+# RTM
+| REQ-ID  | Issue | Risk | Evidence                     | Status              | Approver | Date       |
+| ------- | ----- | ---- | ---------------------------- | ------------------- | -------- | ---------- |
+| REQ-100 | #10   | LOW  | compliance/evidence/REQ-100/ | APPROVED - DEPLOYED | dev      | 2026-05-30 |
+| REQ-101 | #11   | MED  | compliance/evidence/REQ-101/ | IN PROGRESS         | dev      | 2026-06-01 |
+RTM
+assert_eq "RTM single IN PROGRESS row -> REQ-101" "REQ-101" "$(run_helper)"
+
+# Case 14: step-4-bis ambiguity guard. Two IN PROGRESS rows → falls
+# through to the bare date rather than guessing.
+make_fixture "$WORK/c14" "chore: devaudit update to 0.1.29"
+mkdir -p compliance
+cat > compliance/RTM.md <<'RTM'
+| REQ-ID  | Status         |
+| ------- | -------------- |
+| REQ-101 | IN PROGRESS    |
+| REQ-102 | IN PROGRESS    |
+RTM
+assert_eq "RTM two IN PROGRESS rows -> bare date $TODAY" "$TODAY" "$(run_helper)"
+
+# Case 15: step-4-bis must ignore legend rows that mention IN PROGRESS
+# inside backticks (the wawagardenbar-app RTM convention) and prose
+# mentions in description columns.
+make_fixture "$WORK/c15" "chore: devaudit update to 0.1.29"
+mkdir -p compliance
+cat > compliance/RTM.md <<'RTM'
+# RTM
+## Conventions
+| Value              | Meaning                       |
+| ------------------ | ----------------------------- |
+| `IN PROGRESS`      | Active development underway   |
+
+| REQ-ID  | Status                                                            |
+| ------- | ----------------------------------------------------------------- |
+| REQ-200 | RELEASED (was IN PROGRESS during Q3, then deployed)               |
+RTM
+assert_eq "RTM legend + prose mentions -> bare date $TODAY" "$TODAY" "$(run_helper)"
+
+# Case 16: step-4-bis with the real META-JOBS-shaped RTM row (long
+# parenthetical commentary in the status cell). The status cell still
+# starts with `IN PROGRESS` after the pipe.
+make_fixture "$WORK/c16" "chore: devaudit update to 0.1.29"
+mkdir -p compliance
+cat > compliance/RTM.md <<'RTM'
+| REQ-ID  | Issue | Risk        | Evidence                     | Status                                                                | Approver   | Date       |
+| ------- | ----- | ----------- | ---------------------------- | --------------------------------------------------------------------- | ---------- | ---------- |
+| REQ-056 | #117  | MEDIUM-HIGH | compliance/evidence/REQ-056/ | IN PROGRESS (WhatsApp inbound-message router; many details follow...) | ostendo-io | 2026-06-01 |
+RTM
+assert_eq "RTM long parenthetical status -> REQ-056" "REQ-056" "$(run_helper)"
+
+# Case 17: step-4-bis must NOT win over a pending ticket on disk.
+# Step 4 returns first.
+make_fixture "$WORK/c17" "chore: devaudit update to 0.1.29"
+mkdir -p compliance/pending-releases compliance
+cat > compliance/pending-releases/RELEASE-TICKET-REQ-301.md <<'TICKET'
+# Release Ticket: REQ-301
+TICKET
+cat > compliance/RTM.md <<'RTM'
+| REQ-ID  | Status      |
+| ------- | ----------- |
+| REQ-302 | IN PROGRESS |
+RTM
+assert_eq "pending ticket REQ-301 beats RTM IN PROGRESS REQ-302" "REQ-301" "$(run_helper)"
+
+# Case 18: step-4-bis respects RTM_PATH env override.
+make_fixture "$WORK/c18" "chore: devaudit update to 0.1.29"
+mkdir -p docs
+cat > docs/custom-RTM.md <<'RTM'
+| REQ-ID  | Status      |
+| ------- | ----------- |
+| REQ-400 | IN PROGRESS |
+RTM
+GOT=$(RTM_PATH=docs/custom-RTM.md run_helper)
+assert_eq "RTM_PATH=docs/custom-RTM.md -> REQ-400" "REQ-400" "$GOT"
+
 echo ""
 echo "=== Summary: $PASS pass / $FAIL fail ==="
 

package/sdlc/files/_common/scripts/validate-commits.sh

@@ -22,7 +22,10 @@ echo "Comparing: $BASE_BRANCH...HEAD"
 echo ""
 
 # Conventional Commit regex: type(optional-scope): description
-CC_REGEX='^(feat|fix|docs|test|refactor|chore|compliance|security|perf|ci|build|revert)(\([a-zA-Z0-9_-]+\))?!?: .+'
+# Scope accepts anything except `)` so multi-scope subjects like
+# `feat(auth,profile):` and `fix(rewards/expiry):` validate. The closing-paren
+# guard prevents pathological inputs. DevAudit-Installer#93.
+CC_REGEX='^(feat|fix|docs|test|refactor|chore|compliance|security|perf|ci|build|revert)(\([^)]+\))?!?: .+'
 
 COMMITS=$(git log "$BASE_BRANCH"..HEAD --format='%H' || true)