# Codex Implementation Flow

## Project configuration

The project configuration is `.codex/config.toml`. It selects GPT-6-Sol with
medium reasoning for the primary coordinator and GPT-6-Luna with high reasoning
as the default for spawned agents. Custom project agents are discovered from
`.codex/agents/`:

| Agent         | File                             | Responsibility                                      |
| ------------- | -------------------------------- | --------------------------------------------------- |
| `implementer` | `.codex/agents/implementer.toml` | Implement a bounded task and focused tests          |
| `reviewer`    | `.codex/agents/reviewer.toml`    | Independently review actual changes without editing |
| `repairer`    | `.codex/agents/repairer.toml`    | Resolve findings and provide regression evidence    |
| `explorer`    | `.codex/agents/explorer.toml`    | Optional read-only prerequisite research            |

All four custom agents explicitly select GPT-6-Luna/high. There is no separate
coordinator subagent: the primary session is the coordinator. At most three
spawned threads run concurrently, but file ownership defaults to one writer.

## Starting work

Open a fresh Codex session in this project, using a client that supports the
documented project configuration and custom agents. Project trust, managed
requirements, and explicit client/session overrides can affect which settings
are applied. Verify the coordinator and spawned-agent model/effort settings in
the client before implementation; report unavailable models rather than silently
substituting alternatives. Existing sessions are not reconfigured by these files.

An example execution request is:

> Execute the next pending milestone in PLANS.md. Use implementer for bounded
> implementation, a fresh reviewer for independent review, and repairer for
> findings. Repeat review and repair until the acceptance gates pass, update
> PLANS.md with evidence, and stop after accepting this milestone or recording
> a concrete blocker. Use explorer only when prerequisite research is needed.

For an explicitly authorized full-plan run, continue to the next milestone only
after the current one is accepted. Do not confuse this project's Commit action
with permission to create Git commits.

## Flow and limitations

The root instructions define prepare, implement, review, repair, re-review, and
acceptance. PLANS.md is the durable record of milestone/task IDs, ownership,
progress, findings, validation, and blockers. The TOML files configure model
selection and agent instructions; they do not implement a deterministic workflow
engine or automatically start execution.

Reviewer/explorer read-only behavior is an instruction boundary, not a distinct
OS sandbox. Custom agents inherit the parent's permission controls. This setup
does not change sandbox, approvals, provider, MCP access, or user-level trust.

Container tests require a disposable Alpine Testcontainers environment, and real
systemd validation requires a separate disposable VM; see [TESTING.md](TESTING.md).
No role is authorized to experiment on production.

## Verification status

The files were parsed as TOML and checked for consistent role names and requested
model/effort values. A live model session and subagent dispatch were not started.
The installed CLI reports version 0.161.0. Its `features` command does not support
`--strict-config`, so that command cannot establish complete schema validation.

Official references:

- [Subagents and custom agent files](https://learn.chatgpt.com/docs/agent-configuration/subagents)
- [Configuration reference](https://learn.chatgpt.com/docs/config-file/config-reference)