Persist retryable post-publish cleanup obligations

docs/internal/manifest.md

@@ -16,6 +16,9 @@ Explain the session-progress and invocation-audit models implemented by
 - `inputs` records
 - durable `artifacts` records
 - per-stage `stages` map
+- an optional `post_publish_cleanup` obligation, which binds a committed run,
+  remote commit identity, and each exact root-confined local target to its
+  completion evidence
 
 Session, campaign, and run identities in local and downloaded manifests must be
 portable opaque segments. Unsafe legacy identities are rejected with migration
@@ -111,6 +114,13 @@ runner marks it stale and executes it.
 Session manifest is the authoritative stage-progress ledger across invocations.
 Run manifest is invocation-scoped audit state.
 
+After a publish commits remotely, any configured local cleanup is first recorded
+as a session-manifest obligation before deletion begins. Each target becomes
+complete only after its confined deletion (or safe absence check) and a
+successful manifest save. An incomplete obligation is retried on later
+invocations independently of their selected stages and retains the committed
+run and remote identity that authorized it.
+
 Each invocation derives campaign, session, run, local-path, and remote-prefix
 metadata from the validated resolved configuration as one projection. A persisted
 session manifest must agree on campaign and session identity before execution;

docs/internal/stage-publish.md

@@ -59,6 +59,7 @@ Includes counts/lists for:
 - skipped unselected outputs
 - locked outputs
 - remote commit and current-pointer key paths
+- the run identifier selected by the commit
 
 ## Invariants
 
@@ -72,6 +73,8 @@ Includes counts/lists for:
   archived only when recorded by the run manifest.
 - publish locks are not overridden by `--force`; remote locks are revalidated
   immediately before current-state selection.
+- post-commit local cleanup is authorized by the committed publish metadata and
+  is durably recorded by the application lifecycle before any local deletion.
 
 The commit boundary and cleanup gate are normative architecture invariants; see
 [Architecture](../policy/architecture.md#publish-commit-boundary).

docs/internal/workspace.md

@@ -54,13 +54,17 @@ lock only while their context remains active, and report a release failure.
 
 Automatic post-publish cleanup:
 
-- only runs when publish actually executed and succeeded;
+- is created only after a successful publish commit with complete publish
+  metadata, then is persisted before any deletion;
 - requires `uploaded=true`, a remote commit key, and a current commit-pointer
   key in publish metadata;
 - consumes the resolved cleanup policy described in
   [Configuration](../config.md);
 - refuses unsafe deletes (root delete, out-of-root delete, and symlinked
-  ancestors or entries).
+  ancestors or entries);
+- retries any recorded incomplete target on later invocations even when no
+  publish work is selected. Missing targets are a successful, idempotent
+  cleanup result only after the completion evidence is saved.
 
 Manual cleanup uses the same root-confined deletion mechanism. Invocation
 syntax and exact deletion scope belong in [CLI](../cli.md#clean) and

docs/operations.md

@@ -381,6 +381,9 @@ Rules:
 - automatic post-publish cleanup is gated by successful publish commit plus:
   - `pipeline.spool.delete_audio_after_publish=true`
   - `pipeline.workspace.cleanup_after_publish=true`
+  - Narratio first records the exact run-scoped cleanup obligation. If cleanup
+    reports incomplete, the remote committed snapshot remains current; rerun
+    Narratio to retry only the outstanding confined local cleanup.
 
 ## Operational Caveats
 

docs/policy/architecture.md

@@ -179,6 +179,10 @@ selection; loss of that check leaves the prior committed snapshot current.
 
 Automatic local cleanup is permitted only after a successful publish commit,
 only when explicitly configured, and only through the path-safety guardrails.
+It is a durable local obligation bound to that committed run and its exact
+targets, not an inferred side effect of the current stage list. A cleanup
+failure makes the invocation incomplete while leaving the committed remote
+snapshot authoritative; later invocations resume the recorded obligation.
 
 ## Security, Privacy, And Diagnostics
 

docs/roadmap/implementation.md

@@ -31,7 +31,7 @@ All stages are pending when this plan is created.
 | 13 | Introduce the immutable remote-commit model and legacy boundary | ARC-003 | Completed |
 | 14 | Publish through immutable commits and canonical mappings | COR-004, COR-011, DUP-002, TST-004 | Completed |
 | 15 | Make remote locks generation-safe and harden pagination | RSK-005, RSK-014 | Completed |
-| 16 | Persist retryable post-commit cleanup state | COR-006, COR-007 | Pending |
+| 16 | Persist retryable post-commit cleanup state | COR-006, COR-007 | Completed |
 | 17 | Bind restore/status to a committed snapshot and reject conflicts | COR-008, COR-009, TST-005 | Pending |
 | 18 | Serialize restore transitions and make restored paths portable | RSK-006, RSK-008 | Pending |
 | 19 | Bind audio cache reuse to remote object identity | RSK-007 | Pending |