A two-role Codex workflow from specification to CI

Why use two roles

An agent that wrote a change carries the same context and assumptions into self-review. A second role does not guarantee correctness, but it creates a separate critical step grounded in the specification and observable artifacts.

The split only works when the roles have different contracts. Two sessions following the same broad instruction do not create quality control.

The working contract

The implementation role receives scope, acceptance criteria, and allowed changes. The verification role receives the same criteria without the author's internal assumptions. It must point to evidence: a test, diff, log, or reproducible scenario.

specification → implementation → independent review → CI → human decision

What CI should cover

• formatting, lint, and types;
• unit tests for critical behaviour;
• data-contract validation;
• a browser test of the user journey;
• version and limitation records.

CI does not judge product value. It provides repeatable external evidence that one version satisfies its technical contract.

Common failure modes

The first is scope expansion during implementation. The second appears when review comments on style but never executes the acceptance scenario. The third is green CI backed by tests that do not touch the changed path.

Where the pattern helps

This workflow is useful for tasks with an explicit contract and testable outputs. When product direction remains unresolved, an owner decision is needed before more agents are added.