@metasession.co/devaudit-cli 0.1.43 → 0.1.44

package/package.json

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

package/sdlc/files/_common/1-plan-requirement.md

@@ -25,7 +25,7 @@ description: Define a new requirement in the RTM, classify risk, create implemen
 
 ### Step 1: Identify the GitHub Issue
 
-Every tracked change starts from a GitHub Issue. The issue provides the *what* and *why*; the RTM provides the compliance audit trail.
+Every tracked change starts from a GitHub Issue. The issue provides the _what_ and _why_; the RTM provides the compliance audit trail.
 
 - If the user references an issue number (e.g., `#123`): fetch its title, description, and labels using `gh issue view 123`.
 - If the user describes work without an issue: ask **"Is there a GitHub Issue for this, or should we create one?"**
@@ -42,11 +42,11 @@ The next ID is one higher (e.g., if the last is REQ-007, use REQ-008).
 
 ### Step 3: Classify Risk Level
 
-| Risk Level | Criteria |
-|---|---|
-| **Low** | Internal tools, no regulated data, no auth changes |
+| Risk Level | Criteria                                                         |
+| ---------- | ---------------------------------------------------------------- |
+| **Low**    | Internal tools, no regulated data, no auth changes               |
 | **Medium** | Touches PII, user-facing features, API changes, new dependencies |
-| **High** | Security, payments, RBAC, data handling, authentication |
+| **High**   | Security, payments, RBAC, data handling, authentication          |
 
 AI involvement raises risk by one level when touching Medium or High categories. See Test Policy for the full risk matrix.
 
@@ -68,11 +68,12 @@ mkdir -p compliance/evidence/REQ-XXX
 
 ### Step 6: Implementation Plan (MEDIUM/HIGH Risk — Required)
 
-For MEDIUM and HIGH risk requirements, create an implementation plan before defining test scope. The implementation plan defines *what code changes are needed* — the test scope is then derived from it.
+For MEDIUM and HIGH risk requirements, create an implementation plan before defining test scope. The implementation plan defines _what code changes are needed_ — the test scope is then derived from it.
 
 **Skip this step** for LOW risk requirements — proceed directly to Step 7.
 
 **6a. Explore the codebase:**
+
 - Understand existing patterns, models, services, and API routes relevant to the change
 - Identify files that will be created, modified, or affected
 
@@ -89,27 +90,35 @@ Create `compliance/evidence/REQ-XXX/implementation-plan.md`:
 **Date:** [YYYY-MM-DD]
 
 ## Approach
+
 [1-3 sentences describing the overall approach]
 
 ## Files to Create
+
 - `path/to/new-file.ts` — [purpose]
 
 ## Files to Modify
+
 - `path/to/existing-file.ts` — [what changes and why]
 
 ## Architecture Decisions
 
 > Populated by the [`adr-author` skill](../skills/adr-author/SKILL.md) at Stage 1 plan APPROVAL. The skill applies a decision tree (new third-party dependency / new database, cache, or queue / new external service / pattern change spanning > 3 files / HIGH-CRITICAL risk) and either drafts `docs/ADR/ADR-NNN-<slug>.md` + injects "Produced ADR-NNN: <title>" here, or injects "No ADR needed — <one-line rationale>" so the question is visibly asked and answered. Don't author this section inline as bullets — the persistent decision lives in `docs/ADR/`, not buried in the plan.
 
-- ADR-NNN — <title> (`docs/ADR/ADR-NNN-<slug>.md`) — Operator edits stub + flips to *Accepted* before APPROVAL — OR — No ADR needed — <rationale>
+- ADR-NNN — <title> (`docs/ADR/ADR-NNN-<slug>.md`) — Operator edits stub + flips to _Accepted_ before APPROVAL — OR — No ADR needed — <rationale>
 
 ## Dependencies
+
 - [New packages needed, or "None"]
 
 ## Risks / Considerations
-- [Anything that could go wrong or needs special attention]
+
+> Populated by the [`risk-register-keeper` skill](../skills/risk-register-keeper/SKILL.md) at Stage 1 for MEDIUM/HIGH risk REQs (LOW skipped by default per `sdlc-config.json:risk_register_keeper.stage_1_min_risk_class`). The skill identifies discrete risks the change introduces, allocates `RISK-NNN` per project, drafts canonical rows in `compliance/risk-register.md`, and injects the RISK-NNN reference list here (replacing the inline bullets). Don't author this section inline as bullets — the persistent risk record lives in `compliance/risk-register.md`, not buried in the plan.
+
+- RISK-NNN — <title> (`compliance/risk-register.md`) — Operator edits canonical row + signs off residual rating before APPROVAL — OR — @risk-deferred — <rationale>
 
 ## Post-Deploy Actions
+
 - [Data migrations, backfill scripts, schema changes — or "None"]
 - [If any: create script in `scripts/`, document exact command and target environment]
 ```
@@ -117,6 +126,7 @@ Create `compliance/evidence/REQ-XXX/implementation-plan.md`:
 ### WAIT CHECKPOINT: Implementation Plan Review
 
 **Present the implementation plan to the developer.** Summarize:
+
 - Approach and rationale
 - Files to create/modify
 - Architecture decisions
@@ -277,6 +287,7 @@ EOF
 ### WAIT CHECKPOINT: Test Scope Review
 
 **Present the test scope to the developer.** Summarize:
+
 - Risk classification and rationale
 - Test approach (which additional testing applies)
 - Acceptance criteria
@@ -332,6 +343,7 @@ EOF
 ### WAIT CHECKPOINT: Test Plan Review
 
 **Present the test plan to the developer.** Summarize:
+
 - Tests to add, update, and remove
 - How acceptance criteria map to specific tests
 - Any non-functional testing required

package/sdlc/files/_common/Implementation_Plan_TEMPLATE.md

@@ -21,27 +21,27 @@ authored_at: "REPLACE — YYYY-MM-DD"
 
 **Closes clauses** (every implementation plan satisfies all four):
 
-| Clause | What this plan must contain |
-|---|---|
-| **ISO 29119 §3.4** Test Plan | Acceptance criteria + the strategy for verifying each one. Reference the per-REQ `test-plan.md` if it lives separately. |
-| **ISO 27001 A.8.25** Secure development life cycle | Threat model + secure-design considerations (auth, data handling, dependencies, secrets). |
+| Clause                                                    | What this plan must contain                                                                                                                                       |
+| --------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| **ISO 29119 §3.4** Test Plan                              | Acceptance criteria + the strategy for verifying each one. Reference the per-REQ `test-plan.md` if it lives separately.                                           |
+| **ISO 27001 A.8.25** Secure development life cycle        | Threat model + secure-design considerations (auth, data handling, dependencies, secrets).                                                                         |
 | **GDPR Art. 25** Data protection by design and by default | Per-purpose data flows; minimisation; lawful basis; retention. **Required for any REQ that processes personal data; explicit "no personal data" callout if not.** |
-| **EU AI Act Art. 11** Technical documentation (Annex IV) | When the REQ touches AI / model behaviour: model provenance, prompt sources, oversight path. **Explicit "no AI in scope" callout if not.** |
+| **EU AI Act Art. 11** Technical documentation (Annex IV)  | When the REQ touches AI / model behaviour: model provenance, prompt sources, oversight path. **Explicit "no AI in scope" callout if not.**                        |
 
 Each section below maps to one (or more) of these clauses. Don't delete sections — mark with "N/A — <reason>" if the clause genuinely doesn't apply.
 
 ## 1. Goal + acceptance criteria
 
-> *Closes ISO 29119 §3.4 — test plan*
+> _Closes ISO 29119 §3.4 — test plan_
 
 - **Goal:** REPLACE — one sentence describing what this REQ delivers, no jargon.
 - **Acceptance criteria:**
 
-| AC | Description | SRS item it traces to |
-|---|---|---|
+| AC  | Description                                | SRS item it traces to                                                                   |
+| --- | ------------------------------------------ | --------------------------------------------------------------------------------------- |
 | AC1 | REPLACE — one-line behavioural description | REQ-AREA-NNN (existing) / REQ-AREA-NNN (new — propose stub) / `@srs-deferred: <reason>` |
-| AC2 | REPLACE | REPLACE |
-| … | | |
+| AC2 | REPLACE                                    | REPLACE                                                                                 |
+| …   |                                            |                                                                                         |
 
 > **SRS-ID column populated by the `requirements-aligner` skill** at Stage 1 plan APPROVAL. The skill fuzzy-matches each AC against `docs/SRS.md`, proposes new `REQ-AREA-NNN` stubs for behaviour the SRS doesn't yet describe, and flags stale items. Plan APPROVAL blocks (configurable per `sdlc-config.json:requirements_aligner.block_on_stage_1`, ramp-up mode default-on for legacy projects) until every AC has either an existing SRS item, a new SRS-ID stub added in this cycle, or an explicit `@srs-deferred` annotation. See [`requirements-aligner` skill](../skills/requirements-aligner/SKILL.md).
 
@@ -52,13 +52,13 @@ Each section below maps to one (or more) of these clauses. Don't delete sections
 
 ## 3. Architecture decisions
 
-> *Populated by the [`adr-author` skill](../skills/adr-author/SKILL.md) at Stage 1 plan APPROVAL.*
+> _Populated by the [`adr-author` skill](../skills/adr-author/SKILL.md) at Stage 1 plan APPROVAL._
 
 Either an ADR-NNN reference list (when the skill judges the REQ architecturally significant) OR an explicit "no ADR" rationale. **Don't author this section inline as bullets** — the `adr-author` skill applies its decision tree and either drafts a `docs/ADR/ADR-NNN-<slug>.md` stub the operator edits, or annotates the no-ADR case.
 
 When **ADR warranted**:
 
-- **ADR-NNN — <decision title>** — Drafted by `adr-author`. File at `docs/ADR/ADR-NNN-<slug>.md`. Operator edits stub to canonical prose + flips status to *Accepted* before plan APPROVAL.
+- **ADR-NNN — <decision title>** — Drafted by `adr-author`. File at `docs/ADR/ADR-NNN-<slug>.md`. Operator edits stub to canonical prose + flips status to _Accepted_ before plan APPROVAL.
 
 When **No ADR needed**:
 
@@ -68,20 +68,31 @@ The negative case is audit evidence too — auditors examine "no ADR — <ration
 
 ## 4. Threat model + security considerations
 
-> *Closes ISO 27001 A.8.25 — secure development life cycle*
+> _Closes ISO 27001 A.8.25 — secure development life cycle_
 
-| Threat | Likelihood | Impact | Mitigation |
-|---|---|---|---|
-| REPLACE — e.g. SQL injection via X param | REPLACE | REPLACE | REPLACE |
-| REPLACE — e.g. unauthenticated access to Y route | REPLACE | REPLACE | REPLACE |
+| Threat                                           | Likelihood | Impact  | Mitigation |
+| ------------------------------------------------ | ---------- | ------- | ---------- |
+| REPLACE — e.g. SQL injection via X param         | REPLACE    | REPLACE | REPLACE    |
+| REPLACE — e.g. unauthenticated access to Y route | REPLACE    | REPLACE | REPLACE    |
 
 **Secrets / credentials:** REPLACE — does this REQ handle any? If yes, how stored, rotated, scoped?
 
 **Dependencies introduced:** REPLACE — list new npm/pip packages; flag any with known CVEs or transitive concerns.
 
+### Risk register entries
+
+> _Populated by the [`risk-register-keeper` skill](../skills/risk-register-keeper/SKILL.md) for MEDIUM/HIGH risk REQs at Stage 1 plan APPROVAL. The persistent risk record lives in [`compliance/risk-register.md`](../../risk-register.md); this section references the RISK-NNN entries this REQ opened, mitigated, or accepted._
+
+When **risk class is MEDIUM or HIGH**, expect a list like:
+
+- **RISK-NNN — <title>** — Status: OPEN. Opened by `risk-register-keeper`. Operator edits canonical row + signs off residual rating before plan APPROVAL.
+- **RISK-NNN — <title>** — Status: MITIGATED. Controls landing in this PR close the residual.
+
+When **risk class is LOW** OR no register-worthy risk is identified, write: _"@risk-deferred: <one-line rationale>"_ — the negative case is audit evidence too. Don't leave this section empty.
+
 ## 5. Data protection (GDPR Art. 25)
 
-> *Closes GDPR Art. 25 — data protection by design*
+> _Closes GDPR Art. 25 — data protection by design_
 
 **Personal data processed by this REQ:** REPLACE — yes / no.
 
@@ -99,11 +110,11 @@ If **yes**, fill in:
   - Is a DPIA required? REPLACE — yes (file under `compliance/governance/dpia-<reqid>.md`) / no / N/A
 - **Cross-border transfers:** REPLACE — none / specify mechanism
 
-If **no**, write: *"N/A — this REQ does not process personal data. <Why — e.g. UI-only change, internal-routing refactor, dev-tooling.>"*
+If **no**, write: _"N/A — this REQ does not process personal data. <Why — e.g. UI-only change, internal-routing refactor, dev-tooling.>"_
 
 ## 6. AI / model considerations (EU AI Act Art. 11)
 
-> *Closes EUAIA Art. 11 — technical documentation*
+> _Closes EUAIA Art. 11 — technical documentation_
 
 **AI / ML in scope for this REQ:** REPLACE — yes / no.
 
@@ -117,7 +128,7 @@ If **yes**, fill in:
 - **Cross-references:**
   - Is `compliance/governance/ai-disclosure.md` updated? REPLACE — yes / no / N/A
 
-If **no**, write: *"N/A — this REQ does not introduce or change AI behaviour. <Why.>"*
+If **no**, write: _"N/A — this REQ does not introduce or change AI behaviour. <Why.>"_
 
 ## 7. Rollback plan
 

package/sdlc/files/_common/governance/risk-register.md.template

@@ -0,0 +1,116 @@
+---
+title: 'Risk register'
+project: 'REPLACE — project name'
+maintained_by: 'risk-register-keeper skill (DevAudit-Installer v0.1.44+)'
+scoring_matrix: 'likelihood × impact (3×3)'
+last_reviewed_at: 'REPLACE — YYYY-MM-DD'
+review_cadence_days: 90
+---
+
+> ⚠️ **STARTER TEMPLATE — REPLACE BEFORE COMMITTING.**
+> Installed on demand via `devaudit bootstrap-governance` as a starting point.
+> It does **not** describe your project's actual risks. The `risk-register-keeper` skill (DevAudit-Installer#121) maintains this file as REQs land, incidents close, and accepted risks come due for re-validation.
+> Auditors reject unedited stubs.
+
+# Risk register — REPLACE project
+
+**Framework coverage:** primary audit surface for `SOC2.CC3.2` (Risk identification and assessment), `SOC2.CC3.4` (Risk monitoring), `ISO27001.A.5.1` (Policies for information security — risk-driven), `ISO27001.A.6.2` (Risk management procedures), `GDPR.Art-32` (Security of processing — risk-based) when a risk pertains to personal-data processing.
+
+**Maintained by:** the [`risk-register-keeper` skill](../../.claude/skills/risk-register-keeper/SKILL.md) at Stage 1 (MEDIUM/HIGH risk classification — open new entries), at incident close (residual-risk entries), and at Stage 3 (per-REQ `risk-assessment.md` artefact summarises entries touched).
+
+**Scoring:** likelihood × impact, 3×3 matrix (low / medium / high). CVSS-aware scoring deferred to Phase B.
+
+---
+
+## Scoring matrix
+
+| Inherent + Residual rating | Likelihood (frequency / ease-of-exploit) | Impact (worst-case if realised) |
+|---|---|---|
+| **Low** | Unlikely in a typical year; requires unusual access or coincidence | Recoverable inconvenience; no regulatory exposure |
+| **Medium** | Plausible within a year; standard skill or access | Recoverable but disruptive; possible reportable incident |
+| **High** | Probable within months; trivial to trigger | Material loss; regulatory reporting required |
+
+Residual = post-mitigation rating. **A risk's residual rating drives review cadence:** Low = annual, Medium = quarterly, High = monthly until reduced.
+
+---
+
+## OPEN risks
+
+> Risks currently being treated — controls planned but not yet demonstrated effective, or monitoring continues.
+
+### RISK-001 — REPLACE one-line title
+
+- **Status:** OPEN
+- **Opened:** YYYY-MM-DD (REQ-XXX) — REPLACE
+- **Owner:** REPLACE — operator
+- **Description:** REPLACE — what the risk is, in operator-readable terms (2-3 sentences).
+- **Inherent likelihood × impact:** REPLACE (e.g. medium × high)
+- **Mitigations planned / in flight:** REPLACE — list controls being applied
+- **Residual likelihood × impact (post-mitigation):** REPLACE
+- **Framework cross-references:** REPLACE — ISO27001.A.X.Y / SOC2.CC3.2 / GDPR.Art-32 (as applicable)
+- **Review due:** YYYY-MM-DD (default: monthly for OPEN-HIGH, quarterly for OPEN-MEDIUM, annually for OPEN-LOW)
+- **Cross-links:** REPLACE — REQ-XXX implementation plan / ADR-NNN / incident-report-N
+
+---
+
+## MITIGATED risks
+
+> Risks whose controls have landed and been demonstrated effective. Residual rating ≤ Low. Periodic re-validation confirms controls remain effective.
+
+### RISK-NNN — example template
+
+- **Status:** MITIGATED
+- **Opened:** YYYY-MM-DD (REQ-XXX) / **Mitigated:** YYYY-MM-DD
+- **Owner:** REPLACE
+- **Description:** REPLACE
+- **Original inherent likelihood × impact:** medium × high
+- **Mitigations applied:** REPLACE — list controls + evidence reference (e.g. "rate limit middleware shipped REQ-042; verified via integration test in `__tests__/auth/rate-limit.test.ts`")
+- **Residual likelihood × impact:** low × low
+- **Framework cross-references:** REPLACE
+- **Re-validation due:** YYYY-MM-DD (default: annually for MITIGATED)
+- **Cross-links:** REPLACE
+
+---
+
+## ACCEPTED risks
+
+> Risks the operator has explicitly chosen to accept (typically: residual is tolerable + mitigation cost exceeds expected loss). Each acceptance needs sign-off + a periodic re-validation date.
+
+### RISK-NNN — example template
+
+- **Status:** ACCEPTED
+- **Opened:** YYYY-MM-DD / **Accepted:** YYYY-MM-DD
+- **Owner:** REPLACE
+- **Description:** REPLACE
+- **Inherent likelihood × impact:** REPLACE
+- **Mitigations applied:** REPLACE — partial mitigations + why full mitigation isn't pursued
+- **Residual likelihood × impact:** REPLACE — tolerated
+- **Acceptance rationale:** REPLACE — why the operator judges this acceptable (cost / use-case / compensating controls / regulatory context)
+- **Acceptance sign-off:** REPLACE — operator name + date. For organisations with separate risk-owner role, the risk-owner signs off here, not the implementing engineer.
+- **Framework cross-references:** REPLACE
+- **Re-validation due:** YYYY-MM-DD (default: every 365d; sooner if the risk landscape changes)
+- **Cross-links:** REPLACE
+
+---
+
+## CLOSED risks
+
+> Risks that no longer apply (removed scope, deprecated dependency, etc.). Kept on the register for audit-trail completeness — auditors examine what was closed and why.
+
+### RISK-NNN — example template
+
+- **Status:** CLOSED
+- **Opened:** YYYY-MM-DD / **Closed:** YYYY-MM-DD
+- **Owner:** REPLACE
+- **Description:** REPLACE
+- **Close rationale:** REPLACE — why this risk no longer applies (e.g. "feature deprecated REQ-080", "dependency removed REQ-095", "external dependency now provides the control")
+- **Cross-links:** REPLACE
+
+---
+
+## Audit-trail rules
+
+- **Append-only edits.** Never delete a RISK-NNN entry. Status transitions (OPEN → MITIGATED → ACCEPTED → CLOSED) are visible audit history.
+- **Re-validation cadence is binding.** When an ACCEPTED risk's `Re-validation due:` date passes, the operator must either re-sign or change status. Stale acceptances are an audit finding.
+- **Cross-linking is bidirectional.** When an entry references an incident report, the incident report's frontmatter references the entry. When an entry references an ADR, the ADR references the entry.
+- **`solo_with_gap` projects** must carry a documented control-gap entry referencing `SOC2.CC8.1` — see the `risk-register-keeper` skill's Phase 4 for the canonical entry shape.

package/sdlc/files/_common/skills/governance-doc-author/SKILL.md

@@ -7,25 +7,27 @@ description: Author or refresh one of the project's governance documents — RoP
 
 Author or refresh a single governance document so it correctly closes the framework clauses it's meant to satisfy. Five document classes covered:
 
-| Document | Tier | File | Upload path | Closes |
-|---|---|---|---|---|
-| **RoPA** | 2 | `compliance/governance/ropa.md` | **Portal Upload form** (type `ropa`) — CI does NOT auto-upload since v0.1.39 | `GDPR.Art-30` |
-| **DPIA** | 2 | `compliance/governance/dpia.md` (or `dpia-<reqid>.md`) | **Portal Upload form** (type `dpia`) — CI does NOT auto-upload since v0.1.39 | `GDPR.Art-35` |
-| **AI Use Disclosure** | 2 | `compliance/governance/ai-disclosure.md` | **Portal Upload form** (type `ai_disclosure`) — CI does NOT auto-upload since v0.1.39 | `EUAIA.Art-13` |
-| **Periodic Security Review Schedule** | 2 | `SDLC/Periodic_Security_Review_Schedule.md` | **Portal Upload form** (type `compliance_document`) | `ISO27001.A.12.1` schedule expectation (quarterly runs close it via `periodic_review` evidence — see Phase 6) |
-| **Incident Report (project-level template)** | 3 | `compliance/governance/incident-report.md` | **CI auto-upload** via `compliance-evidence.yml` | `ISO29119.3.5.4` baseline; conditionals via [[incident-classification]] |
+| Document                                     | Tier | File                                                   | Upload path                                                                           | Closes                                                                                                        |
+| -------------------------------------------- | ---- | ------------------------------------------------------ | ------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- |
+| **RoPA**                                     | 2    | `compliance/governance/ropa.md`                        | **Portal Upload form** (type `ropa`) — CI does NOT auto-upload since v0.1.39          | `GDPR.Art-30`                                                                                                 |
+| **DPIA**                                     | 2    | `compliance/governance/dpia.md` (or `dpia-<reqid>.md`) | **Portal Upload form** (type `dpia`) — CI does NOT auto-upload since v0.1.39          | `GDPR.Art-35`                                                                                                 |
+| **AI Use Disclosure**                        | 2    | `compliance/governance/ai-disclosure.md`               | **Portal Upload form** (type `ai_disclosure`) — CI does NOT auto-upload since v0.1.39 | `EUAIA.Art-13`                                                                                                |
+| **Periodic Security Review Schedule**        | 2    | `SDLC/Periodic_Security_Review_Schedule.md`            | **Portal Upload form** (type `compliance_document`)                                   | `ISO27001.A.12.1` schedule expectation (quarterly runs close it via `periodic_review` evidence — see Phase 6) |
+| **Incident Report (project-level template)** | 3    | `compliance/governance/incident-report.md`             | **CI auto-upload** via `compliance-evidence.yml`                                      | `ISO29119.3.5.4` baseline; conditionals via [[incident-classification]]                                       |
 
-Each doc has a starter template under `sdlc/files/_common/governance/*.md.template` (installed on demand via `devaudit bootstrap-governance` since v0.1.36). This skill does NOT regenerate the template — it walks the operator through *filling it in* against the project's actual state.
+Each doc has a starter template under `sdlc/files/_common/governance/*.md.template` (installed on demand via `devaudit bootstrap-governance` since v0.1.36). This skill does NOT regenerate the template — it walks the operator through _filling it in_ against the project's actual state.
 
 ## Scope
 
 **In scope**
+
 - Authoring or refreshing one (or more) of the five governance docs above.
 - Gathering source data from the codebase / CI runs / git history.
 - Confirming framework attribution before commit.
 - Driving the commit + push → portal upload (manual for Tier 1/2, CI auto for Tier 3) → portal verification loop.
 
 **Out of scope**
+
 - Incident response itself — that path is the `e2e-test-engineer` skill's defect-filing flow plus `incident-export.yml` on issue close.
 - Test execution evidence — handled by `e2e-test-engineer`.
 - Implementation plans for individual REQs — handled by the `sdlc-implementer` skill's Phase 1 against `Implementation_Plan_TEMPLATE.md`.
@@ -39,13 +41,14 @@ Six phases. Phase 0 is a routing step; phases 1–5 are per-document.
 
 Determine which document the operator needs. Ask if ambiguous; otherwise infer from the trigger phrase.
 
-- *"create / refresh the RoPA"* → Phase 1 with doc = ROPA
-- *"write / update a DPIA"* → Phase 1 with doc = DPIA (ask: tied to a specific HIGH-risk REQ, or project-wide?)
-- *"AI use disclosure"* / *"document our AI use"* → Phase 1 with doc = AI_DISCLOSURE
-- *"periodic security review schedule"* / *"how often do we review"* → Phase 1 with doc = REVIEW_SCHEDULE
-- *"incident-report template"* → Phase 1 with doc = INCIDENT_TEMPLATE (and remind the operator that per-incident reports come from `incident-export.yml`, not this skill)
+- _"create / refresh the RoPA"_ → Phase 1 with doc = ROPA
+- _"write / update a DPIA"_ → Phase 1 with doc = DPIA (ask: tied to a specific HIGH-risk REQ, or project-wide?)
+- _"AI use disclosure"_ / _"document our AI use"_ → Phase 1 with doc = AI_DISCLOSURE
+- _"periodic security review schedule"_ / _"how often do we review"_ → Phase 1 with doc = REVIEW_SCHEDULE
+- _"incident-report template"_ → Phase 1 with doc = INCIDENT_TEMPLATE (and remind the operator that per-incident reports come from `incident-export.yml`, not this skill)
+- _"register a new risk"_ / _"open a risk-register entry"_ / _"document a control gap"_ → **delegate to the [`risk-register-keeper` skill](../risk-register-keeper/SKILL.md)** (DevAudit-Installer#121, v0.1.44+). The risk register is a separate SoT (`compliance/risk-register.md`) with its own lifecycle (OPEN / MITIGATED / ACCEPTED / CLOSED) and stage hooks (Stage 1 / incident close / Stage 3). This skill does not maintain it.
 
-When the trigger is *"GDPR.Art-30 is MISSING on the matrix, what do I upload?"* and similar — route to the matching doc above.
+When the trigger is _"GDPR.Art-30 is MISSING on the matrix, what do I upload?"_ and similar — route to the matching doc above. When the trigger is about per-REQ risks or control gaps — route to `risk-register-keeper`.
 
 ### Phase 1 — Confirm the starter exists
 
@@ -61,7 +64,7 @@ Each doc class has different inputs. Read what's needed; don't ask the operator
   - Read `app/`, `lib/`, `prisma/schema.prisma` (or equivalent) to enumerate processing activities.
   - For each, infer: data categories, recipients (third-party SDKs / services), retention (DB triggers, env vars naming retention windows), lawful basis where reasonable.
   - Read `.env.example` for third-party service names.
-  - Ask the operator to confirm purposes (you can guess the technical surface; the *purpose* is a business decision).
+  - Ask the operator to confirm purposes (you can guess the technical surface; the _purpose_ is a business decision).
 
 - **DPIA**
   - Project-wide DPIA → same source data as RoPA, plus a risk identification pass against Art. 35(3) triggers (large-scale special category, systematic monitoring, automated decisions with legal effect).
@@ -92,13 +95,13 @@ Each doc class has different inputs. Read what's needed; don't ask the operator
 
 For each clause the doc closes, confirm the corresponding section of the doc is non-stub:
 
-| Doc | Clause | Section that must be non-stub |
-|---|---|---|
-| ROPA | GDPR.Art-30 | §Controller + ≥1 §Processing activities row with all fields filled |
-| DPIA | GDPR.Art-35 | All six sections (description / necessity / risks / measures / consultation / sign-off) |
-| AI_DISCLOSURE | EUAIA.Art-13 | All six checklist items in the template's Framework checklist |
-| REVIEW_SCHEDULE | ISO27001.A.12.1 | A schedule entry per control area + a named reviewer per cadence |
-| INCIDENT_TEMPLATE | ISO29119.3.5.4 baseline | §1–§8 of the template are skeletal but coherent (per-incident files inherit the shape) |
+| Doc               | Clause                  | Section that must be non-stub                                                           |
+| ----------------- | ----------------------- | --------------------------------------------------------------------------------------- |
+| ROPA              | GDPR.Art-30             | §Controller + ≥1 §Processing activities row with all fields filled                      |
+| DPIA              | GDPR.Art-35             | All six sections (description / necessity / risks / measures / consultation / sign-off) |
+| AI_DISCLOSURE     | EUAIA.Art-13            | All six checklist items in the template's Framework checklist                           |
+| REVIEW_SCHEDULE   | ISO27001.A.12.1         | A schedule entry per control area + a named reviewer per cadence                        |
+| INCIDENT_TEMPLATE | ISO29119.3.5.4 baseline | §1–§8 of the template are skeletal but coherent (per-incident files inherit the shape)  |
 
 If any required section is still stub, **do not commit**. Surface the gap in the Phase 5 report, ask the operator for the missing input.
 
@@ -118,10 +121,10 @@ Tier 1/2 docs (RoPA, DPIA, AI Disclosure, Periodic Security Review Schedule) and
 
 These are **two different artefacts** and the skill must not conflate them:
 
-| Artefact | What | Closes | Cadence | Skill responsibility |
-|---|---|---|---|---|
-| **Periodic_Security_Review_Schedule.md** | The *plan* — which controls get reviewed, how often, by whom | `ISO27001.A.12.1` (the schedule presence) | Once, refresh annually | **In scope.** Author / refresh via this skill. |
-| **periodic-review.md** | The *execution evidence* — this quarter's actual review | `ISO27001.A.12.1` + `SOC2.CC4.1` (effectiveness evidence) | Quarterly | **Out of scope.** Auto-generated by `periodic-review.yml`; the operator fills in the 60% operator-fill section per the PR body's checklist. |
+| Artefact                                 | What                                                         | Closes                                                    | Cadence                | Skill responsibility                                                                                                                        |
+| ---------------------------------------- | ------------------------------------------------------------ | --------------------------------------------------------- | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
+| **Periodic_Security_Review_Schedule.md** | The _plan_ — which controls get reviewed, how often, by whom | `ISO27001.A.12.1` (the schedule presence)                 | Once, refresh annually | **In scope.** Author / refresh via this skill.                                                                                              |
+| **periodic-review.md**                   | The _execution evidence_ — this quarter's actual review      | `ISO27001.A.12.1` + `SOC2.CC4.1` (effectiveness evidence) | Quarterly              | **Out of scope.** Auto-generated by `periodic-review.yml`; the operator fills in the 60% operator-fill section per the PR body's checklist. |
 
 If the operator asks for "the periodic review", clarify which they mean. If they want the quarterly execution, point them at the open auto-PR (or, if cron hasn't fired yet, suggest `gh workflow run periodic-review.yml`).
 
@@ -139,7 +142,7 @@ When Phase 5 commits successfully, append a short narrator update in the final r
 
 **Don't invent.** If you can't derive a value from the codebase / CI / git, ask the operator. Never guess at lawful basis, retention windows, controller contacts, or AI provider names.
 
-**Framework checklist is load-bearing.** The portal's matrix uses the *presence* of the doc to flip COVERED; auditors use the *content* to decide if that's defensible. Tick boxes only when they're actually true.
+**Framework checklist is load-bearing.** The portal's matrix uses the _presence_ of the doc to flip COVERED; auditors use the _content_ to decide if that's defensible. Tick boxes only when they're actually true.
 
 **Confirm before destructive or public actions.** Same as the e2e-test-engineer principle. Diff, confirm, commit. The operator approves the doc going to GitHub before push.