TraceCore Action brings deterministic verification to GitHub Actions

Why this matters

Most CI teams do not want to hand-roll TraceCore setup logic in each workflow. They want one step they can pin, one surface they can trust, and outputs that later steps can consume without custom shell glue.

That is the role of tracecore-action: keep the GitHub Actions integration thin, stable, and aligned with the authoritative runtime behavior in TraceCore itself.

What the action ships

• A stable GitHub Actions wrapper for TraceCore run, verify, and run-and-verify flows.
• Known-good TraceCore version pinning so workflow behavior stays explicit and reproducible.
• Structured outputs like success, run-id, artifact-hash, verify-ok, and verify-report for downstream steps.
• Optional bundle sealing and badge generation for trust and status surfaces.
• Support for strict-spec and replay-bundle gated workflows without inventing action-only semantics.

Copy-paste default

The default path is intentionally simple: run the agent and verify the result in one step, while keeping the underlying TraceCore CLI authoritative.

- uses: actions/checkout@v5
- uses: justindobbs/tracecore-action@v1
  with:
    command: run-and-verify
    agent: ./agents/my_prod_agent.py
    task: filesystem_hidden_config@1
    strict-spec: true

For teams adopting TraceCore across multiple repos, this removes repeated setup work and makes the workflow contract easier to audit.

Built for downstream workflow consumption

The action is not just a launcher. It emits stable workflow outputs so later GitHub Actions steps can make decisions using verified TraceCore state instead of scraping logs.

- id: tracecore
  uses: justindobbs/tracecore-action@v1
  with:
    command: run-and-verify
    agent: ./agents/app_agent.py
    task: filesystem_hidden_config@1
    strict-spec: true

- name: Build downstream summary
  run: |
    cat <<EOF > tracecore-summary.json
    {
      "success": "${{ steps.tracecore.outputs.success }}",
      "run_id": "${{ steps.tracecore.outputs.run-id }}",
      "verify_ok": "${{ steps.tracecore.outputs.verify-ok }}"
    }
    EOF

Trust signals and release posture

The current action contract is intentionally narrow. It stays thin over the CLI, targets known-good TraceCore versions, and uses @v1 as the stable major channel while still allowing immutable tags like @v1.0.1 for exact reproducibility.

• Validated workflow shapes include basic smoke, run-and-verify, and app-shaped downstream consumption.
• The published action contract was exercised from a separate consumer repo rather than only from source-repo CI.
• Badge generation and wrapper outputs were covered in tests and external validation scenarios.

Where it fits in the TraceCore stack

tracecore-action is the GitHub entry point, not a second runtime. Runtime semantics, verification rules, and spec contracts still live in TraceCore itself. The action exists to make adoption inside GitHub Actions simpler and safer, especially for teams that want a documented integration surface instead of bespoke shell scripts.