Skip to content

[FLO-13.4a] Revalidate dependency graphs before durable resume and execution #64

Description

@szmyty

Complete: PR #67 merged as 83f1ea161aa5aba03da5de6b287005252000cd4b; main CI passed. #64 is closed and #65 is dependency-ready. #31 remains open.

Parent: #31
Suite roadmap: #11
Depends on: #49 (merged through PR #63)

Outcome

Provide deterministic, read-only assessment of every step in an immutable durable plan, and require fresh ancestor evidence before executing a dependent step. A recorded successful dependency is historical evidence, not proof that it remains reusable.

Acceptance criteria

  • Add a typed, versioned assessment report tied to the saved plan and state identity, with ready, reusable, invalidated, dependency-blocked, approval-required, and abandoned decisions.
  • Freshly check completed prerequisite inputs, provider/configuration/authority identities, validator identity, and accepted artifacts; propagate stale evidence to all descendants while keeping independent valid branches reusable.
  • Require complete current context inventory and exact expected-plan identity; refuse omissions, mismatches, corrupt state, and attempts to bypass dependency validation through the single-step API.
  • Execute a caller-selected ready step only after recomputing current evidence; serialized assessment reports never grant execution authority.
  • Prove reopen/reuse, branching and transitive invalidation, no repeated successful launches, blocked dependencies, and preserved history with real hermetic providers and deterministic assertions.
  • Update canonical architecture, ADR rationale, schema examples, public API documentation, and required CI checks.

Boundaries

Reuse #49 state and acceptance gates. Assessments describe current eligibility without rewriting accepted history or deleting artifacts. No automatic graph scheduler, cross-plan cache migration, automatic retry, or real provider adapter. Changed plans require a separate explicit future planning/migration path.

Handoff

This is checkpoint 1 of #31. The next checkpoints add the full lifecycle trace corpus and authority/effect/cleanup proofs. Keep #31 open until all three are reconciled.

Verification and next checkpoint

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions