Milestone 8 — The Final Submission

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

Chapter: Chapter 8 — Deliver Week: 8 of 8 · the last twenty of your 160 hours · feature freeze from Monday Due: Before your presentation slot, not after. Freeze Monday, audit Tuesday–Wednesday, prove and submit Thursday. Weight: 50% of the course grade. This is the final. The six milestones you already shipped are a separate 25%; the eight weekly quizzes are a separate 15%; the 30-minute presentation is a separate 10%. Submit: One repository link, one release tag, one commit SHA, and the submission block, pasted into the course dropbox. Where it lands in the final package: This milestone is the final package. Every artifact from Milestones 1, 2, 3, 5, 6, and 7 is graded here, at the paths below. Nothing you submit this week is new except the retrospective and the release itself. AI policy: Open, with full disclosure. Use whatever assistance you used all term and account for it in docs/ai-usage.md. The spine rule is unchanged and it is now a graded line: the assistant accelerates, you decide, verify, and are accountable. You sign the integrity statement. “The model wrote it” has never been a defense and is not one now.

The Setup

The link goes out and you do not get to stand next to it.

That is the entire test. Somewhere, someone opens a repository they have never seen, belonging to a person they cannot ask questions of, and tries to understand what it is, run it, verify it works, and figure out what to do next. Everything you have built for eight weeks either survives that encounter or it does not.

This is not a school exercise dressed up as a professional one. It is the actual thing. When you hand a project to a new team, when you leave a job, when you open-source something, when a client’s engineer takes over your work — this is the moment, exactly as described. The only difference is that this time somebody is scoring it and telling you where the holes are, which is a kindness you will rarely get again.

You are not producing this package. You produced it, one week at a time, since Week 1. What you are doing now is freezing, auditing, proving, and handing over. If you kept pace, this is a twenty-hour audit with a talk attached. If you did not, this is the week the deferred bill arrives — on top of the milestone points already lost along the way. The milestones were never a separate thing from this package. They were this.

And one honest word about size. Your package has the same twelve graded lines a sixteen-week capstone submits. What is two-thirds the size is what sits inside them: three or four Musts, four decision records, eight weeks of hours. Do not apologize for that anywhere in this submission. A 160-hour project scoped and delivered on purpose scores higher than a 240-hour project attempted in 160 and abandoned half-built — every year, without exception, because one of those is engineering and the other is wishing.

Learning Targets

You will demonstrate that you can:

• Assemble a complete, professional software deliverable — code plus the documents that make code usable by someone else.
• Audit your own work against a published rubric from a clean clone, with defensible evidence for every line.
• Prove reproducibility by having a stranger run your project on their machine from your documentation alone, and record the result honestly.
• Cut a release: freeze, change log, annotated tag, release notes, immutable commit reference.
• Publish safely — no credential, no private data, no unlicensed content in the working tree or the history.
• Show that you adapted rather than inherited — a specification that describes your project, not the brief you started from.
• Disclose AI assistance accurately and take accountability for work you did not personally type.
• Retrospect with evidence, converting eight weeks of logs into a portable rule about how you actually work.
• Tell the truth about the state of your own project, including what does not work.

Normal Tier

Required deliverables

One repository, one tag. Twelve graded artifacts, at these paths or at paths obviously equivalent to them and indexed in the README.

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 — are not separate rubric lines. They feed the lines above and a grader opens them when a line is contested. docs/scoping-decision.md in particular carries line 2: it is where you say which Fast-Start brief you started from, what you kept, what you changed, and what you cut to fit 160 hours. If you have been keeping hours in a spreadsheet, export it to docs/hours-log.csv before you submit — that is the path on the rubric. Nothing in your repository may be named after a course file (chapter, exercises, project-08); your repository is a professional artifact and reads like one.

A reference layout, which you may adapt as long as the README indexes it:

your-capstone/
├── README.md
├── LICENSE
├── CHANGELOG.md
├── .gitignore
├── .env.example                    # placeholder values, committed on purpose
├── src/                            # or app/, cmd/, lib/ — whatever your stack calls it
├── tests/
├── script/                         # setup, seed, test, smoke — one-word verbs
├── docs/
│   ├── charter.md                  # M1: the problem, the user, the commitment
│   ├── scoping-decision.md         # M1: brief adopted, adapted, and what you cut
│   ├── requirements.md             # M2: FRs, NFRs, constraints, traceability
│   ├── definition-of-done.md       # M2
│   ├── architecture.md             # M3, revised in M7: the technical spec, as built
│   ├── plan.md                     # M3: work breakdown, estimates, schedule
│   ├── risk-register.md            # M3 onward
│   ├── test-plan.md                # M6
│   ├── test-results.md             # M6 + this week's clean-machine record
│   ├── defect-log.md               # M6 onward
│   ├── hours-log.csv               # M1 onward, all eight weeks
│   ├── runbook.md                  # M7: operate, back up, roll back
│   ├── clean-machine-test.md       # M7: the first proof it runs elsewhere
│   ├── handoff.md                  # M7: day one for your successor
│   ├── ai-usage.md                 # every week + the integrity statement
│   ├── retrospective.md            # M8
│   ├── presentation/               # M8: run sheet, deck, demo script, fallback
│   ├── adr/                        # M3 onward: 0001-choose-the-stack.md, ...
│   └── change-requests/            # Week 4 onward: CR-001-....md, one file per request
└── .github/workflows/ci.yml        # M3, or your CI provider's equivalent

Normal-tier rubric (out of 100)

Two gates, scored before the rubric is read. Fail either and the rubric is not applied until it is fixed:

1. Access. The grader can open the link. Verify from a logged-out private browser window. If the repository is private, the invitation must be accepted, not merely sent.
2. No live credential anywhere in the working tree or the history. If a sweep finds one, rotate it first, then clean, then resubmit. A pushed key is a compromised key.

How the points actually move. Only 18 of 100 are the software running. The other 82 are the evidence that it is specified, verified, documented, and transferable. Do not spend your last week on features; spend it on the eighty-two.

The Clean-Machine Acceptance Test

Required, recorded, and the hardest single standard in the course. You ran one in Week 7 in docs/clean-machine-test.md; that one was probably you, in a container, on your own machine. This one is not.

Setup. A person who is not you. A machine that is not yours. Your README, and nothing else. The exact tag you intend to submit. Use code/clean-machine-test.sh — it clones the tag into a throwaway directory, times the attempt, and writes the record.

The rule: you do not speak. Not a hint, not a correction, not a sympathetic noise. You sit with a notebook and write down everything the tester has to guess, ask, or look up. Each one is a documentation defect.

Record it in docs/test-results.md: date, tester (initials are fine if they prefer), operating system, tag, commit SHA, minutes to first successful run, and every gap found. Then fix the gaps and note the fixes. A recorded failing test that you fixed and re-ran scores better than a passing test you cannot evidence — because the second one is not a test, it is a claim.

Medium Tier (+ up to 25% extra credit)

Evidence that goes past the bar. Pick what genuinely fits; two done well beat five done thinly.

• A live deployment. A running instance at a URL, named in the README, with the deployment procedure in the runbook and a note on what it costs to keep up. (Hosting tiers change constantly — state what you are using and when you checked it, not what it costs forever.)
• Green CI at the submitted tag. The pipeline from Milestone 3 running the full suite on the tagged commit, with the run linked from the README.
• Measured non-functional evidence. Your NFR targets from Week 2 with actual measured numbers beside them and the method used — not “it feels fast.”
• A second independent clean-machine test on a different operating system, by a different person, both recorded.
• A successor backlog. Five or more well-formed issues — title, context, acceptance criteria, a pointer to the relevant code — that a new engineer could pick up cold. Label the two easiest as good first issues.
• A dependency and license inventory. Every third-party component, its version, and its license, with a note on anything that constrains how your project may be used. (SPDX is the standard identifier list; choosealicense.com is the plain-language guide.)
• A security pass in docs/security-review.md: what you checked, what you found, what you fixed, what you consciously accepted and why.

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

Required: the Successor’s Brief — a 3–4 page memo, written to the engineer who inherits this project. No assistant can write it for you, because every section requires you to own a judgment. Address it to a real reader: competent, unfamiliar, and about to be responsible for your work.

1. The decision I would reverse. Name one architectural or scoping decision, cite the ADR or the change request, state what you knew then and what you know now, and lay out the migration path — what it would cost in hours to change it today, and whether it is worth doing. A recommendation with a number, not a regret.
2. The parts I do not trust. Every system has regions its author is uneasy about. Name yours specifically — the module with thin tests, the integration whose failure modes you never mapped, the query that will not survive ten times the data. Say why, and say what evidence would settle it. This section is worth more than any other and students consistently avoid it.
3. What eight weeks cost me. The compression is a real engineering constraint, so treat it as one. Name the two places where 160 hours visibly shows in this codebase, say what a further 80 hours would buy and in what order, and say which of your Week-4 cuts you would restore first. Not an excuse — a plan.
4. The AI accountability statement. Where you drew the line between what you delegated and what you refused to delegate, and — with hindsight — where you would draw it differently. Name one specific thing an assistant produced that you accepted and should have scrutinized harder, or scrutinized and rejected and were right to. Then answer the question your first employer will actually ask: what is your rule for what you will sign your name to?

Graded on judgment, specificity, and honesty. A memo that admits nothing scores near zero; the whole value of the exercise is that it requires the one thing a tool cannot supply, which is ownership.

Submission

Do this in order, the day before your presentation.

1. Freeze. Stop writing features. After the freeze, only three kinds of commit are allowed: documentation, a fix for something the audit found, and the change log.

2. Audit from a clean clone. Never from your working directory.

git clone --branch <your-current-tag> --depth 1 https://github.com/<you>/<repo> /tmp/selfaudit

Work code/final-submission-checklist.md against that clone — including its accelerated-edition sweep for inherited language — and run the auditor widget on the chapter page. Fix gaps in points-per-hour order.

3. Sweep for secrets in the working tree and the history, then read every hit; password = process.env.DB_PASSWORD is correct code and will match. Rotate anything real. Only then make the repository visible.

4. Update the change log, then tag. You cut v1.0.0 in Milestone 7; docs and fixes since then make this v1.0.1, new user-visible functionality makes it v1.1.0 (semver.org). Never move an existing tag.

git add CHANGELOG.md && git commit -m "docs: changelog for v1.0.1"
git push origin main
git tag -a v1.0.1 -m "Capstone final submission"
git push origin v1.0.1
git rev-parse v1.0.1^{commit}          # copy this SHA into the submission block

5. Publish a release from the tag with release notes: what it is in one sentence, what works, what does not, roughly how long setup takes, and the clean-machine verification date.

6. Verify access from outside. Logged-out private browser window. Paste the URL. If it 404s, nothing else you did this term is visible.

7. Submit the block.

Repository:   https://github.com/<owner>/<repo>
Tag:          v1.0.1
Commit SHA:   <40 hex characters>
Access:       public  |  <grader-username> invited and accepted on <date>
Verified on:  <OS/runtime> — clean-machine test <date>, tester <name or initials>
Known gaps:   <open Must requirements by ID, or "none">
Integrity:    <the statement below, signed>

Academic Integrity and AI Disclosure

You will sign this. Put it at the top of docs/ai-usage.md and paste it into the submission block.

Integrity statement. This repository is my own work. I wrote or directly supervised, reviewed, and understand every line in it, and I can explain any part of it on request. All assistance I received — from AI tools, documentation, tutorials, libraries, classmates, the Fast-Start Catalog brief I adapted, or anyone else — is disclosed in docs/ai-usage.md and docs/scoping-decision.md. Third-party code and content are attributed and used within their licenses. No requirement, test result, measurement, or log entry in this repository is fabricated.

— <your full name>, <date>

Adapting a Fast-Start brief is not something to disclose defensively; it is the course design, and every brief is written to be adopted. What you must do is say so plainly, in docs/scoping-decision.md and on your scope slide, and be able to state what you changed. An adapted brief you can account for is professional. An inherited brief you cannot is the failure this edition exists to prevent.

The AI disclosure log is a table, kept all term, and it is graded on specificity, not on how little AI you used. Nobody is penalized for using assistance well. People are penalized for vagueness.

A bad disclosure:

I used ChatGPT to help with some of the coding and to fix bugs.

A real disclosure:

Note what the good version does: it names what was rejected, not just what was accepted — the clearest possible evidence that a human was in the loop. Do not guess at a model version you cannot see; write what the tool displayed, or write “version not shown.”

What is not acceptable, in any tier: submitting code you cannot explain; a fabricated test result, measurement, or hours-log entry; an undisclosed third-party component; presenting someone else’s project as your own. These are integrity violations, not rubric deductions, and they are handled under your institution’s policy.

Hints

• Recruit your clean-machine tester on Monday. The failure mode is not that nobody will help; it is finding nine README defects on Thursday night with a talk on Friday morning.
• Audit and deck in parallel. They are the same source material. Every evidence note you write for the rubric is a slide you no longer have to invent.
• Write the evidence note before you tick the box. Half the gaps students find this week are found in the act of writing one sentence of proof and discovering there is nothing to point at.
• Fix by points-per-hour. A missing LICENSE is 5 points and four minutes. Rewriting a section you never liked is worth almost nothing and will eat a day.
• Read your requirements against the running software once, out loud. That is how you catch the requirement that still describes the brief instead of your build.
• Disclose gaps first, everywhere. README, release notes, defect log, the slide built for them. A disclosed gap costs one line’s points; a discovered one costs the grader’s trust in every other line.
• Submit before you present, never after. You will not be in a state to run a careful checklist at 4 p.m. on delivery day.
• The templates are already written. Appendix C has every artifact as a blank template, a worked example, and a deliberately bad version annotated with what it costs. Appendix D is this rubric on one page.
• Use the auditor twice — Monday to build the list, Thursday to confirm it is empty.

What Mastery Looks Like

A mastered submission is one a stranger can take over on a Tuesday afternoon.

They clone it, read the README, and are running it in eleven minutes. They open the requirements specification and find every claim in the README backed by an ID with acceptance criteria they could verify themselves — and every requirement is unmistakably about this project, not about a brief. They open the architecture document and it matches the code in front of them, and where it doesn’t, an ADR explains when and why the build diverged. They look for what’s broken and don’t have to hunt, because the author listed it first, with severities, in three places. They find a scoping decision that says, in writing, “160 hours buys four Musts, so I cut these two in Week 4, and here is the change request.” They find an hours log with a bad week in it, honestly recorded. They find an AI usage log that names things the author rejected. They find a retrospective with numbers in it and one hard sentence about a decision the author would remake.

And somewhere in the first twenty minutes they think: this person is careful, and I can trust what they wrote down.

That is the whole grade, and it is the whole job. Every professional reputation you will ever have is built out of exactly that reaction, repeated.

Coach’s Note — The temptation on the last day is to spend your final six hours making the software slightly better. Resist it. Six hours on the eighty-two points is worth more than six hours on the eighteen — and more importantly, an unfrozen repository cannot be audited, cannot be tested on a clean machine, and cannot be honestly described. You cannot deliver a moving target. Freeze it, then finish it.

When You’re Done

• Feature freeze declared Monday; only docs, audit fixes, and change log since
• Fresh clone of the tag audited against all twelve rubric lines, each with a written evidence note
• Inherited-language sweep done: no requirement, persona, or target still describes the brief instead of your build
• Secret sweep clean on the working tree and the history; anything found has been rotated
• Clean-machine test run by a human who is not you, on a machine that is not yours, recorded in docs/test-results.md
• Every open Must disclosed in the README, the release notes, and the defect log
• Every post-baseline scope change has a CR-nnn file, indexed by the change table in CHANGELOG.md
• CHANGELOG.md entry written and dated for the submitted version
• LICENSE present, and its identifier matches what the README claims
• Hours log complete for all eight weeks, including the bad ones
• docs/ai-usage.md specific, current, and headed by the signed integrity statement
• docs/retrospective.md written from the logs, with at least one rule that has a number in it
• Annotated tag pushed; commit SHA copied; release published with real release notes
• Repository link opened successfully from a logged-out private browser window
• Submission block pasted and submitted — before the presentation

A theological footnote. “I have fought the good fight, I have finished the race, I have kept the faith” (2 Timothy 4:7, ESV). Notice what Paul does not claim. Not that he won every argument, not that everything he started came to fruition, not that nothing was left undone. Three completed verbs about faithfulness to the work he was given — and that is the only kind of finished that has ever been available to anyone. Your repository has flaws; you have them written down with severity ratings. Eight weeks ago you counted the cost of the tower before building it, and you counted it honestly enough to build something you could actually finish rather than something that would have looked better on a slide. This week you lay it down and let others see it. That takes a particular courage, because as long as work is unfinished it cannot be found wanting. Submitting is an act of trust: I did what I could with the hours I was given, and I am telling the truth about it. Do the work honestly, describe it truthfully, hand it over cleanly — and then rest. That order is not accidental. It is the pattern set on the seventh day, and it is the only definition of finished that will still hold when the framework you used is long gone.