Chapter 16 — Delivery Day

“Real artists ship.” — Steve Jobs, as recounted by Andy Hertzfeld in the Macintosh team’s folklore

“I have fought the good fight, I have finished the race, I have kept the faith.” — 2 Timothy 4:7 (ESV)

Why This Matters

Fifteen weeks ago you had an idea and an empty repository. This week you hand somebody a link.

That is the whole difference between a student and an engineer, and it is bigger than it sounds. A student produces work that gets looked at. An engineer produces work that gets taken over — cloned by a stranger, run on a machine that is not theirs, read at eleven at night by someone who needs to fix a bug you left, and judged not by how hard it was for you but by how usable it is for them. Everything this course has made you do — the requirement IDs, the ADRs, the defect log, the hours log, the runbook — exists to make that handoff survivable. This week you find out whether it worked.

The hat you wear this week is the last one, and it is the heaviest: you are the owner. Not the developer who wrote it, not the tester who broke it, not the writer who documented it. The owner is the person who says this is done, here it is, and I will answer for it. Nobody else in a software organization gets to say that sentence, which is why the people who can say it honestly get paid to. In SDLC terms you are in closeout — release, delivery, and the retrospective that turns sixteen weeks of experience into something transferable.

Here is the grading reality, stated plainly one last time. The final implementation and its documentation are 50% of your grade. The fourteen weekly milestones are 25%. The sixteen weekly quizzes and the Week-8 checkpoint are 15%. The 30-minute presentation is 10%. The milestones were never a separate thing from this submission — you have already been paid for shipping them, and you have been building this package one week at a time since Week 1. The rubric in Milestone 16 awards points for exactly the artifacts those milestones produced. If you have kept pace, this week is an audit. If you have not, this week is where the deferred bill arrives, and it arrives at full price.

The AI thread runs one final lap, and it is a useful one. As a tool, an assistant is genuinely good at the job in front of you this week: give it your README with the instruction “you have never seen this project, you have thirty minutes, tell me the first place you would give up” and you will get a real list of real gaps. As a workload you govern, you have one non-negotiable duty before you make anything public: prove there is no key, token, or private dataset anywhere in the history you are about to publish. And the spine rule holds all the way to the last commit — the assistant reviews, the human decides, and the name on the integrity statement is yours.

Which brings us to the question the whole week hangs on: what makes work finished? Not “what makes it due” — the calendar answers that. Finished. There is a version of you that will still be adding features at 2 a.m. on delivery day, and a version that stopped three days ago, tested the release on a friend’s laptop, and slept. One of those versions has understood something about completion that the other has not. We will take that question seriously, because it is not really a project-management question. It is a question about what a work is for.

Let’s close this out.

16.1 — The Final Package, Artifact by Artifact

Your submission is one repository. Inside it are the artifacts a grader will look for by name — scored on twelve rubric lines, a couple of which bundle more than one file — and every one of them was produced by a milestone you already shipped.

This is the map. Keep it open all week.

Two things are gates, not point lines. Fail either and the rubric does not get read: the grader must be able to open the link, and the repository must contain no live credential. We handle both later this week.

Notice what this table says about the shape of your grade. Only 18 of 100 points are the code running. Eighty-two are the surrounding evidence that the code is understood, verified, documented, and transferable. Students find that ratio outrageous until they take a job, at which point they discover it is generous to the code.

Coach’s Note — If a file in that table does not exist yet, do not start by writing it from scratch. Start by looking for where its content already lives — in issues, in commit messages, in a Slack message to your roommate, in your own head. Almost nothing on this list is genuinely new work in Week 16. It is collection work. That distinction is the difference between an eight-hour week and a thirty-hour week.

A note on file names, because it costs points every year: use these names or names obviously equivalent to them. A grader with sixty repositories to read is not going to hunt. If your architecture document is called docs/design-doc-v3-FINAL.md, either rename it or say so in the README’s document index. And nothing in your repository should be named after a course file — no chapter, no exercises, no project-16. Those are our filenames for teaching you; your repository is a professional artifact and should read like one.

16.2 — Running the Rubric Against Your Own Repository

There is a specific discipline here and most students skip it, which is why most students lose points they had already earned.

Grade yourself first, with evidence, from a clone.

Not from your working directory — from a fresh clone of the tag you intend to submit. Your working directory is full of files you never committed, and the number of capstones that lose points because the crucial document was sitting untracked on the author’s desktop is not small.

The procedure:

git clone --branch v1.0.1 --depth 1 https://github.com/<you>/<repo> /tmp/selfaudit
cd /tmp/selfaudit
ls -R docs

Then, for each of the twelve rubric lines, write down three things: the path, a one-line evidence note, and a score you would defend to a stranger. Use code/final-submission-checklist.md; it is already laid out this way.

The evidence note is the part that matters, and it must be checkable in under a minute. Compare:

Weak evidence (scores itself full marks, will not survive):

Requirements: yes, they’re in docs/requirements.md. Complete.

Real evidence:

Requirements: docs/requirements.md §3 has FR-01 … FR-23, each with a MoSCoW priority and 1–3 acceptance criteria in Given/When/Then form; §4 has NFR-01 … NFR-09, each with a number and a measurement method; §6 is the traceability matrix mapping every FR to at least one test case ID. Two Shoulds (FR-14, FR-19) are marked deferred with a link to the issue.

The second one takes four minutes to write and it does two things at once: it proves the artifact to a grader, and it forces you to open the file. Roughly half the gaps students find in Week 16 are found in exactly this act — writing the evidence note and discovering that the thing you were about to claim is not actually in there.

Score honestly. If a line is a 6 out of 10, write 6. A self-audit that returns 100/100 is not an audit; it is a mood. The whole point is to find the cheapest points still on the table while there is still time to pick them up.

Coach’s Note — Rank your gaps by points per hour, not by how much they bother you. A missing LICENSE file is worth real points and takes four minutes. Rewriting a section of the architecture document you have never liked is worth almost nothing and will eat your Tuesday. This is the last week; be ruthlessly economic.

16.3 — The Hostile Read: Your README Through a Stranger’s Eyes

You cannot read your own README. Nobody can. You know what the missing step is, so your eye skates over the gap the way it skates over a typo in your own name.

An assistant is a genuinely good instrument for this, because it has the one qualification you have permanently lost: it has never seen your project. Paste the README — the whole file, not a summary — and give it a role and a stopping condition:

You are a competent developer who has never seen this project and has thirty minutes. Follow this README literally, step by step. At the first instruction you could not execute without guessing something, stop and tell me: which line, what you would have had to guess, and what you would have tried next. Do not be encouraging. Do not fill in anything the document does not say.

Then run it three more times with three different strangers: someone on Windows, someone with no admin rights on their laptop, and someone who has never used your language’s package manager. Each persona finds a different class of gap. What this catches, reliably:

• The unstated prerequisite. Your README says npm install; it never says you need Node, or which version.
• The invisible environment file. Your app reads DATABASE_URL; the README never names it and there is no .env.example.
• The command that only works from a specific directory, and the dead link to a document you renamed in Week 13.
• The step you do automatically — seeding the database, running a migration, creating the first user — and therefore never wrote down.

What it will not catch, and this is why §16.5 exists: whether the commands actually work. A language model will happily report that your quickstart looks clear while your build has been broken since Thursday. It is reading prose, not executing it. Treat its output as a list of suspicions, verify each one against the actual repository, and never let it be the last check before you submit.

One more use, cheap and worth it: ask an assistant to read your docs/handoff.md as the engineer who has just been assigned this project and to write the three questions they would ask you in their first meeting. If those three questions are answered nowhere in the repository, you have just found your handoff guide’s three biggest holes.

Coach’s Note — The most common failure of the hostile read is that students argue with it. The model says “I could not tell which port the server runs on” and the student thinks it’s obviously 3000. It is obviously 3000 to you. Every objection you dismiss this week, a grader will raise on Friday, and they will not be arguing — they will be deducting.

16.4 — Nothing Secret in the History

Before you make the repository public or hand the link to anyone outside your project, you owe one hard check. This one is not about points. It is about the fact that a published secret is a published secret, and there is no undo.

Two facts you need to hold onto:

1. Deleting a file does not remove it from history. git rm removes it from the tip. The blob is still in every earlier commit, and anyone who clones gets all of it.
2. Rewriting history does not un-leak a key. If a credential was pushed to a hosted service, assume it was seen. The only real remediation is rotation — revoke the old credential and issue a new one. Cleaning the history afterward is hygiene, not a fix.

Run the sweep in code/secret-scan.sh against a fresh clone:

bash secret-scan.sh /tmp/selfaudit

It checks three places — files that should never be tracked (.env, *.pem, id_rsa, keystores), the working tree, and every commit on every branch. It looks for the well-known credential shapes and for the assignment patterns people use when they mean to come back and fix it later. It will produce false positives; a line reading password = process.env.DB_PASSWORD is exactly right and will still match. Read every hit. A scanner you trust blindly is worse than none.

Beyond credentials, three more things must not be in a repository you are about to publish. Real user data — if you interviewed roommates in Week 3 and pasted their answers into a document, anonymize it, and if your test fixtures were seeded from real records, replace them. Someone else’s licensed content — vendored code, a restrictively licensed dataset, an image you did not have rights to; your LICENSE covers your work and does not launder anyone else’s. Anything you were asked to keep private — if your project touched a real organization’s data, honor whatever you agreed to, and verbally is still agreed to.

Check the reverse condition too, because it is the more common failure: your .gitignore should exclude secrets, but a .env.example with placeholder values should be committed. A stranger who clones your repository needs to know that DATABASE_URL and PRODUCT_API_KEY exist, what shape they take, and where to get their own. Placeholders in, secrets out.

16.5 — The Clean-Machine Test, One Last Time, on Someone Else’s Machine

You ran a clean-machine test in Week 13. Run it again. Two reasons: your project has changed, and — this is the part students dodge — the Week 13 test was probably run by you, in a container, on your own laptop, with your own tooling already installed.

This one has a rule that makes it real: a human being who is not you sits at a machine that is not yours, and you may not speak.

Not a hint. Not “oh you just need to—”. Not a sympathetic noise. You sit behind them with a notebook and write down every single thing they have to guess, ask, or look up. Every one of those is a documentation defect, and this test is the only instrument that finds them.

Use code/clean-machine-test.sh to run it honestly. The harness clones the exact tag you intend to submit into a throwaway directory, times the attempt, prompts the tester for the four numbers that matter, and writes a report you paste into docs/test-results.md:

bash clean-machine-test.sh https://github.com/<you>/<repo> v1.0.1 "Sam (roommate, Windows)"

The four numbers, and what a good one looks like:

Then fix what it found, today, and record the run. The record is worth points on the README line and it is worth far more than points in a job interview, where “we tested the setup instructions on somebody else’s laptop and it took eleven minutes” is a sentence very few new graduates can say.

Here is the standard, stated as flatly as I can: if a competent stranger cannot get your project running from your README in under thirty minutes without talking to you, your project does not run. It runs for you, which is a different and much smaller claim, and it is not the claim the rubric is grading.

Coach’s Note — Recruit your tester on Monday, not Thursday. The failure mode is not that nobody will help you — people are generous about this. The failure mode is that you find nine README defects on Thursday night with a talk to give on Friday morning.

16.6 — Tagging the Release and Submitting the Link

A branch moves. A tag points at one commit forever. You submit a tag, and you submit the commit SHA behind it, because a tag can technically be moved and a SHA cannot.

Sequence, in this order:

# 1. Everything merged and pushed. Stop writing features.
git status                    # must be clean
git push origin main

# 2. Update the change log for the version you are about to cut, then commit it.
git add CHANGELOG.md
git commit -m "docs: changelog for v1.0.1"
git push origin main

# 3. Annotated tag on the exact commit you are submitting.
git tag -a v1.0.1 -m "Capstone final submission"
git push origin v1.0.1

# 4. Record the immutable pointer.
git rev-parse v1.0.1^{commit}

Which number? You cut v1.0.0 in Week 14 as your deployable release. Semantic versioning (semver.org) gives you the rule for what comes next: documentation and bug fixes since then make it v1.0.1; new user-visible functionality makes it v1.1.0. Either is correct. What is not correct is retagging v1.0.0 at a different commit — a tag that changes meaning is exactly the thing tags exist to prevent.

Then publish a release from that tag on your hosting platform, with release notes. Release notes are not the change log; the change log is for developers and lists every change, while release notes are for a reader deciding whether to care. Roughly 150 words. Here is the difference:

Bad release notes:

v1.0.1 — Final version. Fixed bugs and updated documentation. Everything should work now.

Good release notes:

v1.0.1 — Capstone submission

PantryPilot tracks what food a household has, flags what is about to expire, and suggests what can be cooked from it tonight. This release covers all nine Must requirements (FR-01 … FR-09): inventory add/edit/remove, barcode lookup against the product API, expiry alerts, and the shared household view.

Not in this release: CSV export (FR-14, deferred, issue #52) and the recipe-suggestion feature (FR-19, cut in Week 12 — see docs/adr/0007-cut-recipe-suggestions.md). Keyboard-only navigation (NFR-05) is incomplete and tracked as DEF-31, severity Major.

Setup takes about ten minutes; see README.md. Verified on a clean machine 2026-05-01 by a tester who had not seen the project. Requires a free product-lookup API key.

The good one is honest about what is missing, and being honest about what is missing is worth points on three rubric lines. Notice also that it is written for a human being who does not already know what PantryPilot is. Your grader reads sixty of these. Be the one that explains itself in the first sentence.

Last: verify the link from outside your own account. Open a private browser window, log out, and paste the URL. If the repository is private, invite your grader and confirm they accepted — an invitation sitting unaccepted in someone’s inbox is, from the rubric’s point of view, a repository that does not exist. This ten-second check has saved more capstone grades than any other ten seconds in the course.

16.7 — Delivery Day: Setup, Nerves, and the Thirty Minutes

You built the deck and rehearsed it in Chapter 15. This section is about the ninety minutes around the talk, which is where talks are actually lost.

Arrive early enough to fail once. Thirty minutes if the room allows it, fifteen at minimum. Plug in. Project something. Find out that the adapter is wrong, that the projector clips your slide edges, that the room’s Wi-Fi captive portal wants a login — find out now, while it is an inconvenience instead of a disaster.

The pre-flight list, and do not improvise it:

• Deck exported to PDF, on the laptop, and on a USB drive, and emailed to yourself.
• Demo running locally with seeded data, already started, already logged in.
• The recorded demo fallback open in a second tab. You built this in Week 15. This is the day it earns its keep.
• Notifications off, Do Not Disturb on, everything you are not presenting closed.
• Battery at 100% and plugged in; screen sleep disabled. And water — a dry mouth at minute four is a real problem with a free fix.

On nerves. The physical sensation before you present is not a signal that something is wrong; it is your body preparing to do something that matters. The way through it is not calm, it is preparation: the first ninety seconds of your talk should be so rehearsed that you could deliver them badly rattled, because you might. Know your opening sentence cold. By minute three the adrenaline has metabolized and you are just a person explaining a thing they know well.

Demo discipline, one more time, because this is where thirty minutes goes to die. The demo is scripted, seeded, and rehearsed on the exact machine you will use. If anything is even slightly unreliable, you show the recording. Nobody in the room has ever thought less of a presenter for showing a recording; everyone in the room has watched a live demo die and felt the eight minutes of the presenter’s life leaking away. Cut to the recording within twenty seconds of a failure. Twenty seconds. Practice the cut.

Questions. You will get some version of these four:

1. Why did you choose that stack? — you have an ADR; answer with the tradeoff, not the preference.
2. What would you do differently? — you have a retrospective; give one specific answer with a number in it.
3. How did you use AI? — you have docs/ai-usage.md; answer plainly and completely. Hedging here reads as guilt for something you did not do.
4. What doesn’t work? — you have a defect log; name the open Musts before they have to ask twice.

And the answer you must have ready: “I don’t know.” Followed by “here’s how I’d find out.” Every experienced person in that room has said it; nobody respects a bluff, and a bluff is trivially exposed by one follow-up question. Then submit before you present, not after. Submitting after leaves your grade dependent on how the talk went, and you will not be in a state to run a careful checklist at 4 p.m. on delivery day.

16.8 — The Retrospective: The Same 240 Hours, Spent Better

The retrospective is worth 4 points and it is the most valuable four points in the rubric, because it is the only artifact you will still be using in three years.

The prompt is precise, so read it precisely: not “what did you learn,” which produces mush. The question is what would you do differently with the same 240 hours? Same budget. Same starting knowledge. Same semester. That constraint is what forces a real answer, because you cannot escape it by saying you would have had more time.

Here is the difference, and it is the whole lesson:

A bad retrospective:

This project taught me a lot about full-stack development and time management. I learned that planning is important and that I should start earlier next time. If I had more time I would have added more features. Overall I am happy with how it turned out and I feel more confident as a developer.

Nothing in that paragraph is false. Nothing in it is usable. It contains no number, no requirement ID, no decision, and no evidence. It could have been written in Week 1 by someone who did nothing.

A good retrospective, same student, same project:

Estimate error. I budgeted 62 hours for construction (Weeks 9–12) and spent 104 — a 68% overrun, all of it in two tasks. FR-07 (barcode lookup integration) was estimated at 6 hours and took 27. FR-19 (recipe suggestion) was estimated at 8 and took 21. Every task I had done something like before came in within 15% of estimate. The pattern is not “I am bad at estimating”; it is specific: any task that calls an interface I have never personally called before, multiply by three. I am carrying that multiplier into my first job.

The decision I would remake. ADR-0004 chose the barcode API on the strength of its documentation. I never called it before committing. Its rate limit — undocumented in the quickstart — cost me two full days in Week 10 and forced the caching layer in ADR-0006 that I had not planned or budgeted. What I know now: evaluate an integration by making one real call, not by reading the docs. A 30-minute spike in Week 5 would have saved 16 hours.

The same 240 hours. Cut FR-19 entirely — 21 hours, a Should, and zero of my three test users touched it in the Week 12 demo. Put 9 of those hours into NFR-05 (keyboard navigation), which is a Must and is still failing as DEF-31, and the other 12 into the two weeks I logged 6 hours instead of 15 (Weeks 6 and 7). The Week 6 shortfall is why the technical specification was thin, and the thin spec is why Week 10 went sideways.

Every claim in the good version points at a file already in the repository. That is the test: a retrospective is only as good as the evidence behind it, and you have sixteen weeks of evidence sitting right there in docs/hours-log.csv, docs/requirements.md, docs/defect-log.md, and docs/adr/. Start from code/retrospective-template.md and fill it from those files, not from memory.

Coach’s Note — The sentence to hunt for is one that has a number and a rule in it. “I underestimate unfamiliar integrations by about 3×” is worth more to your career than the entire rest of the document, because it is portable. You will use it in your first sprint planning at your first job, and your tech lead will notice that you know something about yourself that most engineers learn at 30.

16.9 — What This Becomes in an Interview

You are about to own something almost no new graduate has: a complete, documented, defensible software project with your name on it and a link you can send.

Use it correctly. Three formats, and you should have all three ready before you graduate.

The one-liner, for a résumé. Problem, scale, evidence, link. Not technologies — problem.

Bad: “Built a full-stack web app using React, Node, PostgreSQL, and Docker.”

Good: “PantryPilot — household food-inventory app that cut a four-person household’s expired-food waste in a two-week trial; 23 requirements specified and traced to tests, 87% of Musts passing at release, documented for handoff. github.com/you/pantrypilot”

The bad one lists tools, which every applicant lists. The good one describes a problem you owned and offers evidence a reader can check in ninety seconds. Both are one line; only one of them is worth the line.

The two-minute version, for a phone screen. Four beats, roughly thirty seconds each: the problem and who had it; the one hard decision and why you made it; what you shipped and how you know it works; what you would do differently. That last beat is the one that separates candidates — an engineer who can criticize their own work is an engineer who can be trusted with someone else’s.

The deep-dive, for a technical round. Have three stories loaded and rehearsed:

That last row is now a standard question and most candidates answer it badly — either “I don’t use them” (nobody believes you) or “I use them for everything” (nobody wants you). The right answer is the one you have been practicing all semester: name what you delegated, name what you refused to delegate, and name how you verified. You have a written record. Almost nobody does. One warning, though: do not claim more than the repository supports. If an interviewer opens your README while you talk — and some will — everything you just said gets checked in real time. The good news is that this is exactly why you did the work: your repository is the citation for your claims. Keep it public, keep the link on your résumé, and keep the tag pointing at the thing you actually finished.

16.10 — Interactive Lab: The Final Submission Auditor

Below this chapter on the website is The Final Submission Auditor. It is the rubric, live. Use it before you submit — ideally on Monday, and again on Thursday.

Work through it artifact by artifact. For each of the fourteen required items — working code, requirements specification, technical specification, decision records, test suite and results, defect log, hours log, README, runbook, handoff guide, change log, ai-usage log, license, release tag, which the rubric scores across its twelve lines — you confirm it is present, enter the repository path where it lives, and write the one-line evidence note that proves it. The auditor will not let you tick a box without both. That refusal is the entire pedagogical point.

As you go, it computes your projected score against the 50% implementation rubric, lists exactly what is missing, and — the part that changes behavior — tells you what each gap costs in points. Seeing “no LICENSE file: −5” next to “runbook thin: −3” reorders your week in about four seconds, and it reorders it correctly, because you will fix the five-point four-minute problem first.

When you are done it prints the submission block — repository URL, tag, commit SHA, access status, known gaps, integrity statement — formatted to paste straight into the course dropbox.

What it teaches: that grading is not a mystery. The rubric is published, the artifacts are enumerated, and the distance between where you are and full marks is a list, not a mood. Run it, work the list top-down by points-per-hour, and rerun it. Do this and you will not be surprised by your grade — which, on the day you hand over 50% of a course, is worth an enormous amount of sleep.

16.11 — What Makes Work Finished?

“I have fought the good fight, I have finished the race, I have kept the faith.” (2 Timothy 4:7, ESV)

Paul writes that near the end, in prison, to Timothy. What strikes me every time is the grammar of it. Three verbs, all completed. Not “I am fighting,” not “I hope to finish.” Finished. And notice what he does not say: he does not say I won, he does not say everything I started came to fruition, he does not say the churches he planted all thrived. He says he fought, he finished, he kept faith. The completion he claims is about faithfulness to the work given, not about the results being everything he once hoped.

That is a genuinely useful distinction on delivery day, because there is a lie waiting for you this week, and the lie is that finished means complete. It does not. It never has. Your project has things that do not work. There are requirements you cut, a Must that is still failing, an idea from Week 2 that never got built. Every professional project on Earth ships in that condition. Software is never complete; the question is whether it is finished, and those are different words.

So what does make work finished? Three things, and none of them is “there is nothing left to do.”

First, honesty about its state. A work is finished when you can say truthfully what it does and what it does not. This is why the defect log and the “what did not get done” section earn points — not as punishment, but because an accurate account of a thing is part of the thing. A project whose author cannot tell you its condition is not finished; it is abandoned with the lights left on. Scripture is relentless about honest weights and measures, and a status report is a measure.

Second, that it can be handed over. Genesis says God finished his work and rested; the world was given to someone to keep. There is something built into the shape of good work that it is for somebody, and it is not done until it can be received. This is the whole theological weight behind the clean-machine test, which otherwise looks like a grading gimmick. A work you cannot hand to another person is a work still tangled up in you. Documentation is the untangling.

Third, that you stop. This is the hard one for the students I most enjoy teaching. There is a form of perfectionism that presents as diligence and is actually a refusal — a refusal to submit the work to judgment, because as long as it is unfinished it cannot be found wanting. Stopping is an act of trust: I did what I could with the hours I was given, and I am releasing it. That is not laziness. It is closer to the opposite. The person who is still adding features at 2 a.m. on delivery day is not more committed than the person who stopped on Tuesday and tested; they are more afraid.

Which is where the last clause matters most: I have kept the faith. Sixteen weeks ago we opened this course counting the cost of a tower (Luke 14:28). You counted it, you built, and you are laying it down. Some of what you hoped for did not happen. That is not a verdict on you. The verdict was never yours to render on yourself anyway — “Let another praise you, and not your own mouth” (Proverbs 27:2, ESV), which you sat with last week. Do the work honestly, describe it truthfully, hand it over cleanly, and then let it go.

Finished is not the same as flawless. Finished means: I ran the race that was actually in front of me, all the way to the line, and I told the truth about how it went.

That is available to you this week. Take it.

16.12 — Common Pitfalls

Pitfall: Auditing your working directory instead of a fresh clone. Example: docs/handoff.md looks perfect on your laptop. It was never git added. The grader clones the tag and it is not there. Fix: Every audit this week runs against git clone --branch <tag> into a throwaway directory. Never against the folder you have been working in.

Pitfall: Submitting a private repository link nobody can open. Example: You invite the grader; the invitation sits unaccepted. Or you submit a link to a branch that you later delete. Fix: Open the URL in a logged-out private browser window. If private, confirm the invitation was accepted, and submit the tag plus the full commit SHA, not a branch name.

Pitfall: Writing new features in Week 16. Example: Tuesday night inspiration adds a half-built feature that breaks the build, and the clean-machine test you scheduled for Wednesday now fails. Fix: Feature freeze on Monday. After the freeze, only three kinds of commit are allowed: documentation, a fix for something the audit found, and the change log. Anything else becomes an issue for your successor.

Pitfall: Hiding what does not work, hoping it goes unnoticed. Example: An open Must requirement omitted from the README, the release notes, and the talk. Fix: Name it first, everywhere — README, release notes, defect log, slide 12. A grader who finds an undisclosed gap stops trusting every other claim in the repository, and that costs far more than the gap did. Disclosed gaps earn points; discovered ones cost several lines’ worth.

Pitfall: A retrospective made of feelings. Example: “I learned a lot about time management and would start earlier next time.” Fix: Every claim cites a file: an hours-log row, a requirement ID, a defect number, an ADR. End with at least one rule that has a number in it. See §16.8 for the pair.

Pitfall: Publishing a repository whose history contains a credential. Example: A working API key committed in Week 9, deleted in Week 10, still sitting in the history you just made public. Fix: Run code/secret-scan.sh against a fresh clone before you publish, and rotate anything it finds. History rewriting is cleanup, not remediation — a pushed key is a compromised key.

Pitfall: Submitting after the presentation instead of before. Example: The talk runs long, you are wrung out, and you rush the submission block at 4:40 p.m. with the wrong SHA. Fix: Freeze, tag, audit, and submit the day before delivery day. Walk into the room with nothing left to do but talk.

16.13 — Where Your Hours Went This Week

Roughly fifteen hours, the last fifteen of two hundred and forty. A realistic shape:

Two things about that table. First, only 1.5 hours are the presentation itself — the deck was built last week, and if you are still building slides on Thursday you have borrowed those hours from the audit, which is where the 50% lives. Second, notice that the largest block is auditing, not producing. That is what a well-run Week 16 looks like: you are collecting and verifying work that already exists. If your week looks nothing like this, the honest move is to write that down in the hours log too. It is the last row, and it should be as true as the first.

16.14 — Reps

The reps for this week are in the exercises, and this week they are not conditioning — they are the submission, built in order. Preview:

• Rep 1 — clone your own tag into a throwaway directory and inventory what is actually there.
• Rep 2 — score all twelve rubric lines with a defensible evidence note for each.
• Rep 4 — run the hostile README read, then verify every finding against the real repository.
• Rep 5 — run the clean-machine test with a live human and do not speak.
• Rep 9 — write the retrospective’s estimate-versus-actual section from the hours log.

Do the on-page Check Your Reps quiz when you finish the chapter, then take Week 16 Quiz in Canvas — the sixteenth and last of the graded weekly quizzes. Then work the reps in order; the order is the order of the week.

16.15 — This Week’s Milestone

Milestone 16 — Milestone 16: The Final Submission. This is the one. 50% of the course grade, the full artifact list with repository paths, the complete rubric, the clean-machine acceptance test, the submission procedure, and the integrity statement you will sign.

Read it before you touch anything else this week. Everything in this chapter is instructions for satisfying that file, and the whole book has been pointing at it since Week 1.

The related assessments: the 30-minute presentation (10%) that you prepared in Chapter 15 and deliver this week, and the sixteenth weekly quiz (part of 15%). Three things due, in that order of weight. The full grading contract lives in Appendix C if you want to see it all on one page one more time.

16.16 — Coach’s Final Word

Sixteen weeks ago you had an idea and an empty repository, and I told you a capstone is not a big homework assignment. Here is what I meant.

You wore every hat. You were the product owner deciding what this thing was for, and the business analyst who had to write it down so precisely that a stranger could verify it. You were the architect who chose a stack and — harder — wrote down why, permanently, where your future self could see the reasoning. You were the project manager estimating work you had never done, and then living with the estimate. You were the developer, the tester who went looking for your own faults, the technical writer nobody thanks, the release engineer who made it run somewhere that was not your laptop. And this week, the owner.

Most people never wear all of those. That is the actual education here. The framework you used will be legacy in six years. The ability to take an idea, specify it so it can be verified, plan it against real hours, build it, test it, document it, and hand it to a stranger — that is not going to be legacy, and it is not going to be automated away, because every one of those steps is a place where a human being has to decide something and be accountable for the decision. The assistants got better all semester. The judgment stayed yours. That was always the point.

Your project has flaws. Every shipped thing does. You know exactly what they are, they are written down with severity ratings and issue numbers, and you can speak about them without flinching — which puts you ahead of engineers with a decade on you.

So: freeze it. Audit it from a clean clone. Test it on somebody else’s machine. Tag it. Submit it. Stand up and tell the truth about it for thirty minutes. Then close the laptop.

You fought the good fight. You finished the race. Go turn it in.

It has been a privilege. Ship it.

Up next: the exercises is the submission week rep by rep · Milestone 16 is the final submission itself, the 50%. Reference appendices: Appendix A (your workbench), Appendix B (the document kit — templates and worked examples for every artifact on the list), Appendix C (the grading contract and full rubric), Appendix D (fifty capstone ideas, sized), Appendix E (glossary). Previous: Chapter 15.