test: prove durable authority, effect accounting, and cleanup residuals

ROADMAP.md

@@ -3,7 +3,7 @@ schema: aether.architecture-document/v1
 id: flow-roadmap
 title: Flow Roadmap
 kind: architecture-document
-version: 1.3.4
+version: 1.3.5
 status: draft
 owners:
   - egohygiene
@@ -48,11 +48,21 @@ accepted checkpoints, fresh resume eligibility, and explicit recovery decisions.
 `83f1ea161aa5aba03da5de6b287005252000cd4b`, with green
 [default-branch CI](https://github.com/egohygiene/flow/actions/runs/36226457853).
 It adds fresh graph assessment and safe dependent execution.
-[#65](https://github.com/egohygiene/flow/issues/65) adds the
+[#65](https://github.com/egohygiene/flow/issues/65) merged through
+[PR #68](https://github.com/egohygiene/flow/pull/68) as
+`6db839facc822707e9e3a9d74dda044faac77fe7`. It adds the
 [deterministic durable lifecycle corpus](docs/integrations/lifecycle-scenarios.md)
-with 34 recipes executed twice, fresh-process restarts, and bounded receipts; [#66](https://github.com/egohygiene/flow/issues/66)
-proves authority, duplicate-effect prevention, and recovery residuals. Land one
-review PR and verify default-branch CI before starting the next checkpoint.
+with 34 initial recipes executed twice, fresh-process restarts, and bounded receipts.
+[#66](https://github.com/egohygiene/flow/issues/66) adds 15 counter-backed authority,
+duplicate-effect, recovery-approval, and cleanup-residual recipes, bringing the
+corpus to 49. Its guide reconciles all original #31 acceptance criteria. Keep #31
+and #66 open until maintainer merge; #13 still requires the real-provider proofs.
+
+The maintainer's 2026-09-26 instruction supersedes older CI-wait wording: hand back
+each bounded PR after focused local checks, report unverified gates honestly, and
+do not wait for hosted or default-branch CI. Keep one review checkpoint at a time;
+the maintainer owns merges. This changes handoff timing, not CI definitions or
+the final release/audit evidence requirements.
 FLO-Q03 remains active until real released-provider adapters satisfy its
 remaining exit criteria. [#62](https://github.com/egohygiene/flow/issues/62) is
 later documentation visualization work and does not block this sequence.
@@ -108,9 +118,10 @@ Creative artifact forest:
 Renderflow #421 → #422–#430 → Flow #10 exhaustive comic workflow
 ```
 
-The suite therefore has four useful parallel ready fronts:
-Flow #65 (then #66 after merge and green default-branch CI), Renderflow #415,
-Optiflow #88, and Aniflow #8. Keep provider domain
+The current review checkpoint is Flow #66. After its maintainer merge, the agreed
+Optiflow-first queue is #88 → #89 → #90 → #91 → #92 → #96 → #93, followed by
+#94 → #95. Renderflow #415 and Aniflow #8 remain independent provider fronts.
+Re-query live dependencies before starting any of them. Keep provider domain
 logic in the provider repositories and consume only immutable public contracts
 from Flow.
 

docs/architecture/foundation/ARCHITECTURE.md

@@ -3,7 +3,7 @@ schema: aether.architecture-document/v1
 id: flow-architecture
 title: Flow Architecture
 kind: architecture-document
-version: 0.13.1
+version: 0.13.2
 status: draft
 owners:
   - egohygiene
@@ -140,6 +140,14 @@ not executable plans, authorization tokens, or a second runtime state model.
 Portable reports contain allowlisted identities and typed outcomes; raw operational
 evidence stays local. The lifecycle guide owns recipe coverage and resource limits.
 
+Counter-backed conformance additionally checks that recorded authority and intent
+precede provider launch, accepted work is not relaunched, and unresolved attempts
+require matching recovery authority. Synthetic provider cleanup may fail or be
+cancelled after removing disposable work. Flow preserves the unaccepted candidate,
+unfinished work, and failure history; it does not infer complete cleanup or perform
+automatic compensation. Explicitly acknowledged retries may repeat an uncertain
+effect. These proofs do not establish exactly-once behavior for unconfined providers.
+
 ### External adapters
 
 Adapters isolate process invocation, version/capability probing, structured
@@ -290,7 +298,9 @@ assessment, and explicit recovery decisions described above. Issue #64 requires
 fresh prerequisite evidence for graph assessment and dependent execution without
 adding a scheduler or rewriting accepted history. Issue #65 adds the bounded
 [durable lifecycle corpus](../../integrations/lifecycle-scenarios.md), including
-fresh-process restart and deterministic recovery receipts. Flow does not yet supply
+fresh-process restart and deterministic recovery receipts. Issue #66 extends it
+with authority denials, observable effect counters, and retained cleanup residuals
+using the existing public APIs, without changing runtime schemas. Flow does not yet supply
 the public CLI, real holon adapters, signature or transparency verification,
 provider-native artifact validation, an atomic filesystem snapshot, an
 operating-system sandbox or authenticated enforcement evidence,

docs/integrations/durable-state.md

@@ -3,8 +3,9 @@
 Flow #49 adds a library API for persistent execution of fully prepared process
 steps. It builds on the exact subject, authority, transcript, and artifact gates.
 Flow #64 adds fresh graph eligibility and safe caller-selected dependent
-execution. There is no product CLI or graph scheduler. #31 continues through
-#65 (the [lifecycle corpus](lifecycle-scenarios.md)) and #66 (authority/effect and residual-state proofs);
+execution. There is no product CLI or graph scheduler. #31 is qualified by
+#65 and #66 through the [lifecycle corpus](lifecycle-scenarios.md), including
+authority/effect and residual-state proofs;
 #53 owns the supported CLI.
 
 ## Public entry points
@@ -205,7 +206,7 @@ cover deterministic fresh-root/reopen reports, transitive and branch invalidatio
 all local identity boundaries, complete inventories, stale-report non-authority,
 the single-step bypass, blocked future inputs, and preserved history. The
 acceptance driver includes these test sources in its evidence identity and runs
-them with `--all-targets`, along with the 34-row [lifecycle receipt corpus](lifecycle-scenarios.md)
-from #65. The latter runs every recipe twice, includes fresh-process recovery,
+them with `--all-targets`, along with the 49-row [lifecycle receipt corpus](lifecycle-scenarios.md)
+from #65/#66. The latter runs every recipe twice, includes fresh-process recovery,
 and checks bounded portable reports.
 macOS/Windows CI runs the portable store suite; Linux runs the full provider matrix.

docs/integrations/lifecycle-scenarios.md

@@ -1,7 +1,7 @@
 # Durable lifecycle scenarios
 
-Flow #65 qualifies durable recovery through the public APIs introduced by #49
-and #64. The test-owned corpus lives in `tests/lifecycle_matrix/`, with 34 fixed
+Flow #65 and #66 qualify durable recovery through the public APIs introduced by #49
+and #64. The test-owned corpus lives in `tests/lifecycle_matrix/`, with 49 fixed
 recipes and expected outcomes in `tests/fixtures/lifecycle-scenarios.v1.json`.
 It supplements the [acceptance matrix](acceptance-scenarios.md). It does not add
 a scheduler, a runtime state model, or a new public contract.
@@ -21,6 +21,9 @@ regenerate expected outcomes from observed results.
 | Recovery | Retry cancelled or interrupted work, abandon invalid partial output, refuse unacknowledged or completed retries | Explicit recovery decisions, ordered attempt transitions, preserved uncertain output before retry |
 | Staleness | Input, exact plan, configuration values, provider identity, executable bytes, validator implementation, output bytes | Local stale boundary, downstream invalidation, independent branch reuse, dependent launch refusal without state writes |
 | Store refusal | Changed validation profile, corrupt checkpoint context, checksum mismatch, partial write, future schema, malformed JSON | Exact reopen refusal; no fallback to an older accepted snapshot |
+| Authority | Source mutation, upload, publication, signing, network, paid AI service, destructive action | Declaration denied by unchanged operator lock; exact-profile escalation denied; recorded denial and blocked descendant have zero launches/effects; independent positive control runs once |
+| Effect accounting | Completed reuse after fresh-process restart, stale authority, failed/interrupted retry, replayed recovery decision, explicit abandonment | Persisted authority before launch, observed counters, unchanged completed work, exact authority/attempt correlation, and no launch from approval alone |
+| Cleanup residuals | Cancellation after partial cleanup; actual nonempty-directory removal failure | Reaped direct provider, typed cancellation/failure, absent checkpoint, preserved source/candidate/unfinished work, blocked descendant, and refusal to relaunch on reopen |
 
 The graph fixture is A → B plus independent C, with separate source bindings.
 It proves ordering dependencies and stale-ancestor propagation. The existing
@@ -42,6 +45,14 @@ recipes, frames describe the valid history before fault injection; the final
 history digest identifies the rejected snapshot bytes. No successful reopen or
 new assessment is implied by those frames.
 
+Fixture version `1.1.0` adds an optional closed `outcome.safety` projection for the
+15 #66 recipes. It records ordered launch/effect/cleanup counter observations,
+authority decisions projected to step/attempt/granted, typed refusal codes, and a
+closed residual disposition. Older recipe outcomes remain unchanged. Rust checks
+every authority/recovery identity against the saved plan and compares both fresh
+executions; Python rejects changed or missing safety evidence. This is test-owned
+evidence, not an extension to the durable run schemas.
+
 The fixture preserves originals before deliberate byte corruption and retains
 failed candidates. Interrupted output is moved to a separate retained file
 before an explicitly approved retry. An ignored Rust helper is a subprocess
@@ -63,6 +74,62 @@ retryability policy. Reopening, assessing, or deserializing a receipt grants no
 authority and launches nothing. The [durable-state guide](durable-state.md) owns
 production storage and recovery semantics.
 
+## Authority, effects, and cleanup boundaries
+
+The effect provider writes only a bounded, allowlisted local witness journal and
+synthetic candidate files. Before entering the runner, a cancellation callback
+inspects the actual persisted running snapshot and granted authority while the
+counters are still unchanged. The counters distinguish launches, simulated effects,
+cleanup starts, and disposable items removed. A repeated launch remains visible
+even if a provider later refuses to overwrite an existing candidate.
+
+Seven denial recipes test both declaration-versus-lock resolution and attempted
+per-invocation grant escalation. Each denial is then recorded with `deny_pending`;
+execution of that step and its dependent is refused. Independently authorized C
+executes the same harmless counter mode as a positive control. Upload is represented
+by a network endpoint and paid-service use by an AI-provider grant: v1 has no separate
+upload or billing authorization dimension. These cases perform no real transfers,
+publication, signing, payments, source mutation, or destructive collection actions.
+
+Completed work stays at one launch/effect through reopen, reuse assessment, rejected
+execution, and rejected retry. An uncertain attempt stays at one effect until a
+fresh matching recovery decision explicitly acknowledges uncertainty. Missing
+acknowledgement, changed authorization identity, changed grants, and reuse of an
+earlier recovery decision ID are rejected without history or counter changes.
+Approval alone leaves counters unchanged. A subsequent explicit retry reaches two
+effects while retaining the first candidate. **That second effect is intentional
+evidence of the guarantee's limit:** accepted work is not silently repeated, but
+Flow cannot undo or prove exactly-once external effects from an unconfined provider.
+
+Cleanup happens inside the synthetic provider. It creates a candidate, removes one
+disposable file, and leaves another item unfinished. One recipe cancels after an
+atomic readiness signal; the other encounters a real nonempty-directory removal
+error. Neither gets a checkpoint. Reopening retains the original source, candidate,
+unfinished evidence, and history and requires a recovery decision. Flow provides
+no cleanup scheduler, automatic rollback, or compensation here. Moving a candidate
+aside before retry is an explicit test-operator action, not automatic Flow behavior.
+
+## Parent #31 acceptance reconciliation
+
+| Original criterion | Executable evidence |
+| --- | --- |
+| Compatible resume preserves accepted completed work | `completed-restart`, `partial-restart`, `effect-completed-reuse`; #64 graph reuse tests |
+| Changed/corrupt identity invalidates affected and dependent work | `changed-*`, `corrupt-*`, `effect-stale-authority`; #64 transitive/fan-in/context inventory tests |
+| Retry never silently duplicates accepted or consequential work | `retry-completed`, `effect-completed-reuse`, `effect-retry-failed`, `effect-retry-interrupted`, `effect-recovery-decision-replay`, `effect-abandon-interrupted`; uncertain repeats require explicit acknowledgement |
+| Authority denial precedes prohibited effects | Seven `deny-*` recipes with zero denied/descendant counters and a working independent positive control |
+| Interrupted runs retain bounded inspection/recovery evidence | Host-exit recipes, preserved retry candidates, `cleanup-cancelled`, `cleanup-failed`, and enforced history/artifact budgets |
+| Traces/explanations match #3 durable schemas | Public `RunStore` APIs, validated `RunState` history and `RunAssessment`, typed failures/refusals, allowlisted receipts and privacy canaries |
+| Suite is deterministic, hermetic, budgeted, drift-checked | Every recipe twice in fresh roots, strict Python receipt verification, source identities, kernel limits, and negative report-gate tests |
+
+This completes the synthetic lifecycle proof when #66 is merged. Parent #13 remains
+open for real released-provider integration and the #32/#33/#34 qualification gates.
+
+The [#66 local validation record](../validation/flow-66-local.json) pins the tested
+commit, source identities, report/receipt digests, and executed checks. Rust 1.85
+ran all targets and both corpora; stable Rust ran the lifecycle corpus. Hosted CI
+and macOS/Windows results were not checked for this handoff. Full reports remain
+reproducible with the commands below; the committed record is their compact summary.
+
 ## Running and checking coverage
 
 Populate Cargo's locked cache, then run on Linux:
@@ -124,8 +191,8 @@ This tier qualifies Linux synthetic trusted-unconfined providers. Existing
 macOS/Windows durable-store jobs provide narrower portability evidence. Real
 provider releases, sandbox enforcement, hardware power loss, every crash window,
 provider-native checkpoints, migration, automatic scheduling/retry, and
-exactly-once external effects remain outside this proof. **Flow #66** owns the
-remaining authority transitions, effect counters, and residual cleanup
-qualification. Parent **#31 stays open** until that checkpoint passes. Future
+exactly-once external effects remain outside this proof. **Flow #66** supplies the
+bounded authority/effect/cleanup qualification above. Parent **#31 stays open** until
+its review PR is merged and the acceptance reconciliation is recorded. Future
 scenario visualization in #62 can consume these checked receipts while retaining
 these coverage limits.