Deliver an isolated engineering task

What you will build

A complete proof-of-concept packet for the parser task. The deliverable is evidence another engineer can inspect and reproduce, not a screenshot of an agent saying it finished.

Read the mechanism

A demonstration shows that a path can work. A useful engineering POC tests a specific claim under stated conditions, including at least one failure path. Define the acceptance criteria before seeing the agent’s result.

Freeze the input revision, task scope, test contract, capability profile and budget. Otherwise the experiment can drift until success means something different from the original question. Publication is a separate gate: the agent may produce a patch while a reviewer controls remote integration.

Treat the exported patch as untrusted until reviewed. A clean test run inside the original guest is useful but does not replace independent verification against the preserved contract.

Worked lab · the evidence packet

Use chapter 12’s synthetic parser repository. Add the following acceptance contract to your local notebook:

Claim: an isolated agent can produce a scoped parser fix.
Input: exact baseline commit.
Allowed changes: parse.mjs and parse.test.mjs only.
Required behavior: non-negative safe integers; reject invalid input.
Required tests: preserved baseline assertions plus documented edge cases.
Network: only approved provider/package needs.
Publication: no autonomous push or PR.
Failure injection: deny an unnecessary external request.
Cleanup: confirm deletion after export and review.

Run the failing baseline test and retain its exit status. Select clone or mountless mode deliberately. After the candidate is produced, collect:

1. Input SHA, version matrix and capability manifest.
2. Actual process/test results, with bounded redacted logs.
3. Patch or output commit, plus exported artifact hashes.
4. Independent review notes and verification results.
5. Negative-test result and one recovery observation.
6. Resource cleanup confirmation or an explicit unresolved record.

For a PR-ready description, use this structure:

Problem: parseCount accepted values outside its intended contract.
Change: describe the actual validation behavior and files changed.
Verification: exact commands, observed results, environment.
Limits: untested cases and remaining uncertainty.
Evidence: links to sanitized packet and output commit.

This is a template. Replace every claim with the actual final implementation; do not publish it as a completed result before the exercise runs.

Expected observations

A passing POC packet should let a reviewer answer “what changed, why, how was it tested and what remains uncertain?” A failure packet can be equally useful if it identifies the boundary or assumption that failed.

A PR is not a deployment. A merged commit is not proof of a live release. If the exercise later includes publication, inspect the repository’s actual automation and verify the resulting environment separately.

Troubleshooting

If the agent changes files outside scope, preserve the diff and reject or revise the task deliberately. If independent tests fail, investigate the discrepancy instead of quoting the earlier passing summary. If cleanup is uncertain, keep the resource in the ledger.

Interview practice

Completion check

Have another engineer reproduce the verification from your packet. Record any missing instruction as a defect in the evidence, not a reader mistake.

Sources and version notes

Checked 6 October 2026; current baseline: sbx v0.46.0. Develop and test locally · Use Git with sandboxes · Errors and retries