@getarbiter/cli 0.5.0

package/dist/templates/governance/contract-integrity-policy.md.ejs

@@ -0,0 +1,116 @@
+# Contract Integrity 5-Gate Suite — <%= projectName %>
+
+> **Origin:** Policy template ported from `reference-impl/docs/FRAMEWORK/CONTRACT_INTEGRITY/*` (M-08, #716).
+>
+> **Distinct from Pact (M28):** Pact is consumer-driven contracts (the consumer dictates what the producer must satisfy). Contract Integrity is API surface stability + drift detection (the producer asserts its surface and detects when it changes). The two are complementary; use both for L3 surfaces.
+>
+> **Opt-in flags:** all under the `contract_integrity.gates.*` namespace (see §Configuration).
+
+## The five gates
+
+### Gate A — OpenAPI snapshot
+
+**What:** snapshot the rendered OpenAPI document at build time. On every PR, compare the new snapshot against the committed baseline. Any non-additive change (removed endpoint, removed field, narrowed type, added required field) fails the gate.
+
+**Why:** rejects accidental breaking changes to the public API surface. Additive changes pass automatically.
+
+**Configuration:** `contract_integrity.gates.openapi_snapshot: true`
+
+### Gate B — DTO parity
+
+**What:** assert structural equivalence between the server's response DTOs and the client's generated types. Run on every PR; the gate fails when the server emits a field that the client cannot deserialise, or the client expects a field the server does not emit.
+
+**Why:** prevents the "server-changed-but-client-not-regenerated" class of integration bug.
+
+**Configuration:** `contract_integrity.gates.dto_parity: true`
+
+### Gate C — Operation smoke (404 / 5xx)
+
+**What:** for every declared endpoint, send a probe with intentionally malformed input. Assert the response is a documented error class (404 for missing resource, 422 for validation, 5xx for server error with structured body) — NOT an unhandled stack trace or empty 500.
+
+**Why:** catches half-implemented endpoints that respond to the happy path but return undefined-behaviour on error paths.
+
+**Configuration:** `contract_integrity.gates.operation_smoke: true`
+
+### Gate D — Dead code
+
+**What:** detect endpoints declared in the OpenAPI document but never reached by any test or call site in the codebase. Detect handlers in the codebase not referenced by the OpenAPI document. Either direction is a contract leak.
+
+**Why:** dead endpoints become security debt (unauthenticated, untested code paths). Undeclared handlers leak surface that consumers cannot rely on.
+
+**Configuration:** `contract_integrity.gates.dead_code: true`
+
+### Gate E — Test hygiene
+
+**What:** for every endpoint in the OpenAPI document, assert at least one test exists. The minimum test must cover the happy path + the documented error class (per gate C). Endpoints without tests fail this gate.
+
+**Why:** the OpenAPI document is a contract; an untested contract is a wish.
+
+**Configuration:** `contract_integrity.gates.test_hygiene: true`
+
+## Configuration
+
+```jsonc
+{
+  "contract_integrity": {
+    "gates": {
+      "openapi_snapshot": true,
+      "dto_parity": true,
+      "operation_smoke": true,
+      "dead_code": true,
+      "test_hygiene": true,
+    },
+    "snapshot_path": "tests/fixtures/openapi-baseline.yaml",
+    "smoke_probe_timeout_ms": 5000,
+  },
+}
+```
+
+All gates default to `false`. Enable per-gate as the surface stabilises. The recommended adoption order is **A → D → E → B → C**:
+
+1. **A first** — cheapest signal, catches the most regressions
+2. **D second** — surfaces dead code while the codebase is still small enough to clean up
+3. **E third** — requires test infrastructure but produces durable coverage
+4. **B fourth** — requires client-side codegen wiring
+5. **C last** — requires a running server in CI
+
+## What each gate does NOT do
+
+- **Gate A** does not detect semantic changes (handler-behavior change with same API shape). Use Pact (M28) for consumer-driven semantic contracts.
+- **Gate B** does not detect runtime type mismatches (e.g. server emits a value outside the declared enum). Add a separate runtime-validation step at the client boundary if needed.
+- **Gate C** does not test correctness of error responses, only their existence + shape.
+- **Gate D** has false-positive risk on dynamically-routed endpoints (e.g. dispatched via a switch table). Configure the per-project allowlist if needed.
+- **Gate E** does not assess test quality — a single happy-path assertion satisfies the gate. Pair with mutation testing (M22) for quality signal.
+
+## Distinct from Pact (M28)
+
+| Property                | Contract Integrity (M-08) | Pact (M28)                   |
+| ----------------------- | ------------------------- | ---------------------------- |
+| Direction               | producer asserts surface  | consumer dictates surface    |
+| Run trigger             | every PR                  | consumer-side first, then broker |
+| Catches                 | API surface drift         | semantic contract drift      |
+| Tooling                 | language-specific schema diff | Pact framework               |
+| Output                  | pass/fail per gate        | verification report          |
+
+**Use both** for L3 surfaces: M-08 catches accidental breaking changes; M28 catches handler-semantics drift.
+
+## Per-stack implementation
+
+The 5 gates are mechanical and per-stack. Each gate ships as a separate script under `scripts/contract-integrity/` in the consumer project. The detailed implementations are tracked as **follow-up issues** (one per gate), not bundled into this template port.
+
+## Source
+
+#716 (M-08 — Contract Integrity 5-gate suite).
+
+## Follow-up issues
+
+The 5 gate scripts and the generator that wires them are tracked separately so each can be reviewed independently:
+
+- Gate A implementation
+- Gate B implementation
+- Gate C implementation
+- Gate D implementation
+- Gate E implementation
+- `src/generators/contract-integrity.ts` that emits the per-stack script bundles
+
+This template provides the **policy and configuration surface**; the scripts come in subsequent PRs.

package/dist/templates/governance/enterprise-compliance-baseline.md.ejs

@@ -0,0 +1,111 @@
+# Enterprise Compliance Baseline — <%= projectName %>
+
+> **Origin:** Structural skeleton ported from reference-impl/docs/SYSTEM/ENTERPRISE_COMPLIANCE.md (M-03, #711). The reference document is 6308 LOC; this template ports the **structure**, not the content. Fill in each section with project-specific evidence.
+
+## How to use this baseline
+
+1. This file is generated by `arbiter init` when `compliance.enterprise_baseline: true` is set in `arbiter.json` (see §Opt-in below).
+2. Each section below has a marker `[FILL: ...]` indicating what your team must provide. Empty markers fail the L2 compliance gate.
+3. Update this baseline whenever scope changes (new processing activity, new region, new third-party processor). Diffs are reviewed in the same PR as the change.
+
+## Opt-in flag
+
+```jsonc
+{
+  "compliance": {
+    "enterprise_baseline": true,
+  },
+}
+```
+
+---
+
+## 1. Data Protection (GDPR)
+
+### 1.1 Legal basis register
+
+[FILL: For each processing activity, list the GDPR Art.6 legal basis (consent / contract / legal-obligation / vital-interest / public-task / legitimate-interest). Include the data category and the retention period.]
+
+### 1.2 Right to erasure (Art. 17)
+
+[FILL: Document the cascade for an erasure request. The cascade must enumerate every system that holds the user's data, including third-party processors. Use the M-05 erasure-runbook template (see governance/gdpr-erasure-runbook.md once #713 lands) for the orchestration detail. Pay special attention to systems where the user record is DISABLED rather than DELETED — those are incomplete Art.17 compliance.]
+
+### 1.3 Security of processing (Art. 32)
+
+[FILL: For each system in the legal-basis register, document the technical and organisational measures. Minimum surface: encryption at rest + in transit, access logging, key-rotation cadence, incident-response runbook reference, breach-notification path.]
+
+### 1.4 Data subject access (Art. 15)
+
+[FILL: SLA for access requests + the system that exports the data + format(s) supported. Include the human reviewer step before release.]
+
+---
+
+## 2. NIS2
+
+### 2.1 Supply-chain register
+
+[FILL: Every third-party that processes or transmits in-scope data. For each: scope of data, contract reference, last security review date, fallback supplier if any.]
+
+### 2.2 Incident classification + reporting timeline
+
+[FILL: NIS2 requires initial notification within 24h of a significant incident. Document the classification matrix (severity vs business impact) and the on-call escalation path that produces that notification.]
+
+### 2.3 Risk management framework reference
+
+[FILL: Point to your project's risk register (template at governance/risk-register.md) and the assessment cadence. NIS2 expects an annual review at minimum.]
+
+---
+
+## 3. ISO 27001 (lite mapping)
+
+### 3.1 Annex A controls in scope
+
+[FILL: List the Annex A controls your project applies. Common in-scope subset for SaaS: A.5.* (information security policies), A.6.* (organisation), A.8.* (asset management), A.9.* (access control), A.12.* (operations), A.14.* (development).]
+
+### 3.2 Statement of Applicability
+
+[FILL: For each in-scope control, declare implemented / planned / not-applicable. Justify any "not-applicable" — the auditor's first question.]
+
+---
+
+## 4. OWASP Top 10 alignment
+
+[FILL: For each OWASP Top 10 (current year) category, document the project's mitigation. Use a one-row-per-category table; empty rows fail the L2 compliance gate.]
+
+| OWASP   | Mitigation                                  |
+| ------- | ------------------------------------------- |
+| A01: Broken access control       | [FILL] |
+| A02: Cryptographic failures      | [FILL] |
+| A03: Injection                   | [FILL] |
+| A04: Insecure design             | [FILL] |
+| A05: Security misconfiguration   | [FILL] |
+| A06: Vulnerable components       | [FILL] |
+| A07: Authentication failures     | [FILL] |
+| A08: Software/data integrity     | [FILL] |
+| A09: Logging + monitoring        | [FILL] |
+| A10: SSRF                        | [FILL] |
+
+---
+
+## 5. Review cadence
+
+| Trigger                                                | Section(s) to re-review |
+| ------------------------------------------------------ | ----------------------- |
+| New processing activity                                | 1.1, 1.2                |
+| New third-party processor                              | 2.1                     |
+| New deployment region                                  | 1.3, 2.1                |
+| Annual ISO surveillance audit                          | 3.* (all)               |
+| OWASP Top 10 update (typically every 3 years)          | 4 (all)                 |
+| Quarterly                                              | All sections — sanity check |
+
+---
+
+## What this baseline does NOT include
+
+- **Vendor lock-in advice.** Per never-import policy, this template avoids prescribing specific vendors (KMS, SIEM, etc.). Reference any-vendor patterns; pick your own.
+- **Country-specific data residency rules.** The reference-impl is EU-centric. If your project ships in additional jurisdictions, extend §1.* with the additional regimes (CCPA, LGPD, etc.) — do not edit this file's structure, append new top-level sections.
+- **Per-control implementation evidence.** Evidence belongs in `.evidence/compliance/` with SHA pins; this baseline is the index, not the artifact store.
+
+## Source issue
+
+#711 (M-03 — Enterprise compliance baseline template).

package/dist/templates/governance/evidence-retention.md.ejs

@@ -0,0 +1,43 @@
+# Evidence Retention Policy — <%= projectName %>
+
+This document defines how task-completion evidence is stored, rotated, and pruned.
+
+## Retention Mode
+
+**Mode:** `<%= evidenceRetention.mode %>`
+<% if (evidenceRetention.mode === 'local-last-N') { %>
+Evidence runs are stored under `.evidence/` and the last **<%= evidenceRetention.count ?? 5 %>** runs are kept automatically.
+<% } else if (evidenceRetention.mode === 'external-bucket') { %>
+Evidence runs are uploaded to an external bucket: `<%= evidenceRetention.bucketUrl %>`.
+Local copies are pruned after upload. Ensure bucket credentials are configured.
+<% } %>
+
+## Scripts
+
+| Script | Purpose | When to run |
+| --- | --- | --- |
+| `scripts/evidence-rotate.mjs` | Rotation — keeps last N runs, removes older ones | Manual tool — run as needed by maintainer, or wire into CI/a hook if you want automatic rotation |
+| `scripts/evidence-prune.mjs` | Manual maintenance — supports --keep-last, --keep-days, --dry-run | Run as needed by maintainer |
+
+## Usage
+
+```sh
+# Dry-run: see what would be removed without deleting
+node scripts/evidence-prune.mjs --dry-run --keep-last=10
+
+# Prune runs older than 30 days, skip ACK prompt
+node scripts/evidence-prune.mjs --keep-days=30 --yes
+
+# Keep only last 3 runs
+node scripts/evidence-prune.mjs --keep-last=3 --yes
+```
+
+## Location
+
+Evidence runs are stored in `.evidence/run-NNNN/` directories (gitignored).
+Each run directory contains the SHA-pinned output files listed in `evidence-files.json`.
+
+## Governance
+
+This policy is enforced by the done-evidence harness (`scripts/done-evidence.mjs`).
+Runs without valid SHA pins fail the L2 gate.

package/dist/templates/governance/gdpr-erasure-runbook.md.ejs

@@ -0,0 +1,165 @@
+# GDPR Art.17 Erasure Cascade Runbook — <%= projectName %>
+
+> **Origin:** Ported from reference-impl `docs/SYSTEM/PRIVACY_MODEL.md:86-120` (M-05, #713). Includes the Keycloak DELETE fix discovered during the reference-impl audit (the reference implementation only DISABLED the Keycloak record — incomplete Art.17 compliance).
+>
+> **Opt-in flag:** `compliance.gdpr_erasure`
+
+## When this runbook fires
+
+Trigger: a verified GDPR Art.17 erasure request reaches the data-controller team for the data subject identified by `<subject_id>`.
+
+**Verification step (pre-runbook):** identity proof + scope confirmation (which data subjects + which processing activities). This runbook does NOT include the identity-verification step — that belongs in your access-control SOP, not in the cascade.
+
+## 14-step cascade
+
+Run **in order**. Each step has an exit assertion that must pass before the next runs. If any assertion fails, escalate to data-protection officer + halt the cascade.
+
+### 1. Lock subject record
+
+- Set `users.locked_for_erasure_at = NOW()` on the primary user table.
+- **Assertion:** no new writes to any subject-owned row after this timestamp.
+
+### 2. Snapshot audit trail
+
+- Export the subject's audit log to `.evidence/erasure/<subject_id>/<request_id>/audit.jsonl` for retention purposes (Art.17 §3(b) allows retention for legal claims; the evidence is the legal basis for retention).
+- **Assertion:** snapshot file exists, SHA pinned in evidence manifest.
+
+### 3. Anonymise application database
+
+- For each table with subject-owned rows: replace PII fields with deterministic-anonymised tokens.
+- **Assertion:** `SELECT COUNT(*) FROM <table> WHERE <pii_column> LIKE '%<subject_email_pattern>%'` returns 0 across all tables.
+
+### 4. Anonymise read replicas
+
+- Wait for replication lag → 0 OR force-replicate the anonymisation transaction.
+- **Assertion:** same query as step 3 across each replica returns 0.
+
+### 5. Delete cached artifacts
+
+- Purge cached responses, generated PDFs, exported CSVs, profile thumbnails.
+- **Assertion:** cache-key search for `subject_id` returns no entries.
+
+### 6. Delete object-storage artifacts
+
+- For each object-storage bucket: list objects tagged with `subject_id`, delete each.
+- **Assertion:** `aws s3 ls --recursive s3://<bucket>/<subject_prefix>` (or equivalent) returns empty.
+
+### 7. Invalidate active sessions
+
+- Revoke refresh tokens + invalidate session cookies.
+- **Assertion:** sessions table has no rows where `user_id = <subject_id>` AND `expires_at > NOW()`.
+
+### 8. Delete from analytics warehouse
+
+- Run anonymisation/deletion DAG on the warehouse.
+- **Assertion:** warehouse query for `subject_id` returns 0 rows in the next nightly recompute.
+
+### 9. Delete from search index
+
+- Issue index-level delete for `subject_id`.
+- **Assertion:** search-by-PII-fragment returns no hits.
+
+### 10. Notify third-party processors
+
+- For each processor in `compliance.third_party_processors[]`: issue the processor-specific erasure call (API, support ticket, secure email).
+- **Assertion:** acknowledgement received from each processor (SLA: 14 days).
+
+### 11. Delete from email provider
+
+- Issue contact-delete via email-provider API.
+- **Assertion:** API response confirms deletion.
+
+### 12. **DELETE Keycloak record (NOT disable) — M-05 audit fix**
+
+- Issue `DELETE /admin/realms/<realm>/users/<keycloak_id>` to fully remove the identity-provider record.
+- **Assertion:** GET of the same path returns 404.
+- **Why this step exists:** The reference-impl audit discovered Keycloak users were only DISABLED (`enabled=false`). A disabled user still exists in the directory, which is incomplete Art.17 compliance — the user's identifier is still recoverable. DELETE is the correct primitive.
+
+### 13. Delete from backup retention
+
+- Backups containing the subject's data CANNOT be re-anonymised retroactively. Document the backup retention window in the user-facing erasure confirmation: "Your data will be fully removed from backups by `<NOW + retention_window>`".
+- **Assertion:** the dated promise appears in the user-facing confirmation email; the deletion-from-backup is scheduled in your backup-rotation job.
+
+### 14. Final user-facing confirmation
+
+- Send a signed confirmation to the subject containing: request ID, completion timestamp, backup-purge date, list of third-party processors notified, evidence-manifest reference (or instructions to request it).
+- **Assertion:** confirmation send is logged in `.evidence/erasure/<subject_id>/<request_id>/confirmation.json` with a delivery receipt.
+
+## Multi-stack hook stubs
+
+The cascade above is the **policy**. The mechanical execution is per-stack. Below are the recommended hook stubs to wire into each stack's data-mutation layer:
+
+### TS / Express
+
+```ts
+// src/erasure/cascade.ts
+import { lockSubjectRecord } from './step1.js'
+import { snapshotAuditTrail } from './step2.js'
+// … 12 more imports
+
+export async function runErasureCascade(subjectId: string, requestId: string): Promise<void> {
+  await lockSubjectRecord(subjectId)
+  await snapshotAuditTrail(subjectId, requestId)
+  // … step 3-14
+}
+```
+
+### Java / Spring
+
+```java
+// src/main/java/com/example/erasure/CascadeService.java
+@Service
+public class CascadeService {
+  public void run(String subjectId, String requestId) {
+    lockSubjectRecord(subjectId);
+    snapshotAuditTrail(subjectId, requestId);
+    // … step 3-14
+  }
+}
+```
+
+### Go / chi
+
+```go
+// internal/erasure/cascade.go
+package erasure
+
+func RunCascade(ctx context.Context, subjectID string, requestID string) error {
+    if err := lockSubjectRecord(ctx, subjectID); err != nil { return err }
+    if err := snapshotAuditTrail(ctx, subjectID, requestID); err != nil { return err }
+    // … step 3-14
+    return nil
+}
+```
+
+## Anti-patterns (do NOT do)
+
+- **Soft-delete-only.** A `deleted_at` timestamp is NOT erasure. The PII must be physically replaced or removed.
+- **Disable instead of delete.** This is the Keycloak fix above. Applies anywhere an identity provider has both verbs.
+- **Skip backups.** Backups containing PII are still controlled by Art.17. You cannot anonymise retroactively, but you MUST document the retention window and honor it.
+- **Skip third-party processors.** Your DPA with the processor is itself the legal basis for Art.17 transmission; failing to forward the erasure breaks both.
+- **Treat erasure as a one-step DB delete.** A multi-system data-architecture needs a multi-step cascade, sequenced with exit assertions.
+
+## Evidence
+
+Every cascade run produces an evidence bundle at `.evidence/erasure/<subject_id>/<request_id>/`:
+
+| File                    | Content                                                       |
+| ----------------------- | ------------------------------------------------------------- |
+| `audit.jsonl`           | Pre-erasure audit-trail snapshot (step 2)                     |
+| `cascade-log.jsonl`     | One entry per step: step number, started_at, completed_at, assertion result |
+| `confirmation.json`     | User-facing confirmation send result (step 14)                |
+| `processor-acks/`       | Acknowledgements from each third-party processor (step 10)    |
+| `backup-purge-date.txt` | Date by which the subject's data will be purged from backups  |
+
+The bundle is retained for the legal claims window (typically 6 years EU, 10 years some jurisdictions). Configure via `compliance.erasure_evidence_retention_years`.
+
+## What this runbook does NOT cover
+
+- **Right to object (Art.21)** — different request, different flow. Track separately.
+- **Right to data portability (Art.20)** — export, not delete.
+- **Cross-controller orchestration** — if your project is a co-controller, the orchestration with the other controller is contract-specific.
+
+## Source
+
+#713 (M-05 — GDPR Art.17 erasure cascade runbook).

package/dist/templates/governance/qa-audit-phases.md.ejs

@@ -0,0 +1,129 @@
+# QA-Audit Phases — <%= projectName %>
+
+> **Origin:** Format ported from `reference-impl/qa-audit/PHASE*.md` (15 narrative reports, 4951 LOC). The reference reports are CERIMONIA — one-shot, no rerun. **M-A1 ports the FORMAT, not the content.** Each phase is defined as a JSON schema + rerun command. The MD report is the OUTPUT of a rerun, not the audit itself.
+>
+> **Opt-in flag:** `governance.qa_audit_phases`
+
+## Philosophy
+
+Audits that cannot be rerun become ceremony. The reference-impl QA audit produced 15 narrative reports dated 2026-02-12 — readable, useful, but **frozen in time**. Three weeks later, the codebase had drifted and the reports were stale. A month later, they were lies.
+
+This template ports the **format** of those reports as a schema + rerun command per phase. The output MD is the artifact of the most recent rerun; the audit is reproducible at any point.
+
+## Phase schema
+
+Each phase is defined by a JSON document at `.arbiter/qa-audit/phase-<NN>.json`:
+
+```jsonc
+{
+  "phase": "01",
+  "title": "Static analysis baseline",
+  "rerun": "node scripts/qa-audit/phase-01.mjs",
+  "owner": "core-team",
+  "cadence": "weekly",
+  "output_path": "docs/QA_AUDIT/phase-01-latest.md",
+  "schema_version": 1,
+  "checks": [
+    {
+      "id": "lint-clean",
+      "command": "npm run lint",
+      "expect_exit_code": 0,
+      "rationale": "no lint warnings on main",
+    },
+    {
+      "id": "no-circular-deps",
+      "command": "npx madge --circular --extensions ts,tsx,js,jsx src/",
+      "expect_exit_code": 0,
+      "rationale": "circular deps regress maintainability",
+    },
+  ],
+  "severity_thresholds": {
+    "errors_max": 0,
+    "warnings_max": 10,
+  },
+}
+```
+
+## Default phases
+
+The template ships **6 default phases**. Each is opt-in via `governance.qa_audit_phases.phases[]` and can be customised per project. Use these as starting scaffolding.
+
+### Phase 01 — Static analysis baseline
+
+Lint clean, no circular deps, type-checks pass. Weekly cadence.
+
+### Phase 02 — Test coverage + quality
+
+Coverage thresholds met, mutation score ≥ 60%, no `.skip`/`.only` left in committed tests. Weekly cadence.
+
+### Phase 03 — Architecture conformance
+
+Module boundaries respected (depcruiser rules), public-API surface bounded by ratchet, no new ADR-violations. Bi-weekly cadence.
+
+### Phase 04 — Security baseline
+
+Dependency audit clean (or all surviving CVEs documented in suppressions with expiry), secrets-scan clean, IAM least-privilege spot-check. Weekly cadence.
+
+### Phase 05 — Performance + resource baseline
+
+Bundle size within budget, p95 latency on smoke benchmark within baseline, no memory regression on long-running test. Monthly cadence.
+
+### Phase 06 — Documentation freshness
+
+Public APIs documented (JSDoc/TSDoc coverage), changelog up-to-date, ADR index complete (no orphan ADRs), README install steps still work. Monthly cadence.
+
+## Rerun command
+
+```sh
+arbiter audit run [--phase NN] [--all] [--json]
+```
+
+- `--phase 03` reruns one phase
+- `--all` reruns every defined phase in order
+- `--json` emits machine-readable output instead of the rendered MD
+
+Each rerun:
+
+1. Loads the phase JSON
+2. Runs each `checks[].command`, captures exit code + stdout + stderr
+3. Compares against `severity_thresholds`
+4. Writes the rendered MD report to `output_path`
+5. Exits 0 on PASS, 1 on threshold breach, 2 on schema error
+
+The rendered MD is meant to be committed (so historical reports are findable). The schema JSON is the source of truth — when audit logic changes, edit the schema, not the rendered MD.
+
+## Cadence enforcement
+
+A separate CI job (cron schedule) reruns each phase at its declared cadence. If the latest output MD is older than the cadence window, the cadence job fails. This catches the failure mode where audits are defined but never rerun.
+
+Suggested cron mapping:
+
+| Cadence    | Cron schedule (UTC) |
+| ---------- | ------------------- |
+| daily      | `0 3 * * *`         |
+| weekly     | `0 4 * * 1`         |
+| bi-weekly  | `0 4 1,15 * *`      |
+| monthly    | `0 5 1 * *`         |
+
+## Anti-patterns (NI-4 — never-import: ceremony)
+
+- **Phase whose rerun is "ask team X"** — that is ceremony, not audit. Every phase must have a mechanical rerun.
+- **Phase that always passes** — either the thresholds are wrong or the phase is decorative. Tune thresholds quarterly.
+- **Phase whose output is never read** — pair each phase with a documented escalation path on failure. If failure is consequence-free, the audit is theatre.
+- **Ad-hoc phases that aren't in the schema** — out-of-band audits don't get cadence enforcement. Promote them to schema-defined phases or accept they're one-offs.
+
+## What this template does NOT include
+
+- **CI cron job templates per cadence.** Generated per stack in the corresponding `.github/workflows/qa-audit-*.yml` files. Wired by the (forthcoming) `src/generators/qa-audit.ts` generator.
+- **The arbiter audit run CLI command itself (planned, not yet shipped).** Stubbed in this PR's audit doc; full implementation tracked as a follow-up.
+- **Default phase content beyond the 6 scaffolds above.** Project-specific phases live in your project's `.arbiter/qa-audit/phase-NN.json` files.
+
+## Source
+
+#727 (M-A1 — Audit-as-Code).
+
+## See also
+
+- `docs/SYSTEM/CANON.md` — process rules
+- `docs/audits/` — already-rerun audits using this format (the audit docs in this repo)
+- NI-4 (never-import: ceremony) — the rule this template enforces

package/dist/templates/governance/risk-assessment-template.md.ejs

@@ -0,0 +1,105 @@
+# Risk Assessment Template — <%= projectName %>
+
+<!-- arbiter-managed: risk-assessment-template (#712) -->
+
+> Use this template for each new risk before adding a row to `RISK_REGISTER.md`.
+> ISO 27001:2022 §6.1.2 — P×I (Probability × Impact) scoring.
+
+---
+
+## Risk Identification
+
+| Field          | Value                                      |
+| -------------- | ------------------------------------------ |
+| **Risk ID**    | R-XXX _(assign next sequential ID)_        |
+| **Date**       | YYYY-MM-DD                                 |
+| **Author**     | _Name / team_                              |
+| **Category**   | Confidentiality / Integrity / Availability |
+
+### Threat description
+
+_Describe the threat: what could go wrong, who/what is the threat actor?_
+
+### Asset at risk
+
+_Which data, system, or process is affected?_
+
+### Vulnerability / root cause
+
+_What weakness makes this threat exploitable?_
+
+---
+
+## P×I Scoring
+
+### Probability (1–4)
+
+| Score | Label           | Criteria                                        |
+| ----- | --------------- | ----------------------------------------------- |
+| 1     | Unlikely        | Rare; requires exceptional circumstances        |
+| 2     | Possible        | Could occur; has happened in similar contexts   |
+| 3     | Likely          | Expected to occur at some point                 |
+| 4     | Almost Certain  | Will occur; seen frequently in this domain      |
+
+**Selected Probability:** \_\_ / Rationale: _..._
+
+### Impact (1–4)
+
+| Score | Label    | Criteria                                                         |
+| ----- | -------- | ---------------------------------------------------------------- |
+| 1     | Low      | Minimal disruption; no data exposure; quickly recoverable        |
+| 2     | Medium   | Partial service disruption; limited data exposure                |
+| 3     | High     | Significant outage; potential regulatory impact or data breach   |
+| 4     | Critical | Full service down; major data breach; legal / reputational damage |
+
+**Selected Impact:** \_\_ / Rationale: _..._
+
+### Score
+
+**Score = Probability × Impact = \_\_ × \_\_ = \_\_**
+
+| Score | Tier     | Response SLA                                  |
+| ----- | -------- | --------------------------------------------- |
+| ≤ 4   | Low      | Monitor; review at next quarterly cycle       |
+| 5–8   | Medium   | Mitigate within 90 days; add to backlog       |
+| 9–12  | High     | Mitigate within 30 days; notify security lead |
+| > 12  | Critical | Immediate action; escalate to management      |
+
+**Tier:** \_\_
+
+---
+
+## Mitigation
+
+### Treatment option
+
+- [ ] **Mitigate** — implement controls to reduce probability or impact
+- [ ] **Accept** — formally accept residual risk (document business justification)
+- [ ] **Transfer** — shift risk to third party (insurance, contract)
+- [ ] **Avoid** — change design or process to eliminate the risk
+
+### Mitigation plan
+
+_Describe the specific controls or changes to implement._
+
+| Control               | Type (preventive / detective / corrective) | Owner | Due date | Status |
+| --------------------- | ------------------------------------------ | ----- | -------- | ------ |
+| _Control 1_           | _Type_                                     | TBD   | TBD      | Open   |
+
+### Residual risk (post-mitigation)
+
+| Field                    | Value |
+| ------------------------ | ----- |
+| Residual Probability     | \_\_  |
+| Residual Impact          | \_\_  |
+| **Residual Score**       | \_\_  |
+| **Residual Tier**        | \_\_  |
+
+---
+
+## Approval
+
+| Role             | Name | Date | Signature |
+| ---------------- | ---- | ---- | --------- |
+| Risk owner       | TBD  | TBD  | —         |
+| Security lead    | TBD  | TBD  | —         |