@blamejs/exceptd-skills 0.12.22 → 0.12.24

package/data/_indexes/_meta.json

@@ -1,10 +1,10 @@
 {
   "schema_version": "1.1.0",
-  "generated_at": "2026-05-15T06:49:36.722Z",
+  "generated_at": "2026-05-15T18:45:49.423Z",
   "generator": "scripts/build-indexes.js",
   "source_count": 50,
   "source_hashes": {
-    "manifest.json": "2adf0e88322f3903ffd323dbcee69b406c7d801a1539cb1e79e569e47bbafc4c",
+    "manifest.json": "557bf7b459de4fb6af3d0bbad86626bf76581f44e31c30e240682ca87dbb9f69",
     "data/atlas-ttps.json": "20339e0ae3cd89c06f1385be31c50f408f827edc2e8ab8aef026ade3bcf0a917",
     "data/attack-techniques.json": "6db08a8e8a4d03d9309b1d185112de7f3c9595d2cd3d24566b7ce0b3b8aa5d1a",
     "data/cve-catalog.json": "7936ba3c8f27156235bf327830e8f1a684658865e97f089aed98b2a7cdbb88ef",
@@ -83,7 +83,7 @@
     "frequency_fields": 7,
     "activity_feed_events": 50,
     "catalog_summaries": 11,
-    "stale_content_findings": 0
+    "stale_content_findings": 1
   },
   "invalidation_note": "If any source file in source_hashes has a different SHA-256 than recorded here, the indexes are stale. Re-run `npm run build-indexes`."
 }

package/data/_indexes/stale-content.json

@@ -3,12 +3,19 @@
     "schema_version": "1.0.0",
     "reference_date": "2026-05-01",
     "note": "Stale-content snapshot derived from audit-cross-skill checks. Re-runs of build-indexes against the same inputs produce byte-identical output (reference_date is manifest.threat_review_date, not 'now'). audit-cross-skill.js remains the canonical interactive audit.",
-    "finding_count": 0,
+    "finding_count": 1,
     "by_severity": {
       "high": 0,
-      "medium": 0,
+      "medium": 1,
       "low": 0
     }
   },
-  "findings": []
+  "findings": [
+    {
+      "severity": "medium",
+      "category": "badge_drift",
+      "artifact": "README.md",
+      "detail": "jurisdictions badge shows 35, live count is 34"
+    }
+  ]
 }

package/data/playbooks/ai-api.json

@@ -297,7 +297,7 @@
         "monitor": 40,
         "close": 25
       },
-      "framework_lag_declaration": "NIST 800-53 SI-3/SC-7/AC-2, ISO 27001:2022 A.8.16, SOC 2 CC6/CC7, EU AI Act Art.15 are all structurally insufficient for AI-API C2. The shared failure: each control treats the AI API endpoint as a legitimate authorized SaaS, the service account using it as authorized, and the traffic over it as business-as-usual. The SesameOp pattern operates entirely inside that authorized envelope. Until frameworks add 'AI-API egress baseline + content inspection + bearer-token-to-process attribution' controls, anomaly-detection audit opinions provide zero signal about AI-as-C2 exposure. Companion gap: secrets-management controls (IA-5, A.8.5) focus on repository-committed keys and ignore the dotfile credential surface where most developer keys actually live. Lag = ~190 days behind the SesameOp pattern's first documentation; no framework body has issued draft language as of 2026-05-11.",
+      "framework_lag_declaration": "NIST 800-53 SI-3/SC-7/AC-2, ISO 27001:2022 A.8.16, SOC 2 CC6/CC7, EU AI Act Art.15 are all structurally insufficient for AI-API C2. The shared failure: each control treats the AI API endpoint as a legitimate authorized SaaS, the service account using it as authorized, and the traffic over it as business-as-usual. The SesameOp pattern operates entirely inside that authorized envelope. Until frameworks add 'AI-API egress baseline + content inspection + bearer-token-to-process attribution' controls, anomaly-detection audit opinions provide zero signal about AI-as-C2 exposure. Companion gap: secrets-management controls (IA-5, A.8.5) focus on repository-committed keys and ignore the dotfile credential surface where most developer keys actually live. Lag = ~190 days behind the SesameOp pattern's first documentation; no framework body has issued draft language as of 2026-05-11. UK CAF Principles B3 (Data Security) and B4 (System Security) treat egress monitoring and trust-boundary enforcement as outcomes without naming AI-API endpoints as a distinct exfiltration channel — B3/B4 evidence passes while authorized-SaaS C2 channels stay invisible. AU Essential 8 ML2 Application Control (E8 M.1) + Restrict Admin Privileges (E8 M.5) and ACSC ISM-1546 cover process-lineage and admin-privilege restriction, but Essential 8 does not yet enumerate AI-API endpoints in its allowlist guidance — operators who allow AI SaaS at the proxy retain no per-token attribution.",
       "skill_chain": [
         {
           "skill": "ai-c2-detection",

package/data/playbooks/containers.json

@@ -257,7 +257,7 @@
         "monitor": 65,
         "close": 35
       },
-      "framework_lag_declaration": "NIST 800-190 + CIS K8s Benchmark + NIST 800-53 CM-7 + ISO A.8.9 + PCI Req.2.2 collectively cover container hardening but accept cluster-wide attestation as evidence. None require per-manifest analysis as a control. Manifest drift in GitOps repos can introduce privileged: true / hostPID / unscoped capabilities faster than any attestation cadence. EU CRA + NIST SSDF + SLSA cover supply-chain posture but most orgs are at SLSA L1-L2 without digest pinning. Gap = ~21 days between manifest drift and review cadence; per-CVE gap (e.g. Leaky Vessels) is hours from public PoC to weaponization vs. weeks of node-staging windows.",
+      "framework_lag_declaration": "NIST 800-190 + CIS K8s Benchmark + NIST 800-53 CM-7 + ISO A.8.9 + PCI Req.2.2 collectively cover container hardening but accept cluster-wide attestation as evidence. None require per-manifest analysis as a control. Manifest drift in GitOps repos can introduce privileged: true / hostPID / unscoped capabilities faster than any attestation cadence. EU CRA + NIST SSDF + SLSA cover supply-chain posture but most orgs are at SLSA L1-L2 without digest pinning. Gap = ~21 days between manifest drift and review cadence; per-CVE gap (e.g. Leaky Vessels) is hours from public PoC to weaponization vs. weeks of node-staging windows. UK CAF Principles B4 (System Security) and B5 (Resilient Networks & Systems) treat container-runtime hardening as an outcome assessable via attestation, without binding evidence to per-manifest privileged-flag or host-namespace exposure. AU Essential 8 Strategy 1 (Application Control, E8 M.1 ML2) covers execution allowlisting on workstations/servers but does not bind to Kubernetes admission-controller policy: privileged-pod denial via OPA/Kyverno or PodSecurity `restricted` admission is the operational analogue, and Essential 8 has no maturity-level requirement enforcing it. ACSC ISM-1546 and ISM-1683 (workload isolation) name workload separation but stop short of banning privileged + hostPID + hostNetwork in cluster manifests as an attested admission-time gate.",
       "skill_chain": [
         {
           "skill": "container-runtime-security",

package/data/playbooks/cred-stores.json

@@ -236,7 +236,7 @@
         "monitor": 60,
         "close": 30
       },
-      "framework_lag_declaration": "NIST 800-63b AAL specs, NIST 800-53 IA-2/IA-5, ISO A.5.16/A.5.17, NIS2 Art.21(2)(j), PCI-DSS Req.8 collectively specify target authenticator properties (phishing-resistant, short-lived, MFA-gated). They do not require enumeration of credentials actually present on developer endpoints. SSO + MFA attestation is accepted as evidence even when local credential stores hold long-lived bearer tokens that bypass SSO. Gap = ~25 days between credential-store drift (new PAT issued, new long-lived AWS key created) and any framework's review cadence.",
+      "framework_lag_declaration": "NIST 800-63b AAL specs, NIST 800-53 IA-2/IA-5, ISO A.5.16/A.5.17, NIS2 Art.21(2)(j), PCI-DSS Req.8 collectively specify target authenticator properties (phishing-resistant, short-lived, MFA-gated). They do not require enumeration of credentials actually present on developer endpoints. SSO + MFA attestation is accepted as evidence even when local credential stores hold long-lived bearer tokens that bypass SSO. Gap = ~25 days between credential-store drift (new PAT issued, new long-lived AWS key created) and any framework's review cadence. UK CAF Principle B2 (Identity and Access Control) defines authentication outcomes and credential-management practice, but does not require enumeration of credentials persisted in local credential stores outside the SSO/IdP envelope. AU Essential 8 ML2 MFA (E8 M.4) + Restrict Admin Privileges (E8 M.5) and ACSC ISM-1546 cover authenticator strength and admin-privilege scope but treat long-lived bearer tokens stored in dotfiles / OS keychains as out of frame — Essential 8 evidence passes while landed-attacker credential harvest stays trivial.",
       "skill_chain": [
         {
           "skill": "identity-assurance",

package/data/playbooks/crypto-codebase.json

@@ -322,7 +322,7 @@
         "monitor": 45,
         "close": 25
       },
-      "framework_lag_declaration": "Frameworks structurally bind the OPERATING organization, not the library author. NIST 800-53 SC-13, ISO 27001:2022 A.8.24/A.8.28, PCI DSS 4.0 §3.6/§8.3.2 all push obligations downstream to consumers who inherit the shipped defaults. EU CRA Annex I §1 is the first framework with direct upstream obligations on manufacturers of products with digital elements, but its binding date for vulnerability-handling and SBOM provisions is 2026-09-11 (four months from now) with full compliance 2027-12-11. NIS2 Art.21(2)(g) exerts indirect pressure via essential-entity consumers. UK CAF C.5 + UK PSTI covers connected products only. ISO 27001:2022 A.8.28 'secure coding' is silent on PQC, KDF iteration minimums, RNG-source requirements, constant-time-implementation requirements — the longest structural laggard. NIST IR 8547 + OMB M-23-02 + CNSA 2.0 push federal-system PQC migration through 2030 but rely on procurement pressure to flow upstream. Gap = ~365 days from operational PQC readiness (2024-08-13 FIPS finalization) to binding library-author obligations (2026-09-11 EU CRA partial bind). Compensating controls (downstream-consumer adoption pressure, supply-chain auditing tools, voluntary SECURITY.md disclosure of cryptographic provenance) must close this gap pending EU CRA enforcement.",
+      "framework_lag_declaration": "Frameworks structurally bind the OPERATING organization, not the library author. NIST 800-53 SC-13, ISO 27001:2022 A.8.24/A.8.28, PCI DSS 4.0 §3.6/§8.3.2 all push obligations downstream to consumers who inherit the shipped defaults. EU CRA Annex I §1 is the first framework with direct upstream obligations on manufacturers of products with digital elements, but its binding date for vulnerability-handling and SBOM provisions is 2026-09-11 (four months from now) with full compliance 2027-12-11. NIS2 Art.21(2)(g) exerts indirect pressure via essential-entity consumers. UK CAF C.5 + UK PSTI covers connected products only. ISO 27001:2022 A.8.28 'secure coding' is silent on PQC, KDF iteration minimums, RNG-source requirements, constant-time-implementation requirements — the longest structural laggard. NIST IR 8547 + OMB M-23-02 + CNSA 2.0 push federal-system PQC migration through 2030 but rely on procurement pressure to flow upstream. Gap = ~365 days from operational PQC readiness (2024-08-13 FIPS finalization) to binding library-author obligations (2026-09-11 EU CRA partial bind). Compensating controls (downstream-consumer adoption pressure, supply-chain auditing tools, voluntary SECURITY.md disclosure of cryptographic provenance) must close this gap pending EU CRA enforcement. AU Essential 8 ML2 Patch Applications (E8 M.2) plus ACSC ISM-1138 (cryptographic-algorithm transition), ISM-0467 (approved cryptographic algorithms), and ISM-0471 (cryptographic protocol selection) reference downstream consumer migration but place no obligation on upstream library authors to ship PQC-by-default, KDF iteration minima, or constant-time implementations — Essential 8 evidence flows from operating-org posture, not from library-publisher posture. UK CAF Principle C.5 (System Security — outcome-tested cryptographic deployments) and UK PSTI together lag because CAF C.5 mandates outcome-tested cryptographic deployments at the operator but does not require library authors to ship PQC-by-default, constant-time implementations, or KDF iteration minima; PSTI scope is connected products only and excludes upstream library distribution entirely. The library-author surface therefore sits in a coverage seam between CAF (operator-side) and PSTI (finished-product-side) — neither binds the upstream publisher.",
       "skill_chain": [
         {
           "skill": "pqc-first",

package/data/playbooks/crypto.json

@@ -288,7 +288,7 @@
         "monitor": 45,
         "close": 25
       },
-      "framework_lag_declaration": "Every framework in scope is structurally insufficient for HNDL. NIST 800-53 SC-8/SC-13, ISO 27001:2022 A.8.24/A.8.25, PCI DSS 4.0 §3.6/§4.2.1, NIS2 Art.21(2)(h), DORA Art.9, EU CRA Annex I all permit fully-classical cryptographic posture as 'strong cryptography'. NIST itself is the exception: FIPS 203/204/205 are finalized, NIST IR 8547 is a published migration roadmap, OMB M-23-02 mandates federal PQC inventory — but the 800-53 control catalog is unchanged. ISO 27001:2022 was published before PQC finalization and has no scheduled amendment. PCI Council and EU regulators are publicly aware but have not amended binding controls. Lag = ~180 days behind operational readiness (PQC has been production-ready since 2024-08-13) and 4-8+ years behind the CRQC horizon that drives the harvest-now-decrypt-later attack. Compensating controls (crypto-agility, hybrid algorithms, layered encryption envelopes) must close this gap before SLA-only compliance can be accepted.",
+      "framework_lag_declaration": "Every framework in scope is structurally insufficient for HNDL. NIST 800-53 SC-8/SC-13, ISO 27001:2022 A.8.24/A.8.25, PCI DSS 4.0 §3.6/§4.2.1, NIS2 Art.21(2)(h), DORA Art.9, EU CRA Annex I all permit fully-classical cryptographic posture as 'strong cryptography'. NIST itself is the exception: FIPS 203/204/205 are finalized, NIST IR 8547 is a published migration roadmap, OMB M-23-02 mandates federal PQC inventory — but the 800-53 control catalog is unchanged. ISO 27001:2022 was published before PQC finalization and has no scheduled amendment. PCI Council and EU regulators are publicly aware but have not amended binding controls. Lag = ~180 days behind operational readiness (PQC has been production-ready since 2024-08-13) and 4-8+ years behind the CRQC horizon that drives the harvest-now-decrypt-later attack. Compensating controls (crypto-agility, hybrid algorithms, layered encryption envelopes) must close this gap before SLA-only compliance can be accepted. UK CAF Principles B3 (Data Security) and B4 (System Security) treat cryptography as an outcome (data-in-transit + data-at-rest protection) without naming PQC migration or HNDL exposure as a B3/B4 requirement — CAF evidence passes against fully-classical posture. AU Essential 8 ML2 Patch Applications + Patch Operating Systems (E8 M.2) plus ACSC ISM-1138 (cryptographic-algorithm transition) and ISM-0467 (approved cryptographic algorithms) reference algorithm-suite policy, but ISM transition guidance remains advisory in 2026-05 and Essential 8 maturity levels do not bind PQC inventory + migration deadlines.",
       "skill_chain": [
         {
           "skill": "pqc-first",

package/data/playbooks/framework.json

@@ -320,7 +320,7 @@
         "monitor": 40,
         "close": 20
       },
-      "framework_lag_declaration": "All 20 frameworks listed in domain.frameworks_in_scope are structurally insufficient for at least one upstream-playbook threat class. ISO 27001:2022, SOC 2 TSC, and PCI DSS 4.0 are the longest-laggard for AI/MCP/PQC threats (no scheduled amendments). NIST 800-53, NIS2, DORA, EU AI Act, and EU CRA have publishing cadences but lag the threat tempo by 90-365 days. UK CAF (outcome-based) and AU Essential 8 are partially forward-compatible but inconsistent across regulators/sectors. SG MAS TRM, JP FISC, IN CERT-In, CA OSFI B-10 are sector- and jurisdiction-specific with tempo varying by sector. Compound effect: an org running all current threat-class exposures under a single audit opinion is the modal state in mid-2026, not an outlier.",
+      "framework_lag_declaration": "All 20 frameworks listed in domain.frameworks_in_scope are structurally insufficient for at least one upstream-playbook threat class. ISO 27001:2022, SOC 2 TSC, and PCI DSS 4.0 are the longest-laggard for AI/MCP/PQC threats (no scheduled amendments). NIST 800-53, NIS2, DORA, EU AI Act, and EU CRA have publishing cadences but lag the threat tempo by 90-365 days. UK CAF (outcome-based) and AU Essential 8 are partially forward-compatible but inconsistent across regulators/sectors. SG MAS TRM, JP FISC, IN CERT-In, CA OSFI B-10 are sector- and jurisdiction-specific with tempo varying by sector. Compound effect: an org running all current threat-class exposures under a single audit opinion is the modal state in mid-2026, not an outlier. Named per-framework lags: NIST 800-53 CA-7 (Continuous Monitoring) lags because it is designed for control-effectiveness assessment and does not require correlation across frameworks to surface paper-vs-actual evidence. EU NIS2 Art.21(2) lags because it enumerates 10 risk-management categories but does not require operators to correlate their asset inventory against EU AI Act risk classifications when AI systems are present. UK CAF Principle A (Governance) lags because it is designed to assess governance-of-cyber-resilience outcomes and does not require correlation of `outcome-test` failures across CAF outcomes to surface compliance-theater. AU Essential 8 Strategy 1 (Application Control, ML2) lags because it is designed for execution allowlisting on workstations/servers and does not reach AI-tool-and-MCP-server allowlisting as a sub-class of executable trust. ISO/IEC 27001:2022 A.5.1 (Policies for information security) lags because it requires top-level policy presence and does not require cross-framework gap analysis as part of policy maintenance.",
       "skill_chain": [
         {
           "skill": "framework-gap-analysis",

package/data/playbooks/hardening.json

@@ -226,7 +226,7 @@
         "monitor": 65,
         "close": 30
       },
-      "framework_lag_declaration": "NIST CM-6, ISO A.8.9, Essential 8 OS Hardening, CMMC CM.L2-3.4.1/2 all permit baseline + change-management evidence without requiring continuous attestation of the specific kernel hardening flags (kptr_restrict, unprivileged_userns_clone, unprivileged_bpf_disabled, yama.ptrace_scope, dmesg_restrict, kernel.lockdown, MAC enforcement mode) that determine whether a vulnerable kernel is actually exploitable. Gap = ~21 days at typical orgs between drift event and review. For environments using GitOps-deployed kernel parameters, drift can occur faster than monitoring catches.",
+      "framework_lag_declaration": "NIST CM-6, ISO A.8.9, Essential 8 OS Hardening, CMMC CM.L2-3.4.1/2 all permit baseline + change-management evidence without requiring continuous attestation of the specific kernel hardening flags (kptr_restrict, unprivileged_userns_clone, unprivileged_bpf_disabled, yama.ptrace_scope, dmesg_restrict, kernel.lockdown, MAC enforcement mode) that determine whether a vulnerable kernel is actually exploitable. Gap = ~21 days at typical orgs between drift event and review. For environments using GitOps-deployed kernel parameters, drift can occur faster than monitoring catches. UK CAF Principles B4 (System Security) and B5 (Resilient Networks & Systems) treat OS hardening as a system-security outcome assessable via baseline-and-change-management evidence, without binding to continuous attestation of specific kernel hardening flags (kptr_restrict, unprivileged_userns_clone, unprivileged_bpf_disabled, yama.ptrace_scope, dmesg_restrict, kernel.lockdown, MAC enforcement) — CAF evidence passes against a host whose flags drifted hours after the last review. AU Essential 8 ML2 Patch Operating Systems (E8 M.2) + Restrict Admin Privileges (E8 M.5) and ACSC ISM-1144 / ISM-1493 (vulnerability management) reference OS-hardening posture but do not enumerate the per-sysctl flag set whose state determines whether a vulnerable kernel is actually exploitable. EU NIS2 Art.21(2)(c) `secure development lifecycle` and DORA Art.9(4) `secure configuration` both reference hardening posture obligation but stop short of requiring per-flag kernel-hardening attestation; the gap is that operators can claim compliance with `vm.mmap_min_addr` defaulted-but-not-attested, because neither framework requires the per-sysctl evidence that distinguishes a hardened kernel from a default-shipped one.",
       "skill_chain": [
         {
           "skill": "kernel-lpe-triage",

package/data/playbooks/kernel.json

@@ -224,7 +224,7 @@
         "monitor": 70,
         "close": 30
       },
-      "framework_lag_declaration": "NIST SI-2 + ISO A.8.8 + NIS2 Art.21(2)(c) permit 30-day patch SLAs that are inadequate for KEV-listed kernel LPEs with confirmed exploitation. NIST 800-53 Rev. 5.1.1 does not require KEV-aware prioritization, only risk-based — leaving it to implementer interpretation. Real-world tempo: weaponization in hours, patch SLA in weeks. Gap = ~28 days. Compensating controls (live-patch, MAC, kernel hardening) MUST close this gap before SLA-only compliance can be accepted.",
+      "framework_lag_declaration": "NIST SI-2 + ISO A.8.8 + NIS2 Art.21(2)(c) permit 30-day patch SLAs that are inadequate for KEV-listed kernel LPEs with confirmed exploitation. NIST 800-53 Rev. 5.1.1 does not require KEV-aware prioritization, only risk-based — leaving it to implementer interpretation. Real-world tempo: weaponization in hours, patch SLA in weeks. Gap = ~28 days. Compensating controls (live-patch, MAC, kernel hardening) MUST close this gap before SLA-only compliance can be accepted. UK CAF Principles B4 (System Security) and B5 (Resilient Networks & Systems) treat patching as an outcome without binding to KEV-aware tempo; CAF evidence passes against the 30-day SLA that real-world weaponization beats. AU Essential 8 ML2 / ML3 Patch Operating Systems (E8 M.2) sets a 48-hour patch target for internet-facing services with known exploitation, and ACSC ISM-1144 / ISM-1493 (vulnerability management + critical patching) name kernel patching specifically — but Essential 8 maturity adoption surveys show ML3 attainment <15% across regulated AU entities, leaving the structural gap operational even where the framework anticipates it.",
       "skill_chain": [
         {
           "skill": "kernel-lpe-triage",

package/data/playbooks/library-author.json

@@ -477,7 +477,7 @@
         "monitor": 50,
         "close": 30
       },
-      "framework_lag_declaration": "NIST 800-53 SR-3/4/5, NIST 800-218 SSDF PS.3.2 / PW.4 / RV.2, ISO 27001:2022 A.8.30 / A.5.20, SOC 2 CC8.1 / CC9.2, NIS2 Art.21(2)(d), DORA Art.28, UK CAF C1.b, AU Essential 8 E1, and CMMC SI.L2-3.4.4 all permit publisher posture that omits (a) OIDC-based publish, (b) Sigstore / Rekor transparency-log entries per release, (c) signed + distributed SBOM, (d) transitive completeness, (e) VEX feed for filed CVEs, (f) coordinated-disclosure intake at /.well-known/security.txt, (g) tag-protection on release refs, (h) reproducible builds, (i) skill / plugin signature verification gated in the install path. Operational tooling for (a)-(i) shipped 2023-2025; framework lag = ~540 days behind tooling and ~18 months ahead of EU CRA Art.10/13/14 binding (2027). Compensating controls MUST close (a)-(i) before SSDF-only compliance can be accepted as CRA-readiness.",
+      "framework_lag_declaration": "NIST 800-53 SR-3/4/5, NIST 800-218 SSDF PS.3.2 / PW.4 / RV.2, ISO 27001:2022 A.8.30 / A.5.20, SOC 2 CC8.1 / CC9.2, NIS2 Art.21(2)(d), DORA Art.28, and CMMC SI.L2-3.4.4 all permit publisher posture that omits (a) OIDC-based publish, (b) Sigstore / Rekor transparency-log entries per release, (c) signed + distributed SBOM, (d) transitive completeness, (e) VEX feed for filed CVEs, (f) coordinated-disclosure intake at /.well-known/security.txt, (g) tag-protection on release refs, (h) reproducible builds, (i) skill / plugin signature verification gated in the install path. Operational tooling for (a)-(i) shipped 2023-2025; framework lag = ~540 days behind tooling and ~18 months ahead of EU CRA Art.10/13/14 binding (2027). UK CAF C1.b (Identity and Access Management — Privileged user management) is designed to govern human privileged users and does not require SLSA L3+ provenance attestation on every release artifact; the gap is that a compromised publisher token (no human-MFA gate, no provenance attestation) yields an attacker-signed release that passes C1.b's evidence surface. AU Essential 8 Strategy 5 (Restrict Admin Privileges, E8 M.5) is designed for runtime admin-account scoping and does not reach build-time admin privileges on signing-key material: a CI runner holding the publish credential is a build-time admin that E8 M.5 evidence does not enumerate. Compensating controls MUST close (a)-(i) before SSDF-only compliance can be accepted as CRA-readiness.",
       "skill_chain": [
         {
           "skill": "supply-chain-integrity",

package/data/playbooks/mcp.json

@@ -326,7 +326,7 @@
         "monitor": 50,
         "close": 25
       },
-      "framework_lag_declaration": "Every framework in scope (NIST 800-53 SA-12/CM-7, ISO 27001:2022 A.5.19/A.5.20/A.8.30, SOC 2 CC9, NIS2 Art.21(2)(d), EU AI Act Art.15, EU CRA Art.13) is structurally insufficient. The shared structural failure: every control treats third-party software risk as a procurement event with a discrete vendor list, while MCP servers are continuously sideloaded by developers from package registries with no procurement signal, no enforced signing, and no allowlist that survives version drift. Until frameworks add a 'developer-installed AI tool plugin' control category with mandatory manifest signature verification + version pinning with integrity hash + provenance attestation, vendor-management audit opinions provide zero signal about MCP exposure. Gap = ~210 days behind operational reality; no framework body has issued draft language as of 2026-05-11.",
+      "framework_lag_declaration": "Every framework in scope (NIST 800-53 SA-12/CM-7, ISO 27001:2022 A.5.19/A.5.20/A.8.30, SOC 2 CC9, NIS2 Art.21(2)(d), EU AI Act Art.15, EU CRA Art.13) is structurally insufficient. The shared structural failure: every control treats third-party software risk as a procurement event with a discrete vendor list, while MCP servers are continuously sideloaded by developers from package registries with no procurement signal, no enforced signing, and no allowlist that survives version drift. Until frameworks add a 'developer-installed AI tool plugin' control category with mandatory manifest signature verification + version pinning with integrity hash + provenance attestation, vendor-management audit opinions provide zero signal about MCP exposure. Gap = ~210 days behind operational reality; no framework body has issued draft language as of 2026-05-11. UK CAF Principles B3 (Data Security) and B4 (System Security) treat third-party tooling as a procurement-and-supply-chain assurance outcome, with no Principle that names developer-installed AI tool plugins as a distinct surface — CAF B3/B4 evidence remains silent on MCP-server sideload. AU Essential 8 ML2 Application Control (E8 M.1) + Restrict Admin Privileges (E8 M.5) plus ACSC ISM-1490 (application control) and ISM-1657 (supply chain) cover application-execution allowlisting in principle, but Essential 8 maturity guidance assumes a discrete vendor list and does not enumerate registry-pulled MCP servers as application-control scope.",
       "skill_chain": [
         {
           "skill": "mcp-agent-trust",

package/data/playbooks/runtime.json

@@ -230,7 +230,7 @@
         "monitor": 65,
         "close": 35
       },
-      "framework_lag_declaration": "NIST CM-7 + AC-6, ISO A.8.2 + A.8.18, and NIS2 Art.21(2)(i) treat least-privilege and least-functionality as policy outcomes reviewable annually. They do not require programmatic enumeration of the specific primitives (sudoers NOPASSWD, non-baseline SUID, world-writable cron, host-mounted systemd services, listening sockets on non-loopback) that attackers use to convert foothold into root. A host can be CM-7/AC-6 compliant on paper while presenting dozens of LPE primitives to a landed attacker. Gap = ~21 days between drift and policy review at typical orgs; for fast-moving environments (containerized + GitOps-deployed), drift accumulates faster than annual review can catch.",
+      "framework_lag_declaration": "NIST CM-7 + AC-6, ISO A.8.2 + A.8.18, and NIS2 Art.21(2)(i) treat least-privilege and least-functionality as policy outcomes reviewable annually. They do not require programmatic enumeration of the specific primitives (sudoers NOPASSWD, non-baseline SUID, world-writable cron, host-mounted systemd services, listening sockets on non-loopback) that attackers use to convert foothold into root. A host can be CM-7/AC-6 compliant on paper while presenting dozens of LPE primitives to a landed attacker. Gap = ~21 days between drift and policy review at typical orgs; for fast-moving environments (containerized + GitOps-deployed), drift accumulates faster than annual review can catch. UK CAF Principles B4 (System Security) and B5 (Resilient Networks & Systems) treat least-privilege as a system-security outcome assessable through control-design evidence, without binding to per-host enumeration of LPE primitives (sudoers NOPASSWD, non-baseline SUID, writable cron, host-mount services). AU Essential 8 ML2 Restrict Admin Privileges (E8 M.5) + Patch Operating Systems (E8 M.2) plus ACSC ISM-1175 (privilege management) and ISM-1490 (application control) cover admin-account and application-execution policy, but Essential 8 maturity evidence does not enumerate the specific runtime primitives that convert foothold into root.",
       "skill_chain": [
         {
           "skill": "attack-surface-pentest",

package/data/playbooks/sbom.json

@@ -390,7 +390,7 @@
         "monitor": 50,
         "close": 30
       },
-      "framework_lag_declaration": "Supply-chain frameworks have advanced fastest of any class in this exceptd release, but implementation gaps are pervasive. NIST 800-53 SA-12, NIST 800-218 SSDF, ISO 27001:2022 A.8.30/A.5.20, SOC 2 CC9.2, PCI DSS 4.0 sect.6.3, NIS2 Art.21(2)(d), DORA Art.28, EU CRA Art.13/14 all permit (a) SBOM as deliverable without continuous correlation, (b) lockfile-pinning without integrity hash, (c) direct-deps-only SBOM, (d) absence of VEX statements, (e) absence of AI-generated-code provenance, (f) model weights treated as content blobs. Lag = ~90 days behind operational tooling (SLSA / Sigstore / in-toto / VEX-CSAF) and ~210 days behind AI-coding-assistant adoption tempo. Compensating controls (continuous CVE correlation, integrity-pinned lockfiles, transitive SBOM completeness, VEX maintenance, AI-code provenance, model weight signature verification + safetensors-only loading) MUST close the gap before SBOM-as-deliverable compliance can be accepted.",
+      "framework_lag_declaration": "Supply-chain frameworks have advanced fastest of any class in this exceptd release, but implementation gaps are pervasive. NIST 800-53 SA-12, NIST 800-218 SSDF, ISO 27001:2022 A.8.30/A.5.20, SOC 2 CC9.2, PCI DSS 4.0 sect.6.3, NIS2 Art.21(2)(d), DORA Art.28, EU CRA Art.13/14 all permit (a) SBOM as deliverable without continuous correlation, (b) lockfile-pinning without integrity hash, (c) direct-deps-only SBOM, (d) absence of VEX statements, (e) absence of AI-generated-code provenance, (f) model weights treated as content blobs. Lag = ~90 days behind operational tooling (SLSA / Sigstore / in-toto / VEX-CSAF) and ~210 days behind AI-coding-assistant adoption tempo. Compensating controls (continuous CVE correlation, integrity-pinned lockfiles, transitive SBOM completeness, VEX maintenance, AI-code provenance, model weight signature verification + safetensors-only loading) MUST close the gap before SBOM-as-deliverable compliance can be accepted. UK CAF Principles B5 (Resilient Networks & Systems) and D1 (Response and Recovery Planning) treat supply-chain assurance and recovery readiness as outcomes, with no Principle binding continuous CVE correlation against the shipped SBOM or VEX maintenance as evidence. AU Essential 8 ML2 Patch Applications (E8 M.2) plus ACSC ISM-0717 (supply-chain risk management) and ISM-1657 (vendor assessment) cover supply-chain due diligence, but Essential 8 patch-tempo evidence accepts vendor advisories without requiring SBOM-driven transitive-CVE correlation or AI-generated-code provenance.",
       "skill_chain": [
         {
           "skill": "supply-chain-integrity",

package/data/playbooks/secrets.json

@@ -76,6 +76,8 @@
       "nis2",
       "dora",
       "uk-caf",
+      "au-ism",
+      "au-essential-8",
       "hipaa"
     ]
   },
@@ -138,6 +140,18 @@
             "california_resident_records_affected",
             "containment_record"
           ]
+        },
+        {
+          "jurisdiction": "AU",
+          "regulation": "Privacy Act 1988 — Notifiable Data Breaches scheme (s26WK)",
+          "obligation": "notify_regulator",
+          "window_hours": 720,
+          "clock_starts": "analyze_complete",
+          "evidence_required": [
+            "secret_inventory",
+            "australian_resident_records_affected",
+            "remediation_completed_evidence"
+          ]
         }
       ],
       "theater_fingerprints": [
@@ -210,6 +224,30 @@
             "control_id": "B3 — Data security",
             "designed_for": "NCSC CAF outcome that data important to the essential function is protected from compromise, including credential and key material.",
             "insufficient_because": "Outcome can be assessed against managed secret-store contents. Plaintext credentials leaked into source-code repositories, CI logs, IaC files, and AI assistant context windows do not register on the outcome's evidence surface."
+          },
+          {
+            "framework": "au-essential-8",
+            "control_id": "Strategy 4 — Multi-factor authentication (E8 M.4)",
+            "designed_for": "MFA on privileged + internet-facing accounts.",
+            "insufficient_because": "MFA defends the interactive auth flow; bearer tokens / API keys / OAuth refresh tokens committed to source artifacts bypass MFA entirely — scraper-bot exploitation against cloud-provider APIs uses the static credential and never reaches an interactive auth surface. Compliance-theater test: audit the last 90 days of admin actions and count those executed by service-account tokens vs human-MFA sessions; if service tokens dominate, Strategy 4 compliance is paper."
+          },
+          {
+            "framework": "au-essential-8",
+            "control_id": "Strategy 1 — Application Control (E8 M.1)",
+            "designed_for": "Execution allowlisting on workstations and servers.",
+            "insufficient_because": "Application Control governs runtime execution but does not constrain build agents reading from arbitrary secret stores or environment variables at build time — CI runners with broad env-var access defeat the intent. Compliance-theater test: inventory CI runner environment variables; any token-shaped string (regex /[A-Za-z0-9]{32,}/) means ML2 compliance leaks at build time."
+          },
+          {
+            "framework": "au-ism",
+            "control_id": "ISM-1546",
+            "designed_for": "Multi-factor authentication for privileged users and remote access.",
+            "insufficient_because": "ISM-1546 covers human authentication; CI/CD service identities (which now hold the actual privileges) are out of scope. Stolen GitHub Actions OIDC tokens grant identical blast radius without ever crossing the human-MFA gate. Compliance-theater test: list CI runner OIDC token TTLs and audience scopes; any token with TTL > 1h or wildcard audience defeats ISM-1546's intent."
+          },
+          {
+            "framework": "au-ism",
+            "control_id": "ISM-1559",
+            "designed_for": "Privileged account credential management.",
+            "insufficient_because": "ISM-1559 names key/credential storage but treats source-code-embedded credentials as a policy violation, not a detection control. Modern exfiltration reads credentials post-decryption from /proc, container layers, or build artifacts. Compliance-theater test: run a process listing inside one production container and grep env for tokens; any hit means storage encryption was bypassed at the runtime boundary."
           }
         ]
       },
@@ -227,7 +265,7 @@
         "monitor": 60,
         "close": 30
       },
-      "framework_lag_declaration": "GDPR Art.32, ISO A.8.24, PCI-DSS Req.3, SOC 2 CC6.1 collectively cover encryption + key management + access control in production storage backends. None of them name 'secret in source artifact' as a distinct exposure category, despite this being the dominant 2025-2026 cloud-compromise vector. NIS2 Art.21(2)(j) names cryptography but not development-workflow exposure. Gap = ~30 days between developer commit and framework's quarterly access-review cadence; in practice, scraper bots exploit faster than any framework cadence.",
+      "framework_lag_declaration": "GDPR Art.32, ISO A.8.24, PCI-DSS Req.3, SOC 2 CC6.1 collectively cover encryption + key management + access control in production storage backends. None of them name 'secret in source artifact' as a distinct exposure category, despite this being the dominant 2025-2026 cloud-compromise vector. NIST 800-53 IA-5 (Authenticator Management) lags because it mandates authenticator protection in storage but does not require detection of authenticators committed to source repositories or build artifacts — IA-5 evidence is satisfied by a vault inventory while bearer tokens leak through `.env`, IaC tfvars, and CI logs unscanned. NIS2 Art.21(2)(j) names cryptography but not development-workflow exposure. Gap = ~30 days between developer commit and framework's quarterly access-review cadence; in practice, scraper bots exploit faster than any framework cadence. UK CAF Principle B2 (Identity and Access Control) treats credential lifecycle as an outcome reviewable on cycle, not as a per-commit scanning obligation — secrets embedded in source artifacts do not register against B2 evidence. AU Essential 8 Strategy 1 (Application Control, E8 M.1) is the relevant lever — restricting build agents from accessing arbitrary secret stores or environment variables at build time — but Essential 8 evidence does not enumerate CI-runner secret-store reachability as a sub-control; ISM-1546 covers MFA + admin-account hygiene but bearer tokens / API keys / OAuth refresh tokens in source artifacts bypass MFA entirely, never crossing the interactive auth surface ISM-1546 protects.",
       "skill_chain": [
         {
           "skill": "dlp-gap-analysis",

package/lib/auto-discovery.js

@@ -31,7 +31,7 @@ const fs = require("fs");
 const path = require("path");
 const { scoreCustom, RWEP_WEIGHTS, ACTIVE_EXPLOITATION_LADDER } = require("./scoring");
 
-// C: stored rwep_factors must reproduce the stored rwep_score.
+// Stored rwep_factors must reproduce the stored rwep_score.
 // `buildScoringInputs` is the single source of truth for both — it captures
 // the conservative defaults applied to a freshly-imported KEV draft (CISA
 // only lists vulnerabilities with documented exploitation, so we assume a
@@ -199,7 +199,7 @@ function buildKevDraftEntry(kevEntry, nvdPayload, epssPayload) {
   const knownRansomware =
     String(kevEntry.knownRansomwareCampaignUse || "").toLowerCase() === "known";
 
-  // C: stored rwep_factors and computed rwep_score MUST agree.
+  // Stored rwep_factors and computed rwep_score MUST agree.
   // Previously rwep_factors held nulls (for unknown poc/ai/reboot) but
   // rwep_score was computed from concrete defaults (poc=true, reboot=true).
   // `scoring.validate()` then flagged every auto-imported draft for
@@ -365,7 +365,16 @@ function discoverNewKev(ctx, cap = DEFAULT_CAP) {
 
 // --- RFC discovery -----------------------------------------------------
 
-async function fetchDatatracker(url) {
+async function fetchDatatracker(url, ctx) {
+  // Air-gap refusal — Datatracker is a live IETF service. When the operator
+  // (or the caller's ctx) declares air-gap, return a structured refusal so
+  // refresh-external can surface "discovery skipped" rather than logging a
+  // generic network error. Caller's signature already accepts a nullable
+  // return; the structured object is distinguishable from a successful
+  // payload by `ok:false`.
+  if ((ctx && ctx.airGap === true) || process.env.EXCEPTD_AIR_GAP === "1") {
+    return { ok: false, error: "air-gap-blocked", source: "datatracker" };
+  }
   const ac = new AbortController();
   const t = setTimeout(() => ac.abort(), TIMEOUT_MS);
   try {
@@ -532,7 +541,22 @@ async function discoverNewRfcs(ctx, opts = {}) {
       `https://datatracker.ietf.org/api/v1/doc/document/` +
       `?type=rfc&group__acronym=${encodeURIComponent(wg)}` +
       `&time__gt=${cutoff}&order_by=-time&limit=20&format=json`;
-    const payload = await fetchDatatracker(url);
+    const payload = await fetchDatatracker(url, ctx);
+    // Treat the air-gap structured refusal as a discovery skip — not an
+    // error. The existing `!payload || !Array.isArray(payload.objects)`
+    // path would have classed it as `errors++`, which misreports an
+    // operator-chosen offline posture as a fault. Short-circuit the whole
+    // WG loop on first air-gap refusal because every subsequent fetch will
+    // refuse identically.
+    if (payload && payload.ok === false && payload.error === "air-gap-blocked") {
+      return {
+        diffs: [],
+        errors: 0,
+        spilled: 0,
+        summary: "RFC discovery: skipped (air-gap mode)",
+        skipped: "air-gap",
+      };
+    }
     if (!payload || !Array.isArray(payload.objects)) {
       errors++;
       continue;

package/lib/cross-ref-api.js

@@ -19,12 +19,12 @@ const ROOT = path.join(__dirname, '..');
 const DATA_DIR = process.env.EXCEPTD_DATA_DIR || path.join(ROOT, 'data');
 const INDEX_DIR = path.join(DATA_DIR, '_indexes');
 
-// DD P1-1: cache entries store the parsed payload AND the mtimeMs of the
-// source file at parse-time. Each load call re-stats the file; if mtime
-// matches, the cached value is returned (one syscall, no parse). If mtime
-// changed, re-parse + repopulate. If stat fails (file vanished mid-run,
-// permission glitch), fall back to the cached value. Pre-fix the cache was
-// process-lifetime — long-running `orchestrator watch` processes never saw
+// Cache entries store the parsed payload AND the mtimeMs of the source
+// file at parse-time. Each load call re-stats the file; if mtime matches,
+// the cached value is returned (one syscall, no parse). If mtime changed,
+// re-parse + repopulate. If stat fails (file vanished mid-run, permission
+// glitch), fall back to the cached value. Without mtime-keyed
+// invalidation, long-running `orchestrator watch` processes never see
 // `data/cve-catalog.json` mutations driven by `exceptd refresh --apply`.
 const _cache = new Map();
 
@@ -106,13 +106,14 @@ function entries(catalog) {
  * that references it across skills, framework gaps, theater fingerprints,
  * recipes, and zero-day lessons.
  *
- * FF P1-4: auto-imported drafts (entries with `_auto_imported === true`) are
+ * Auto-imported drafts (entries with `_auto_imported === true`) are
  * EXCLUDED by default. Drafts carry conservative-default mechanical fields
  * and null analytical fields pending curation; downstream analyze / bundle
- * emitters that assume `byCve()` returns curated data would treat the draft's
- * placeholders as authoritative. The cve-curation flow (which surfaces the
- * editorial questionnaire) opts in via `byCve(id, { include_drafts: true })`.
- * Every other caller stays on the default exclude path.
+ * emitters that assume `byCve()` returns curated data would treat the
+ * draft's placeholders as authoritative. The cve-curation flow (which
+ * surfaces the editorial questionnaire) opts in via
+ * `byCve(id, { include_drafts: true })`; every other caller stays on the
+ * default exclude path.
  */
 function byCve(cveId, opts) {
   const includeDrafts = !!(opts && opts.include_drafts);

package/lib/cve-curation.js

@@ -76,7 +76,7 @@ function loadCveEntrySchema() {
   }
 }
 
-// J7: lazy-loaded module-level catalog cache. The ATLAS / ATT&CK / CWE /
+// Lazy-loaded module-level catalog cache. The ATLAS / ATT&CK / CWE /
 // framework-control-gaps catalogs don't change inside a single CLI process,
 // so re-reading them per `curate()` call is wasted I/O. Cache once per
 // process; batch-curate paths (future) get the speedup for free.
@@ -87,7 +87,7 @@ function loadJsonRaw(absPath) {
   catch { return null; }
 }
 
-// J4: resolve a catalog path that may be absolute (operator passed
+// Resolve a catalog path that may be absolute (operator passed
 // `--catalog C:\tmp\cat.json` or `/tmp/cat.json`) or repo-relative. Plain
 // `path.join(ROOT, abs)` mishandles absolute paths on Windows.
 function resolveCatalogPath(p) {
@@ -141,11 +141,10 @@ function pickCandidates(draftDigest, catalog, idField, descriptionField) {
   return candidates.slice(0, 5);
 }
 
-// J5: report the actual upstream source on a draft. The previous check
-// only knew about `_source_ghsa_id`; OSV-imported drafts (MAL-*, SNYK-*,
-// RUSTSEC-*, etc. that land via lib/source-osv.js) carry `_source_osv_id`
-// and were always tagged "unknown". Add a registry so future sources are
-// a one-line addition.
+// Report the actual upstream source on a draft. A check that only knows
+// about `_source_ghsa_id` would tag every OSV-imported draft (MAL-*,
+// SNYK-*, RUSTSEC-*, etc. that land via lib/source-osv.js) as "unknown".
+// The registry makes future sources a one-line addition.
 const SOURCE_FIELDS = [
   { field: "_source_ghsa_id", label: "GHSA" },
   { field: "_source_osv_id", label: "OSV" },
@@ -161,9 +160,9 @@ function autoImportedFrom(draft) {
   return "unknown";
 }
 
-// J3: severity word. cvss_score: null no longer collapses to "low" (which
-// is wrong + misleading on a draft that has not been scored yet). Use
-// "unrated" so operators can grep for unsevered drafts and the curate
+// Severity word. cvss_score: null returns "unrated" — collapsing it to
+// "low" would be wrong + misleading on a draft that has not been scored
+// yet. "unrated" lets operators grep for unscored drafts and the curate
 // summary reflects the actual state.
 function severityWord(score) {
   if (typeof score !== "number" || Number.isNaN(score)) return "unrated";
@@ -173,7 +172,7 @@ function severityWord(score) {
   return "low";
 }
 
-// J2: the fields the strict CVE schema requires. Used to (a) extend the
+// The fields the strict CVE schema requires. Used to (a) extend the
 // questionnaire so the operator is prompted for every blocking gap, and
 // (b) compute `residual_warnings` after an apply.
 const REQUIRED_SCHEMA_FIELDS = [
@@ -300,10 +299,10 @@ function buildQuestionnaire(cveId, draft) {
   // specific ASK to surface what the reviewer needs to decide.
   const questions = [];
 
-  // J6: pre-filled empty containers (`iocs: {}`, `atlas_refs: []`) used to
-  // be treated as "answered" because `if (!draft.iocs)` is truthy for {}.
-  // Use explicit emptiness checks so drafts seeded with empty objects /
-  // arrays still get the prompt.
+  // Pre-filled empty containers (`iocs: {}`, `atlas_refs: []`) must NOT
+  // be treated as "answered". `if (!draft.iocs)` is truthy for {}, which
+  // would skip the prompt. Use explicit emptiness checks so drafts
+  // seeded with empty objects / arrays still get the prompt.
   const arrEmpty = (a) => !Array.isArray(a) || a.length === 0;
   const objEmpty = (o) => !o || typeof o !== "object" || Object.keys(o).length === 0;
 
@@ -380,9 +379,9 @@ function buildQuestionnaire(cveId, draft) {
     });
   }
 
-  // J2: schema-required field prompts. Without these populated, the apply
-  // path cannot produce a schema-passing entry — i.e. the entry stays a
-  // draft even after curate --apply. Prompt for them explicitly so the
+  // Schema-required field prompts. Without these populated, the apply
+  // path cannot produce a schema-passing entry — the entry stays a draft
+  // even after curate --apply. Prompt for them explicitly so the
   // operator sees what's actually blocking promotion.
   if (draft.cvss_score === null || draft.cvss_score === undefined
       || draft.cvss_vector === null || draft.cvss_vector === undefined
@@ -460,7 +459,7 @@ function buildQuestionnaire(cveId, draft) {
 }
 
 /**
- * J1: apply operator-supplied answers to a draft and write back atomically.
+ * Apply operator-supplied answers to a draft and write back atomically.
  *
  * Answers shape (each key optional; missing keys leave the draft unchanged
  * for that field):

package/lib/exit-codes.js

@@ -0,0 +1,72 @@
+'use strict';
+
+/**
+ * Canonical exit-code constants for every CLI verb.
+ *
+ * Every `process.exitCode = N` / `process.exit(N)` site in `bin/exceptd.js`
+ * (and any library that wants to set an exit code via emit() ok:false bodies)
+ * should reference one of these constants rather than a bare number literal.
+ * The map is the source of truth for help text — `exceptd doctor --exit-codes`
+ * dumps it as JSON so operator-facing docs cannot drift from runtime.
+ *
+ * History: prior to v0.12.24 codes were bare magic numbers scattered across
+ * ~30 sites. Code 3 in particular meant both "session-id collision" (cmdRun)
+ * and "ran-but-no-evidence" (cmdCi) — two semantics, one code, no doc surface.
+ * v0.12.24 splits them and centralises so a new verb cannot regress by typo.
+ */
+
+const EXIT_CODES = Object.freeze({
+  SUCCESS: 0,
+  GENERIC_FAILURE: 1,
+  DETECTED_ESCALATE: 2,
+  RAN_NO_EVIDENCE: 3,
+  BLOCKED: 4,
+  JURISDICTION_CLOCK_STARTED: 5,
+  TAMPERED: 6,
+  SESSION_ID_COLLISION: 7,
+  LOCK_CONTENTION: 8,
+  STORAGE_EXHAUSTED: 9,
+});
+
+/**
+ * Human-readable + machine-stable description per code. Source for the
+ * `exceptd doctor --exit-codes` dump and for help-text rendering.
+ */
+const EXIT_CODE_DESCRIPTIONS = Object.freeze({
+  0: { name: 'SUCCESS', summary: 'Verb completed successfully.' },
+  1: { name: 'GENERIC_FAILURE', summary: 'Unhandled error or validation failure.' },
+  2: { name: 'DETECTED_ESCALATE', summary: 'CI gate: classification === detected, operator action required.' },
+  3: { name: 'RAN_NO_EVIDENCE', summary: 'CI gate: verb ran but produced no actionable evidence.' },
+  4: { name: 'BLOCKED', summary: 'CI gate: ok:false body — precondition refusal or hard error.' },
+  5: { name: 'JURISDICTION_CLOCK_STARTED', summary: 'Jurisdictional notification window opened (e.g. NIS2 24h, DORA 4h, GDPR 72h).' },
+  6: { name: 'TAMPERED', summary: 'Attestation sidecar verification failed (signed-but-invalid, corrupt, unsigned-substitution, algorithm-unsupported).' },
+  7: { name: 'SESSION_ID_COLLISION', summary: 'Persisting attestation would overwrite an existing session; pass --force-overwrite to replace or supply a fresh --session-id.' },
+  8: { name: 'LOCK_CONTENTION', summary: 'Concurrent invocation holds the per-playbook attestation lock; retry after the busy run releases.' },
+  9: { name: 'STORAGE_EXHAUSTED', summary: 'Disk full, quota exceeded, or read-only filesystem prevented attestation write (ENOSPC, EDQUOT, EROFS).' },
+});
+
+/**
+ * Return the human-readable name for a numeric exit code.
+ */
+function exitCodeName(code) {
+  const e = EXIT_CODE_DESCRIPTIONS[code];
+  return e ? e.name : 'UNKNOWN';
+}
+
+/**
+ * Return all exit codes as a stable-shape array suitable for JSON dump.
+ */
+function listExitCodes() {
+  return Object.entries(EXIT_CODE_DESCRIPTIONS).map(([code, info]) => ({
+    code: Number(code),
+    name: info.name,
+    summary: info.summary,
+  }));
+}
+
+module.exports = {
+  EXIT_CODES,
+  EXIT_CODE_DESCRIPTIONS,
+  exitCodeName,
+  listExitCodes,
+};