@blamejs/exceptd-skills 0.14.28 → 0.15.1

package/skills/mlops-security/skill.md

@@ -62,7 +62,7 @@ forward_watch:
   - EU AI Act high-risk technical-file implementing acts (2026-2027) — operational requirements for Article 10 / 13 / 15 documentation may pin ML-BOM or model-signing
   - MITRE ATLAS v5.6.0 (released May 2026) shipped the AML.T0010 sub-technique expansion this forecast tracked plus new techniques ("Publish Poisoned AI Agent Tool", "Escape to Host"); inventory now 16 tactics, 84 techniques, 56 sub-techniques. Forward watch: subsequent ATLAS minor and major releases — track next-cadence updates to agentic-AI TTPs and MLOps-pipeline-specific techniques
 last_threat_review: "2026-05-22"
-discovery_mode: "standalone"  # v0.13.2: operator-reached via `exceptd brief mlops-security` or `exceptd ask`; not chained into any playbook's direct.skill_chain by design
+discovery_mode: "standalone"  # operator-reached via `exceptd brief mlops-security` or `exceptd ask`; not chained into any playbook's direct.skill_chain by design
 ---
 
 # MLOps Pipeline Security Assessment
@@ -136,7 +136,7 @@ Cross-walk to CWE (see `data/cwe-catalog.json`):
 
 ## Exploit Availability Matrix
 
-Sourced from `data/cve-catalog.json`, public incident history, and `data/atlas-ttps.json` real-world-instances as of 2026-05-11. Per AGENTS.md hard rule #1, CVE references include CVSS, KEV, PoC, AI-discovery, exploitation, and patch availability. Technique-class rows are scored as ongoing class risks per AGENTS.md hard rule #3 — RWEP is not assigned because the field is defined for individual CVEs in `data/cve-catalog.json`.
+Sourced from `data/cve-catalog.json`, public incident history, and `data/atlas-ttps.json` real-world-instances as of 2026-05-11. Every CVE reference includes CVSS, KEV, PoC, AI-discovery, exploitation, and patch availability (no theoretical-only intel). Technique-class rows are scored as ongoing class risks; CVSS is reported alongside RWEP for compatibility but is never the prioritization signal — RWEP is not assigned because the field is defined for individual CVEs in `data/cve-catalog.json`.
 
 | Incident / Class | CVSS | PoC Public? | CISA KEV? | AI-Accelerated? | Patch / Mitigation | SLSA-Detectable? | ML-BOM-Detectable? |
 |---|---|---|---|---|---|---|---|
@@ -298,7 +298,7 @@ A genuinely conformant MLOps program answers all four with concrete artifacts: a
 
 ## Defensive Countermeasure Mapping
 
-D3FEND techniques referenced (see `data/d3fend-catalog.json`). Each is annotated with defense-in-depth layer position, least-privilege scope, zero-trust posture, and AI-pipeline applicability per AGENTS.md hard rule #9.
+D3FEND techniques referenced (see `data/d3fend-catalog.json`). Each is annotated with defense-in-depth layer position, least-privilege scope, zero-trust posture, and AI-pipeline applicability (some controls are architecturally impossible in ephemeral / serverless contexts).
 
 - **D3-EHB (Executable Hash-based Allowlist)** — Hash-pinned allowlist for model artifacts at load time. Maps to model-weight SHA-256 verification at inference-service load, and to in-toto / SLSA-style attestation enforcement at deployment. Defense-in-depth layer: runtime model-load. Least-privilege scope: serving service has read-only access to a pinned set of model hashes for its project, no read on other models. Zero-trust posture: default-deny on any model hash not in the allowlist. AI-pipeline applicability: persistent registries store the allowlist; ephemeral serving pods pull and verify on each model-load.
 
@@ -306,7 +306,7 @@ D3FEND techniques referenced (see `data/d3fend-catalog.json`). Each is annotated
 
 - **D3-IOPR (Input/Output Profiling)** — Profiling of input and output payloads at inference services to detect adversarial inputs (AML.T0043) and model-probing patterns (AML.T0017). Defense-in-depth layer: serving-layer pre- and post-inference. Least-privilege scope: profiling service has read-only access to inference traffic at the serving proxy; no model-load privileges, no registry-write privileges. Zero-trust posture: every inference request is profiled regardless of source authentication — authenticated users execute AML.T0043 attacks too. AI-pipeline applicability: serves both ephemeral inference pods (profiling sidecar) and persistent monitoring services (drift-detection pipeline ingesting profiled telemetry).
 
-Per AGENTS.md hard rule #9, MLOps stacks span three architectural layers each requiring an explicit defense story:
+MLOps stacks span three architectural layers, each requiring an explicit defense story (and each surfacing controls that are architecturally impossible in ephemeral environments):
 
 - **Ephemeral training jobs** — per-run pods on Kubeflow / Vertex / SageMaker / Ray. SLSA-style training-run attestation is the integrity anchor; D3-EAL on the training container is the runtime control. Live patching is not applicable — runs are torn down post-training.
 - **Persistent model registries** — MLflow Model Registry, SageMaker Model Registry, Vertex Model Registry, Azure ML registry, Hugging Face Hub private orgs. RBAC is the access-layer control; signature attestation on every write is the integrity control. Standard server-hardening + patch-SLA applies.
@@ -328,4 +328,4 @@ After producing the MLOps pipeline security assessment, chain into the following
 - **`ai-risk-management`** — governance overlay (ISO 42001, ISO 23894, NIST AI RMF). Where this skill identifies a framework gap, the governance overlay translates findings into the management-system documentation, AI impact assessment, and high-risk AI classification work products.
 - **`coordinated-vuln-disclosure`** — AI vulnerability intake. Where this skill surfaces a vendor vulnerability (MLflow class, framework class, MCP server class), or where research surfaces a novel poisoning pattern requiring coordinated disclosure, chain into the CVD skill for the ISO 29147 / 30111 / CSAF 2.0 publication workflow.
 
-For ephemeral / serverless MLOps pipelines (per AGENTS.md hard rule #9): training-run lineage attestation in environments where the training pod is torn down before the registry write completes requires that the attestation is emitted from inside the training run and pushed to the registry as a registry-side artifact (OCI referrers API or in-toto bundle attached to the model entry). Live patching of in-flight training runs is architecturally impossible — the scoped alternative is roll-forward (kill the run, re-run from a signed training-script revision) plus post-hoc attestation-chain audit.
+For ephemeral / serverless MLOps pipelines (where some controls are architecturally impossible): training-run lineage attestation in environments where the training pod is torn down before the registry write completes requires that the attestation is emitted from inside the training run and pushed to the registry as a registry-side artifact (OCI referrers API or in-toto bundle attached to the model entry). Live patching of in-flight training runs is architecturally impossible — the scoped alternative is roll-forward (kill the run, re-run from a signed training-script revision) plus post-hoc attestation-chain audit.

package/skills/ot-ics-security/skill.md

@@ -44,7 +44,7 @@ cwe_refs:
   - CWE-1037
 d3fend_refs: []
 last_threat_review: "2026-05-11"
-discovery_mode: "standalone"  # v0.13.2: operator-reached via `exceptd brief ot-ics-security` or `exceptd ask`; not chained into any playbook's direct.skill_chain by design
+discovery_mode: "standalone"  # operator-reached via `exceptd brief ot-ics-security` or `exceptd ask`; not chained into any playbook's direct.skill_chain by design
 ---
 
 # OT / ICS Security (mid-2026)
@@ -61,7 +61,7 @@ OT is no longer air-gapped. The "air gap" is a label on a Visio file, not a prop
 
 **State-sponsored OT targeting is continuous, not episodic.** Volt Typhoon pre-positioning against US critical infrastructure (water, energy, transport) was confirmed by CISA/NSA/FBI in 2023–2024 and re-affirmed in 2025 joint advisories. Sandworm continues active operations against Ukrainian grid through 2025 (Industroyer2, Pipedream/Incontroller-derived tooling, and bespoke OT-aware wipers). 2025 saw the first publicly attributed AI-assisted OT reconnaissance campaign — adversaries using LLMs to triage exfiltrated engineering documents at scale.
 
-**The exemption posture inverts vs. AGENTS.md rule #9.** Hard Rule #9 is about ephemeral and AI-pipeline environments where some controls are architecturally impossible. OT is the opposite: OT systems are LONG-LIVED, often 10–30 year service lives. PLCs in service today were commissioned when Windows XP was current; HMIs running Windows 7 are routine; safety-instrumented systems (SIS) are deliberately frozen. The exemption that applies is reversed: "patch within 30 days" is architecturally impossible not because the workload is ephemeral but because the workload is fossilised, change-controlled, and physically dangerous to disturb. Recommendations must explicitly acknowledge multi-decade lifecycles and provide compensating-control paths (segmentation, allowlisting, unidirectional gateways, virtual patching at the L2/L3 boundary) rather than handwave "update the firmware."
+**The exemption posture inverts vs. the ephemeral / AI-pipeline case.** The usual architectural-impossibility exemption is about ephemeral and AI-pipeline environments where some controls cannot run. OT is the opposite: OT systems are LONG-LIVED, often 10–30 year service lives. PLCs in service today were commissioned when Windows XP was current; HMIs running Windows 7 are routine; safety-instrumented systems (SIS) are deliberately frozen. The exemption that applies is reversed: "patch within 30 days" is architecturally impossible not because the workload is ephemeral but because the workload is fossilised, change-controlled, and physically dangerous to disturb. Recommendations must explicitly acknowledge multi-decade lifecycles and provide compensating-control paths (segmentation, allowlisting, unidirectional gateways, virtual patching at the L2/L3 boundary) rather than handwave "update the firmware."
 
 ---
 
@@ -82,7 +82,7 @@ OT is no longer air-gapped. The "air gap" is a label on a Visio file, not a prop
 | TW CSMA (Cyber Security Management Act) | National critical-infrastructure cyber-security management | TW critical infrastructure including semicon fabs and energy | Strong on segmentation and reporting; AI-assistant integration into operator workflows not specifically scoped. |
 | ISO 27001:2022 + ISO/IEC 27019 (energy utilities) | Generic ISMS + energy-sector extension | Organisation-level ISMS | A.8.8 vulnerability management is IT-flavoured; ISO/IEC 27019 adds energy specifics but predates AI-augmented HMI. |
 
-**Cross-jurisdiction posture (per AGENTS.md rule #5):** Any OT/ICS gap analysis for a multi-jurisdiction operator must cite at minimum EU NIS2 + DORA + CRA, UK NIS+CAF, AU SOCI+AESCSF, JP NISC, IL INCD, ID BSSN, TW CSMA, alongside ISO 27001:2022 + ISO/IEC 27019. US-only (NIST 800-82r3, NERC CIP) is insufficient for any operator with multinational exposure.
+**Cross-jurisdiction posture (global-first, not US-centric):** Any OT/ICS gap analysis for a multi-jurisdiction operator must cite at minimum EU NIS2 + DORA + CRA, UK NIS+CAF, AU SOCI+AESCSF, JP NISC, IL INCD, ID BSSN, TW CSMA, alongside ISO 27001:2022 + ISO/IEC 27019. US-only (NIST 800-82r3, NERC CIP) is insufficient for any operator with multinational exposure.
 
 ---
 
@@ -117,13 +117,13 @@ ATT&CK for ICS is a separate matrix from Enterprise. Many IT-rooted SOCs do not
 | Vendor-side OT CVEs (Siemens, Rockwell, Schneider, ABB, GE Vernova) | varies | varies | Several KEV listings 2024–2026 | Mixed — vendor disclosures only sometimes accompanied by PoC | Increasing AI-assisted RE | Targeted exploitation by Sandworm-aligned and Volt Typhoon-aligned actors | Vendor-dependent — typical lag 60–180 days; deploy lag 1–5 years | No — firmware updates require change windows | ICS-aware IDS (Claroty, Nozomi, Dragos, Tenable OT) detection signature lag varies |
 | AI-HMI prompt injection (no CVE-class yet) | n/a | risk-modelled, not CVSS | n/a | Demonstrated in research and 2025 incident-response engagements | n/a (vector is the AI conduit itself) | Suspected in 2025 advanced campaigns | Mitigation only — design-time controls on the AI integration | n/a | Requires LLM-aware telemetry — almost never present |
 
-**Honest gap statement (per AGENTS.md rule #10).** This project's `data/cve-catalog.json` does not yet contain an exhaustive inventory of vendor-side OT CVEs (Siemens SSAs, Rockwell SD advisories, Schneider Electric Security Notifications, ABB CSAs, GE Vernova advisories). The authoritative source for current OT/ICS CVEs is the CISA ICS-CERT advisory feed at https://www.cisa.gov/news-events/cybersecurity-advisories/ics-advisories — captured in `forward_watch` for inclusion in the catalog as part of the next data refresh. Do not invent CVE IDs to fill this matrix.
+**Honest gap statement (declare what the catalog does not yet cover).** This project's `data/cve-catalog.json` does not yet contain an exhaustive inventory of vendor-side OT CVEs (Siemens SSAs, Rockwell SD advisories, Schneider Electric Security Notifications, ABB CSAs, GE Vernova advisories). The authoritative source for current OT/ICS CVEs is the CISA ICS-CERT advisory feed at https://www.cisa.gov/news-events/cybersecurity-advisories/ics-advisories — captured in `forward_watch` for inclusion in the catalog as part of the next data refresh. Do not invent CVE IDs to fill this matrix.
 
 ---
 
 ## Analysis Procedure
 
-This procedure threads the three foundational design principles required by AGENTS.md skill-format spec (defense in depth, least privilege, zero trust) through every step.
+This procedure threads the three foundational design principles (defense in depth, least privilege, zero trust) through every step.
 
 **Defense in depth.** Purdue Enterprise Reference Architecture layers (L0 physical I/O → L1 PLC/RTU/BPCS → L2 SCADA/HMI → L3 site operations/MES → L3.5 IDMZ → L4 enterprise → L5 cloud/enterprise edge). Controls required at every layer, with the IDMZ (L3.5) acting as the policy-enforcement boundary between OT and IT. Network segmentation (D3-NI), unidirectional gateways for OT→IT data egress, ICS-aware IDS at L2/L3 boundary (D3-NTA), signed-firmware enforcement at L1 where vendor supports it, executable allowlisting (D3-EAL) on engineering workstations and HMI hosts.
 
@@ -311,7 +311,7 @@ Ask: "Show me the SOCI / NIS2 / NERC CIP / CAF evidence for OT asset inventory,
 
 ## Defensive Countermeasure Mapping
 
-Per AGENTS.md optional 8th section (required for skills shipped on or after 2026-05-11). Maps OT/ICS offensive findings to MITRE D3FEND IDs from `data/d3fend-catalog.json`, with explicit defense-in-depth layer position, least-privilege scope, zero-trust posture, and the inverted ephemeral/AI-pipeline applicability per Hard Rule #9.
+Maps OT/ICS offensive findings to MITRE D3FEND IDs from `data/d3fend-catalog.json`, with explicit defense-in-depth layer position, least-privilege scope, zero-trust posture, and the inverted ephemeral/AI-pipeline applicability (long-lived OT inverts the usual architectural-impossibility exemption).
 
 | D3FEND ID | Technique | Purdue Layer Position | Least-Privilege Scope | Zero-Trust Posture | OT-Realistic Applicability |
 |---|---|---|---|---|---|
@@ -321,7 +321,7 @@ Per AGENTS.md optional 8th section (required for skills shipped on or after 2026
 | D3-EAL | Executable Allowlisting | L2 HMI hosts; L2 engineering workstations; L3 historian/MES hosts | Per-host allowlist of signed executables; vendor-tooling exceptions explicit | Default-deny execution; only enumerated binaries run | Applicable to Windows/Linux HMI and engineering workstation hosts. Cannot apply directly to L1 PLC/RTU devices — for those, signed-firmware enforcement (where vendor supports) is the analogue. |
 | D3-PSEP | Process Segment Execution Prevention | L2 HMI hosts; L2 engineering workstations | Per-process memory-execution policy; non-exec data segments | Memory regions and process behaviour continuously verified at execution time | Applicable where host OS supports modern memory protections. Brownfield Windows 7 / WinCC older versions have weaker support — compensating control: tighter D3-EAL + D3-NTA. |
 
-**Inverted ephemerality posture (per Hard Rule #9, reversed).** OT assets are long-lived (10–30 year service lives). Controls that assume rapid patching are unrealistic; controls that assume rebuild-on-change are catastrophic. The OT-appropriate posture: virtual patching at L3.5 / L2 boundaries, executable allowlisting on hosts that cannot be re-imaged, ICS-IDS detection as the primary control where prevention is architecturally unavailable, signed-firmware enforcement where supported, and explicit documentation of multi-decade compensating-control programmes where the device itself cannot be hardened. Recommendations that read "patch the PLC firmware" without specifying the change window, the vendor's signed-firmware support status, and the rollback plan are operationally indefensible.
+**Inverted ephemerality posture (the usual architectural-impossibility exemption, reversed).** OT assets are long-lived (10–30 year service lives). Controls that assume rapid patching are unrealistic; controls that assume rebuild-on-change are catastrophic. The OT-appropriate posture: virtual patching at L3.5 / L2 boundaries, executable allowlisting on hosts that cannot be re-imaged, ICS-IDS detection as the primary control where prevention is architecturally unavailable, signed-firmware enforcement where supported, and explicit documentation of multi-decade compensating-control programmes where the device itself cannot be hardened. Recommendations that read "patch the PLC firmware" without specifying the change window, the vendor's signed-firmware support status, and the rollback plan are operationally indefensible.
 
 ---
 

package/skills/policy-exception-gen/skill.md

@@ -99,7 +99,7 @@ A granted exception does not remove the threat — it shifts the burden onto com
 | Exception 3 — Zero Trust Architecture Network Segmentation | T1021 (Remote Services), T1570 (Lateral Tool Transfer), T1078 (Valid Accounts), T1199 (Trusted Relationship) | Workload identity (SPIFFE/SPIRE), per-request mTLS, device-posture verification, east-west behavioral analytics |
 | Exception 4 — Critical Systems No-Reboot Kernel Patching | T1068 (Exploitation for Privilege Escalation — Copy Fail class), T1548.001 (Setuid and Setgid), T1611 (Escape to Host) | Live kernel patch deployed and verified (`kpatch list` / `canonical-livepatch status`), eBPF/auditd exploitation-pattern rules, network-layer isolation if no live patch available, scheduled reboot window |
 
-The TTP source-of-truth is `data/atlas-ttps.json` (MITRE ATLAS v5.6.0, May 2026) supplemented by ATT&CK Enterprise. Per Hard Rule #4, no exception in this skill is granted without an enumerated residual-TTP set; an exception with no listed residual is theater.
+The TTP source-of-truth is `data/atlas-ttps.json` (MITRE ATLAS v5.6.0, May 2026) supplemented by ATT&CK Enterprise. No orphaned controls: no exception in this skill is granted without an enumerated residual-TTP set; an exception with no listed residual is theater.
 
 ---
 
@@ -475,4 +475,4 @@ Every defensible exception names the residual TTPs in scope and the compensating
 
 **Zero-trust posture:** the exception is defensible only when the cited D3FEND techniques are deployed, monitored, and tested against the residual TTPs at exception-grant time and re-verified at the documented review cadence. An exception with deployed techniques but no test evidence (chaos-engineering exercise, red-team result, detection-rule firing on a controlled trigger) is unverified. The "Review Cadence" field in the Output Format must specify the re-verification test, not just the calendar date.
 
-**AI-pipeline applicability (per AGENTS.md Hard Rule #9):** for AI Pipeline Change Management exceptions, `D3-EAL` and `D3-EFA` do not apply to serverless inference endpoints — the scoped alternative is `D3-CSPP` at the inference gateway plus provider-signed-image attestation in the model-card. `D3-FAPA` on ephemeral RAG indices degrades to per-query retrieval logging via `D3-IOPR` plus index-build provenance signed at construction. These degradations must be enumerated in the exception's "Compensating Controls" field; an AI-pipeline exception that copies a non-AI exception template is incomplete.
+**AI-pipeline applicability (some controls are architecturally impossible in serverless / ephemeral contexts):** for AI Pipeline Change Management exceptions, `D3-EAL` and `D3-EFA` do not apply to serverless inference endpoints — the scoped alternative is `D3-CSPP` at the inference gateway plus provider-signed-image attestation in the model-card. `D3-FAPA` on ephemeral RAG indices degrades to per-query retrieval logging via `D3-IOPR` plus index-build provenance signed at construction. These degradations must be enumerated in the exception's "Compensating Controls" field; an AI-pipeline exception that copies a non-AI exception template is incomplete.

package/skills/pqc-first/skill.md

@@ -123,7 +123,7 @@ Sovereign-cyber programs outside the EU/UK/AU/ISO axis are producing the most co
 - **Brazil (LGPD + ANPD):** ANPD has signalled that "state-of-the-art" technical measures under LGPD Art. 46 will include PQC consideration for long-sensitivity-window data; no hard mandate yet.
 - **US sub-national — NYDFS 23 NYCRR 500.15:** Encryption-of-nonpublic-information requirement is algorithm-agnostic but recently amended (Nov 2023) to require periodic CISO review of cryptographic controls — operationally this is the hook for PQC inclusion in covered entities' annual review cycles, ahead of any federal mandate beyond CNSA 2.0.
 
-PQC migration is the clearest example of the project's hard rule #5 (global-first): the lag is not uniformly distributed — INCD, KISA, and BSI/ANSSI guidance leads, while many compliance-framework controls still treat algorithm choice as ungoverned.
+PQC migration is the clearest example of why a global-first lens matters: the lag is not uniformly distributed — INCD, KISA, and BSI/ANSSI guidance leads, while many compliance-framework controls still treat algorithm choice as ungoverned.
 
 ### IETF Tracking — The IETF Lag IS the Framework Lag for PQC
 
@@ -562,7 +562,7 @@ D3FEND references from `data/d3fend-catalog.json`. The harvest-now-decrypt-later
 
 **Zero-trust posture:** every session negotiates PQC-hybrid key exchange regardless of network trust level — there is no "internal traffic is safe from HNDL" exemption, because a passive collector on an internal span harvests ciphertext as readily as one on the public path. Confidentiality is asserted per-session at the crypto layer, not inferred from network position.
 
-**AI-pipeline applicability (per AGENTS.md Hard Rule #9):** `D3-FE` applies to model-weight files, training datasets, and embedding stores at rest; for ephemeral inference workloads that never persist state locally, the control shifts to PQC-hybrid-wrapped object storage (e.g. SSE-KMS with an ML-KEM-based envelope) rather than local-disk encryption. `D3-MENCR` applies to all AI-API traffic, which must move to TLS 1.3 with hybrid key exchange on the CNSA 2.0 timeline — noting that PQC protects the confidentiality of that traffic but not its content-layer abuse as a covert channel (pair with the AI-C2 egress controls in `ai-c2-detection`).
+**AI-pipeline applicability (some controls shift when workloads are ephemeral and never persist state):** `D3-FE` applies to model-weight files, training datasets, and embedding stores at rest; for ephemeral inference workloads that never persist state locally, the control shifts to PQC-hybrid-wrapped object storage (e.g. SSE-KMS with an ML-KEM-based envelope) rather than local-disk encryption. `D3-MENCR` applies to all AI-API traffic, which must move to TLS 1.3 with hybrid key exchange on the CNSA 2.0 timeline — noting that PQC protects the confidentiality of that traffic but not its content-layer abuse as a covert channel (pair with the AI-C2 egress controls in `ai-c2-detection`).
 
 ---
 

package/skills/rag-pipeline-security/skill.md

@@ -302,7 +302,7 @@ After producing the RAG pipeline security assessment, the operator should chain
 - **`ai-attack-surface`** — RAG is one component of the broader AI-application threat model. Chain into the AI attack surface skill to situate the RAG findings within the surrounding LLM, tool-use, and prompt-handling threat surfaces (especially when Attack Class 5 indirect prompt injection findings extend into agent tool-call behaviour).
 - **`attack-surface-pentest`** — RAG corpora and embedding-store APIs (Pinecone, Weaviate, Qdrant, pgvector, Chroma management endpoints) must be enumerated in pen-test scope. The architectural-control mitigations above are only verifiable through adversarial exercise; without pen-test coverage, the Step 3 posture score is self-reported.
 
-For ephemeral / serverless RAG pipelines (per AGENTS.md rule #9): embedding-distribution-shift monitoring across rolling deployments where the vector store is rebuilt per request is architecturally impossible. The scoped alternative is per-ingestion-event content scanning and provenance attestation, with the distribution-shift signal computed off-line against a sampled snapshot rather than the live store.
+For ephemeral / serverless RAG pipelines (where some controls are architecturally impossible): embedding-distribution-shift monitoring across rolling deployments where the vector store is rebuilt per request is architecturally impossible. The scoped alternative is per-ingestion-event content scanning and provenance attestation, with the distribution-shift signal computed off-line against a sampled snapshot rather than the live store.
 
 ---
 
@@ -324,7 +324,7 @@ D3FEND v1.3.0+ references from `data/d3fend-catalog.json`. The five RAG attack c
 
 **Zero-trust posture:** every retrieved chunk is treated as untrusted content. `D3-CSPP` inspects the composed prompt as if the retrieved context came from a hostile source — because under Attack Class 5, it did. No "internal document is trusted" exemption — internal documents are the documented vector for indirect prompt injection that survives external-content filters.
 
-**AI-pipeline applicability (per AGENTS.md Hard Rule #9):** `D3-FAPA` on ephemeral, per-query rebuilt indices degrades to per-query retrieval logging (`D3-IOPR` captures the query + result set) because there is no persistent corpus to baseline against. The scoped alternative is build-time provenance (signed index manifest at construction) combined with query-time `D3-IOPR` capture of the query+result-set tuple — equivalent observation surface, different anchoring.
+**AI-pipeline applicability (some controls are architecturally impossible on ephemeral, per-query rebuilt indices):** `D3-FAPA` on ephemeral, per-query rebuilt indices degrades to per-query retrieval logging (`D3-IOPR` captures the query + result set) because there is no persistent corpus to baseline against. The scoped alternative is build-time provenance (signed index manifest at construction) combined with query-time `D3-IOPR` capture of the query+result-set tuple — equivalent observation surface, different anchoring.
 
 ---
 

package/skills/ransomware-response/skill.md

@@ -129,7 +129,7 @@ Cross-cutting gap: **no security framework treats the four ransomware-specific d
 
 Shadow Copy deletion and exfil-staging via Web Service align to the parent IR playbook's `T1486` and `T1567` entries; the parent's `AML.T0096 / T0017 / T0051` entries do not apply to ransomware-as-a-class but may apply if AI-system data is exfiltrated within the ransomware operation.
 
-ATLAS pinned to v5.6.0 (May 2026) per AGENTS.md rule #12. ATT&CK pinned to v19.0 (April 2026) per the same rule.
+ATLAS pinned to v5.6.0 (May 2026). ATT&CK pinned to v19.0 (April 2026). Both are explicit version pins — never silently upgraded.
 
 ---
 
@@ -155,7 +155,7 @@ Detection-tool maturity for ransomware mid-2026:
 
 ## Analysis Procedure
 
-Apply the three foundational design principles per AGENTS.md Skill File Format requirements, then walk the ransomware-specific decision tree on top of the parent IR playbook's PICERL frame.
+Apply the three foundational design principles (defense in depth, least privilege, zero trust), then walk the ransomware-specific decision tree on top of the parent IR playbook's PICERL frame.
 
 **Defense in depth — ransomware-specific layer stack.** The parent IR playbook defines the IR layer stack (Preparation, Identification, Containment, Eradication-Recovery, Lessons). Ransomware response adds five sub-properties:
 
@@ -209,9 +209,9 @@ Execute the determined recovery path: restore from immutable backup (if Step 5 p
 
 ### Step 10 — Post-incident learning + framework-gap filing
 
-Per the parent IR playbook Step 9 + AGENTS.md DR-8: file `data/zeroday-lessons.json` entry if a new initial-access vector or family pattern was observed; file `data/framework-control-gaps.json` entries for any of the four ransomware-specific decision properties that failed to operationalize; trigger `framework-gap-analysis` for the control-class gap; schedule a ransomware-specific tabletop exercise within 90 days with sanctions-screening + decryptor-lookup + carrier-notification + immutable-backup viability as exercise injects.
+Per the parent IR playbook Step 9, run the zero-day learning loop: file a `data/zeroday-lessons.json` entry if a new initial-access vector or family pattern was observed; file `data/framework-control-gaps.json` entries for any of the four ransomware-specific decision properties that failed to operationalize; trigger `framework-gap-analysis` for the control-class gap; schedule a ransomware-specific tabletop exercise within 90 days with sanctions-screening + decryptor-lookup + carrier-notification + immutable-backup viability as exercise injects.
 
-**Ephemeral / cloud-workload ransomware (per AGENTS.md rule #9):** Ransomware against cloud workloads is increasingly hypervisor-level (ESXi-targeting families: Akira ESXi locker, ALPHV/BlackCat ESXi locker) or cloud-storage-API-driven (mass encryption of S3 / Azure Blob / GCS object storage via compromised admin credentials). Forensic preservation against ephemeral compute follows the parent playbook's recommendation: pre-incident continuous forensic-grade telemetry shipping to immutable store; absent the pre-incident pipeline, post-hoc evidence is limited to whatever shipped before workload termination and immutable object-storage versions.
+**Ephemeral / cloud-workload ransomware (where some controls are architecturally impossible):** Ransomware against cloud workloads is increasingly hypervisor-level (ESXi-targeting families: Akira ESXi locker, ALPHV/BlackCat ESXi locker) or cloud-storage-API-driven (mass encryption of S3 / Azure Blob / GCS object storage via compromised admin credentials). Forensic preservation against ephemeral compute follows the parent playbook's recommendation: pre-incident continuous forensic-grade telemetry shipping to immutable store; absent the pre-incident pipeline, post-hoc evidence is limited to whatever shipped before workload termination and immutable object-storage versions.
 
 ---
 
@@ -336,7 +336,7 @@ A program passing all four tests is operating ransomware response as infrastruct
 
 ## Defensive Countermeasure Mapping
 
-Per AGENTS.md Skill File Format optional 8th section: map this skill's findings to MITRE D3FEND IDs from `data/d3fend-catalog.json` with defense-in-depth layer position, least-privilege scope, zero-trust posture, and AI-pipeline applicability.
+Map this skill's findings to MITRE D3FEND IDs from `data/d3fend-catalog.json` with defense-in-depth layer position, least-privilege scope, zero-trust posture, and AI-pipeline applicability.
 
 Ransomware response consumes defensive controls across multiple D3FEND categories; the four below are the highest-leverage during active ransomware handling. The parent IR playbook covers the broader IR D3FEND cross-walk; this section names the techniques operationally invoked during ransomware response specifically.
 
@@ -347,9 +347,9 @@ Ransomware response consumes defensive controls across multiple D3FEND categorie
 | **D3-IOPR** (Input/Output Profiling) | Limited direct ransomware applicability; relevant when ransomware operation includes AI-system abuse (rare in current ransomware operations but applicable to AI-pipeline data exfiltration). | Identification layer (limited). | Scoped to the IR analyst role. | Default-suspect for prompt-distribution anomalies if AI systems are within scope. | Applies only when AI systems are within the affected scope. |
 | **D3-CSPP** (Client-Server Payload Profiling) | C2 protocol detection — particularly relevant when the C2 channel is HTTPS to a legitimate service (Box / OneDrive / S3 / consumer cloud-storage) used for exfil staging. | Identification layer. | Scoped to detection-engineering and IR analyst roles; payload-content access controlled. | Default-suspect for novel payload shapes against baseline. | Limited. |
 
-**Explicit statement per AGENTS.md rule #4 (no orphaned controls):** each D3FEND technique above maps to one or more TTPs in the TTP Mapping section (T1486 / T1567 / T1078 / T1059). The defensive cross-walk in `defensive-countermeasure-mapping` covers the broader D3FEND ontology; this section names only the techniques operationally invoked during ransomware response.
+**No orphaned controls:** each D3FEND technique above maps to one or more TTPs in the TTP Mapping section (T1486 / T1567 / T1078 / T1059). The defensive cross-walk in `defensive-countermeasure-mapping` covers the broader D3FEND ontology; this section names only the techniques operationally invoked during ransomware response.
 
-**AI-pipeline statement per AGENTS.md rule #9:** Direct AI-pipeline applicability to ransomware response is limited; the parent IR playbook covers AI-class incident response separately. If a ransomware operation includes AI-system data exfiltration, hand off the AI-system-specific containment to the parent IR playbook's AI-class sub-flow.
+**AI-pipeline statement:** Direct AI-pipeline applicability to ransomware response is limited; the parent IR playbook covers AI-class incident response separately. If a ransomware operation includes AI-system data exfiltration, hand off the AI-system-specific containment to the parent IR playbook's AI-class sub-flow.
 
 ---
 
@@ -364,7 +364,7 @@ Ransomware response is a sub-flow of `incident-response-playbook` with ransomwar
 - **`sector-financial`** — *financial-entity trigger.* When the affected entity is a DORA-in-scope financial entity, hand off for the 4h initial notification chain to competent authority + ECB / EIOPA / ESMA; for NYDFS 500.17 the 24h ransom-payment notification (if payment is made and sanctions screening cleared) is routed through this skill.
 - **`framework-gap-analysis`** — *control-gap filing.* When the ransomware response surfaces that one of the four ransomware-specific decision properties (sanctions / decryptor / insurance / immutability / exfil-before-encrypt) failed to operationalize during the incident, file the gap entry against the relevant framework controls (NIST IR-4, ISO A.5.26, SOC 2 CC7.4, HIPAA 164.308(a)(7), AU E8 Backup, UK CAF D1).
 - **`compliance-theater`** — *paper-recovery detection.* The four ransomware-specific theater tests in this skill compose with the broader theater detection across frameworks. Run `compliance-theater` after this skill when the org is claiming SOC 2 / ISO 27001 / NIST CSF maturity that the four ransomware-specific tests contradict.
-- **`zeroday-gap-learn`** — *novel-vector trigger.* When the initial-access vector is a novel CVE or attack class, file the learning-loop entry per AGENTS.md DR-8.
+- **`zeroday-gap-learn`** — *novel-vector trigger.* When the initial-access vector is a novel CVE or attack class, file the learning-loop entry so the lesson lands in the catalog before the change ships.
 - **`coordinated-vuln-disclosure`** — *vendor-coordination trigger.* When the initial-access vector involves an exploited CVE in a third-party product (VPN appliance, management plane, supply-chain component), coordinate with the vendor advisory and downstream notification cascade.
-- **`threat-model-currency`** — *refresh trigger.* The ransomware incident is a real-world signal that the threat model may be stale; trigger refresh per AGENTS.md DR-8.
+- **`threat-model-currency`** — *refresh trigger.* The ransomware incident is a real-world signal that the threat model may be stale; trigger a currency refresh.
 - **`skill-update-loop`** — *meta-loop trigger.* When the incident exposes a gap in this skill (a new family with unfamiliar sanctions posture, a decryptor catalog not yet integrated, a carrier-policy clause not yet rehearsed), trigger the loop.

package/skills/researcher/skill.md

@@ -25,7 +25,7 @@ atlas_refs: []
 attack_refs: []
 framework_gaps: []
 last_threat_review: "2026-05-11"
-discovery_mode: "standalone"  # v0.13.2: operator-reached via `exceptd brief researcher` or `exceptd ask`; not chained into any playbook's direct.skill_chain by design
+discovery_mode: "standalone"  # operator-reached via `exceptd brief researcher` or `exceptd ask`; not chained into any playbook's direct.skill_chain by design
 ---
 
 # Researcher — Threat Intel Triage and Dispatch
@@ -121,7 +121,7 @@ The researcher's job is to PRODUCE this matrix from the local catalogs, not to c
 | Blast radius (affected version range) | `data/cve-catalog.json` |
 | Deterministic exploit (no race)? | `data/cve-catalog.json` |
 
-If the input is not a CVE — for example, an ATLAS TTP, a vendor advisory without a CVE, or an incident narrative — the researcher emits a degenerate matrix: "N/A; this input is not a CVE. Map to ATLAS technique and downstream skill instead." Per AGENTS.md hard rule #1, no fabricated exploit availability data. If the catalog lacks the input, flag it as "not yet in catalog — propose adding" and route to `zeroday-gap-learn` for the catalog update procedure.
+If the input is not a CVE — for example, an ATLAS TTP, a vendor advisory without a CVE, or an incident narrative — the researcher emits a degenerate matrix: "N/A; this input is not a CVE. Map to ATLAS technique and downstream skill instead." No fabricated exploit availability data — theoretical-only intel is refused. If the catalog lacks the input, flag it as "not yet in catalog — propose adding" and route to `zeroday-gap-learn` for the catalog update procedure.
 
 ---
 
@@ -157,7 +157,7 @@ Surface the full entry. Quote field values directly from the catalog. Do not par
 
 ### Step 3 — RWEP scoring
 
-If the input is a CVE present in `data/cve-catalog.json`, the RWEP score is already computed. Surface it. The CVSS score is reported alongside for compatibility per AGENTS.md hard rule #3, never as the primary signal.
+If the input is a CVE present in `data/cve-catalog.json`, the RWEP score is already computed. Surface it. The CVSS score is reported alongside for compatibility (see `lib/scoring.js`), never as the primary signal.
 
 If the input is a CVE not yet in catalog, compute RWEP per `lib/scoring.js` formula and flag the entry for addition to `data/cve-catalog.json`. The formula factors: CISA KEV (0.25), public PoC (0.20), AI-assisted weaponization (0.15), active exploitation (0.20), patch availability (-0.15), live-patch availability (-0.10), blast radius (0.15). Output the RWEP score with the factor breakdown so the operator can audit the score.
 
@@ -169,7 +169,7 @@ For a CVE, perform these joins:
 
 - Related ATLAS TTPs via the `atlas_refs` field on the CVE entry. Pull the technique descriptions from `data/atlas-ttps.json`.
 - Related framework gaps via the `framework_gaps` field on the CVE entry. Pull the full gap rationale from `data/framework-control-gaps.json`.
-- Corresponding zero-day lessons entry in `data/zeroday-lessons.json` (keyed by CVE ID). If present, surface the full attack-vector → control-gap → framework-gap → new-control-requirement chain. If absent, per AGENTS.md hard rule #6, flag that the zero-day learning loop has not yet been run for this CVE and route to `zeroday-gap-learn`.
+- Corresponding zero-day lessons entry in `data/zeroday-lessons.json` (keyed by CVE ID). If present, surface the full attack-vector → control-gap → framework-gap → new-control-requirement chain. If absent, flag that the zero-day learning loop has not yet been run for this CVE and route to `zeroday-gap-learn`.
 - Live exploit availability in `data/exploit-availability.json` (PoC URLs, weaponization status, last_verified date).
 
 For an ATLAS TTP, perform the reverse join: which CVEs in `data/cve-catalog.json` reference this TTP, and which skills declare it in `atlas_refs`.
@@ -178,7 +178,7 @@ For a framework control, perform: which CVEs in `data/cve-catalog.json` referenc
 
 ### Step 5 — Global-jurisdiction surface
 
-Per AGENTS.md hard rule #5, every threat must be evaluated against at least: EU (NIS2, DORA, EU AI Act, EU CRA), UK (NCSC CAF, Cyber Essentials Plus), Australia (ISM, ASD Essential 8, APRA CPS 234), and ISO 27001:2022. Look up the jurisdiction-specific obligations in `data/global-frameworks.json`. Surface:
+Every threat must be evaluated against at least the following jurisdictions (global-first, not US-centric): EU (NIS2, DORA, EU AI Act, EU CRA), UK (NCSC CAF, Cyber Essentials Plus), Australia (ISM, ASD Essential 8, APRA CPS 234), and ISO 27001:2022. Look up the jurisdiction-specific obligations in `data/global-frameworks.json`. Surface:
 
 - EU: which NIS2 / DORA / EU AI Act / EU CRA articles apply, and what notification timelines they impose.
 - UK: which CAF outcome the threat maps to.
@@ -186,7 +186,7 @@ Per AGENTS.md hard rule #5, every threat must be evaluated against at least: EU
 - ISO 27001:2022: which Annex A control IDs are relevant.
 - US (NIST 800-53, NIST AI RMF, NIST CSF 2.0): for completeness, not as the primary jurisdiction.
 
-If the operator's organization operates only in one jurisdiction, surface that jurisdiction first but never omit the others. Per AGENTS.md DR-4, US-only analysis is incomplete.
+If the operator's organization operates only in one jurisdiction, surface that jurisdiction first but never omit the others. US-only analysis is incomplete.
 
 ### Step 6 — Route to specialized skill(s)
 
@@ -241,9 +241,9 @@ Multiple routes are common and expected. A new MCP CVE routes to `mcp-agent-trus
 Several triggers in `manifest.json` legitimately resolve to more than one skill. The researcher does not pick one and discard the other — it emits an ordered dispatch list. The policy:
 
 - **PROMPTSTEAL / PROMPTFLUX** route to BOTH `ai-attack-surface` AND `ai-c2-detection`. This is intentional fan-out, not a collision to resolve. `ai-attack-surface` produces the attack-class analysis (the offensive characterization, the prompt-injection mechanics, the LLM-integration abuse surface per AML.T0051 / AML.T0096); `ai-c2-detection` produces the detection-engineering response (the telemetry signatures, the egress patterns, the SIEM/EDR rule shape). The researcher emits BOTH skills as the answer to a PROMPTSTEAL/PROMPTFLUX query, ordered by the phase of the operator's question — analysis-first if the operator is scoping the threat, detection-first if the operator is hunting active intrusion. Multi-jurisdiction note: PROMPTSTEAL-class C2 over commercial AI APIs implicates EU NIS2 Art. 23 notification, DORA Art. 17 for financial entities, and ICO / CNIL guidance on AI-API data egress under GDPR Art. 32.
-- **"compliance gap"** routes primary to `framework-gap-analysis` (the analytical depth: which control, which version, which jurisdiction, which gap). `compliance-theater` is the natural secondary if the gap analysis reveals the control exists on paper but is structurally inadequate for current TTPs. Researcher emits `framework-gap-analysis` FIRST and recommends `compliance-theater` as the secondary when the operator's framing is "we 'comply' but..." (the scare quotes are the tell). Global-first applies: gap analysis always spans EU + UK + AU + ISO 27001:2022 alongside US references per AGENTS.md hard rule #5.
+- **"compliance gap"** routes primary to `framework-gap-analysis` (the analytical depth: which control, which version, which jurisdiction, which gap). `compliance-theater` is the natural secondary if the gap analysis reveals the control exists on paper but is structurally inadequate for current TTPs. Researcher emits `framework-gap-analysis` FIRST and recommends `compliance-theater` as the secondary when the operator's framing is "we 'comply' but..." (the scare quotes are the tell). Global-first applies: gap analysis always spans EU + UK + AU + ISO 27001:2022 alongside US references.
 - **"defense in depth"** routes primary to `defensive-countermeasure-mapping` (the structural D3FEND mapping: which defensive technique on which layer, which least-privilege scope, which zero-trust verification gate). `security-maturity-tiers` is the secondary if the operator is asking "where on the MVP-Practical-Overkill maturity curve does this control sit?" — `defensive-countermeasure-mapping` first to establish the structural mapping, `security-maturity-tiers` second to place it on the maturity axis. EU CRA Annex I essential-cybersecurity-requirements framing is relevant for product-side defense-in-depth questions; NIST CSF 2.0 Protect function and ISO 27001:2022 A.8.* controls are the cross-jurisdiction anchors.
-- **"zero trust"** disambiguates the same way: `defensive-countermeasure-mapping` for "what verification controls implement ZT for this attack class?", `policy-exception-gen` for "we cannot implement full ZT in our ephemeral/serverless/AI-pipeline environment — how do we document the exception with compensating controls per AGENTS.md hard rule #9?". The first question is structural, the second is exception-management. Researcher routes by which framing the operator used. Cross-jurisdiction note: NIST SP 800-207 is the US ZT anchor; UK NCSC ZT design principles and EU ENISA ZTA guidance are the parallel references and must be surfaced if the operator's jurisdiction is non-US.
+- **"zero trust"** disambiguates the same way: `defensive-countermeasure-mapping` for "what verification controls implement ZT for this attack class?", `policy-exception-gen` for "we cannot implement full ZT in our ephemeral/serverless/AI-pipeline environment — how do we document the exception with compensating controls for an environment where some controls are architecturally impossible?". The first question is structural, the second is exception-management. Researcher routes by which framing the operator used. Cross-jurisdiction note: NIST SP 800-207 is the US ZT anchor; UK NCSC ZT design principles and EU ENISA ZTA guidance are the parallel references and must be surfaced if the operator's jurisdiction is non-US.
 
 When the researcher emits a fan-out or a primary/secondary pair, the Output Format's "Routed to" block lists Primary first, then each Secondary on its own line with its one-line rationale. Operators run skills in the emitted order unless they have a specific reason to deviate.
 
@@ -303,7 +303,7 @@ US (for context): <NIST 800-53 control IDs + NIST AI RMF function if AI-related>
 
 ## Next actions
 1. Invoke <primary skill> with input <canonical reference>.
-2. If the catalog lacks this entry, open data update PR per AGENTS.md "Adding a New CVE" procedure.
+2. If the catalog lacks this entry, open a data update PR following the project's "Adding a New CVE" procedure.
 3. <Operator-specific action: live-patch within 4h / disable feature / update detection rules / etc.>
 4. If notification thresholds tripped (NIS2 24h early warning, DORA, etc.), start the regulatory clock now.
 ```
@@ -324,7 +324,7 @@ The researcher skill is dispatch, not analysis — but every dispatched finding
 | **D3-EHB** (Executable Hash-based Allowlist) | Input is a supply-chain CVE / advisory (npm worm, PyPI malware, model-registry compromise). | Harden | Hash-pinning is the canonical counter to the AML.T0010 / T1195.001 pattern across `supply-chain-integrity`, `mcp-agent-trust`, and `mlops-security`. The dispatcher names it so the downstream skill does not re-derive the harden layer from first principles. |
 | **D3-PA** (Process Analysis) | Input is a kernel LPE, container-escape, or post-exploitation narrative. | Detect | The auditd / eBPF / EDR layer that `kernel-lpe-triage`, `container-runtime-security`, and `incident-response-playbook` all depend on. RWEP-90 LPE inputs route here before live-patch consideration. |
 
-Defense-in-depth posture: the researcher's job is to recommend the **first** D3FEND layer the downstream skill should produce evidence against. Subsequent layers are the downstream skill's responsibility. Per AGENTS.md hard rule #4 (no orphaned controls), every D3FEND mapping above resolves to a real ATLAS or ATT&CK TTP enumerated in the TTP Mapping section.
+Defense-in-depth posture: the researcher's job is to recommend the **first** D3FEND layer the downstream skill should produce evidence against. Subsequent layers are the downstream skill's responsibility. No orphaned controls: every D3FEND mapping above resolves to a real ATLAS or ATT&CK TTP enumerated in the TTP Mapping section.
 
 ---
 
@@ -332,7 +332,7 @@ Defense-in-depth posture: the researcher's job is to recommend the **first** D3F
 
 The compliance theater test for the researcher skill is itself a meta-test: does the operator's existing triage process treat all inputs at the same depth, anchored on CVSS bands?
 
-> "Pull your last 30 days of vulnerability and threat-intel tickets. Bucket them by your current triage outcome: Critical, High, Medium, Low. Now overlay each one with the corresponding RWEP score from `data/cve-catalog.json` and the CISA KEV status and the AI-discovery flag. How many of your 'Critical' tickets are RWEP ≥ 85 and CISA KEV listed? How many of your 'Medium' tickets are RWEP ≥ 85 and CISA KEV listed but happened to land at CVSS 7.x? If any Medium-bucket ticket is a CISA-KEV-listed AI-discovered LPE, your triage process is CVSS-band theater. The control nominally exists (you triage every input) but the prioritization is anchored on a severity metric, not a risk metric. Per AGENTS.md hard rule #3, CVSS is severity, not risk."
+> "Pull your last 30 days of vulnerability and threat-intel tickets. Bucket them by your current triage outcome: Critical, High, Medium, Low. Now overlay each one with the corresponding RWEP score from `data/cve-catalog.json` and the CISA KEV status and the AI-discovery flag. How many of your 'Critical' tickets are RWEP ≥ 85 and CISA KEV listed? How many of your 'Medium' tickets are RWEP ≥ 85 and CISA KEV listed but happened to land at CVSS 7.x? If any Medium-bucket ticket is a CISA-KEV-listed AI-discovered LPE, your triage process is CVSS-band theater. The control nominally exists (you triage every input) but the prioritization is anchored on a severity metric, not a risk metric. CVSS is severity, not risk."
 
 A second, complementary test:
 

package/skills/sector-energy/skill.md

@@ -57,7 +57,7 @@ forward_watch:
   - MadIoT-class research on consumer-IoT-driven grid frequency manipulation moving from proof-of-concept to attributed campaigns
   - ICS-CERT advisory feed (https://www.cisa.gov/news-events/cybersecurity-advisories/ics-advisories) for vendor CVEs in Siemens, Rockwell, Schneider Electric, ABB, GE Vernova, Hitachi Energy, AVEVA / OSIsoft PI
 last_threat_review: "2026-05-11"
-discovery_mode: "standalone"  # v0.13.2: operator-reached via `exceptd brief sector-energy` or `exceptd ask`; not chained into any playbook's direct.skill_chain by design
+discovery_mode: "standalone"  # operator-reached via `exceptd brief sector-energy` or `exceptd ask`; not chained into any playbook's direct.skill_chain by design
 ---
 
 # Sector — Energy (Electric Power, Oil & Gas, Water/Wastewater, Renewables) — mid-2026
@@ -86,7 +86,7 @@ State-sponsored targeting of energy infrastructure has escalated, not plateaued.
 - **AI-augmented HMI / control-room copilots** are arriving in substation automation suites (Siemens Industrial Copilot, GE Vernova, Hitachi Energy, AVEVA). The risk inversion vs. classical NERC CIP is the same as in `ot-ics-security`: LLM-generated content is non-deterministic content over a conduit that the standards do not name.
 - **AI-assisted reverse engineering of vendor firmware** dropped exploit-development time for vendor-specific OT vulnerabilities in 2025 (per multiple vendor security advisory acknowledgements). The implication: vendor advisory-to-PoC latency is shrinking from months to weeks.
 
-**Inverted ephemerality (AGENTS.md Hard Rule #9, reversed — see `ot-ics-security`).** Energy infrastructure is among the longest-lived OT in existence. Substation relays from the 1980s remain in service. Transmission RTUs commissioned in the 1990s carry IEC 60870-5-101 / -104 traffic today. Pipeline SCADA running on Windows XP / Server 2003 hosts remains operationally common. Recommendations assuming patch-fast or rebuild-on-change are operationally indefensible without an explicit compensating-control programme.
+**Inverted ephemerality (the usual architectural-impossibility exemption, reversed — see `ot-ics-security`).** Energy infrastructure is among the longest-lived OT in existence. Substation relays from the 1980s remain in service. Transmission RTUs commissioned in the 1990s carry IEC 60870-5-101 / -104 traffic today. Pipeline SCADA running on Windows XP / Server 2003 hosts remains operationally common. Recommendations assuming patch-fast or rebuild-on-change are operationally indefensible without an explicit compensating-control programme.
 
 ---
 
@@ -111,7 +111,7 @@ State-sponsored targeting of energy infrastructure has escalated, not plateaued.
 | US CISA ICS Joint Working Group (ICSJWG) output | Coordinated US ICS guidance across sectors | Voluntary guidance for US CI | Non-binding; high-quality but adoption uneven. The ICS-CERT advisory cadence is the most actionable output. |
 | ISO 27001:2022 + ISO/IEC 27019:2017 (energy utilities sector extension) | Generic ISMS + energy-sector extension | Organisation-level ISMS for energy | ISO/IEC 27019 predates AI-augmented HMI (2017 publication). A.8.8 vulnerability management is IT-flavoured; 27019 adds energy specifics but no AI conduit treatment. |
 
-**Cross-jurisdiction posture (per AGENTS.md rule #5):** Any energy-sector gap analysis for a multi-jurisdiction operator must cite at minimum US NERC CIP v6/v7 + TSA SD (if pipeline) + AWWA (if water) + NIST 800-82r3, EU NIS2 + NCCS-G + CER Directive, UK NIS+CAF for ESN, AU SOCI+AESCSF, JP NISC + METI, IL INCD, alongside ISO 27001:2022 + ISO/IEC 27019. US-only analysis is insufficient for any operator with European, Australian, or Asian footprint.
+**Cross-jurisdiction posture (global-first, not US-centric):** Any energy-sector gap analysis for a multi-jurisdiction operator must cite at minimum US NERC CIP v6/v7 + TSA SD (if pipeline) + AWWA (if water) + NIST 800-82r3, EU NIS2 + NCCS-G + CER Directive, UK NIS+CAF for ESN, AU SOCI+AESCSF, JP NISC + METI, IL INCD, alongside ISO 27001:2022 + ISO/IEC 27019. US-only analysis is insufficient for any operator with European, Australian, or Asian footprint.
 
 ---
 
@@ -155,7 +155,7 @@ Energy-sector TTPs span ATT&CK for ICS, ATT&CK Enterprise (for the IT side of th
 | OCPP / V2G / ISO 15118 attack surface (EV charging) | varies | varies | Limited KEV coverage | Yes — research community publishes | Mixed | Demonstrated in research; opportunistic abuse confirmed | Vendor / charge-point-operator dependent | No | Charge-point-operator side analytics; weak external detection |
 | AI-dispatch / AI-forecast poisoning (no CVE class) | n/a | risk-modelled | n/a | Demonstrated in research and 2025 incident-response engagements | n/a | Suspected | Mitigation only — design-time controls on ML pipeline | n/a | Requires ML-pipeline telemetry; almost never present at utilities |
 
-**Honest gap statement (per AGENTS.md rule #10).** This project's `data/cve-catalog.json` does not yet contain an exhaustive inventory of vendor-side energy-OT CVEs (Siemens SSAs, Rockwell SD advisories, Schneider Electric Security Notifications, ABB CSAs, GE Vernova advisories, Hitachi Energy advisories, AVEVA advisories). The authoritative source for current energy-OT CVEs is the CISA ICS-CERT advisory feed at https://www.cisa.gov/news-events/cybersecurity-advisories/ics-advisories — captured in `forward_watch` for inclusion in the catalog as part of the next data refresh. Do not invent CVE IDs to fill this matrix.
+**Honest gap statement (declare what the catalog does not yet cover).** This project's `data/cve-catalog.json` does not yet contain an exhaustive inventory of vendor-side energy-OT CVEs (Siemens SSAs, Rockwell SD advisories, Schneider Electric Security Notifications, ABB CSAs, GE Vernova advisories, Hitachi Energy advisories, AVEVA advisories). The authoritative source for current energy-OT CVEs is the CISA ICS-CERT advisory feed at https://www.cisa.gov/news-events/cybersecurity-advisories/ics-advisories — captured in `forward_watch` for inclusion in the catalog as part of the next data refresh. Do not invent CVE IDs to fill this matrix.
 
 ---
 
@@ -378,7 +378,7 @@ Ask: "Walk me through your IR playbook for a confirmed compromise of [pick one:
 
 ## Defensive Countermeasure Mapping
 
-Per AGENTS.md optional 8th section (required for skills shipped on or after 2026-05-11). Maps energy-sector offensive findings to MITRE D3FEND IDs from `data/d3fend-catalog.json`, with explicit defense-in-depth layer position, least-privilege scope, zero-trust posture, and the inverted ephemeral/AI-pipeline applicability per Hard Rule #9.
+Maps energy-sector offensive findings to MITRE D3FEND IDs from `data/d3fend-catalog.json`, with explicit defense-in-depth layer position, least-privilege scope, zero-trust posture, and the inverted ephemeral/AI-pipeline applicability (long-lived OT inverts the usual architectural-impossibility exemption).
 
 | D3FEND ID | Technique | Purdue Layer + Energy Overlay | Least-Privilege Scope | Zero-Trust Posture | Energy-Realistic Applicability |
 |---|---|---|---|---|---|
@@ -388,7 +388,7 @@ Per AGENTS.md optional 8th section (required for skills shipped on or after 2026
 | D3-EAL | Executable Allowlisting | L2 station HMI hosts; L2 engineering workstations (PCM600, DIGSI, AcSELerator, etc.); L3 historian/MES hosts; AMI head-end servers; market-systems servers | Per-host allowlist of signed executables; vendor-tooling exceptions explicit and audited | Default-deny execution; only enumerated binaries run | Applicable to Windows/Linux engineering and HMI hosts. Cannot apply directly to L1 IEDs, smart meters, smart inverters — for those, signed-firmware enforcement (where vendor supports) is the analogue; signed-firmware support varies widely across energy vendors. |
 | D3-PSEP | Process Segment Execution Prevention | L2 station HMI hosts; L2 engineering workstations; control-center operator hosts | Per-process memory-execution policy; non-exec data segments | Memory regions verified at execution time | Applicable where host OS supports modern memory protections. Brownfield Windows 7 / Windows Server 2008 hosts have weaker support — compensating control: tighter D3-EAL + D3-NTA + isolated network. Substation engineering hosts often locked to vendor-tool-supported OS versions, constraining options. |
 
-**Inverted ephemerality posture (per Hard Rule #9, reversed — extended from `ot-ics-security`).** Energy infrastructure is among the longest-lived OT in existence. Substation relays from the 1980s remain in service; transmission RTUs from the 1990s carry IEC 60870-5-104 today; pipeline SCADA hosts running Windows XP / Server 2003 remain operationally common. Controls assuming rapid patching are unrealistic; controls assuming rebuild-on-change are catastrophic for grid stability. The energy-appropriate posture: virtual patching at L3.5 / L2 boundaries, executable allowlisting on engineering and HMI hosts, ICS-IDS detection with energy-protocol decoders as the primary control where prevention is architecturally unavailable, signed-firmware enforcement where supported, and explicit documentation of multi-decade compensating-control programmes. Recommendations that read "patch the substation relay firmware" without specifying the change window (often an annual outage), the vendor's signed-firmware support status, the protective-relay coordination re-test plan, and the rollback plan are operationally indefensible.
+**Inverted ephemerality posture (the usual architectural-impossibility exemption, reversed — extended from `ot-ics-security`).** Energy infrastructure is among the longest-lived OT in existence. Substation relays from the 1980s remain in service; transmission RTUs from the 1990s carry IEC 60870-5-104 today; pipeline SCADA hosts running Windows XP / Server 2003 remain operationally common. Controls assuming rapid patching are unrealistic; controls assuming rebuild-on-change are catastrophic for grid stability. The energy-appropriate posture: virtual patching at L3.5 / L2 boundaries, executable allowlisting on engineering and HMI hosts, ICS-IDS detection with energy-protocol decoders as the primary control where prevention is architecturally unavailable, signed-firmware enforcement where supported, and explicit documentation of multi-decade compensating-control programmes. Recommendations that read "patch the substation relay firmware" without specifying the change window (often an annual outage), the vendor's signed-firmware support status, the protective-relay coordination re-test plan, and the rollback plan are operationally indefensible.
 
 ---
 

package/skills/sector-federal-government/skill.md

@@ -61,7 +61,7 @@ forward_watch:
   - EU Cybersecurity Certification Scheme on Common Criteria (EUCC) operational — first certificates issued 2024; high-assurance level for government use cases ramping
   - Australia PSPF 2024 revision and ISM quarterly updates — track for Essential Eight Maturity Level requirements for federal entities
 last_threat_review: "2026-05-11"
-discovery_mode: "standalone"  # v0.13.2: operator-reached via `exceptd brief sector-federal-government` or `exceptd ask`; not chained into any playbook's direct.skill_chain by design
+discovery_mode: "standalone"  # operator-reached via `exceptd brief sector-federal-government` or `exceptd ask`; not chained into any playbook's direct.skill_chain by design
 ---
 
 # Federal Government and Defense Contractor Cybersecurity
@@ -136,7 +136,7 @@ Cross-walk to CWE (see `data/cwe-catalog.json`):
 
 ## Exploit Availability Matrix
 
-Sourced from `data/cve-catalog.json`, `data/exploit-availability.json`, and CISA KEV (https://www.cisa.gov/known-exploited-vulnerabilities-catalog) plus public federal incident history as of 2026-05-11. Per AGENTS.md hard rule #1, every CVE reference includes CVSS, KEV status, PoC availability, AI-discovery flag, active-exploitation status, and patch availability. Technique-class rows are scored as ongoing class risks per AGENTS.md hard rule #3 — RWEP is not assigned because the field is defined for individual CVEs in `data/cve-catalog.json`.
+Sourced from `data/cve-catalog.json`, `data/exploit-availability.json`, and CISA KEV (https://www.cisa.gov/known-exploited-vulnerabilities-catalog) plus public federal incident history as of 2026-05-11. Every CVE reference includes CVSS, KEV status, PoC availability, AI-discovery flag, active-exploitation status, and patch availability (no theoretical-only intel). Technique-class rows are scored as ongoing class risks; CVSS is reported alongside RWEP for compatibility but is never the prioritization signal — RWEP is not assigned because the field is defined for individual CVEs in `data/cve-catalog.json`.
 
 | Incident / Class | CVSS | RWEP | PoC Public? | CISA KEV? | AI-Accelerated? | Patch / Mitigation | FedRAMP-Visible? | CMMC-Visible? | SSDF-Attestable? |
 |---|---|---|---|---|---|---|---|---|---|

package/skills/sector-financial/skill.md

@@ -140,7 +140,7 @@ In all three, the SCA evidence chain (the customer's authenticated session, the
 | ISO 27001:2022 + ISO/IEC 27017 (cloud) + ISO/IEC 27018 (cloud PII) | Generic ISMS for financial entities | Organisation-level ISMS | A.5.16 (identity management) and A.8.5 (secure authentication) cross-walk to SCA but do not name agent-initiation. A.5.23 (cloud services) generic; financial-sector cloud risk not specifically addressed. |
 | SOC 2 Trust Services Criteria (CC6 logical access) | Service-organisation logical access controls | Audit attestation for service organisations | Captured in `data/framework-control-gaps.json#SOC2-CC6-logical-access`. Logical-access criteria treat the authenticated session as the access boundary; injected intent within an authenticated AI-agent session is invisible. |
 
-**Cross-jurisdiction posture (per AGENTS.md rule #5).** Any financial-sector gap analysis for a multi-jurisdiction institution must cite at minimum: EU DORA + PSD2 (transitioning to PSD3/PSR) + RTS-SCA + national overlays (BaFin BAIT/VAIT, ACPR, BdP, Banca d'Italia, AEPD, ENISA), UK FCA + PRA operational resilience + CBEST, AU APRA CPS 234 + CPS 230 + AESCSF, JP FISC v9 + JFSA, SG MAS TRM + Notice 655 + Notice 644, HK HKMA CFI 2.0 + iCAST + TM-G-1, IL BoI Directive 361 + INCD, CA OSFI B-13 + B-10, BR BCB Resolução 85, AE CBUAE + DFSA + FSRA, SA SAMA CSF, IN SEBI + RBI Master Direction, NZ RBNZ BS11, alongside SWIFT CSCF v2026, NYDFS 23 NYCRR 500 (for any NY-connected entity), ISO 27001:2022 + ISO/IEC 27017/27018, and SOC 2. US-only (FFIEC, NYDFS, NIST CSF) is incomplete.
+**Cross-jurisdiction posture (global-first, not US-centric).** Any financial-sector gap analysis for a multi-jurisdiction institution must cite at minimum: EU DORA + PSD2 (transitioning to PSD3/PSR) + RTS-SCA + national overlays (BaFin BAIT/VAIT, ACPR, BdP, Banca d'Italia, AEPD, ENISA), UK FCA + PRA operational resilience + CBEST, AU APRA CPS 234 + CPS 230 + AESCSF, JP FISC v9 + JFSA, SG MAS TRM + Notice 655 + Notice 644, HK HKMA CFI 2.0 + iCAST + TM-G-1, IL BoI Directive 361 + INCD, CA OSFI B-13 + B-10, BR BCB Resolução 85, AE CBUAE + DFSA + FSRA, SA SAMA CSF, IN SEBI + RBI Master Direction, NZ RBNZ BS11, alongside SWIFT CSCF v2026, NYDFS 23 NYCRR 500 (for any NY-connected entity), ISO 27001:2022 + ISO/IEC 27017/27018, and SOC 2. US-only (FFIEC, NYDFS, NIST CSF) is incomplete.
 
 ---
 
@@ -175,7 +175,7 @@ In all three, the SCA evidence chain (the customer's authenticated session, the
 | SWIFT CSCF v2026 1.1 violations via AI-API egress | n/a | risk-modelled | n/a | Demonstrated in 2025 red-team | n/a | Suspected | Mitigation — DLP on jump-zone egress, AI-API explicit deny | n/a | DLP + egress telemetry |
 | HMI / treasury-workstation Linux LPE (Copy Fail CVE-2026-31431) where deployed | 7.8 | 90 | Yes (2026-05-01, due 2026-05-15) | Yes — 732-byte script | Yes | Confirmed | Yes | Yes (kpatch/livepatch) on supported distros | EDR if deployable |
 
-**Honest gap statement (per AGENTS.md rule #10).** Vendor-specific financial-sector CVEs (core-banking platform CVEs, payment-gateway CVEs, broker-dealer trading-platform CVEs, SWIFT Alliance Access CVEs) are not exhaustively inventoried in `data/cve-catalog.json`. The authoritative sources are: vendor advisories (Temenos, Finastra, FIS, Fiserv, Jack Henry, Murex, Calypso, Bloomberg, Refinitiv, SWIFT KB), CISA KEV for cross-sector exposure, and sector-specific intel feeds (FS-ISAC, FI-ISAC EU). Forward-watched.
+**Honest gap statement (catalog coverage is not exhaustive).** Vendor-specific financial-sector CVEs (core-banking platform CVEs, payment-gateway CVEs, broker-dealer trading-platform CVEs, SWIFT Alliance Access CVEs) are not exhaustively inventoried in `data/cve-catalog.json`. The authoritative sources are: vendor advisories (Temenos, Finastra, FIS, Fiserv, Jack Henry, Murex, Calypso, Bloomberg, Refinitiv, SWIFT KB), CISA KEV for cross-sector exposure, and sector-specific intel feeds (FS-ISAC, FI-ISAC EU). Forward-watched.
 
 ---
 
@@ -369,7 +369,7 @@ Ask: "What is your fraud-detection model retraining cadence, drift-monitoring ca
 
 ## Defensive Countermeasure Mapping
 
-Per AGENTS.md optional 8th section (required for skills shipped on or after 2026-05-11). Maps financial-sector offensive findings to MITRE D3FEND IDs from `data/d3fend-catalog.json`, with explicit defense-in-depth layer position, least-privilege scope, zero-trust posture, and AI-pipeline applicability per Hard Rule #9.
+Maps financial-sector offensive findings to MITRE D3FEND IDs from `data/d3fend-catalog.json`, with explicit defense-in-depth layer position, least-privilege scope, zero-trust posture, and AI-pipeline applicability.
 
 | D3FEND ID | Technique | Layer Position | Least-Privilege Scope | Zero-Trust Posture | AI-Pipeline Applicability |
 |---|---|---|---|---|---|
@@ -378,7 +378,7 @@ Per AGENTS.md optional 8th section (required for skills shipped on or after 2026
 | D3-NTA | Network Traffic Analysis | Network boundary (internet ↔ customer-facing portal); inter-zone boundary (customer-facing ↔ core-banking); SWIFT secure-zone boundary; administrative jump zone egress; AI-API egress | Operator alerting scoped to operator's zone; SOC aggregated visibility | Network-hostile-until-proven posture; AI-API egress explicitly allowlisted at administrative jump zone | Applicable. AI-API egress monitoring is the specific gap: DLP-aware NTA is required to detect AI-channel exfiltration (T1567) per `data/dlp-controls.json`. |
 | D3-IOPR | Input / Output Pattern Recognition | Application layer (transaction monitoring); fraud-detection model layer; AI-channel inspection (prompt + completion + tool-call) | Transaction-pattern detection per customer; model-probing detection per principal; AI-channel inspection per integration | Every transaction pattern verified against historical norm and against adversary-known patterns; AI-channel outputs treated as untrusted until cross-checked | Critical for AI-pipeline applicability. AI-channel I/O inspection is the primary defensive control against prompt injection mediating agent-initiated payments and AI-mediated SWIFT message drafting. Almost never deployed at mid-2026; this is the dominant defensive gap. |
 
-**AI-pipeline-specific posture (per Hard Rule #9).** Conventional D3-MFA cannot apply to autonomous AI agents acting on behalf of a customer — there is no agent-side biometric inherence factor, and possession factors are reduced to API-key custody. The AI-pipeline-appropriate construct is: scoped delegated-authority attestation (PSD3/PSR forward-looking) + out-of-band confirmation for any transaction above scoped threshold + AI-channel I/O recording (D3-IOPR) sufficient to support post-hoc dispute resolution and forensic reconstruction. Skill `identity-assurance` covers AAL/IAL/FAL constructs and is the companion for human-side authentication; this skill covers the sector-regulatory framing of the agent-side gap.
+**AI-pipeline-specific posture.** Conventional D3-MFA cannot apply to autonomous AI agents acting on behalf of a customer — there is no agent-side biometric inherence factor, and possession factors are reduced to API-key custody. The AI-pipeline-appropriate construct is: scoped delegated-authority attestation (PSD3/PSR forward-looking) + out-of-band confirmation for any transaction above scoped threshold + AI-channel I/O recording (D3-IOPR) sufficient to support post-hoc dispute resolution and forensic reconstruction. Skill `identity-assurance` covers AAL/IAL/FAL constructs and is the companion for human-side authentication; this skill covers the sector-regulatory framing of the agent-side gap.
 
 ---
 

package/skills/sector-healthcare/skill.md

@@ -100,7 +100,7 @@ Healthcare has been the most targeted sector for ransomware for three consecutiv
 | ISO 27001:2022 + ISO/IEC 27799 (health-sector ISMS) + ISO 81001-5-1 (medical-device cybersecurity lifecycle) + ISO/IEC 42001 (AI management system) | Generic ISMS + health sector + medical-device cyber lifecycle + AIMS | Organisation-level | A.8.30 outsourced development control needs explicit AI-pipeline interpretation. ISO 81001-5-1 is the strongest medical-device cybersecurity lifecycle standard available but adoption among smaller device vendors is partial. |
 | NIST 800-53 Rev 5 + NIST 800-66 Rev 2 (HIPAA implementation guidance) + NIST AI RMF 1.0 + NIST GenAI Profile (NIST-AI-600-1) | US federal + HIPAA mapping + voluntary AI risk | US covered entities can opt-in for stronger baseline | AC-2 account management does not specifically address shared clinician credentials, break-glass accounts, or AI-service-principals for clinical copilots — extension required. |
 
-**Cross-jurisdiction posture (per AGENTS.md rule #5):** Any healthcare gap analysis for a multi-jurisdiction operator must explicitly enumerate the regulator and primary instrument for: US (HHS-OCR, FDA), EU (each Member State DPA + ENISA + notified bodies + Commission for AI Act), UK (ICO + NHS England + MHRA), AU (OAIC + Department of Health + TGA), JP (PPC + MHLW + PMDA), IL (PPA + INCD + MoH), SG (PDPC + MOH), IN (DPB + MoHFW + CDSCO), SA (Information Regulator + SAHPRA), BR (ANPD + ANVISA + ANS), UAE (UAE Data Office + DHA / DOH / MOHAP), alongside ISO 27001:2022 + ISO/IEC 27799 + ISO 81001-5-1 + ISO/IEC 42001. US-only (HIPAA, FDA) is insufficient for any multinational provider, payer, device vendor, or digital-health platform.
+**Cross-jurisdiction posture (global-first, not US-centric):** Any healthcare gap analysis for a multi-jurisdiction operator must explicitly enumerate the regulator and primary instrument for: US (HHS-OCR, FDA), EU (each Member State DPA + ENISA + notified bodies + Commission for AI Act), UK (ICO + NHS England + MHRA), AU (OAIC + Department of Health + TGA), JP (PPC + MHLW + PMDA), IL (PPA + INCD + MoH), SG (PDPC + MOH), IN (DPB + MoHFW + CDSCO), SA (Information Regulator + SAHPRA), BR (ANPD + ANVISA + ANS), UAE (UAE Data Office + DHA / DOH / MOHAP), alongside ISO 27001:2022 + ISO/IEC 27799 + ISO 81001-5-1 + ISO/IEC 42001. US-only (HIPAA, FDA) is insufficient for any multinational provider, payer, device vendor, or digital-health platform.
 
 ---
 
@@ -132,13 +132,13 @@ Healthcare has been the most targeted sector for ransomware for three consecutiv
 | FHIR / SMART JWT token theft / replay | varies (CVE-2024-X for various SMART-on-FHIR libraries) | medium-high | Few KEV | Yes for several library-level vulns | n/a | Confirmed in 2024-2025 against patient-app marketplaces | Yes per library | Yes (library hot-swap) | API-gateway telemetry where deployed; many EHR vendors deploy proprietary token-introspection without standardized log schema |
 | EHR / patient-portal credential stuffing | n/a | high | n/a | n/a (credential reuse, not CVE) | n/a | Continuous | n/a | n/a | Bot-management and account-takeover detection if deployed; HHS-OCR has flagged inadequate protection as risk-analysis failure |
 
-**Honest gap statement (per AGENTS.md rule #10).** This project's `data/cve-catalog.json` does not contain an exhaustive inventory of medical-device CVEs (Medtronic, BD, Philips, GE Healthcare, Illumina, Baxter, Welch Allyn, MicroPort, Abbott). The authoritative source is CISA's ICS Medical Advisory feed (https://www.cisa.gov/news-events/cybersecurity-advisories/ics-medical-advisories) and FDA's medical-device safety communications. Captured in `forward_watch` for inclusion in the next data refresh. Do not invent CVE IDs to fill this matrix.
+**Honest gap statement (catalog coverage is not exhaustive).** This project's `data/cve-catalog.json` does not contain an exhaustive inventory of medical-device CVEs (Medtronic, BD, Philips, GE Healthcare, Illumina, Baxter, Welch Allyn, MicroPort, Abbott). The authoritative source is CISA's ICS Medical Advisory feed (https://www.cisa.gov/news-events/cybersecurity-advisories/ics-medical-advisories) and FDA's medical-device safety communications. Captured in `forward_watch` for inclusion in the next data refresh. Do not invent CVE IDs to fill this matrix.
 
 ---
 
 ## Analysis Procedure
 
-This procedure threads the three foundational design principles required by AGENTS.md skill-format spec — defense in depth, least privilege, zero trust — through every step.
+This procedure threads the three foundational design principles — defense in depth, least privilege, zero trust — through every step.
 
 **Defense in depth.** Layer controls across: clinician identity (D3-MFA at phishing-resistant AAL2/AAL3), EHR application (RBAC + minimum-necessary enforcement + break-glass audit), API perimeter (FHIR gateway with JWT validation per RFC-7519 + HTTP message signatures per RFC-9421 where supported), data layer (encryption at rest, field-level encryption for sensitive PHI fields, tokenization for analytics), egress (DLP at LLM boundary D3-IOPR + sanctioned-AI-only egress policy D3-CSPP), endpoint (EDR + browser-isolation on clinician workstations where clipboard-paste-to-LLM is a documented vector), medical-device network (segmentation à la `ot-ics-security`), backups (immutable + air-gap + tested restore).
 
@@ -341,15 +341,15 @@ Ask: "What's the most recent ransomware tabletop exercise outcome, including the
 
 ## Defensive Countermeasure Mapping
 
-Per AGENTS.md optional 8th section (required for skills shipped on or after 2026-05-11). Maps healthcare-sector offensive findings to MITRE D3FEND IDs from `data/d3fend-catalog.json`, with explicit defense-in-depth layer position, least-privilege scope, zero-trust posture, and AI-pipeline applicability per Hard Rule #9.
+Maps healthcare-sector offensive findings to MITRE D3FEND IDs from `data/d3fend-catalog.json`, with explicit defense-in-depth layer position, least-privilege scope, zero-trust posture, and AI-pipeline applicability.
 
-| D3FEND ID | Technique | Healthcare Layer Position | Least-Privilege Scope | Zero-Trust Posture | AI-Pipeline Applicability (Hard Rule #9) |
+| D3FEND ID | Technique | Healthcare Layer Position | Least-Privilege Scope | Zero-Trust Posture | AI-Pipeline Applicability |
 |---|---|---|---|---|---|
 | D3-IOPR | I/O Prompt Inspection (PHI inspection at the LLM boundary) | Egress proxy / DLP inline with the sanctioned AI-tool data path; browser-isolation / clipboard-DLP on clinician workstations for unsanctioned channels | Per-clinician identity binding; per-encounter context scope; per-tool BAA-coverage validation | Default-deny; every prompt inspected and policy-evaluated before reaching the model endpoint, every completion inspected before reaching the clinician | Required for sanctioned AI integration. For ephemeral / serverless clinical-AI tool architectures, the prompt-inspection point shifts to the API-gateway sidecar — never recommend host-agent-only DLP for ephemeral AI workloads. |
 | D3-CSPP | Client-Server Payload Profiling (EHR / FHIR API payload profiling for exfil detection) | At FHIR API gateway, EHR application reverse-proxy, cloud-data-warehouse egress; sampling and signature on bulk-export operations | Per-API-client identity, per-scope, per-resource-type; flag deviations from baseline access pattern | Continuous verification of API-call conformance with declared scope; deviations alert and optionally throttle | Required at every AI-service-principal egress from the EHR — distinguishes legitimate AI workload reads from exfiltration patterns. For serverless AI architectures the profiling point is the API-gateway, not the ephemeral compute. |
 | D3-MFA | Multi-Factor Authentication (clinician auth at AAL2+ minimum; AAL3 for privileged access) | Identity provider (Azure AD / Entra, Okta, PingFederate, ForgeRock) federating SAML/OIDC to EHR, FHIR app marketplace, VPN, Citrix, jump hosts | Per-clinician identity; step-up for privileged roles; phishing-resistant factors required, not optional | Every session re-verified at risk-signal change; no standing trust; break-glass identities distinct and alarmed | Applicable to AI-service-principals via workload-identity federation rather than human MFA; for ephemeral AI workloads use short-lived workload-identity tokens (OIDC workload federation, SPIFFE/SPIRE) rather than long-lived service-account keys. |
 
-**Ephemeral and AI-pipeline applicability statement (per Hard Rule #9).** Recommendations in this skill are explicit about where the host-agent control assumption fails. Cloud-hosted clinical-AI tools and serverless ambient-documentation pipelines are by definition ephemeral; host-agent DLP and host-EDR controls do not apply. The compensating-control surface is the API-gateway / egress-proxy boundary, plus the workload-identity layer, plus immutable audit logging delivered to a SIEM under the covered entity's control rather than the vendor's. For brownfield deployments on traditional hospital infrastructure, host-agent controls do apply and should be the primary control plane — recommendations must specify which architectural mode the control is being placed in.
+**Ephemeral and AI-pipeline applicability statement.** Recommendations in this skill are explicit about where the host-agent control assumption fails. Cloud-hosted clinical-AI tools and serverless ambient-documentation pipelines are by definition ephemeral; host-agent DLP and host-EDR controls do not apply. The compensating-control surface is the API-gateway / egress-proxy boundary, plus the workload-identity layer, plus immutable audit logging delivered to a SIEM under the covered entity's control rather than the vendor's. For brownfield deployments on traditional hospital infrastructure, host-agent controls do apply and should be the primary control plane — recommendations must specify which architectural mode the control is being placed in.
 
 ---
 

package/skills/sector-telecom/skill.md

@@ -67,7 +67,7 @@ forward_watch:
   - "3GPP TS 33.501 updates (5G security architecture rebaseline)"
   - "O-RAN SFG / WG11 security specifications"
 last_threat_review: "2026-05-15"
-discovery_mode: "standalone"  # v0.13.2: operator-reached via `exceptd brief sector-telecom` or `exceptd ask`; not chained into any playbook's direct.skill_chain by design
+discovery_mode: "standalone"  # operator-reached via `exceptd brief sector-telecom` or `exceptd ask`; not chained into any playbook's direct.skill_chain by design
 ---
 
 ## Threat Context (mid-2026)