Build your workbench, then prove it helped

The useful test of a custom environment is not how many features you switched on. For a developer who already uses agents, the standard is operational: can you give it a bounded task, inspect what happened, recover when something is uncertain, and leave work another person can continue?

You now have the pieces. This capstone makes them answer one small question: can the workbench repair its incomplete review guide without weakening the checks, losing provenance, or wandering into unrelated files?

Prerequisites

Complete lessons 10 through 14. Use a fresh workbench ZIP extraction if you already repaired the working document. Keep your completed preset notes and route choices, but never move credentials into the practice project.

You can complete the local repair and evaluation without a model. The full Harness track additionally uses your verified preset, tool, session, and authorized workflow routes. Label which track you actually ran. The Harness safety notice still applies to the live track: this exercise belongs in a disposable environment, not a production account.

What you will build

Produce a correct docs/workflow.md, passing local checks, a reviewed diff, and a short handoff. The only approved content edit is that document. The tool, tests, reference fixtures, and other documents remain unchanged. This “documentation workbench” is our teaching project built from documented capabilities, not an upstream DSH product mode.

Practice: establish the baseline

From the fresh extracted directory, run:

node --test check-doc.test.mjs recovery.test.mjs workflow.test.mjs
node check-docs.mjs

Record the first command's success and the second command's expected exit code 1 in results.md. The broken document has a placeholder and no Recovery section. Confirm both in the file. If your baseline is already green, use a fresh extraction rather than manufacturing a different failure.

For a local diff baseline, you may initialize Git only inside this disposable directory and stage the starting files:

git init
git add .

No commit is required. Later git diff compares your repair with that staged baseline. This is a practice convenience, not an instruction to stage a real repository or publish anything.

Practice: inspect, then approve one repair

On the live track, choose your personal preset and workbench directory. Use prompts.md to request a read-only review with the nested rules and docs-review skill. Run the custom checker if it is actually available. Then run the bounded workflow from lesson 14 and inspect both findings yourself.

On the local track, read those same instructions and perform the two reviews yourself: first structure, then command accuracy. Use the fixture tests to understand the workflow's failure handling, without claiming two models reviewed the document.

Before approving an edit, answer: did the reviews find the real issue, and did they invent any? A complete workflow result means its outputs arrived; the workflow contract does not certify the correctness of those outputs.

Give the writer this bounded instruction, or apply it yourself:

Change docs/workflow.md only. Replace the placeholder with the real
document-check command and add a useful Recovery section.
Keep the existing Purpose. Do not change the checker, reference documents,
fixtures, instructions, or tests. Do not install, commit, push, or deploy.
Run the document check and all three local test files.
Report commands, exit codes, and changed lines. Stop if another path is needed.

The repair should explain node check-docs.mjs, what failure looks like, and why an uncertain previous write needs inspection before another write. Open the reference only after trying your own repair; its wording is one answer, not a required transcription.

Open full-size diagram

Practice: review the result, not just the green label

Run:

node check-docs.mjs
node --test check-doc.test.mjs recovery.test.mjs workflow.test.mjs
git diff --check
git diff -- docs/workflow.md
git status --short

The first three commands should exit 0 after the repair. Read the diff and status to confirm that no unrelated file changed. Worksheet edits should be distinguishable from the authorized document repair; the writer itself was allowed to change only docs/workflow.md.

The checker accepts exact headings, not good explanations. A ## Recovery heading followed by useless advice can pass. Read the command against check-docs.mjs and the recovery advice against the actual situation. This is why a structured tool result is evidence to interpret, not a replacement for acceptance criteria.

Score the capstone with an evidence rubric

Grade the result across four checkpoints: baseline, authorization, repair, and handoff. The baseline must show the original failure on the untouched fixture. Authorization must name the one file and the checks the writer may run. Repair must show the smallest diff that satisfies the requirement and the actual exit codes. Handoff must explain what was verified, what remains unknown, and how another person can continue.

Use a simple evidence table rather than a single pass label:

| Checkpoint | Pass evidence | Weak evidence | | --- | --- | --- | | Baseline | Reproduced failure on a named revision | Agent says the file was broken | | Scope | Diff and status show only allowed paths | Prompt says “small change” | | Behavior | Checker and focused tests pass after repair | A heading or keyword is present | | Recovery | Uncertain write was inspected before retry | The agent says it resumed safely | | Handoff | Checkpoint names next safe action | Transcript ends with “done” |

Apply the rubric to the local track and, separately, to any live run. Never let a live provider result replace missing local fixture evidence. If the live workflow was not run, record that fact and grade the deterministic work you actually performed. If a model changed more than the authorized file, preserve the diff, stop, and treat the capstone as a scope failure even if the document checker passes.

The final review should include one adversarial question: what evidence would disprove this result? Examples include a command that exists only in the agent's explanation, a test that does not exercise the changed branch, or a checkpoint that describes the intended write instead of the observed file. Add one test or inspection step for the strongest doubt before carrying the pattern into a real repository.

Break and recover

Use the uncertain-write scenario from lesson 11 without deliberately crashing a live operation. Write a checkpoint saying that a repair was requested but its outcome was not recorded. Then inspect the document you just repaired. It already contains the intended change: run the checks and verify it rather than applying the patch again.

If you ran Harness, finish its active work, reopen the same session using the tested continuity path, and ask it to distinguish remembered context from current file evidence. Record any missing persistence check as not run. Do not imply the local decision aid tested actual session restoration.

Make it yours

Choose one adaptation for a second run: component documentation that needs an Accessibility section, a runbook with a concrete rollback step, or an API guide with a verified request example. Start from a fresh copy of the same baseline, state your changed acceptance criterion, and add a test for any new deterministic rule.

Change one element at a time: a rule, a skill procedure, a tool check, or a model route. Keep the fixture revision and other conditions recorded. Note actual elapsed time, tool calls, retries, defects found, and review work only when you measured them. Leave missing values blank. A single task cannot establish which model or harness is universally best.

Keep the parts that help you find errors and leave useful evidence. Remove a reviewer or customization if it adds setup without answering a distinct question. You can carry this pattern into a custom Web environment later, with the trust boundaries from lesson 9; this local exercise does not authorize a public deployment.

Completion check

• The original failure is recorded and the repaired document passes the unchanged checks.
• A human verified the example command and the recovery advice.
• The repair stayed inside its authorized file, with other changes accounted for.
• Model routes and observed outcomes are recorded, or clearly marked not run.
• Missing or failed worker output never became approval to edit.
• You can explain one personal rule, skill, tool, or preset decision and change it safely.
• Another reader can continue from checkpoint.md without guessing what happened.

That is the finished exercise: a small environment you understand, a repair you can defend, and enough evidence to improve the next run.