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:

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:

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

Inspect member counts:

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:

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:

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.