Persist dry-run response plans

docs/COMMAND_REFERENCE.md

@@ -229,8 +229,12 @@ outbound IP blocks, systemd unit disablement, suspicious-file quarantine,
 package-restore lookup, and follow-up verification checks.
 
 This command is intentionally read-only: it prints commands for operator review
-and never executes them. The JSON schema is `enodia.response.plan.v1` and marks
-`apply_supported: false` until an audited apply workflow exists.
+and never executes them. Each CLI-generated plan is also saved under
+`<log_dir>/response-plans/`, and a compact JSONL audit record is appended to
+`<log_dir>/response-audit.log` with the plan id, incident id, action count, and
+saved path. The JSON schema is `enodia.response.plan.v1` and marks
+`apply_supported: false` until an audited apply workflow exists. Dashboard/API
+plan previews remain read-only and do not create new artifacts.
 
 Exit code:
 

docs/OPERATIONS.md

@@ -93,7 +93,9 @@ When Sentinel fires:
    ```
 
    Review the plan before acting; Sentinel does not execute containment
-   commands.
+   commands. CLI-generated plans are saved under
+   `/var/log/enodia-sentinel/response-plans/` and indexed in
+   `/var/log/enodia-sentinel/response-audit.log` for later review.
 5. If the alert involves a binary, run:
 
    ```bash

docs/ROADMAP.md

@@ -61,11 +61,13 @@ Purpose: move from "tell me" to "help me act" without unsafe automation.
 
 - ✅ Add response plan generation:
   `enodia-sentinel respond plan <incident-id>`.
+- ✅ Persist CLI-generated dry-run plans under `response-plans/` and append
+  `response-audit.log` records for review/handoff.
 - Add dry-run first actions:
   kill process, stop/disable service, block remote IP, quarantine file, restore
   package-owned file by reinstalling its package, and freeze evidence.
 - Require explicit `--apply` for changes; default to read-only plans.
-- Write response audit logs under the normal log directory.
+- Extend response audit logs to any future state-changing `--apply` workflow.
 - Add baseline reconciliation:
   accept legitimate FIM/package/listener/SUID changes with a recorded reason.
 - Add richer false-positive suppression suggestions that can emit TOML snippets

docs/RUNBOOKS.md

@@ -29,6 +29,11 @@ For any alert, before changing anything:
    enodia-sentinel respond plan <incident-id>
    ```
 
+   The CLI writes a copy under
+   `/var/log/enodia-sentinel/response-plans/` and appends
+   `/var/log/enodia-sentinel/response-audit.log`, so the reviewed plan can be
+   handed off or compared with later actions.
+
 5. **Preserve evidence before you touch anything:**
 
    ```bash

docs/SPECIFICATION.md

@@ -105,6 +105,11 @@ When a fresh alert survives cooldown, Sentinel writes:
 | Push | ntfy, Pushover, and generic webhook notifications. |
 | Red-team harness | Safe drills for testing signatures and demos. |
 
+CLI-generated response plans are durable artifacts: `respond plan` writes the
+reviewed dry-run plan under `response-plans/` and appends a JSONL
+`response-audit.log` record. Dashboard/API previews remain read-only and do not
+create artifacts.
+
 ## Target Scope: Host Security Platform
 
 The next product shape should make Enodia useful before, during, and after an

docs/THREAT_MODEL.md

@@ -108,6 +108,12 @@ Sentinel should remain conservative:
 Future response features should produce dry-run plans first, log all changes,
 and avoid shell-string execution where structured APIs exist.
 
+Current CLI response planning already leaves a local audit trail: generated
+dry-run plans are saved under `response-plans/`, and
+`response-audit.log` records who/what generated the plan and where it was
+stored. This is a review/handoff record only; it does not prove containment
+commands were executed.
+
 ## Abuse Considerations
 
 Some security tools can become dual-use. Enodia should avoid: