Milestone 16 — 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 16 — Delivery Day Week: 16 — the last one Due: Before your presentation slot, not after. Freeze Monday, audit Tuesday–Wednesday, submit Thursday. Weight: 50% of the course grade. This is the final. The fourteen weekly milestones you already shipped are a separate 25%; the weekly quizzes and the Week-8 checkpoint 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 through 15 is graded here, at the paths listed 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 semester, 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 sixteen 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 this week is freezing, auditing, proving, and handing over. If you kept pace, this is a fifteen-hour audit. If you did not, this is the week the deferred bill arrives — because the milestones were never a separate thing from this submission. They were graded on their own as you shipped them, and everything they produced is graded again right here. They were this.

Learning Targets

You will demonstrate that you can:

• Assemble a complete, professional software deliverable — code plus the twelve 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.
• Disclose AI assistance accurately and take accountability for work you did not personally type.
• Retrospect with evidence, converting sixteen 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.

If you kept your onboarding guide separate from your handoff guide in Week 13, docs/onboarding.md counts toward line 8. If you have been keeping your hours in a spreadsheet, export it to docs/hours-log.csv before you submit — that is the path on the rubric, and CSV is what the Week 1 and Week 10 report scripts read. Nothing in your repository may be named after a course file (chapter, exercises, project-16, project-arc); your repository is a professional artifact and reads like one.

A reference layout, which you are free to 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 script, seed script, or a container definition
├── docs/
│   ├── charter.md                  # M1–M2: the problem, the users, the scope decision
│   ├── requirements.md             # M3–M4: FRs, NFRs, constraints, traceability, DoD
│   ├── architecture.md             # M6: the technical specification, as built
│   ├── baseline.md                 # Week 8: what is frozen, at which commit, with which open items
│   ├── review/                     # Week 8: reviewer brief, defect log, review report, halfway audit
│   ├── test-plan.md                # M11
│   ├── test-results.md             # M11 + the Week 16 clean-machine record
│   ├── defect-log.md               # M11 onward
│   ├── hours-log.csv               # M1 onward, all sixteen weeks
│   ├── runbook.md                  # M13–M14: operate, back up, roll back
│   ├── handoff.md                  # M14: day one for your successor
│   ├── ai-usage.md                 # every week + the integrity statement
│   ├── retrospective.md            # M16
│   ├── plan.md                     # M7: work breakdown, estimates, schedule, burn-down
│   ├── risk-register.md            # M7 onward
│   ├── adr/                        # M5 onward: 0001-choose-the-stack.md, ...
│   ├── change-requests/            # M8 onward: CR-001-....md, one file per request
│   └── diagrams/
└── .github/workflows/ci.yml        # M9, 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 does not get applied until it is fixed:

1. Access. The grader can open the link. Verify it 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 the 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

This is a required, recorded part of the README line, and it is the hardest single standard in the course.

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 to run it honestly — 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.

Pass criteria:

Record it in docs/test-results.md: date, tester (not by full name 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 your project; 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. (Free 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 9 running the full suite on the tagged commit, with the run linked from the README.
• Measured non-functional evidence. Your NFR targets from Week 4 with actual measured numbers next to them and the method used to measure — 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 in the tracker — 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: someone 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, state what you knew then and what you know now, and lay out the migration path — what it would actually 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 fully 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. Twelve-month cost of ownership. What it takes to keep this alive for a year: hosting, third-party services and their quotas, key rotations, dependency updates, and the maintenance hours. Where a price or a free-tier limit is involved, state what you observed and when you checked it — do not assert a number as permanent.
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, and run the auditor widget on the chapter page. Fix gaps in points-per-hour order.

3. Sweep for secrets.

bash secret-scan.sh /tmp/selfaudit

Read every hit (code/secret-scan.sh). Rotate anything real. Only then make the repository visible.

4. Update the change log, then tag. You cut v1.0.0 in Week 14; 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 semester 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, or anyone else — is disclosed in docs/ai-usage.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>

The disclosure log itself is a table, kept all semester, 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 — which is 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 actually 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.
• 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.
• Disclose gaps first, everywhere. README, release notes, defect log, slide 12. 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 you need are already written. Appendix B has every artifact on the list as a blank template, a worked example, and a deliberately bad version annotated with what it costs. Appendix C 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. They open the architecture document and it matches the code they are looking at — 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 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; 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
• 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 requirement disclosed in the README, the release notes, and the defect log
• 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 sixteen 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 every church he planted flourished, 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. Sixteen weeks ago we started by counting the cost of a tower before building it (Luke 14:28), and this week you lay the tower 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.