The Runtime

One Graph, Many Pipelines

A workflow builds a DAG of nodes. Each fan-out child wraps the full plan/execute/review pipeline for one project. The graph is validated before any node runs, so a malformed graph fails before any model spend. Bounded concurrency and a per-run token budget act as circuit breakers: when the budget trips, in-flight nodes finish, nothing new is scheduled, and the run is marked rather than crashed. A failed node skips its descendants while independent branches continue.

flowchart TD
    P["Workflow profile
(committed JSON catalogue)"] --> B["Build + validate graph
DAG check, budget breaker"]
    B --> F["Fan-out: one audit node
per enrolled project"]
    F --> A1["audit/agentos-dashboard"]
    F --> A2["audit/salesforce-cicd-blueprint"]
    F --> A3["audit/salesforce-dev-tools"]
    A1 --> V1["verify"]
    A2 --> V2["verify"]
    A3 --> V3["verify"]
    V1 -.->|"fail: one bounded re-run
at reduced scope"| A1
    V1 --> C1["challenge (opt-in,
advisory only)"]
    V2 --> G
    V3 --> G
    C1 --> G["gather: consolidated report
in declared order"]

    %% Blueprint tokens as literal hex (Mermaid cannot parse CSS vars or color-mix)
    classDef code fill:#62d99a1f,stroke:#62d99a,color:#dfe4ee,stroke-width:1.5px;
    classDef model fill:#8b93e81f,stroke:#8b93e8,color:#dfe4ee,stroke-width:1.5px;
    classDef entry fill:#e0be621f,stroke:#e0be62,color:#dfe4ee,stroke-width:1.5px;

    class P entry;
    class B,F,V1,V2,V3,G code;
    class A1,A2,A3,C1 model;
    

Purple nodes run models. Green nodes are deterministic code. The verifier and the gather never call a model; the challenger is model-backed but can only add caution, never change a verdict.

The Verifier Is Code, Not a Model

Each audit node feeds a verifier node that re-checks the output deterministically: did the run actually complete and emit final JSON, does the report validate against the schema, and does every finding's anchor text resolve verbatim against the file on disk. A run that silently ran out of budget is a verification failure routed to a bounded re-run at reduced scope, not a clean pass. A clean zero-findings run with completion proof passes honestly.

The four failure domains are a locked taxonomy, exported and smoke-tested. A finding the model cannot anchor to a real line of source is rejected before it reaches a report. This one gate killed the runtime's worst failure mode: audits that looked clean because the model never finished.

Failover Routes, Not Single Models

Every pipeline stage resolves to an ordered model route: preferred first, then failovers. A transient provider error (429, 5xx, network) restarts the stage on the next model in the route; a real error (schema, validation, safety gate) is rethrown immediately rather than papered over. Stage telemetry records the chain of attempted models, so a run that survived an outage says so. Routes were born from a real incident: free-tier rate limits blocked the first portfolio run, and the fix was architecture, not retries.

Apply Is a Replay, Never an Improvisation

The runtime never writes source during an audit. A fix is applied later, by replaying a saved, verifier-passed report through a deterministic apply engine. Dry-run is the default; a real write requires an explicit flag and then survives a chain of gates enforced in code. Anchor matching is CRLF-aware (content is compared LF-normalised and written back in the file's native line endings), because the first real apply candidate was blocked by exactly that mismatch.

flowchart TD
    R["Saved audit report
(verifier-passed findings)"] --> RP["Replay:
--apply-from-code-report"]
    RP --> D{"Mode?"}
    D -->|"default"| PV["Dry-run preview
no write possible"]
    D -->|"--apply-write"| G1{"Inside FS_ROOTS allow-list?"}
    G1 -->|"no"| X["Rejected: no write"]
    G1 -->|"yes"| G2{"Working tree clean?"}
    G2 -->|"no"| X
    G2 -->|"yes"| G3{"Anchor matches source?
(CRLF-aware)"}
    G3 -->|"no"| X
    G3 -->|"yes"| W["Apply the fix"]
    W --> G4{"Declared build gate passes?"}
    G4 -->|"no"| RV["Revert, native EOLs preserved"]
    G4 -->|"yes"| L["Append-only apply ledger"]

    %% Blueprint tokens as literal hex (Mermaid cannot parse CSS vars or color-mix)
    classDef entry fill:#e0be621f,stroke:#e0be62,color:#dfe4ee,stroke-width:1.5px;
    classDef gate fill:#e0be621f,stroke:#e0be62,color:#dfe4ee,stroke-width:1.5px;
    classDef code fill:#62d99a1f,stroke:#62d99a,color:#dfe4ee,stroke-width:1.5px;
    classDef fail fill:#e697521f,stroke:#e69752,color:#dfe4ee,stroke-width:1.5px;

    class R entry;
    class D,G1,G2,G3,G4 gate;
    class RP,PV,W,L code;
    class X,RV fail;
    

Four Workflows on One Engine

Workflows are catalogued in a committed JSON registry with a hardened contract: profiles are descriptive metadata, an executable profile must map to a real workflow defined in code, and no JSON field can grant apply or execution authority. The registry is validated before any model call; a field that even looks like an authority grant throws at load. Project enrolment lives in a second committed registry, so adding a project to the portfolio is a reviewed git change.

Durable, Local, Honest About It

Underneath the runtime sits a local platform layer: a SQLite run ledger and queue (better-sqlite3, WAL) dual-written alongside the canonical JSONL telemetry, behind an async interface that could later point at a hosted database without touching callers. Store reads are opt-in with strict JSONL fallback. Queue payloads are secret-free by construction; the worker injects credentials at drain time. Orphaned store rows are retained and reported, never fabricated into fake history.

Validated Live