Milestone 10 — Core Increment & Demo

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

Chapter: Chapter 10 — Iteration One: Building the Core Week: 10 of 16 — construction, wearing the developer’s hat Due: End of Week 10 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-16 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 draft of your Week-15 presentation. 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 Appendix C.

The Setup

Your skeleton walks. It is thin, it is ugly, and it proves the pipe is open end to end. Now somebody has to put a product inside it, and that somebody is you, with roughly fifteen 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 16, and by then it is unfixable.

So the milestone has two halves, and they are graded together on purpose. Build three to five vertical slices that 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 shape of this course, because Week 10 is where students start doing the arithmetic. The milestones carry 25% between them — about 1.8 points each — and that is the smaller half of what they are worth. The Week-16 submission is 50% of your grade and it awards points for exactly the artifacts these milestones produce, so every one of them is paid for twice. Skipping this week costs you the milestone now and defers the identical rubric points to a week that already has a presentation, a final rubric audit, and a clean-machine test in it. The pace table in Appendix C tells you where you should be. Six weeks remain.

Learning Targets

You will demonstrate that you can:

• Decompose prioritized requirements into vertical slices that each deliver observable behavior.
• Apply a definition of done as a gate that is genuinely allowed to reject your own work.
• 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.
• Keep a commit history a stranger could read as the story of the week.
• Keep an hours log honest while under real time pressure, and read what it tells you.
• 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 project’s 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 in that 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 of that table 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 6 and one who finds out in Week 14. 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 6 is a conversation and a scope cut. A red discovered in Week 15 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. Three to five 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.
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 self-review record for at least three slices: what each pass found, and for every finding, whether it was fixed, logged as a defect, or accepted with a written reason.
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, subject lines saying what, bodies saying why, issue and requirement ids referenced, and no credentials anywhere in the diff.
6. docs/hours-log.csv current through Week 10, in the eleven-column format — the ten columns from Appendix B, section B.11, plus the ai_assisted column you added in Week 7 — with any reconstructed rows explicitly labeled.
7. A five-minute demo of working software, following docs/demo/iteration-1-script.md, run on committed seed data, 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 this week and what moved.

Normal-tier rubric (out of 100)

Medium Tier (+ up to 25% extra credit)

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

• A sixth and seventh slice, closed to the same standard — but only if the first five actually met it. Quantity that skips the gate scores nothing.
• 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 things four self-review passes will not.
• One measured non-functional requirement. Pick an NFR with a number in it, measure it against real-ish data, and record the method and the result. “It feels fast” is not a measurement; a p95 over 200 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.
• Captions or a transcript on the demo recording, and a demo that runs from a single seed command a stranger could execute.

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 are going to do about it before Week 16.
• 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.
• Answer the chapter’s question in your own words: whose work is this, and what makes that true? Argue it. A memo that just 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 that claims there are none.

Submission

Push to your default branch and tag the increment:

git tag -a iteration-1 -m "Iteration one: FR-04, FR-12, 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
seed/                        # or wherever your seed data lives
src/  (or your stack's equivalent)  # the slices themselves

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. It is a two-minute exercise that tells you exactly which behaviors have to exist by Friday, and it stops you from building things nobody will ever see.
• 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. Keep docs/hours-log.csv open. Thirty seconds. That is the whole discipline.
• Run code/hours_report.py 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 16 either.
• Record the fallback before you need it. Five minutes of screen capture on Saturday buys you the entire demo when the network dies on Sunday.
• When you are behind, cut scope, not process. Three slices done properly beats five slices done invisibly. The rubric agrees with me: twenty points for slices, forty-two for the record of how they were built.

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 just a wish:

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

Every line of that 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 decisions badly on camera.

Good — a script that runs itself:

0:00  "PantryPilot now closes FR-04, FR-12 and FR-18. A household member 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 is already open. Point at the two amber rows (FR-18).
1:15  Add by hand: name "Greek yogurt", qty 2, expires 2026-03-23. 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 product
       name resolves and the item is added.
2:40  Failure path: scan 000000000000 -> "unknown product", form falls through
       to manual entry. That is FR-12 AC-2, and it is 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, two slices, estimated 8 hours, scheduled
       Week 12. It is marked Should-have, so it is the first thing I cut if
       the barcode rate limit becomes a problem."
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 also, quietly, the first two minutes of your Week-15 presentation.

What Mastery Looks Like

A mastered Milestone 10 looks unremarkable from the outside, which is the point. Three or four 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 fifteen hours if the process is not abandoned in hour three.

Coach’s Note — The temptation this week is to believe that 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

• Three to five vertical slices merged, CI green, each traced to a requirement id
• Every acceptance criterion checked against an actual line of code
• docs/definition-of-done.md committed, and nothing sits in Done with a failing check
• Four-pass self-review recorded for at least three slices, findings dispositioned
• docs/ai-usage.md written in-session, with what changed and how you verified
• 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; the report runs with no pattern flags
• Demo script written, seed data committed, five-minute run rehearsed, fallback recorded
• “What is not done” written down, with the week it is scheduled
• 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 entry for a session you could have left out, the honest note that forty of ninety-five lines came from an assistant. Working for men optimizes for what is visible. 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 a policy document cannot reach: the work is yours because you are the one who is 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.