# Spice Agent Phase 0 compatibility evidence

This is a dated compatibility and verification snapshot, not a second
implementation roadmap. Product status and sequencing remain owned by the
[canonical Spice Agent implementation ledger](https://github.com/spice-framework/spice-agent/tree/main/docs/implementation).

## Exact source inputs

The catalog dependency graph and generated workspace include all five Spice
Agent repositories. On 2026-08-06, `origin/main` resolved to:

| Repository | Exact commit |
|---|---|
| `spice-agent` | `1f072842707a5609d811eef3e4858badcc73e7ea` |
| `spice-agent-provider-openai` | `b0d4099d2754f05cc5e8d363e9c853085414e95b` |
| `spice-agent-tools-coding` | `d06a11929ddbc9a9c005eeae69b894c9b2f64b10` |
| `spice-agent-tui` | `7eff972015e69367492fbaf99f8d179d25aadcab` |
| `spice-agent-coding` | `16244f51cecdc66a86ab4721dc276edbc78c47ae` |

The selected module boundaries at those commits are explicit rather than
inferred from moving branches:

- `spice-agent` and `spice-agent-tui` select Spice core
  `v0.1.0-preview.1.0.20260806200749-524424a04df0` and toolchain
  `v0.1.0-preview.1.0.20260806203056-d0b9ac086bd6`.
- `spice-agent-provider-openai` and `spice-agent-tools-coding` still select
  Spice core/toolchain `v0.1.0-preview.1` and Spice Agent
  `v0.0.0-20260806191411-841edd3d47ad`. That older reviewed boundary is a
  recorded compatibility fact, not permission to silently upgrade it.
- `spice-agent-coding` selects the same result-facts core/toolchain pair as
  `spice-agent`, Spice Agent
  `v0.0.0-20260806204214-1f072842707a`, provider
  `v0.0.0-20260806204218-b0d4099d2754`, and coding tools
  `v0.0.0-20260806202006-d06a11929ddb`. Its current module graph does not yet
  select `spice-agent-tui`; catalog ownership and a compiled distribution
  dependency are intentionally reported as separate facts.

## Fast-check ordering

`spice-dev verify` executes the selected dependency graph in topological waves.
Repositories within one ready wave run concurrently up to `--jobs`; a dependent
does not start until all selected dependencies complete successfully. A focused
selection treats unselected ancestors as externally satisfied, so this command
checks the five-repository slice without rerunning the complete framework:

```text
go run ./cmd/spice-dev verify --root .. --jobs 4 --repo spice-agent --repo spice-agent-provider-openai --repo spice-agent-tools-coding --repo spice-agent-tui --repo spice-agent-coding
```

## macOS evidence boundary

The exact commits above are cross-compiled with Go 1.26.5, `CGO_ENABLED=0`,
`GOWORK=off`, `GOPROXY=off`, and the committed vendor graph for both
`darwin/amd64` and `darwin/arm64`. This proves that the selected Go packages
compile for those targets; it is not a macOS execution result.

The 2026-08-06 evidence run used clean detached temporary checkouts at every
commit in the table. The dependency-ordered five-repository fast command passed
(`spice-agent`, then the concurrent provider/tools/TUI wave, then
`spice-agent-coding`), followed by successful
`go build -mod=vendor -trimpath ./...` for every repository on both Darwin
architectures. No product worktree
or module graph was changed by the evidence run.

A real macOS runner remains mandatory for the race detector, process and signal
lifecycle, terminal/UI behavior, filesystem semantics, and executable runtime
acceptance. Those claims must never be inferred from cross-compilation.

## Hosted mirror status

Local repository-owned verification is the delivery gate. Hosted GitHub Actions
runs that remain queued because of the organization billing/policy state are an
unfinished, nonblocking durability mirror: they are neither failures nor green
runs, and this snapshot does not claim they executed. The historical release
queue and its immutable candidates remain recorded in
[`release-continuation.md`](/project/ecosystem/release-continuation/).