Milestone 5 — Core Increment & Demo

“Whatever you do, work heartily, as for the Lord and not for men,” — Colossians 3:23 (ESV)

Chapter: Chapter 5 — Build the Core Week: 5 of 8 — construction, wearing the developer’s hat. Hours 80 through 100 of 160. Due: End of Week 5. Submit: Your repository, pushed, with the tag iteration-1; plus the demo recording link in the Canvas dropbox. Where it lands in the final package: the merged slices become the working software line of the Week-8 rubric — the largest single block of the 50% final. docs/ai-usage.md feeds the AI-disclosure line. docs/hours-log.csv and the commit history feed the process-evidence line. The demo script and recording become the first two minutes of your Week-8 presentation, which is 10% on its own. AI policy: Open, with accountability. Use any assistant you like to help you build. Every contribution that survives into the repository is recorded in docs/ai-usage.md in the session it happened, and you must be able to explain every line you ship without re-reading it. Undocumented use is an integrity violation, not a style preference. The authoritative statement is the Grading Contract.

The Setup

Your skeleton walks and your design has been reviewed. Eighty hours are spent and eighty remain. Now somebody has to put a product inside that skeleton, and that somebody is you, with twenty hours and a specification you wrote when you had more optimism than data.

This is the week your project stops being a stack of documents and becomes software a human can use. It is also the week the process quietly dies in most capstones. The board goes stale. The commits turn into one midnight dump. The hours log gets caught up on Sunday. The definition of done becomes “it ran once.” None of that feels like a decision at the time. All of it is legible to a grader in Week 8 — and by then there is no Week 9 to fix it in.

So the milestone has two halves, graded together on purpose. Build the slices a stranger can watch working — and leave a record that proves how they were built. Working software with no record is a claim. A record with no working software is a story. The engineer ships both.

One more thing about the arithmetic, because Week 5 is where students start doing it. The milestones carry 25% between them — about 4.2 points each — and that is the smaller half of what they are worth: the Week-8 submission is 50% of your grade and it awards points for exactly the artifacts these milestones produce, a second time. Skipping this week does not cost a small deduction now — it defers identical points into a term that has three weeks left, one of which is a presentation. In an eight-week course a lost week is an eighth of everything.

Learning Targets

You will demonstrate that you can:

• Decompose prioritized requirements into vertical slices that each deliver observable behavior, sized to a twenty-hour week.
• Apply a definition of done as a gate that is genuinely allowed to reject your own work.
• Detect inherited scope — a criterion that still describes the catalog brief’s user rather than yours — and cut it while cutting is cheap.
• Review your own code with the four passes, and act on what they find.
• Use an assistant accountably — a prompt contract, then explain / break / rewrite, then a log entry written in-session.
• Keep a commit history a stranger could read as the story of the week.
• Keep an hours log honest under real time pressure, and read what it tells you about the three weeks left.
• Demonstrate working software in five minutes, on seeded data, including what is not done.

What One Finished Slice Looks Like

Graders do not award points for effort they cannot see. Here is the same slice claimed two ways, from the running example — PantryPilot’s FR-12, adding a pantry item by scanning a barcode. Your slice will look nothing like this one. Its evidence should look exactly like this one.

The weak claim — how most students report a slice:

FR-12 barcode scanning - DONE
Implemented the barcode feature. Works.

Nothing there is checkable. Which criteria? Tested how? What happens when the barcode is not in the product database — which is the case FR-12 exists to handle? A grader can only take the student’s word for it, and the rubric does not pay for a student’s word.

The strong claim — the same work, evidenced:

Every row is something a grader can open and check in under a minute, and every row maps to a line of the rubric below. Building the software is most of the work. Making it checkable is most of the grade.

The weekly status block — paste this into your submission comment

Every milestone submission carries these five lines. It takes two minutes, it is the same five lines every week, and it is the difference between an instructor who can help you in Week 3 and one who finds out in Week 7. Copy it into the Canvas submission comment when you submit — not into a document.

Shipped:     what actually works this week, in one line
Cut:         what I dropped or deferred, and where it went (backlog / change request / gone)
Hours:       planned N / actual N        (from docs/hours-log.csv)
Blocked on:  the one thing in my way, or "nothing"
Ship confidence: green | amber | red — if amber or red, the one thing that would move it

Say red when it is red. A red in Week 3 is a conversation and a scope cut. A red discovered in Week 7 is a grade. Nobody has ever been penalised in this course for an honest amber; the only expensive answer is the green that was not true.

Normal Tier

Required deliverables

1. Two to three completed vertical slices, each traced to a functional requirement id, each satisfying its acceptance criteria verbatim, each merged to your default branch with CI green. Three only if the third is genuinely small — the rubric rewards finished, not started.
2. docs/definition-of-done.md committed (adapted from code/definition-of-done.md) and visibly applied — no task sits in Done with a failing check.
3. docs/reviews/iteration-1-self-review.md — the four-pass record for every slice: what each pass found and, for every finding, whether it was fixed, logged as a defect, or accepted with a written reason. Include the pass-4 catalog-residue question and your answer.
4. docs/ai-usage.md — an entry for every assistant contribution that survived into the repository, in the format from code/ai-usage-log-template.md: tool, ask, accepted, changed, verified.
5. A commit history that explains itself — at least eight commits across the week, each a coherent change, subjects saying what, bodies saying why, issue and requirement ids referenced, no credentials anywhere in the diff.
6. docs/hours-log.csv current through Week 5, in the Appendix A column set plus ai_assisted, with any reconstructed rows explicitly labeled.
7. A five-minute demo of working software following docs/demo/iteration-1-script.md, run on a committed seed fixture, with a screen recording saved as the fallback and at least one handled failure path shown.
8. An updated board and burn-down showing what closed, what moved, and what you cut.

Normal-tier rubric (out of 100)

Medium Tier (+ up to 25% extra credit)

More rigor on the same increment. Pick what fits your project:

• One more slice, closed to the same standard — but only if the first two or three actually met it. Quantity that skips the gate scores nothing, and in this edition it is also how students run out of week.
• A human reviewer. Get one classmate, teammate, or working engineer to review one pull request. Record their comments and your dispositions in the self-review file. One outside pair of eyes finds what four self-review passes will not.
• One measured non-functional requirement. Pick an NFR with a number in it, measure it against realistic data, and record the method and the result. “It feels fast” is not a measurement; a p95 over two hundred requests is.
• A spike-and-stabilize on your riskiest integration. Deliberately break the third-party dependency — wrong key, no network, a 429 — and make the system degrade gracefully instead of crashing. Record what you learned and what you changed.
• A demo that runs from a single seed command a stranger could execute, with captions or a transcript on the recording.

Hard Tier (+ up to 25% additional extra credit)

Judgment, in writing. Required: a memo no assistant can write for you.

Write The Authorship Memo, two to three pages, addressed to the engineer who will inherit this repository:

• Name the single most assistant-shaped file in your project. Not the most complicated — the one where the largest share of what you shipped arrived drafted. Say honestly what proportion survived.
• Defend it as your work, or admit it is not yet. Walk the reader through the design decisions you made about that file, the specific changes you made to what you were handed and why, and the tests that prove it does what your requirement says. If you cannot do that for some part of it, say so — and say what you will do about it before Week 8, which is three weeks away and already full.
• Answer the 2 a.m. question. If that file failed in production at 2 a.m., what exactly would you do first? A person who can answer that owns the code. A person who cannot has found their homework.
• Make one call you cannot delegate. Find a place where you accepted output you cannot fully explain. Either explain it properly now or rewrite it in your own hands. Document which you chose, why, and what it cost you in hours — from the log, not from memory.
• Answer the chapter’s question in your own words: whose work is this, and what makes that true? Argue it. A memo that says “I used AI responsibly” is not an argument.

Graded on honesty, specificity, and self-awareness. A memo that admits one real gap and shows the plan to close it scores far above a memo claiming there are none.

Submission

Push to your default branch and tag the increment:

git tag -a iteration-1 -m "Core increment: FR-12, FR-04, FR-18 complete"
git push origin iteration-1

Your repository should now contain, at minimum:

docs/
  definition-of-done.md
  ai-usage.md
  hours-log.csv
  reviews/iteration-1-self-review.md
  demo/iteration-1-script.md
  authorship-memo.pdf        # Hard tier only
script/                      # setup, test, smoke, hours-report
seed/                        # or wherever your seed fixture lives
src/   tests/                # or your stack's equivalents

Submit to the Canvas dropbox: the repository link, the tag name, and the link to the demo recording. If your repository is private, confirm your instructor has access before the deadline — an inaccessible repository is an unsubmitted milestone.

Hints

• Pick the riskiest slice first, on Monday. Whatever depends on somebody else’s service, somebody else’s data, or a technique you have never used goes first, while there is still a week to react.
• Write the demo script before you write the code. Two minutes that tell you exactly which behaviors must exist by Friday — and stop you building things nobody will ever see.
• Multiply your estimates by your calibration factor before you commit to them. Last Friday’s report printed one. If it is 1.2×, then eight hours of typing buys you about six and a half hours of plan.
• Commit at every green test. Small commits are free while you work and impossible to manufacture afterward.
• Log the hours in the same tab as the work. Thirty seconds. That is the whole discipline.
• Run the report on Friday, not Sunday. If it flags your log you still have two days to fix the habit rather than the spreadsheet.
• Seed data is a deliverable. Commit it. A demo you cannot repeat on a clean machine is a demo you will not be able to give in Week 8 either.
• Record the fallback before you need it. Five minutes of screen capture on Saturday buys you the whole demo when the network dies on Sunday.
• When you are behind, cut scope, not process. Two slices done properly beats four done invisibly. The rubric agrees: twenty points for slices, forty-two for the evidence of how they were built. Your brief’s what-to-cut-first list already told you which feature goes.

The Demo Script, Good and Bad

The script is a real deliverable — docs/demo/iteration-1-script.md — and it is worth ninety seconds of your life, because it is the difference between five confident minutes and five apologetic ones.

Bad — a script that is really a wish:

1. Show the app
2. Add an item
3. Show the barcode thing
4. Talk about what's left

Every line requires a decision in the moment: which item, from what state, using which barcode, in what order. Under mild pressure you will make one of those badly, on camera.

Good — a script that runs itself:

0:00  "PantryPilot now closes FR-12, FR-04 and FR-18. A housemate can add an
       item by hand or by barcode, and the list flags anything expiring within
       three days. I'm starting from the seeded pantry - 12 items."
0:45  Pantry list already open. Point at the two amber rows (FR-18).
1:15  Add by hand: name "Greek yogurt", qty 2, expires 2026-02-18. Submit.
       Row appears amber immediately - that is FR-18 firing on new data.
2:00  Add by barcode: scan the known code from seed/products.json -> the name
       resolves and the item is added.
2:40  Failure path: scan 000000000000 -> "unknown product", the form falls
       through to manual entry. That is FR-12 AC-2, and the reason AC-2 exists.
3:20  Terminal: run the suite. 24 passing. Point at the four FR-12 tests.
3:45  "Not done: recipe suggestion. One slice, estimated six hours, scheduled
       Week 6. It is Should-have, so it is the first thing I cut if the lookup
       rate limit bites."
4:20  Stop talking.

Exact values, exact order, a failure path, evidence, and an honest gap — with forty seconds of slack. Rehearse it once and record it. That recording is your fallback, and it is quietly the first two minutes of your Week-8 presentation.

What Mastery Looks Like

A mastered Milestone 5 looks unremarkable from the outside, which is the point. Two or three features work. They work on somebody else’s seeded data. The tests are green in CI, and the commit history reads like a week of decisions rather than a burst of activity. Open docs/ai-usage.md and you find a candid record — this much was drafted, this much survived, here is what I changed and here is the test that proves it. Open docs/hours-log.csv and the numbers are uneven, the descriptions are specific, and one row says the assistant’s code cost an hour to debug.

Then the student demos, and the first sentence names the requirements closed instead of apologizing. Five minutes later they say, without prompting, exactly what is not done and which week it is scheduled for. Nobody had to ask. That is what an engineer looks like at the end of an iteration, and it is entirely reachable in twenty hours if the process is not abandoned in hour three.

Coach’s Note — The temptation this week is to believe the code is the deliverable and everything else is paperwork. Read the rubric again. Twenty points for the slices; forty-two for the evidence that you built them like a professional. That is not the course being fussy. It is the course telling you the truth about what separates a senior engineer from someone who can also make a feature work.

When You’re Done

• Two to three vertical slices merged, CI green, each traced to a requirement id
• Every acceptance criterion checked against an actual line of code — and confirmed to be about your user
• docs/definition-of-done.md committed, and nothing sits in Done with a failing check
• Four-pass self-review recorded for every slice, findings dispositioned
• docs/ai-usage.md written in-session, with what changed and how you verified it
• git log --oneline -15 reads as a story a stranger could follow
• No credentials in the diff or the history; env vars documented by name in README.md
• docs/hours-log.csv current through Week 5; the report runs with no pattern flags
• Demo script written, seed fixture committed, five-minute run rehearsed, fallback recorded
• “What is not done” written down, with the week it is scheduled and what you will cut
• Board and burn-down updated; tag iteration-1 pushed; links submitted

A theological footnote. “Whatever you do, work heartily, as for the Lord and not for men” (Colossians 3:23, ESV) — and the next verse gives the reason: the reward comes from the Lord, and it is the Lord Christ you serve. That reframes an odd amount of this milestone. Most of what is graded here is work nobody would ever catch you skipping: the test written at 11 p.m. when the feature already appeared to work, the log row for a session you could have left out, the honest note that forty of ninety-five lines arrived drafted. Working for men optimizes for what is visible, and a compressed term is exactly where that temptation bites hardest, because there is always something more visible to do with the next twenty minutes. Working heartily means the unseen parts are the same work as the seen parts. That is not a heavier burden than the rubric; it is a lighter one, because it settles in advance the question you would otherwise re-litigate every time you are tired. And it answers the chapter’s question from a direction no policy document can reach: the work is yours because you are the one answerable for it — before your grader, before whoever inherits this repository, and before God, who has always been the harder audience and the kinder one.