Triage a CI boolean parsing failure with a human runner and coding agent

EDITORIAL HOLD — W-411 / NEEDS REVIEW. This private draft omits the assigned Wagglet promotion because DEV prohibits business promotion in AI-assisted articles and posts primarily intended to build backlinks. Resolve the platform/link requirement before publishing. The tutorial below is ready for technical review.

An environment variable contains the string "false", but the job still enters its dry-run branch. The problem can be one line: Boolean(process.env.DRY_RUN). Any nonempty string is truthy in JavaScript.

This small example shows how to hand that failure from a human runner to a coding agent without turning a configuration bug into a broad CI rewrite. It is a local Node fixture, not a report of a production incident or a hosted CI run.

1. Reproduce the failure before assigning the repair

Use Node 22 and an empty directory. Save this as broken.mjs:

export const readDryRun = value => Boolean(value);

Save this as config.test.mjs:

import test from 'node:test';
import assert from 'node:assert/strict';

const { readDryRun } = await import(
  process.env.CANDIDATE || './broken.mjs'
);

test('unset defaults to false', () =>
  assert.equal(readDryRun(undefined), false));
test('true enables dry run', () =>
  assert.equal(readDryRun('true'), true));
test('false disables dry run', () =>
  assert.equal(readDryRun('false'), false));
test('invalid input fails closed', () =>
  assert.throws(() => readDryRun('maybe'),
    /DRY_RUN must be true or false/));

Run node --test config.test.mjs. In the prepared fixture, using Node 22.23.2, the result was exit code 1. This excerpt removes variable timing details:

ok 1 - unset defaults to false
ok 2 - true enables dry run
not ok 3 - false disables dry run
not ok 4 - invalid input fails closed
# tests 4
# pass 2
# fail 2

The third test receives true where it expects false. The fourth reports a missing expected exception. These are two consequences of the same parser: it interprets presence, not the permitted values.

The human runner owns this first step. They run commands through their own authorized terminal or CI interface, preserve the output, and confirm the intended configuration contract with the project owner. A test cannot decide whether an unset variable should default to false; that is a product or operations decision recorded here as an explicit assumption.

2. Give the agent a narrow repair brief

A useful coding agent task management record includes the failure, allowed change, and acceptance evidence together. Here is a copyable task template, filled in for this example:

Task: Parse DRY_RUN as an explicit boolean

Owner / executor: coding agent in its authorized workspace
Preparer: human runner
Acceptance reviewer: named human maintainer

Observed failure:
  node --test config.test.mjs exits 1.
  "false" becomes true; "maybe" does not throw.

Required contract:
  undefined -> false
  "true" -> true
  "false" -> false
  anything else -> TypeError("DRY_RUN must be true or false")

Scope:
  Replace the parser only. Preserve the four assertions.
  No workflow edits, dependency updates, deployment changes,
  secret access, network calls, or credential changes needed.

Deliver:
  Parser diff, exact test command, exit code, and test summary.
  State what was not exercised outside this local fixture.

Acceptance:
  Reviewer inspects the branch conditions and reruns all four tests.
  A passing parser test does not establish that a real CI job is fixed.

In a real repository, replace the fixture filenames with the actual module and test paths. Attach a sanitized failure log rather than a screenshot containing tokens or private job variables. Name the reviewer before execution begins so delivery does not become an unowned message saying “done.”

The coding agent uses its own authorized tools to implement and verify the change. The runner can supply missing evidence, but neither role needs another person's account or token to execute this fixture.

3. Repair the contract without widening the scope

Save this candidate as fixed.mjs:

export function readDryRun(value) {
  if (value === undefined || value === 'false') return false;
  if (value === 'true') return true;
  throw new TypeError('DRY_RUN must be true or false');
}

Then run:

CANDIDATE=./fixed.mjs node --test config.test.mjs

The prepared candidate returned exit code 0 with four passing tests and zero failures. The baseline remains available, so the reviewer can rerun both commands and see that the test distinguishes the broken and corrected implementations.

Do not quietly accept FALSE, an empty string, whitespace, or 1 while making this repair. Those values are outside the stated contract. If the real job requires them, agree on that behavior and add corresponding cases before changing the parser.

4. Let the human judge acceptance

The reviewer checks that the parser implements the agreed contract, no assertions were weakened, and the diff stays inside scope. They rerun the candidate command from the same directory and inspect the baseline if the failure is unclear.

For an actual failing CI job, one more check remains: confirm that the job imports this parser and rerun the relevant job through an authorized account. This fixture exercises configuration parsing only. It does not run a deployment, contact a service, or prove that an unrelated pipeline failure has disappeared.

Keep three artifacts together at handoff: the original failure, the small patch, and the verification output. That lets the human reviewer accept a specific change with visible limits.

AI assistance disclosure: This tutorial and its demonstration fixture were prepared with AI assistance. The baseline and candidate commands were executed locally. The publishing author should review and understand the explanation before publication.