Skip to content

[EPIC] Finish the flow suite and prove production-ready orchestration #11

Description

@szmyty

Outcome

Finish the four-tool Flow suite to a production-usable, independently releasable milestone and prove that Flow can orchestrate the holons without collapsing their boundaries.

This epic is the suite-level source of truth for sequencing work across:

What “finished” means here

The core finish line is not “no future ideas can ever be added.” It means:

  1. Each holon is independently installable, testable, documented, and releasable.
  2. Public provider/CLI contracts are versioned and usable without source coupling.
  3. Flow can inspect, plan, execute, validate, explain, interrupt, and resume real multi-holon work.
  4. The current known completion backlog is either shipped, explicitly superseded with evidence, or moved to a clearly named post-v1 milestone.
  5. At least two representative end-to-end fixtures prove the suite:
    • a static publication/comic release;
    • a time-based media release with animation/audio analysis.
  6. Releases, docs, sites, manifests, and CI all tell the same version/capability truth.

This epic also tracks the exhaustive closeout needed to finish renderflow#367; it must not be closed merely because one happy-path demo runs.

Live baseline snapshot

Observed on 2026-09-13. Re-query before every implementation branch; these SHAs are evidence pins, not permanent assumptions.

Repository Observed main Baseline truth Active anchors
flow 3367fc3b9576d0102ea92df5cadf86d83c4ad854 No open PRs and no recent workflow-run evidence observed #3, #10
renderflow 58aa2cad8ba9e2374d0e7a1bf5277052ae40838c Main is red on Clippy and generated-doc drift renderflow#407, renderflow#367, renderflow#406
optiflow f04c82a0b0c677a2939ea351c4219602cd7181af Main checks and the observed signed-binary release workflow are green optiflow#51, optiflow#29, optiflow#28
aniflow 20ff9f87c2500a3b9727954d0e4b4758e2c9b3ea Main validation is red on the product-name policy check aniflow#15, aniflow#11, aniflow#8, aniflow#13, aniflow#10

No open pull requests were observed in any of the four repositories at the snapshot.

Non-negotiable architecture boundaries

  • Flow owns cross-holon orchestration, run state, recovery, and explanations.
  • Renderflow, Optiflow, and Aniflow remain independently useful products.
  • Integration occurs through versioned public APIs/CLIs and immutable artifacts, never source-tree imports.
  • A process exit code or file-exists check is not sufficient proof of success.
  • Plans and manifests must state inputs, outputs, tool/provider versions, checksums, diagnostics, and provenance.
  • Interruption and retry must not silently duplicate completed work.
  • Upload, publication, mutation, signing, and other consequential side effects remain explicit authority boundaries.
  • Every issue is implemented and reviewed as a bounded unit; this epic is not authorization for one cross-repository mega-PR.

Roadmap

Wave 0 — restore repository truth

Nothing later may claim a stable suite while a provider's default branch is red or its build evidence is absent.

  • Finish renderflow#407: restore Clippy and generated-document checks without weakening gates.
  • Finish aniflow#15: reconcile the lowercase product-name policy and restore validation.
  • Reconfirm Optiflow's green build, tests, docs/site checks, security checks, and signed release from a fresh checkout.
  • Reconcile optiflow#28 against the actual deployed site/DNS/TLS state; close with evidence if already delivered rather than rebuilding it.
  • As part of flow#3, establish repeatable Flow CI evidence before declaring the vertical slice complete.

Wave 1 — stabilize the provider seams

Optiflow and Aniflow contract work can proceed independently once their own baselines are green.

  • Finish optiflow#51: safe plugin/provider SDK for inspectors, analyzers, planners, and validators.
  • Finish aniflow#11: provider SDK, temporal hooks, and the bounded pipeline migration it owns.
  • Re-verify Renderflow's public provider/capability boundary under renderflow#367; open a focused follow-up only for a demonstrated gap.
  • Record a Flow compatibility matrix that pins provider contract versions and capability negotiation behavior.
  • Keep holon-specific algorithms in their repositories; do not “finish faster” by moving them into Flow.

Wave 2 — prove the orchestration kernel

  • Finish Implement a versioned cross-holon orchestration vertical slice #3 using at least Optiflow and Renderflow as independent providers.
  • Demonstrate inspect → plan → transform → validate with immutable input/output references.
  • Demonstrate interruption, persisted run state, resume, retry, and a deliberate failure explanation.
  • Add conformance fixtures for unavailable capabilities, partial output, invalid output, and provider-version mismatch.
  • Ensure structured output and exit semantics are stable enough for automation.

Wave 3 — complete the provider capabilities needed by real products

These can be developed in parallel where their issue dependencies allow.

Wave 4 — close Renderflow's exhaustive artifact roadmap

Track this work through renderflow#367, not through duplicate umbrella issues.

  • Finish renderflow#378, then integrate it through renderflow#379.
  • Finish renderflow#350: Slidev presentation profile.
  • Finish renderflow#349: repository briefings and podcast derivatives.
  • Finish renderflow#397: Sonic DNA.
  • Re-run the maximal/exhaustive artifact profile against the golden corpus.
  • Close renderflow#367 only after its remaining issue set and final Flow integration evidence are reconciled.

Wave 5 — prove real release workflows

  • Finish [Publication] Orchestrate exhaustive comic finalization and multilingual release workflows #10: orchestrate comic finalization, layered/textless sources, optimization, localization, exhaustive artifacts, preflight, and ship-readiness evidence.
  • Prove a static publication fixture through Flow + Optiflow + Renderflow.
  • Prove a time-based fixture through Flow + Aniflow + Renderflow; include Optiflow where poster/frame assets make it semantically appropriate.
  • Validate clean-room resume behavior by interrupting each fixture after at least one completed provider step.
  • Validate negative cases: missing source, unavailable tool, invalid locale, corrupt artifact, insufficient print quality, and provider-version mismatch.
  • Store expected manifests and normalized evidence as reviewable fixtures without checking in inappropriate large generated binaries.

Wave 6 — release and distribution truth

  • Finish aniflow#10 only after its external policy/release dependencies are re-verified live.
  • Confirm Optiflow's released version, install path, site, docs, and repository metadata agree.
  • Define a bounded Flow release-hardening issue after Implement a versioned cross-holon orchestration vertical slice #3 exposes the real public contract; do not speculate its version surface prematurely.
  • Define the corresponding Renderflow release closeout from renderflow#367 evidence.
  • Smoke-test all four tools from immutable released artifacts, not workspace source imports.
  • Publish a version/capability compatibility table and rollback instructions.

Wave 7 — governance convergence

The ADR backfill issues are deliberately gated. Do not execute them merely because they are old or open.

  • Re-verify every external prerequisite on flow#9, renderflow#405, optiflow#60, and aniflow#14.
  • Run the shared ADR backfill only after the common schema, index, validation, and repository-policy gates are truly available.
  • Reconcile architecture, decision, roadmap, security, release, and operational documents after implementation truth is stable.

Recommended execution order

For sequential work, use this order unless a freshly observed dependency changes it:

  1. renderflow#407
  2. aniflow#15
  3. optiflow#51
  4. aniflow#11
  5. flow#3
  6. renderflow#406
  7. optiflow#29
  8. aniflow#8
  9. aniflow#13
  10. renderflow#397
  11. flow#10
  12. remaining renderflow#367 profiles
  13. release closeout
  14. gated ADR convergence

Items 1 and 2 can run independently. Items 3 and 4 can run independently after their repository baselines are green. Re-query repository state before relying on this order.

Suite definition of done

  • All four default branches have required, reproducible green validation.
  • Each tool installs and runs independently from an immutable released artifact.
  • Public contracts and structured output have compatibility/version rules.
  • Flow proves real multi-holon planning, execution, validation, explanation, interruption, and resume.
  • Static-publication and time-based fixtures pass positive and negative acceptance suites.
  • Manifests capture checksums, tool/provider versions, provenance, diagnostics, and validation evidence.
  • Documentation, sites, release metadata, and observed binaries agree.
  • The open issues named by this epic are closed, superseded with evidence, or explicitly assigned to a named post-v1 milestone.
  • No provider depends on another provider's source tree.
  • No consequential external side effect occurs without explicit authority.
  • The final completion report links exact commits, releases, workflow runs, fixtures, and any intentional deferrals.

Working protocol

For each child issue:

  1. Read the repository instructions and the architecture/decision/roadmap documents required by them.
  2. Re-check main, open PRs, current CI, and the child issue's dependencies.
  3. Pin the starting commit.
  4. Implement one bounded issue on one branch.
  5. Run repository-local checks plus the relevant contract/conformance suite.
  6. Open one focused PR; do not merge it automatically.
  7. Update this epic with links and newly discovered dependency changes after review/merge.

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