codex-mmo/docs/ACCEPTANCE.md

# Release acceptance

A Codex MMO release is acceptable only when the source tree, generated archives, and cleanly extracted archive trees all represent the same package.

## Required gates

Run from the project root:

```bash
make clean-bytecode
make test
make validate
make release
```

`make test` runs the offline integration suite. `make validate` checks required files, source syntax, configuration syntax, profile semantics, model inventories, output contracts, package safety, catalog reproducibility, and the integration suite. `make release` repeats validation, builds deterministic tar.gz and ZIP artifacts, verifies every archived file against the staged file manifest, and performs a second build to confirm byte-for-byte reproducibility.

A successful source release must satisfy all of the following:

- Every bundled profile resolves and compiles into a content-addressed snapshot.
- The installed Codex binary is exactly 0.149.0 and its 401 generated experimental schema files
  match the pinned digest, including Unix host, thread/goal/turn/history/control, pending-input,
  elicitation, and approval request/response contracts.
- Every role receives the snapshot's exact generated `AGENTS.md`. Spawn- or control-capable roles receive the registered orchestration `SKILL.md`; true leaf homes do not materialize it, and leaf config layers explicitly disable the inherited skill. Leaf guidance declares the no-spawn/no-control boundary, and changed guidance changes snapshot identity.
- The bundled set is exactly eight featured workload profiles plus four documented experimental labs; retired IDs have no aliases, compatibility readers, or install-time migration.
- Every profile has a nonredundant purpose, a justified exact route-qualified model assignment, and a matching smoke/evaluation scenario.
- Native-agent, Agent-MCP, and hybrid capabilities are represented where their enforcement trade-offs fit; no pure-native profile is required merely to exercise a mode.
- Tool MCP definitions remain operator-owned, profile grants can only narrow finite tool allowlists, snapshots contain no credential values, and generated native-role overlays do not widen authority.
- Low-trust roles are mechanically restricted.
- Native-only roles do not claim strict contract enforcement, and no profile documents an advisory native control as an MCP guarantee.
- Roots use dependency-only waiting instructions; spawn- or control-capable generated guidance describes
  inspect/trace/steer/interrupt/pause/continue/detach/stop/finalize/compact/respond/effort/fork controls;
  write-heavy MCP work has at most one active worker writer or read-only workers; and bounded
  nesting cannot exceed declared depth/budget.
- Every root and Agent-MCP worker uses a non-ephemeral Unix app-server thread, authoritative event
  and terminal history, goal/turn lifecycle, warning-only stall policy, bounded explicit
  finalization, exact-thread recovery, `suspended` continuation, and partial-result retention.
- Mutating controls serialize revision assignment through delivery; a lost reply after delivery
  begins is retained as `delivery_unknown`, not rewritten as a definite rejection or failure.
- Interactive and noninteractive roots use the same app-server host; the TUI is a remote client.
  An external harness wall limit detaches while work continues, and pause, continue, detach,
  graceful full-stop, and immediate cancel have distinct tests.
- Positive decomposable evaluation tasks require their intended reachable MCP roles, while negative controls remain free to reject unnecessary delegation.
- Required multimodal roles preserve image input through the complete compiled transport, and the visual evaluation carries a real reference image.
- The release-time OpenRouter, OpenCode Zen/Go, Z.AI, Z.AI Coding Plan, and Codex inventories match their hash-checked common snapshots and the generated catalog baseline.
- Python, shell, TOML, and JSON files parse successfully.
- No credentials, private keys, unresolved template markers, development markers, bytecode, or symlinks are present.
- The release tree includes the runtime, CLI, catalog, profiles, documentation, evaluations, tests, installer, and uninstaller.
- Tar and ZIP member names, exact permission modes, sizes, and content hashes match the staged release tree.
- Archive member-count and expanded-byte ceilings are enforced progressively during streaming tar inspection/extraction and bounded ZIP extraction.
- Repeated builds with the same source epoch produce identical archive hashes.
- Remote TUI launch passes the PTY color, foreground-process-group, live-resize, and host-retention regression test.
- Every external selected model has an exact startup catalog slug and validated context, reasoning, modality, and patch-tool metadata.
- Mixed built-in/external native-agent processes preserve the active Codex bundled catalog while adding generated external route rows.
- Every featured suite provides matched configured-root, strongest-single, accessible-service, root-plus-worker, full-profile, and complete worker-ablation evidence; release evaluation uses five trials per task.
- Worker results use explicit read/accept/reject/integrate states, and delegated writer patches cannot reach the canonical workspace without accepted, audited integration.
- OpenRouter policy and telemetry distinguish the aggregator route from the actual serving provider, and incomplete route identity fails featured promotion.
- API dollars, API-equivalent estimates, subscription units, and local resource time remain separate ledgers with no aggregate score.
- Every MMO-owned document uses exact schema 8 and, where applicable, exact package/profile version
  8.0.0. Other generations are rejected at load time without mutation, compatibility inspection,
  alternate host, fallback, or migration. No redundant lifecycle-version field exists. Exactly one
  immutable run exists per session and terminal sessions do not resume.
- A generation-8 immutable snapshot whose resolved profile is not generation 8 is rejected before
  its policy can be interpreted by the current runtime.

## Archive verification

The release builder writes a generation-8 `PACKAGE-MANIFEST.json` inside each archive. The manifest records every packaged source file, normalized mode, size, SHA-256 digest, aggregate file count, and total payload bytes. The verifier compares exact permission bits rather than only executable status and calculates a deterministic tree digest over paths, modes, sizes, and bytes.

Verify externally supplied artifacts with:

```bash
sha256sum -c codex-multimodel-orchestrator-8.0.0-SHA256SUMS.txt
```

Inspect member counts:

```bash
tar -tzf codex-multimodel-orchestrator-8.0.0-linux.tar.gz | wc -l
unzip -Z1 codex-multimodel-orchestrator-8.0.0-linux.zip | wc -l
```

Extract each archive into a separate empty directory and run:

```bash
make test
make validate
```

The extracted package must pass the same gates as the source tree.

## Live acceptance

Offline acceptance proves package integrity and orchestration semantics without consuming provider quota. Deployment acceptance additionally requires credentials and reachable endpoints:

```bash
codex-mmo validate --all-profiles
codex-mmo tool-mcp validate
codex-mmo catalog verify --remote --codex
codex-mmo doctor --profile adaptive-engineering --live --probe
codex-mmo profile smoke adaptive-engineering --cwd "$PWD"
```

Repeat live smoke tests for every profile intended for production. A provider account may expose a different live inventory from the release-time baseline; refresh catalog overlays only after reviewing the discovered models and capabilities.

## Acceptance evidence

For a formal release, retain:

- Test and validation output.
- The generated validation JSON report.
- Both release archives.
- The checksum file.
- Archive member counts.
- A clean-extraction comparison report.
- Live doctor and smoke results for deployed profiles.

Live provider checks are deployment evidence and are not substituted by offline tests.