Use the actual Codex built-in roles

Understand the approach

Codex's documented built-in roles are default, worker and explorer. Choose by the task's immediate purpose rather than importing Claude role names. An explorer can trace current behavior and cite the responsible code; a worker can implement an agreed change; the parent or default agent can coordinate and reconcile results. Inspect custom definitions before relying on a built-in name, because a custom role with the same name takes precedence.

In the capstone, exploration should locate both independent defects: missing trim in starter/normalize.cjs and the all-task reduction in starter/report.cjs. It should connect those expressions with the actual baseline result and frozen interface. Implementation then has concrete scope. Package A handles string normalization and its errors; package B validates normalized records and computes completed-only effort. Neither needs an extra specialist merely to rename a role.

After implementation, verification examines the actual combined files. run.cjs starter must return total=4, done=2 and doneMinutes=55. candidate.test.cjs must pass its four learner tests, including cases independent of the main fixture. The separate seven-test reference suite preserves the frozen baseline and checks the supplied solution. Report these different checks clearly. A role label, worker completion message or green reference suite does not establish that the edited starter is correct.

Make role choice a testable assignment. An explorer explains why padded DONE misses the done comparison and why the all-task reduction produces 80, citing the actual starter lines. Workers implement the two frozen contracts. The parent/default agent checks both diffs and runs the combined candidate plus independent invalid-input cases. The guide gives current app, CLI and IDE thread controls, so you can inspect actual delegation rather than merely repeat a role label. If a custom explorer shadows the built-in, preserve its source with the result instead of attributing its behavior to the default role.

Practice and acceptance

Role selection should follow the current stage: evidence gathering, bounded implementation and integrated review.

Try it step by step

1. Reproduce the starter result and identify which facts an explorer would need to establish.
2. Read both module contracts before assigning an implementation role.
3. Fix A and B in the disposable starter or request workers with those owned files through actual Codex delegation.
4. Have the parent review the combined diff and run the integrated candidate.
5. Report observed role activity only if actual agents ran; keep the local reference checks distinct.

A useful starting example

Illustration · adapt before use.

In labs/delegation-capstone, use an explorer or direct read-only inspection to explain the two baseline defects with source references. After reviewing that evidence, have workers implement the separate A and B contracts in their owned starter files. Keep the parent responsible for the combined diff and run.cjs starter plus candidate.test.cjs. Use actual Codex roles available in this client; record any custom role that shadows a built-in. Do not claim reference-solution tests grade the edited starter.

explorer: cite both defects in starter/normalize.cjs and starter/report.cjs
worker A: implement normalizeStatus; check padded strings and errors
worker B: implement buildReport; check completed-only effort and validation
default/parent: inspect both diffs; run run.cjs starter and candidate.test.cjs

Check your result

• Role names and responsibilities match actual Codex roles or inspected custom definitions.
• Both normalization and aggregation defects have concrete source and input evidence.
• The edited starter passes all four candidate tests and its actual combined output is retained.

Common mistakes

• Requesting a Claude-specific built-in name and silently assuming identical Codex behavior.
• Treating the explorer label as a separately enforced read-only environment.