Chapter 5 — Reps

These are not warmups beside the milestone. Done in order, they are the increment: by Rep 12 the slices are merged, the logs are current, and the demo is recorded.

Ground rules

• Work on YOUR project. Every rep operates on your own repository, your own requirement ids, your own stack. PantryPilot and TraceLens are examples in the chapter; they are not the assignment.
• Two slices, three if the third is small. Twenty hours minus reviews, tests, logs, and a demo leaves about eight hours of typing. The two-thirds rule is arithmetic, not modesty.
• Log the hours as you go. Every rep here is real work. Thirty seconds at the end of each session, in docs/hours-log.csv. This is the week that discipline dies if you let it.
• Log the assistant in the same session. Anything drafted by an assistant that survives into the repository gets an entry in docs/ai-usage.md before you close the laptop.
• Nothing merges that fails the definition of done. The gate has to be allowed to say no or it is decoration.
• Write the reflections in plain prose. A rep is not finished until you have written the two to four sentences it asks for. The writing is where the learning lands.

Slicing the work

Rep 1 — Cut this week’s slices

Open your requirements specification. Take only the Must-have functional requirements that are not yet built. Choose two, or three if the third is genuinely small, ordered so the riskiest is first. Write a slice card for each:

SLICE: FR-__  <one sentence a user would recognize>
Layers:       <interface> -> <logic> -> <storage> -> <integration, if any>
Demo in one sentence: ____________________________________________
Acceptance criteria to satisfy: AC-__, AC-__
Estimate (three-point):  optimistic __ h | likely __ h | pessimistic __ h
x calibration factor from last Friday's report: __ h
Riskiest unknown:  _______________________________________________

Reflect: Which slice did you put first, and is it first because it is the riskiest or because it is the most fun? If those are different slices, say why you are overruling the rule — or reorder. Then add your estimates: if they total more than eight hours, you are planning a week you do not have.

Rep 2 — Two sweeps of your board

Sweep one — vertical or horizontal. Mark every open task V (ends in observable behavior) or H (ends in a layer). For each H, fold it into a V slice or write one sentence defending why it must exist alone.

Sweep two — whose project is this? Read every open task against the brief you adopted from the Fast-Start Catalog. Mark anything that exists because the brief said so rather than because your user needs it.

V tasks: __   H tasks: __
Tasks that describe the brief's user and not mine: ____________
Decision on each:  keep (why) / cut / demote to Should

Reflect: A board that is mostly H cannot demo anything in Week 8. And every hour spent on inherited scope is an hour stolen from a Must. What did the second sweep cost you to admit?

The gate

Rep 3 — Adapt the definition of done, then use it as a weapon

Copy code/definition-of-done.md into your repository as docs/definition-of-done.md and adapt the bracketed parts to your stack. Then take a task you already moved to Done — from Week 3 or Week 4 — and run all ten checks against it, honestly.

Task: ______________   Checks passed: __/10   Checks that fail: __________
What I am doing about it:  fix now / log a defect / accept with reason

Reflect: Which check failed first? Almost every student fails on the same one — the test, the docs update, or the log entry. That is your personal weak point for the next three weeks. Name it out loud.

Rep 4 — The four passes on your ugliest file

Pick the file you least want someone else to read. Run all four passes from code/definition-of-done.md — diff, stranger, adversary, contract — and record what each found:

Reflect: Which pass found the most? Pass 3 usually wins; pass 4 usually finds the one that matters. If pass 4 turned up an acceptance criterion with no line of code behind it, you just caught a requirement you were about to claim falsely in Week 8.

Rep 5 — Open a pull request to yourself

Branch, push, open a pull request in the web interface, review your own diff there, leave at least two review comments on your own code, then merge. Confirm CI ran on the branch before the merge.

Reflect: Did the web diff show you anything your editor did not? Most students find at least one thing. Unfamiliar presentation is a cheap substitute for a second pair of eyes, and it is the only one you have.

Working with the assistant

Rep 6 — A prompt contract, not a wish

Take one non-trivial piece of this week’s work. Write the wish version first — one line, the way you would naturally type it. Then write the contract version: context, task, explicit function signature, behavior on every failure mode, constraints, and the closing instruction “then list every assumption you made that I did not state.”

Run both. Save both outputs.

Wish prompt:      ______________________________________________
Contract prompt:  saved at prompts/YYYY-MM-DD-____.txt
Assumptions the model listed that I had not stated: ____________

Reflect: Compare the two outputs. What did the wish version assume about your project that is not true? Those assumptions are the two hours of reconciliation you just avoided — a quarter of this week’s typing budget.

Rep 7 — Explain it, break it, rewrite it

Put the drafted code from Rep 6 through all three tests before it merges.

1. Explain it out loud, line by line, without re-reading. Note every line you stall on.
2. Break it with the hostile inputs from the adversary pass — empty, huge, malformed, timed out, 429.
3. Rewrite the hardest function from memory, in your own naming and your project’s style.

Lines I stalled on:        ______________________________________
What broke it:             ______________________________________
Could I rewrite it?        yes / no — and what I had to look up: ______
Minutes this took:         ______   (this is the debugging tax, measured)

Reflect: If you could not rewrite it, you have found the module you do not own. What are you doing about it this week — studying it, or replacing it? There is no Week 12 here to defer it to.

Rep 8 — Write both disclosure entries

Using code/ai-usage-log-template.md, write the entry for the Rep 6/7 session twice: once badly (one line, the way you would if you were rushing) and once properly (tool, ask, accepted, changed, verified, requirement id). Commit only the good one to docs/ai-usage.md.

Reflect: Read the bad one as a grader who has never met you. What would you assume about the student who wrote it? That assumption is exactly what a thin log buys you.

The record

Rep 9 — Reconstruct one honest day, then run the report

Pick a day in the last two weeks you did not log properly. Rebuild it from evidence only:

git log --since=2026-02-09 --until=2026-02-12 --date=short --pretty='%ad %h %s'

Add browser history, editor recents, and your board. Estimate in quarter hours and label the row [reconstructed from commits]. Then copy code/hours_report.py into your repository as script/hours-report, make it executable, and run it on your real log:

python3 script/hours-report docs/hours-log.csv

Compare the output with the sample in code/hours-log.csv — a hundred honest hours across Weeks 1 to 5 that clears every pattern check.

Flags the report raised:            ____________________________
My calibration factor:              ____ x
Cumulative burn / 160:              ____ h    Weeks left: ____
Hours per week needed to finish:    ____ h

Reflect: What does your phase distribution say about where the term actually went? And multiply your remaining estimates by that calibration factor — do Weeks 6, 7, and 8 still fit in sixty hours? If not, you have a cut to make, and this is the cheap week to make it.

Rep 10 — Rewrite five bad commit messages

Run git log --oneline -20. Find the five worst messages and rewrite them as they should have been — subject saying what, body saying why, with the issue and requirement id.

| Actual message | What it should have said |
|---|---|

Then for the rest of this week, stage with git add -p and write every message in an editor rather than with -m.

Reflect: How much of why is recoverable from your history right now — say, in Week 7, when you need to know why you chose that retry count? Be honest.

Rep 11 — The secret you almost committed

Search your own history for credentials, then fix the process so it cannot happen again.

# 1. did an env file ever get committed?
git log --all --oneline -- '*.env' '*.env.*' '*credentials*' '*secrets*'
# 2. anything that looks like a literal credential in the working tree
git grep -nEI "(api[_-]?key|secret|password|token)[\"']?\s*[=:]\s*[\"'][^\"']{8,}"
# 3. same pattern across history (slow on a large repo — let it run)
git grep -nEI "(api[_-]?key|secret|password|token)[\"']?\s*[=:]\s*[\"'][^\"']{8,}" \
    $(git rev-list --all) | head -20

Whatever you find, decide in writing: rotate now, or confirm it was always a placeholder. Then verify your ignore file covers the real config file, and confirm every credential your project needs is read from an environment variable and documented — by name only — in README.md.

Credentials my project uses:  _______________________________
Read from:                    env var / secret store / (be honest) a literal
In history?                   yes -> rotated on ____  |  no
Ignore file covers:           ______________________________

Reflect: If a real key were in your history right now, what would your next four steps be, in order? Write them down today, because the day you need them you will be panicking.

Rep 12 — The five-minute demo, rehearsed and recorded

Write the demo script — literal clicks or commands, in order, with exact input values — commit your seed fixture, and rehearse the three acts on a timer: the claim (45 s), the software (3 min), the evidence and the gap (75 s). Then record it.

Act 1 opening line (verbatim): _________________________________
Act 2 script steps: 1. ______ 2. ______ 3. ______ 4. ______
Act 2 failure path shown: ______________________________________
Act 3 what is NOT done, and the week it is scheduled: __________
Recorded fallback saved at: ____________________________________

Reflect: Time the first run. Where did you go over? The overrun is almost always in Act 2, and almost always because you improvised instead of following the script. What are you cutting?

Done? One Last Thing.

The full-week dress rehearsal. Run the whole loop end to end, in one sitting, as if the milestone were due tonight:

1. Every slice from Rep 1 is merged, and every merged task passes all ten checks in docs/definition-of-done.md. Any that does not gets moved back off Done — publicly, on the board, where your own board can embarrass you.
2. git log --oneline -15 reads as a story a stranger could follow. No wip, no fix, no forty-one-file dumps.
3. docs/ai-usage.md has an entry for every assistant contribution that survived, each naming what you changed and how you verified it.
4. python3 script/hours-report docs/hours-log.csv runs clean — no pattern flags, and a cumulative burn near a hundred hours that you can defend out loud.
5. The five-minute demo runs from the script, on seeded data, with the recording saved as the fallback, and it ends with you naming what is not done.
6. Everything is committed and pushed, CI is green on the default branch, and the tag is ready.

If that loop runs clean tonight, Milestone 5 is already finished and you spent the week building rather than assembling. If it does not, you found out on a Wednesday instead of a Sunday — which is the entire point of a dress rehearsal, and the only luxury an eight-week course affords you.

Up next: Milestone 5