Mastery: your playbook

Your mastery artifact is a debugging packet containing the repro, constrained prompt, minimal diff, test evidence, and reviewer checklist. It should let a competent colleague repeat diagnose and repair a wrong order-total function without widening the change without inheriting unstated assumptions. Include the job card, source requirements, prompt contract, examples, rubric, privacy boundary, escalation rule, and recovery steps.

Use reproduce → explain → patch → test → review as the spine. For every stage, name the input, action, output, owner, check, and stop condition. Include the concrete prompt:

You are pairing on a TypeScript checkout service. The failing case has `shippingOverride=0`, but the result adds the default shipping fee. Explain the likely cause first. Then propose the smallest diff. Do not change public types or add dependencies. Return: diagnosis, unified diff, and three tests. Flag any assumption.

Then include a specimen response: The assistant identifies a truthiness fallback that replaces free shipping (0) with the default fee, changes it to a nullish fallback, and proposes tests for zero, undefined, and a positive override. Label it as an example, not a guaranteed result. Attach proof from the independent check: you must run the focused unit test, the full test suite, type-check, lint, and inspect the diff against the documented contract.

Run the same playbook on a second case that differs in one meaningful way. Keep the quality bar fixed. Explain which context fields and constraints changed. If the workflow only succeeds on the memorized example, it is not mastered.

Teach the method in five minutes to someone who has not read this chapter. Ask them to identify the source of truth, the riskiest failure, and the human decision. Their answers reveal whether your playbook is explicit.

Score yourself:

1. Framing: I can reject work outside the stated job.
2. Context: I distinguish evidence, assumptions, and untrusted input.
3. Prompting: I constrain output and request inspectable artifacts.
4. Verification: I use an external check, not model confidence.
5. Safety: I enforce this boundary: remove API keys, tokens, customer payloads, private repository URLs, and proprietary code not approved for the tool.
6. Operations: I can recover from invented library methods; broad refactors disguised as fixes; tests that merely copy the implementation; ignored error output.
7. Communication: I disclose limitations and ownership clearly.

A weak score is a practice target, not a reason to pad the playbook. A candidate patch is not working software until the local toolchain proves it. Prefer a five-line diff you understand over a polished rewrite you cannot defend.

Package the project as repair a calculateTotal regression and submit a review-ready patch with tests and a rollback note. Show the before state, constraint decisions, failed case, correction, measured result, and reflection. Remove sensitive inputs and avoid claiming impact you did not measure. Professional credibility comes from showing judgment under constraints.

Use a second bug: a coupon expiry check accepts midnight in the wrong time zone. Provide the failing assertion, ISO timestamps, runtime version, and documented boundary; withhold the rest of the repository. Ask for diagnosis before diff. Reject any patch that changes date libraries or public types. Run the focused test in UTC and one local zone, then the full suite and type-check. In your review note, explain why the chosen comparison handles the boundary and identify one production assumption the tests still do not prove. This simulation tests whether your playbook transfers from truthiness errors to time semantics without inviting a broad rewrite.