Chapter 8 — Deliver

“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

Seven weeks ago you had an empty repository and a brief you had not yet chosen. 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. Every requirement ID, every ADR, every defect-log row and hours-log line you have written since Week 1 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, but 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 life-cycle terms you are in closeout: release, delivery, and the retrospective that turns 160 compressed hours 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 six weekly milestones are 25%, the eight weekly quizzes are 15%, and 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 the milestones are the 50% — you have been building this submission one week at a time since Week 1, and the rubric in Milestone 8 awards points for exactly the artifacts they produced. If you kept pace, this week is an audit. If you did not, this is the week the deferred bill arrives, and in an eight-week course one week is an eighth of the term, so it arrives at double the price it would have in the long edition.

And there is one compression you need to see coming, because it is the only genuinely hard thing about Week 8 of an accelerated capstone. The sixteen-week edition spends an entire week building the presentation and a second week auditing and shipping. You have twenty hours for both. That is doable — comfortably, even — but only in one order: freeze Monday, audit and build the deck in parallel Tuesday and Wednesday, prove it Thursday, submit Thursday night, present Friday. Any plan that starts the deck on Thursday spends the audit hours on slides, and the audit hours are where the 50% lives.

The AI thread runs one final lap. As a tool, an assistant is genuinely good at this week’s job: 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. 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 understands something about completion that the other does not. We will take that 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.

8.1 — The Final Package, Artifact by Artifact

Your submission is one repository. Inside it are the artifacts a grader looks for by name — 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. Both are handled later this week.

Your working documents — docs/charter.md, docs/scoping-decision.md, docs/definition-of-done.md, docs/plan.md, docs/risk-register.md, docs/clean-machine-test.md — do not have rubric lines of their own. They feed the lines above, and a grader reads them when a line is contested. The scoping decision in particular explains why a 160-hour project has four Must requirements instead of nine, and that explanation earns points on line 2 every single year.

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.

Notice something else, and it is the accelerated edition in one sentence: the shelf is the same size, and the boxes on it are smaller. A sixteen-week capstone submits the same twelve lines you are submitting. What is two-thirds the size is what sits inside them — three or four Musts instead of nine, four ADRs instead of eight, eight weeks of hours instead of sixteen. Nothing professional was cut from this course, and nothing professional gets cut from this package. You are not submitting a smaller kind of thing; you are submitting the same kind of thing, sized to the hours you actually had.

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

A note on file names, because it costs points every year: use these names or names obviously equivalent to them, and index anything unusual in the README. A grader with forty repositories to read will not hunt. And nothing in your repository may be named after a course file — no chapter, no exercises, no project-08. Those are our filenames for teaching you; your repository is a professional artifact and should read like one.

8.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.

git clone --branch v1.0.0 --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.

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-12, each with a MoSCoW priority and 1–3 acceptance criteria in Given/When/Then form; §4 has NFR-01 … NFR-05, each with a number and a measurement method; §6 traces every FR to at least one test case ID. FR-07 is marked cut in Week 4 with a link to docs/change-requests/CR-002-cut-barcode-lookup.md.

The second one takes four minutes to write and 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 8 are found in exactly that act. Score honestly while you are at it — 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.

Then run the audit this edition needs. Open docs/requirements.md and hunt for inherited language — any sentence that arrived with your Fast-Start brief from Appendix B and never got adapted to the project you actually built. This is the signature failure mode of an accelerated capstone, and Week 8 is your last chance to catch a survivor:

• A user persona from the brief you never spoke to and never replaced.
• An acceptance criterion with a number from the brief — “under two seconds,” “at least fifty records” — that you never checked against your own build.
• A requirement describing a feature you scoped out in Week 2 or cut in Week 4, still sitting in the Must column.
• An NFR whose measurement method assumes the brief’s suggested stack rather than the one your ADR-0001 actually chose.

Every one of those is a grader finding a document that describes somebody else’s project. Adapting well is the accelerated skill; a leftover is the proof you did not. Fix them by editing the requirement and logging the edit as a change request if it changes scope — and if a requirement genuinely still holds as written, leave it, because inheriting a good requirement is not a sin. The sin is not having decided.

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.

8.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 here, 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.

Run it again as someone on Windows, someone with no admin rights, and someone who has never used your language’s package manager. Each persona finds a different class of gap: the unstated prerequisite (npm install, but never which Node), the invisible environment variable with no .env.example, the command that only works from one directory, the dead link to a document you renamed in Week 7, and 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 §8.5 exists: whether the commands actually work. A 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 against the real repository, and never let it be the last check before you submit.

One more use, cheap and worth it: ask it to read docs/handoff.md as the engineer just assigned this project and write the three questions they would ask in their first meeting. If those three are answered nowhere in your repository, you 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.

8.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. A published secret is a published secret, and there is no undo.

Two facts 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, issue a new one. Cleaning the history afterward is hygiene, not a fix.

Sweep three places against a fresh clone — files that should never be tracked, the working tree, and every commit on every branch:

cd /tmp/selfaudit
git ls-files | grep -Ei '(^|/)\.env($|\.)|\.pem$|(^|/)id_rsa$|\.keystore$|credentials$'
git grep -nIE '(api[_-]?key|secret|token|password)[[:space:]]*[:=][[:space:]]*[^[:space:]]{8,}'
git rev-list --all | xargs -n 40 git grep -nIE '\-\-\-\-\-BEGIN [A-Z ]*PRIVATE KEY\-\-\-\-\-'

Read every hit. A line reading password = process.env.DB_PASSWORD is exactly right and will still match; a scanner you trust blindly is worse than none. Dedicated tools exist — gitleaks and trufflehog are the ones you will hear named — and if one is already installed, run it too and check its own current documentation for the right subcommand rather than trusting a command you read here.

Three more things must not be in a repository you are about to publish. Real user data — if you interviewed roommates in Week 1 and pasted their answers into the charter, anonymize it; if your 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 launders nobody else’s. Anything you agreed to keep private, including verbally. Then check the reverse condition, which is the more common failure: .gitignore excludes secrets, but a .env.example with placeholder values should be committed, so a stranger knows which variables exist and what shape they take. Placeholders in, secrets out.

8.5 — The Clean-Machine Test on Somebody Else’s Machine

You ran this test in Week 7 and recorded it in docs/clean-machine-test.md — Run A, your own reproduction on an environment that was not your machine, and Run B, a real tester on a clean environment, in silence. Run it again, because the tag changed. That record is against a Week 7 commit, and everything since is unverified: the fixes the test itself provoked, the documents you rewrote this week, the release you are about to cut. This run is against the exact commit you are submitting, and its job is to prove that your Week 7 friction stayed fixed and your Week 8 edits did not break the setup path. And if you fell back to a solo Run B in Week 7 because no tester was available, this is the week you make that good.

The rule is the one that made Run B valid in Week 7, and it is worth restating because it is the part students soften: 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 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 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)"

Then fix what it found, today, and record the run. The standard, as flatly as I can put it: 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 smaller claim and not the one the rubric is grading.

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

8.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. 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 Milestone 7 as your deployable release. Semantic versioning (semver.org) gives 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 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.

Bad: “v1.0.1 — Final version. Fixed bugs and updated documentation. Everything should work now.”

Good:

v1.0.1 — Capstone submission

PantryPilot tracks what food a household has and flags what is about to expire. This release covers all four Must requirements (FR-01 … FR-04): inventory add/edit/remove, expiry alerts, the shared household view, and the weekly summary.

Not in this release: barcode lookup (FR-07, cut in Week 4 — see docs/change-requests/CR-002-cut-barcode-lookup.md) and CSV export (FR-11, deferred, issue #38). Keyboard-only navigation (NFR-03) is incomplete and tracked as DEF-17, severity Major.

Setup takes about ten minutes; see README.md. Verified on a clean machine by a tester who had not seen the project.

The good one is honest about what is missing, and being honest about what is missing is worth points on three rubric lines. It also explains itself to a human who has never heard of PantryPilot. Your grader reads forty of these; be the one that lands in the first sentence.

Last: verify the link from outside your own account. Open a private browser window, log out, paste the URL. If the repository is private, invite your grader and confirm they accepted — an unaccepted invitation 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 this course.

8.7 — The Thirty-Minute Presentation: The Arc and the Timing

The talk is 10% of your grade, it happens once, live, and there is no resubmission. The full brief and its rubric ship with this chapter as The Capstone Presentation; read that before you open a slide editor. This section is the shape.

There is exactly one narrative order that works, and it is not chronological. Nobody wants the story of your semester. Tell it like this, and notice that every beat is an index into an artifact you already own:

Three things about that allocation, and each is a retime for a project built in eight weeks rather than sixteen.

The demo is 6.5 minutes, hard-capped at 8. A two-thirds-size project has three or four Musts. You cannot honestly fill ten minutes with four features, and trying is how a demo turns into a tour of your settings page. Show each Must once, tied to its requirement ID, and stop.

Section 3 gets three full minutes, more than the long edition gives it. This is your talk’s distinctive claim, and it is the one your committee is most curious about: you took a brief, you decided what to keep and what to change, and you cut to fit a budget. Say which Fast-Start brief you adopted if you adopted one — that is disclosure, not weakness, and it is required. Then say what you changed about it and why. “I kept the problem and the user, replaced the suggested stack per ADR-0001, rewrote three acceptance criteria after talking to my actual user in Week 2, and cut two Shoulds in Week 4 when the halfway audit projected 190 hours” is the most senior-sounding thirty seconds available to you.

Section 8 gets two minutes. In a compressed project more got cut, so more needs explaining. Three items maximum, each with a requirement ID, a cause that is not “time,” and an hour estimate to finish. Build your run sheet from the template in code/talk-kit.md, which also carries the demo-script format, the failure protocol, the ten questions you will be asked, and the rehearsal-log columns; commit the whole set under docs/presentation/.

Demo discipline, because this is where thirty minutes goes to die. Scripted, seeded, rehearsed on the exact machine you will use. Never type into a form on stage. Rank where it runs: local instance needing no network, then the deployed instance on your own hotspot, then venue wifi, then — worst available option — anything making a live third-party call. Record a fallback, trim it to the demo’s length, write the per-step timestamps into your script, and play it once with the network disabled. If a step fails: one retry maximum, name the defect out loud by its ID, cut to the recording within twenty seconds, keep talking. Committees routinely score a clean fifteen-second recovery above a demo that never broke, because they have now watched you handle a failure.

Coach’s Note — Build the deck with your repository open on the other monitor, and give every slide a source. If you find yourself inventing content for a slide, stop — either the artifact is missing, in which case fix that first because it is worth 50%, or the slide should not exist.

8.8 — Saying What Did Not Get Done, and Why That Earns Points

Every student is convinced this slide will hurt them. Every experienced reviewer knows it is the one that helps most, and the mechanism is not sentimentality.

Your committee will find the gaps. They read the requirements you baselined in Week 4. They will notice that FR-07 never appeared. The only question is whether they hear it from you, framed and reasoned, or discover it themselves, in Q&A, unframed. Same fact, same software, completely different grade:

• You say it: “Barcode lookup is unbuilt. The Week 4 halfway audit projected 190 hours against a 160-hour budget, so I cut it as CR-002 and kept the two Musts it was competing with. It is task one in the handoff guide, about twelve hours.” → This person understands their own project and can plan.
• They find it: “So… what happened to barcode lookup?” “Uh — I ran out of time.” → This person does not know where their hours went.

Three columns, one row per item, three items maximum:

Each row names the requirement by ID, gives a reason that is not “time” — time is the symptom, not the cause — and puts a number on the remaining work, which is the clearest available signal that you can estimate. Two ways to get this wrong. The apology tour: opening with “I didn’t get as far as I wanted,” sprinkling “unfortunately,” closing with “sorry it’s not more impressive.” That does not read as humility; it reads as asking the room to lower its standards, and the room obliges. The cover-up: presenting only what works and hoping nobody opens the requirements. Somebody will, and the moment a committee catches one thing you glossed over, they start auditing everything else you said — including the parts that were true.

Coach’s Note — There is a difference between humility and self-deprecation, and only one is a virtue. Humility is an accurate account of what you did and did not do. Self-deprecation is an inaccurate one that happens to point downward. A lie about yourself is still a lie. Say the true thing, in a steady voice, and let it stand.

8.9 — The Retrospective: What Eight Weeks Taught You About Your Own Estimates

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 160 hours? Same budget. Same starting knowledge. Same eight weeks. That constraint is what forces a real answer, because you cannot escape it by wishing for more time.

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.

Nothing in that is false. Nothing in it is usable. No number, no requirement ID, no decision, 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 40 hours for construction (Weeks 5–6) and spent 61 — a 53% overrun, almost all of it in one task. FR-04 (the shared household view) was estimated at 6 hours and took 23. 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 touching an interface I have never personally called, multiply by three. I am carrying that multiplier into my first job.

The decision I would remake. ADR-0001 kept the stack the Fast-Start brief suggested because it was already written down and Week 1 was short. I had never used its migration tool. That cost me nine hours in Week 5 that a thirty-minute spike in Week 3 would have exposed. What I know now: adopting a brief’s stack is a decision, not a default — spike anything in it you have not personally run.

The same 160 hours. Cut FR-11 entirely — 7 hours, a Should, and neither of my two test users asked for it. Put 6 of those hours into NFR-03 (keyboard navigation), which is a Must and is still failing as DEF-17, and the seventh into Week 3, where I logged 11 hours instead of 20. The thin Week 3 design is why Week 5 went sideways.

Every claim points at a file already in the repository. That is the test. You have eight weeks of evidence sitting 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 — Hunt for one sentence 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 most engineers learn at thirty.

8.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 twice: Monday to build the list, Thursday to confirm it is empty.

Work it artifact by artifact. For each required item — working code, requirements specification, technical specification, decision records, test suite and results, defect log, hours log, README, runbook, handoff guide, change log, disclosure log, license, release tag — 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 finish 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: 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, rerun it. Do that 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.

8.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 he started came to fruition. 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 distinction is useful 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 in Week 4, a Must still failing, an idea from Week 1 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.

An eight-week course makes the point unusually hard to dodge. In sixteen weeks a student can nurse the fantasy that with a little more diligence everything on the list would have been built. In eight, the arithmetic refuses. You had 160 hours. You made a scoping decision in Week 1 and a cut in Week 4, in writing, on purpose, and now you hand over exactly what those decisions bought. That is not a lesser experience of finishing. It is a clearer one — the one every professional project actually has, with the comfortable illusion removed.

So what makes 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, and 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. That 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. 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 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. Eight weeks ago you counted the cost before you built — that is the Luke 14 discipline this course opened with — and this week you lay the tower down where others can see it. Some of what you hoped for did not happen. That is not a verdict on you, and the verdict was never yours to render on yourself anyway: “Let another praise you, and not your own mouth; a stranger, and not your own lips” (Proverbs 27:2, ESV). Which, conveniently, is also the strategy for Friday — let the tests, the demo, and the defect log be the strangers who speak for you.

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.

8.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: An inherited requirement that quietly describes somebody else’s project. Example: Your specification still says “barcode lookup against the product API” because Fast-Start brief #1 said so, and you scoped that out in Week 2. The grader reads a Must that does not exist in your build. Fix: Read every requirement out loud against the running software before you submit. Anything that arrived with the brief and never got adapted is either edited now or logged as a cut. Adapting well is the accelerated skill; a leftover is proof you did not.

Pitfall: Starting the deck on Thursday. Example: Week 8 carries both the audit and the presentation. Slides start Thursday morning, the clean-machine test never happens, and 50% pays for the 10%. Fix: Freeze Monday. Audit and deck run in parallel Tuesday and Wednesday, because the deck is built from what the audit finds. Thursday is the clean-machine test, the tag, and the submission.

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

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 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, never a branch name.

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, the slide built for it. A grader who finds an undisclosed gap stops trusting every other claim in the repository, which 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 §8.9 for the pair.

8.13 — Where Your Hours Went This Week

Twenty hours — the last twenty of a hundred and sixty. A realistic shape:

Two things about that table. First, six of those hours build the talk and two more deliver it — eight in total for 10% of your grade, against eleven and a half protecting the 50%. That ratio only works because the deck is assembled from artifacts rather than written from memory; a student who has to invent content for slides spends fifteen hours on the talk and audits nothing. Second, the largest single block is auditing, not producing. That is what a well-run Week 8 looks like: collecting and verifying work that already exists. If your week looks nothing like this, write that down in the hours log too. It is the last row, and it should be as true as the first.

8.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 — hunt your requirements specification for inherited language that describes somebody else’s project.
• Rep 6 — run the clean-machine test with a live human and do not speak.
• Rep 12 — 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 — the eighth and last of the quizzes that make up 15% of your grade, and the cheapest points still on the board. Then work the reps in order; the order is the order of the week.

8.15 — This Week’s Milestone

Milestone 8 — Milestone 8: 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 this whole book has been pointing at it since Week 1.

Two related assessments land in the same seventy-two hours: the 30-minute presentation (10%), whose full brief and rubric ship with this chapter as The Capstone Presentation, and the eighth weekly quiz (part of 15%). Three things due, in that order of weight. The whole grading contract is on one page in Appendix D if you want to see it once more.

8.16 — Coach’s Final Word

Eight weeks ago you had an empty repository and a catalog of briefs, and I told you that eight weeks is not enough time to discover what you want to build but is exactly enough to build something real. 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 precisely enough 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, then living with the estimate, then cutting in Week 4 when the arithmetic said cut. 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 a brief, adapt it into a project that is genuinely yours, 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 term. The judgment stayed yours. That was always the point.

And you did it in half the calendar. Do not let anyone, including yourself, call that a smaller thing. You made harder scoping decisions than the sixteen-week student made, earlier, with less information, and you had to live with them faster. That is the skill the industry is actually short of. Your project has flaws — every shipped thing does — and you know exactly what 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 8 is the final submission itself, the 50% · and The Capstone Presentation, the graded talk that ships with this chapter, is the 10%. Reference appendices: Appendix A (your workbench), Appendix B (the Fast-Start Catalog you adapted), Appendix C (the document kit — a template and a worked example for every artifact on the list), Appendix D (the grading contract and the full rubric), Appendix E (glossary). Previous: Chapter 7.