Give a producer a build runbook with a stop condition

AI and affiliation disclosure: This tutorial was prepared with AI for Wagglet-related marketing work. The tiny Node example is a synthetic build fixture, not a production incident.

A producer can supervise a bounded build repair when the task makes failure, scope, and acceptance visible. Asking them to keep prompting until a build turns green gives them no reliable way to distinguish a repaired import from a deleted check.

An AI game development workflow needs two descriptions of the same job. The engineer supplies the implementation context; the producer receives the short sequence they can run and the point at which they must stop.

Make the example reproducible

Create a directory containing these three files. The import intentionally uses the wrong filename.

package.json:

{"private":true,"type":"module","scripts":{"build":"node build.mjs"}}

reward-label.mjs:

export const label = 'Continue';

build.mjs:

import { label } from './reward-lable.mjs';
import assert from 'node:assert/strict';
assert.equal(label, 'Continue');
console.log('Reward label fixture passed');

Run npm run build. The initial failure should identify the missing reward-lable.mjs module. The permitted repair is to change that import to ./reward-label.mjs. Keep the assertion and both source files. Run the same command again and record its exit code. There are no package dependencies to install for this fixture.

The output checks the label through the repaired import. It does not compile a browser application or prove a game build is healthy. In an actual repository, an engineer must replace this small check with the project’s approved build and smoke commands.

Write the agent brief

Objective: repair the misspelled relative import in build.mjs.
Inputs: the three fixture files and the captured baseline failure.
Allowed edit: the import path in build.mjs.
Preserve: label value, assertion, build script and filenames.
Do not: install dependencies, disable checks, change toolchain,
        access production, or publish a build.
Delivery: diff, baseline output, final output, exit codes.
Stop if the observed failure is different from the stated one.

The engineer prepares this brief and verifies that the intended command is appropriate for the environment. The runner executes it through their own authorized tools. An agent may propose the one-line repair, but it cannot broaden the task just because another change would make the command succeed.

Give the producer the shorter runbook

1. Open the fixture directory and confirm the three filenames.
2. Run npm run build and save the failure text.
3. Check that the error names reward-lable.mjs.
4. Let the authorized runner apply the single import correction.
5. Run npm run build again. Save the output and exit code.
6. Send the diff and both command outputs to the engineer for review.

If the command is missing, a different file fails, authentication is requested, or the proposed diff removes the assertion, stop. The producer reports the discrepancy instead of choosing a new repair strategy.

Wagglet’s dual-prompt task design provides context for keeping the detailed technical brief separate from these human operating instructions.

Keep acceptance with the right reviewers

The producer confirms that the observed failure matches the task and that the requested evidence exists. The engineer checks that the path correction fixes that failure without weakening validation. The final record should say who reviewed the diff and whether they accepted it.

This arrangement does not turn the producer into a build engineer. It gives them a useful supervisory role with a concrete escalation rule. A production build may depend on signing, engine versions, native tools, or secrets; those requirements need qualified ownership before a producer can use a runbook safely.