Skip to main content

Day-in-the-life workflows

FleetForge’s “Hello Fleet” storyline covers both the individual contributor (IC) loop on a laptop and the ChangeOps gate that runs on every pull request. Use this guide when you need a concrete, reproducible path for fleetforge-ctl receipts, verification, replay, and CI evidence.

IC workflow (local dev)

  1. Run the canonical demo once
    Bring up the demo runtime (just demo or the quickstart Compose stack), submit the Hello Fleet DAG, and capture the printed RUN_ID. Keep that ID handy and reuse it everywhere (CLI, /demo, receipts, replay).

    # export a signed receipt (choose any manifest path under build/ or tmp/)
    fleetforge-ctl receipt --run-id "$RUN_ID" --manifest "build/receipts/${RUN_ID}.c2pa.json"

    # verify an artifact + manifest locally
    fleetforge-ctl verify tmp/hello-fleet/artifacts/demo-output.bin \
    --manifest tmp/hello-fleet/artifacts/demo-output.bin.c2pa.json

    # prove determinism
    fleetforge-ctl replay "$RUN_ID"
  2. Tighten a guardrail and re-run
    Flip the budget preset or run the agent_team_openai variant so you intentionally trip a policy denial. This yields the policy_decisions artifact, surfaces the signed TrustDecision, and gives you a concrete “bad path” that CI can catch later.

  3. Understand the evidence you just generated

    • Receipts are C2PA Content Credentials bound to each artifact, so verifiers can audit “who did what/when” without your runtime.
    • fleetforge-ctl verify walks the manifest + capability-token chain locally; pair it with fleetforge-ctl replay to surface drift (tokens, spend, or tool I/O) immediately.
    • Telemetry follows the OpenTelemetry GenAI semantic conventions (with trust.* attributes) so downstream collectors label runs with attestation IDs, capability tokens, and policy verdicts.
  4. Optional – sign like prod
    Local dev defaults to the env-ed25519 signer. When you need parity with production, point the CLI at AWS/GCP/Azure KMS via the existing shims (FLEETFORGE_TRUST_SIGNING_KEY, FLEETFORGE_SCITT_*, etc.) without changing the workflow above.

CI gate (pull requests)

Treat every pull request as two checks that run back-to-back:

  1. ChangeOps decision (policy/evidence gate) – Pipelines build a JSON bundle (diff summary, novelty, eval coverage, replay/canary telemetry, budget deltas) and request a ruling:

    fleetforge-ctl gates check --input change.json --json decision.json

    The gate returns allow, follow_up, or deny. Missing replay evidence or thin coverage yields structured reasons (for example “coverage below minimum” or “missing replay telemetry”) so CI can fail fast. Gate inputs should include:

    • Replay telemetry with attestation_match=true, tool_io_match=true, and ≤1% token drift.
    • Canary/promote telemetry listing the attestation IDs it observed so reviewers can trace what passed or failed.
  2. Receipts-as-gates (artifact/replay verifier) – A GitHub Action (or equivalent) fetches fleetforge-ctl receipt --run-id … plus replay stats, enforces drift thresholds (defaults: 1% tokens, 0.5% cost), and posts an attestation diff on the PR if anything moved. Pair it with the step above (details in Receipts-as-gates).

Operational knobs you’ll set once

  • Apply core/storage/migrations/0014_changeops_gates.sql and rotate the CI service token that calls gates check.
  • Export gate decisions to your observability stack so reviewers can correlate incidents to specific gate_ids.

Transparency hooks

  • Emit SCITT statements or store receipts in a transparency log by enabling the FLEETFORGE_TRANSPARENCY_* env vars; local runs can stub these while production points at HTTP-backed logs.

Putting it together

On a laptop: run Hello Fleet → export receipt → verify → replay (no drift) and capture one intentional guardrail denial. On every PR: assemble change.jsongates check returns allow/follow_up/deny → the receipts/verifier action enforces replay + receipt quality → PR blocks when evidence is missing or drift exceeds thresholds.

Why this matters to Security/Risk

The gate enforces controls mapped to OWASP’s LLM Top-10 (prompt-injection guardrails, tool ACLs, output handling) and surfaces receipts plus replay evidence as proof—not just logs—so Risk/Security reviewers inherit deterministic, auditable workflows.