Skip to content

Deliver a small in-process flow manager in GoBatch #97

Description

@MasterOfBinary

Product decision

Build flow/ inside GoBatch. This is a committed direction chosen for ShitQuant and similar applications, replacing the earlier recommendation to use OnyxCore. Do not delete/archive OnyxCore or make it a dependency.

Flow runs a finite graph for one input: sequential and parallel functions, dependencies/fan-in, conditions, bounded execution and explicit outcomes. Nodes may call ordinary adapters or a shared RequestBatcher; neither API requires the other.

Delivery

The first two outcomes complete the standalone flow deliverable. Track the optional combined integration separately rather than falsely requiring request batching first.

Acceptance

ShitQuant-shaped enrichment returns an immutable proposal after explicit evidence checks; another provider-independent example demonstrates generic composition. Graph/node results stay isolated across concurrent runs; admission/readiness/execution are bounded globally per runner; failure, skip, cancellation and shutdown semantics are testable. A release can be pinned by ShitQuant and checked against its direct-call/replay baseline.

Scope boundary

No cron, persistence, job database, distributed workers, broker, web UI, plugin/type registry, automatic transaction retries or Airflow control plane. User functions are ordinary Go code; no compulsory Processor[T] adaptation or concurrent mutation of a shared Analysis object.

Flow design. This epic is not an executable implementation issue or a prerequisite to start ShitQuant's recorder/paper baseline. It is independent of profitable trading results.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementtype:epicTracking issue; execute its scoped children

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions