3. Bring your own failure

Package enough context to investigate a real mistake and assess the result.

Start with a representative mistake, not a prompt designed to force a score. For example, an account team expected a discount at exactly the contractual threshold, but a code change made the comparison exclusive.

The supplied adaptations/discounts.json is an original teaching version of that problem. It includes the business rule, before/after code, an equivalent clean refactor, supported inputs, the reference cause, provenance and a privacy declaration. It is not a real customer incident.

python3 -B scaffold.py adaptations/discounts.json ./my-discount-case

This creates two complete tasks, regression and clean refactor. It does not declare them realistic or correct. Inspect:

File or directory	What to verify
tasks/discounts-regression/instruction.md	Work requested, output contract and time limit
environment/	Proposed source, caller, policy, diff and supported inputs
task.toml	Reviewer user, CPU/memory and actor/verifier timeouts
tests/	Separate assessment environment, original and changed implementation, reference and checker
author-declaration.json	Provenance, privacy statement and explicit unqualified status
manifest.json	Task membership and hashes of files inside each task; not the root author declaration or builder files

The meaningful counterexample is a member spending exactly 10,000 cents: the policy permits the discount, the changed strict comparison rejects it. The clean refactor preserves the result. Check both, not just the bug-positive case.

A distinct adaptation

adaptations/tickets.json covers a different workflow: assigning a support ticket requires an active team, matching organization and available capacity. An operator-precedence change can admit an inactive or cross-tenant team. Build and inspect it separately:

python3 -B scaffold.py adaptations/tickets.json ./my-ticket-case

Both adaptations use the same packaging machinery but different rules, inputs and consequences. To run one, upload its task directory and follow lesson 1. Do not upload the entire course workspace or your private credentials.

Replace the teaching material with your work

Capture the actual source and relevant callers/dependencies at the review point. Write the business rule from an authoritative source. Put the task instructions and relevant evidence in the actor environment; keep future fixes, labels and private assessment out. Supply a reproducible environment and an output contract. Then demonstrate that a correct answer can be established from what the actor sees and that the judge has enough information to assess it.

The scaffold supports a finite policy interface. It is not a universal PR importer. For a full repository, use the task authoring contract and preserve its real structure instead of squeezing it into one function. Abundant organized context is usually more realistic than an answer-shaped snippet.

Reject or repair a task when correctness depends on an absent schema, service contract, policy or source file; when a test passes only because the expected answer leaked; or when you cannot redistribute the material. A clever reviewer guessing the answer is not proof of sufficient information. A failing reviewer is not proof that the information is insufficient.

What you now have: a reproducible adaptation and an explicit qualification checklist, not automatic task or judge synthesis. Next, make one measured change.