Subagent scope and quality checks

Back to the Codex learning hub

Goal and preparation

Lessons and resources mentioned here: Subagent division

The parent remains responsible for acceptance. Agreement between two workers is not independent verification if they used the same stale summary or assumption. Separate claims about code behavior, passed tests and delivered changes, then match each to files, execution records or Git state. Inspection and execution establish different things, so not every statement needs the same evidence format.

Step 1: Break narratives into a claim table

[
  {
    "report": "Fictional A",
    "claim": "addTask accepts duplicate task IDs.",
    "evidence": "No symbol or reproduction supplied"
  },
  {
    "report": "Fictional B",
    "claim": "All tests passed and the app is ready to deploy.",
    "evidence": "No command, exit status, commit or browser result supplied"
  }
]

Turn A into the executable question 'Can an existing ID be added?' Split B into whether tests ran and whether release conditions are met. Do not simply forward the reports. Track claim, file/symbol, required evidence, verdict and next step. Mark unchecked items unverified: unsupported and disproven are different verdicts.

This is a verification method, not an instruction to deploy during the exercise.

Step 2: Inspect the current source

Inspect addTask in core.mjs for empty and duplicate-ID checks. Confirm the expected reference copy because another branch or deliberately broken variant may behave differently. Lines move, so cite both file and symbol, adding the current Git commit when applicable. Without Git, record the source copy, date and file hash instead of inventing a commit ID.

node --input-type=module -e "import {addTask} from './core.mjs'; const first=addTask([], 'Read', 'a'); try { addTask(first, 'Build', 'a'); console.error('Unexpected duplicate acceptance'); process.exitCode=1; } catch (error) { if(error.message!=='task-id') throw error; console.log('Duplicate ID rejected: task-id'); }"

Expect Duplicate ID rejected: task-id and exit zero. Unexpected duplicate acceptance with a nonzero exit should be recorded and traced to the copy/function before changing anything; do not edit the check merely to make it pass. The exact task-id condition prevents unrelated exceptions from counting as success. This check writes no stored data and leaves the UI's task list intact.

Immediately inspect $LASTEXITCODE in PowerShell or echo $? on macOS/Linux before another command replaces the result. If Node cannot find core.mjs, that is a path failure, not proof of an addTask bug. A data-behavior failure must have loaded the intended function and used the planned input.

Step 3: Add reproducible boundary checks

import test from 'node:test';
import assert from 'node:assert/strict';
import { addTask, visibleTasks, decodeTasks } from './core.mjs';

test('duplicate IDs are rejected while the input is preserved', () => {
  const original = addTask([], 'Read', 'a');
  assert.throws(() => addTask(original, 'Build', 'a'), { message: 'task-id' });
  assert.deepEqual(original, [{ id: 'a', title: 'Read', completed: false }]);
});

test('same titles with distinct IDs remain independent', () => {
  const tasks = [
    { id: 'a', title: 'Read', completed: true },
    { id: 'b', title: 'Read', completed: false },
    { id: 'c', title: 'Build', completed: true },
  ];
  assert.deepEqual(visibleTasks(tasks, 'active').map(task => task.id), ['b']);
  assert.deepEqual(visibleTasks([], 'active'), []);
});

test('stored completion must be a boolean', () => {
  const raw = JSON.stringify({ version: 1, tasks: [
    { id: 'a', title: 'Read', completed: 'false' },
  ] });
  assert.throws(() => decodeTasks(raw), { message: 'storage-format' });
});

node --test core.test.mjs review-evidence.test.mjs

Check that the new filename is unused before saving. There are six top-level tests in total, retaining the original three. The new cases distinguish duplicate IDs, which are rejected, from identical titles with distinct IDs, which are valid, and reject string false as a boolean. If a worker confuses these concepts, ask it to revisit the case while leaving application code unchanged.

Optional: prove the tests detect the fault

Create a fresh review-negative copy containing the five application files and added test from the six-pass lab. Confirm distinct absolute paths and preserve this copy's original core.mjs. Remove the exact fragment below once from addTask in this disposable copy only, retaining other ID checks. Keep the original read-only review folder unchanged.

 || tasks.some((task) => task.id === id)

In review-negative, rerun the same six tests: expect four passes, two failures and a nonzero exit status. Accepting duplicate IDs breaks one original and one added test. A syntax error, missing file or all-green result is not this reproduced fault; check the folder and edit. Restore the saved core.mjs and require six passes again. Record this as the parent's experiment, not delegated execution or UI acceptance.

Step 4: Handle conflict, staleness and incomplete work

Your claim conflicts with the current addTask implementation and the duplicate-ID reproduction.
Recheck core.mjs and report the exact function behavior, the input used and the observed result.
Distinguish duplicate IDs from duplicate titles. Keep the application files unchanged.
If your earlier report used another checkout or was not executed, state that explicitly.

Mark A disproven and B originally unsupported. Your newly executed six-test run is new evidence from your verification; it cannot retroactively prove that B ran tests. Release still requires complete acceptance and the PR workflow, and this lesson produces no deployment. Preserve the original claim, correction and check time for traceability.

If a worker read an older commit, provide the current version and request only affected conclusions be rechecked. If stopped or waiting for approval, retain completed evidence and return gaps to the parent for a decision. Done does not imply every acceptance criterion passed. When both reports depend on the same unchecked text, add source/test evidence instead of opening more agents to vote.

Common mistakes and recovery

A successful command in the wrong project is caught through the directory and test names. Exit zero still needs confirmation that expected cases ran. An expected-failure case needs the right error type, not any exception. All three can lend false credibility to a report. For accidental app edits, stop competing writes, preserve the diff/test copy and identify ownership before targeted restoration; do not erase others' work with git reset --hard.

Keep review-evidence.test.mjs as additional verification if desired. To restore the original reference, remove only that newly added file after confirming its path and rerun the original three tests. All five app/reference files should match their before-state. Work only in your copy and preserve others' tests. Stopping a worker cannot undo external actions or merged commits, which require separate recovery.

Acceptance and next step

Deliver a corrected evidence table: why A was wrong, what B still has not established, the actual six-test result, preserved files and untested browser/platform scope. Keep fictional reports labeled and real agent records separate. The same Node commands apply across the three systems without claiming unperformed platform runs. Parallel integration applies this verification to two branches.

Back to the Codex learning hub

Read the full description

Three numbered stages: identify the starting point, perform the exercise, and verify the result. Original illustration, not a product screenshot.

• AI tools
• Tutorials
• Codex