WHY THIS LAB
Test whether the work survives outside your memory.
A project is not ready for handoff because its author can make it run. It is ready when another person can recover the question, inputs, code path, evidence, and limitations. This mini hackathon treats confusion and failure as useful information about the project.
Goals
- 01Run another student's project without a verbal tour.
- 02Identify the first reproducibility, provenance, interpretation, or communication blocker.
- 03Compare a human audit with a bounded agent audit.
- 04Rank findings by consequence rather than convenience.
- 05Repair and verify one high-value issue.
Why the author stays quiet
Authors unconsciously supply missing context when they demonstrate their own work. They remember which script runs first, which object was created in the console, and what an abbreviated variable name means. A cold handoff removes that invisible support. The reviewer's first confusion becomes evidence about the project rather than evidence about the reviewer.
The README, source files, console output, diff, prompt, and verification record are the project's flight recorder. They do not prevent every failure. They let another person reconstruct what happened without relying on the pilot's memory.
The final repair is intentionally small. Trust often improves more from one working entry point, one corrected unit, or one qualified claim than from a broad round of cosmetic cleanup. Ranking by consequence helps students learn that good computational work is not the absence of failure. It is the ability to find, explain, and repair the failure that matters most.
A useful failure is a success. A missing package, unclear entry point, broken path, untraceable indicator, or overstated claim is not an embarrassment. It is the exact evidence a handoff test is designed to produce.
0-15 MINUTES
Run the handoff cold.
Share the project folder or screen without explaining its structure.
Find the question, entry point, data source, and expected output.
Restart R and follow only the written instructions.
Note the first blocker, first ambiguity, and first strong design choice.
Author rule. The author observes silently during the first ten minutes. Do not rescue the reviewer. Every question the reviewer needs to ask is evidence that the project may need clearer documentation.
Cold-run record
| Moment | Record |
|---|---|
| First expectation | What did you think would happen? |
| First blocker | Exact file, command, error, or missing instruction. |
| First ambiguity | Decision you could not infer from the project. |
| First strength | Choice that made the work easier to understand. |
15-32 MINUTES
Human audit first, agent audit second.
Spend six minutes on the human audit. Rank no more than four findings. Then give the agent a narrow audit contract and compare priorities.
Entry point, packages, paths, order, and generated output.
Publisher, codes, units, years, retrieval, and transformations.
Sample, units, diagnostics, causality, and limitations.
Question, names, labels, captions, README, and disclosure.
Goal: Audit this Math Camp project for handoff readiness. Context: Read the README or opening note, data documentation, R or Quarto source, generated output, and AI-use note. Review separately: reproducibility, provenance, statistical interpretation, and communication. Constraints: Do not edit files. Rank findings by consequence. Cite the exact file and evidence for every concern. State uncertainty. Do not recommend a more complex model unless needed to explain a current claim failure. Done when: Produce no more than six prioritized findings, each with a human-run check that can confirm or reject it.
Compare the reviewers
| Question | Record |
|---|---|
| Agreement | Which consequential issue did both reviewers identify? |
| Human-only | What did the person notice that the agent missed? |
| Agent-only | Which generated concern is traceable and worth testing? |
| Rejected | Which concern lacked evidence or misunderstood the design? |
32-47 MINUTES
Repair one issue that changes trust.
Choose the highest-consequence finding that can be addressed in 12 minutes. Do not spend the sprint polishing colors while the entry point is broken or the claim is causal.
| Priority | Examples |
|---|---|
| Stop | Code cannot run, source is missing, key duplicates, result is materially misleading. |
| High | Sample is hidden, units are wrong, claim exceeds the design, historical revisions are unreported. |
| Medium | Run order is ambiguous, labels are incomplete, disclosure is vague. |
| Low | Formatting, convenience, or optional extension. |
- 01State the finding and evidence.
- 02Predict what the repair should change.
- 03Edit the source, not only the rendered output.
- 04Restart or rerun the relevant path.
- 05Record whether the check now passes.
Repair record. Write one sentence: “We changed [source] because [evidence]. We expected [observable difference]. We verified the repair by [specific check], which [passed, failed, or remains unresolved].”
47-60 MINUTES
Ninety seconds, three sentences.
Our policy question was... The most important pattern or handoff failure was... The next check we would run is...
Show the figure, error, audit finding, or repaired output that makes the story concrete. Do not summarize every step.
Final reflection
- □I can identify the starting point of a small R project.
- □I can supervise one bounded coding-agent task.
- □I can verify a generated data or code claim.
- □I can distinguish association from causation.
- □I can document a project so another person can inspect it.
Optional high-ceiling extension
Package the project as a small reproducibility bundle with one entry script, a dependency note, an output map, and a clean-render check. Ask a second reviewer unfamiliar with Math Camp to run it without assistance and compare their first blocker with the lab review.
What to keep. The artifact, audit record, and repaired issue remain yours. Nothing is submitted or graded. The durable outcome is the workflow: question, evidence, code, agent, verification, handoff.