Appendix D — The Grading Contract

“A false balance is an abomination to the LORD, but a just weight is his delight.” — Proverbs 11:1 (ESV)

This is the contract. Every line of it is published in Week 1, and none of it changes in Week 8.

Most capstone courses keep the grading vague and then surprise the student in the last fortnight. This one does the opposite. The rubric that will be applied to your repository on the last Thursday of the term is printed below, line by line, with the points, the evidence each line wants, and the week the evidence gets made. There are no hidden criteria. There is no curve for effort, and there is no allowance for the fact that you had eight weeks instead of sixteen — the scope is what shrank, not the standard. There is a stack of artifacts, and either they exist and hold up or they do not.

Read this appendix three times. Week 1, so you know what you are building toward before you commit to a brief. Week 4, at the halfway audit, when you find out whether you are on pace while a correction is still cheap. Monday of Week 8, when you self-score from a fresh clone before a grader does. Between those, keep it open next to the pace table in D.8.

Coach’s Note — A published rubric is a gift and a trap. The gift: you can never lose points for something you were not told. The trap: you can never claim you did not know. From here on, every point you fail to earn is a point you chose to leave on the table. That is the deal professionals work under too — the acceptance criteria are in the contract, and nobody reads them aloud to you on the last day.

D.1 — The contract: 50 / 25 / 15 / 10

Four components. They sum to 100 percent. Nothing else is weighted.

Your course grade is the weighted average of the four percentages:

course grade  =  0.50 × (final %)  +  0.25 × (milestone average %)
              +  0.15 × (quiz average %)  +  0.10 × (presentation %)

Four worked examples, so the arithmetic is never a mystery:

Look hard at rows two and three. The student whose software is better finishes thirty-two points lower, and that is not a quirk — it is the rubric working exactly as designed. Only 18 of the final’s 100 points are the software running; the other 82 are the evidence that it is specified, verified, documented, and transferable to somebody who is not you.

Then look at row four, because it is the failure mode this edition exists to prevent. Nothing is wrong with that student’s ability. What is wrong is the arithmetic they refused to do in Week 1. 160 hours buys a project about two-thirds the size of a sixteen-week capstone — roughly three or four Must features, not five or more. A 160-hour project scoped on purpose and delivered whole outscores a 240-hour project attempted in 160 and abandoned half-built, every term, without exception. One of those is engineering. The other is wishing.

D.2 — Why the six milestones carry a quarter of the grade

The six milestones are graded twice. There is a gradebook line called “Milestone 5.” Weeks 1, 2, 3, 5, 6, and 7 each ship a milestone — six in all, because milestone numbers always equal chapter numbers and there is no Milestone 4; Week 4 is the design review and the midterm checkpoint. Together the six carry 25 percent of the course grade, so each one is worth about 4.2 points on its own — and then everything it produced is graded a second time inside the 50 percent final.

If you just felt that was unfair, read it again with the arithmetic attached. It is not double jeopardy; it is what makes an eight-week solo project survivable.

The milestones are the final deliverable, produced one week at a time. The Week-8 rubric awards points for exactly the artifacts the milestones produce — the requirements specification is Milestone 2, the decision records and the walking skeleton are Milestone 3, the test suite and defect log are Milestone 6, the README and runbook and handoff guide are Milestone 7. Every one of the twelve rubric lines in D.3 is the output of a week you have already been told to do the work in.

So skipping a milestone costs you twice. It costs you about 4.2 points immediately, and then the identical rubric points again, deferred into a week that has no hours left in it — a week that already contains a rubric self-audit, a clean-machine test with a real human, a secret sweep, a release, a retrospective, and a thirty-minute talk. It also costs you every downstream week that needed that milestone as an input, which is all of them.

Here is the whole map, so nobody can claim it was unclear:

How milestones are scored. Each ships its own 100-point rubric and your instructor returns a score; so does the Week-4 lab. Those six scores are averaged, and the average is 25 percent of your course grade — it is a real weighted grade and a pace signal. Milestone scores are capped at 100: the Medium and Hard tiers make the artifact stronger, they do not inflate the bucket. If your instructor’s syllabus weights milestones differently, their syllabus governs and they will say so; this appendix is the book’s contract, not an override of your institution.

What about the milestones’ Medium and Hard tiers? They raise that milestone’s own hundred-point score, up to its cap of 100, and — far more importantly — they build the artifact a grader reads in Week 8. A Hard-tier memo written in Week 3 is not extra credit floating in a gradebook; it is the decision-record evidence that earns a rubric line eight weeks later. The extra credit that moves your recorded grade is on the final itself: see D.6.

Coach’s Note — Students who fail this course almost never fail it in Week 8. They fail it in Weeks 2 and 3, quietly, by treating a four-point milestone as an optional one — and then they spend the back half building software with no specification to build against, no tests to prove it, and nothing written down. The milestone schedule is not a set of assignments stacked beside the final. It is the final, disassembled into six pieces small enough to carry.

D.3 — The final: 50 percent

The full specification of what to submit ships with Chapter 8 as Milestone 8. This section is the same rubric on one page, with the evidence each line wants.

The twelve graded artifacts

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

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

Where the points actually are

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

And note what the compression did not do: 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 instead of five or six, four decision records instead of five, eight weeks of hours instead of sixteen. Do not apologize for that anywhere in the submission. Nothing professional was cut, and a grader is not looking for volume. They are looking for whether the twelve lines hold.

D.4 — What evidence earns each line

A grader does not score intentions. Each line below says what full marks looks like and the cheapest way students lose it.

Working software — 18. Full marks: a fresh clone of the submitted tag runs, and every Must-priority requirement either demonstrably works or appears in the defect log as a rated, disclosed open item. Lost by: a repository that only runs on the author’s laptop; a Must silently missing with no defect entry — the omission costs less than the concealment.

Requirements specification — 12. Full marks: every requirement has a unique ID, a MoSCoW priority, and acceptance criteria a stranger could check without asking you a question; traceability runs forward to tests and backward from tests to IDs; and every requirement describes your build. Lost by: “the system shall be user-friendly,” and — the signature loss of this edition — an inherited sentence that still describes the Fast-Start brief’s hypothetical user, actor, or feature. Week 2 exists to catch that. Week 4 sweeps for it again. A grader who finds one starts checking all of them.

Test plan, suite, and recorded results — 12. Full marks: a plan naming levels, environment, and numeric exit criteria; automated tests that actually run from script/test; a recorded execution at the submitted tag; every test traceable to a requirement ID. Lost by: tests that pass because they assert nothing, and a results file dated three weeks before the tag.

Technical specification — 10. Full marks: context and component views, module responsibilities, interface contracts, the data model, and the critical-path flows — as built. Where the build diverged from the Week-3 design, a decision record says when and why. Lost by: submitting the Week-3 document unchanged. A grader compares it to the code; drift you did not document reads as drift you did not notice.

README — 10. Full marks: what it is, who it is for, prerequisites with versions, install, run, test, configure, a document index, license, and status — proven by the recorded clean-machine test in D.5. Lost by: a README no human being other than the author has ever executed.

Runbook and handoff guide — 8. Full marks: how to operate it, what normal looks like, what to do when it breaks, how to back up and roll back — plus a handoff document that tells a successor what to do on day one and week one. Lost by: writing them for yourself. The reader is a competent stranger with no context and no way to ask.

Hours log — 6. Full marks: all eight weeks, session-level, with the estimate-versus-actual analysis that Week 3’s plan was built to be checked against and Week 4’s audit already used once. Lost by: backfilling. A log of round numbers on tidy dates is visible from across the room, and it is worth less than an ugly honest one.

Architecture decision records — 5. Full marks: at least four, each with context, the options considered, the decision, and the consequences you accepted. Three come from Milestone 3; the fourth is the decision you made while building and had not yet recorded. Lost by: records that list only the option you picked. A decision with no rejected alternative is not a decision; it is a default — and “the brief suggested this stack” is a default until you write down what you weighed.

Defect log — 5. Full marks: real defects found by real testing, with severity, priority, status, and resolution, current as of the tag, including the ones still open. Lost by: an empty log. Nobody believes it, and it costs you the line plus the grader’s trust in every other line.

Change control, change log, tag, license — 5. Full marks: every scope change since the Week-4 baseline as its own CR-nnn file with an impact analysis and a disposition, indexed by the change table at the top of CHANGELOG.md; a dated change-log entry for the submitted version; an annotated tag pushed to the remote; and a real license whose SPDX identifier matches what the README claims. Lost by: cuts that were simply deleted from the requirements document instead of deferred through a change request, a lightweight or moved tag, and a README that says one license next to a file that says another.

AI usage log and integrity statement — 5. Full marks: specific entries kept all term, headed by the signed statement in D.12. Graded on specificity, not abstinence. Lost by: vagueness. See D.11.

Retrospective — 4. Full marks: numbers pulled from your own logs, one decision you would remake, and how you would spend the same 160 hours differently. Lost by: feelings with no figures.

D.5 — The clean-machine acceptance test

Required, recorded, and the hardest single standard in the course. It is part of the README line, and it is the only line no amount of writing can fake.

You run one in Week 7 and record it in docs/clean-machine-test.md; that one is probably you, in a container, on your own machine. The Week-8 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.

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.

Recruit your Week-8 tester on Monday. The failure mode is never that nobody will help; it is discovering nine README defects on Thursday night with a talk on Friday morning.

D.6 — Extra credit on the final

The final carries two optional tiers, on its own 100-point scale:

• Medium tier — up to +25. Evidence past the bar: a live deployment with its cost stated and dated, green CI at the submitted tag, measured non-functional numbers with the method used, a second independent clean-machine test on a different operating system, a successor backlog of well-formed issues, a dependency and license inventory, or a recorded security pass. Two done well beat five done thinly.
• Hard tier — up to +25 more. The Successor’s Brief: a 3–4 page memo to the engineer who inherits your project — the decision you would reverse with a migration cost in hours, the parts of your own system you do not trust, what eight weeks visibly cost this codebase and what a further eighty hours would buy in what order, and your AI accountability statement. 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.

The presentation has no extra-credit tier. It is a performance, not a build; the only way to raise the score is to rehearse.

Whether your institution’s gradebook records a component above 100 is a local policy question. Ask in Week 6, not Week 8.

D.7 — The presentation: 10 percent

Delivered live in your Week-8 slot and built the same week, in parallel with the audit, out of artifacts you already own. Thirty minutes total including questions, unless your institution schedules Q&A separately — in which case plan thirty minutes of content and be ready for questions on top. The complete brief — format, delivery logistics, the recorded-fallback requirement — is The Capstone Presentation assessment that ships with Chapter 8. The scoring is here.

The rubric (out of 100)

The clock

The recommended allocation, which you build into docs/presentation/run-sheet.md:

You may reallocate. You may not exceed thirty minutes, drop the demo, drop the evidence, or drop the “what did not get done” section, and the demo is capped at eight minutes however you rebalance — a project with three or four Musts cannot honestly fill more, and the attempt turns a demo into a tour. Scope gets three full minutes here, more than the long edition gives it, because the adopt-adapt-cut decision is your project’s distinctive engineering story.

You get a visible signal at 25 minutes and at 29. At 30:00 you are stopped, wherever you are. If your evidence and honesty slides are still ahead of you, those points go together — which is exactly why the run sheet exists.

Required regardless: a recorded demo, trimmed to the demo’s time budget, that plays with the network disabled, stored on the presenting machine and in the repository. Using it costs you nothing. Committees routinely score a clean fifteen-second recovery above a demo that never broke, because they have now watched you handle a failure. What costs you is debugging on stage: one retry maximum, then the recording, then move.

The podium is closed to AI. Preparation is open; no assistant may be consulted during the talk or the Q&A, and no device may be used to compose an answer. Expect to be asked what an assistant contributed to your project, and answer from your ai-usage log, honestly.

Say which Fast-Start brief you started from, on the scope slide, before anyone asks. It costs you nothing — the course is built on adoption, and the briefs in Appendix B are published where your committee can read them. Presenting a brief’s drafted requirements as your own original specification is a misrepresentation, and it is trivially caught.

D.8 — The pace table: where you should be every Friday

Eight weeks, about twenty hours a week, 160 hours total. The budget has no slack in it beyond the buffer you declare yourself in Week 3 — which is the point of declaring one.

How to read this table. The artifacts govern, not the hours. Twenty hours logged with nothing committed is not a week on pace; it is a week you should write an honest paragraph about. Every Friday, do two things that take four minutes: run your hours report, and read your row. If the artifacts in your row exist in your repository, you are on pace. If they do not, you are behind by however many rows are incomplete — say the number out loud.

Coach’s Note — The 80-hour line in Week 4 is not decorative. It is the last week where a correction is cheap. Half the budget is gone and the application does not exist yet — a skeleton walks, and that is all. That is on purpose: the first half converted the remaining hours from discovery into construction, and the most expensive hour in software is the one spent building something before you knew what it was. Count the cost before you build the tower (Luke 14:28) — and then count it again at the halfway mark, when the tower is real enough to measure.

D.9 — What falling one week behind actually costs

Here is the sentence this whole edition turns on. In a sixteen-week course, one week is 6.25% of the term. Here it is 12.5%. Falling one week behind is proportionally twice as expensive, and there is no quiet stretch in the middle to absorb it. That is not a scare tactic; it is arithmetic, and it is why Week 4 sits where it does.

A week behind is twenty hours of debt against a budget with no slack in it. There are exactly three ways to settle it, and only one of them is professional.

1. Repay it with extra hours. Two weeks at 30 instead of 20. This is the option everybody believes they will take. Almost nobody does, and here it works only in Weeks 1–4 — after Week 4 there is no room left to borrow from.
2. Cut scope through change control. Write the change request, do the impact analysis, move a Must to a Won’t with a dated reason, re-baseline, and tell your instructor in writing that week. This is the professional move and it costs you almost nothing on the rubric. A smaller Must set, honestly specified and fully delivered, scores far better than a large one half-built — see row four of the table in D.1.
3. Do nothing and pay in Week 8. The default. It is also the most expensive, because you pay it in the week that already holds a self-audit, a clean-machine test, a release, a retrospective, and a thirty-minute talk.

The Week-4 arithmetic, which is the whole recovery mechanism

At the end of Week 4 you have spent 80 of 160 hours. Run the subtraction on what is left and it does not come out to eighty. Four weeks remain, and Weeks 7 and 8 are already committed to documentation, release, audit, and the talk. When you run the halfway audit tool against your own log, the numbers land near 45 plannable hours, of which roughly 27 are feature construction.

Read that second number twice. It is smaller than every student expects, and it is the true number your Must set has to fit inside. If your remaining plan estimates above about 45 hours, or the Must set alone above about 27, you cut that week. The sixteen-week edition runs the same subtraction at its halfway point and lands near 65 and 40. Yours are 45 and 27 — right around two-thirds, which is why the two-thirds rule is stated the way it is, and why a five-Must plan that would merely be tight in the long edition is simply impossible in this one.

The downstream bill

The part of the debt you cannot repay

Some artifacts are not reconstructible in Week 8 at any price, because the evidence no longer exists:

• an elicitation conversation with a real user, held in Week 2, while the requirements were still open;
• a dated verification of a vendor’s terms as they were then;
• an honest hours log — eight weeks of sessions cannot be remembered, and a reconstructed one reads as reconstructed;
• the defects that construction finds, which only appear if construction happened on schedule;
• a spike result, which only teaches you something if it runs before the decision;
• estimate-versus-actual calibration, which requires estimates written before the work;
• a commit history showing work on twenty-five distinct days.

Manufacturing any of those in Week 8 is not catching up. It is fabrication, it is an integrity violation under D.12, and it is the easiest kind to detect, because a repository’s history is a timestamped witness that does not cooperate with revision.

The recovery protocol, when you are behind

1. Measure it honestly. Run your hours report; count the pace-table rows whose artifacts are missing. Write the number down.
2. Do the remaining-capacity arithmetic for your week, the way Week 4 does it — total hours left, minus what Weeks 7 and 8 have already spoken for, minus reading and quizzes. What is left is the only budget you have.
3. Cut scope, never documentation. More code cannot buy back the 82 points that are not code. A Must you cut on purpose, with a written rationale, costs a fraction of a Must you fail to deliver silently.
4. Write the change request and re-baseline through the machinery you stood up in Week 4, and tell your instructor the same week — not in Week 7.
5. Never backfill a log. Write the true row, including the row that says the week was lost. An honest bad week is worth points; an invented good one is worth an integrity referral.

D.10 — The repository structure a grader expects

Adapt it freely — but if a grader cannot find an artifact in under thirty seconds, the README must point at 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 + the Week-8 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            # Week 8
│   ├── presentation/               # Week 8: 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

This is identical to the sixteen-week edition’s layout — same paths, same names, deliberately, so the two books never disagree and neither does your résumé. Your other working documents live beside these: docs/traceability.csv and the dated elicitation notes from Week 2, docs/design-review.md from Week 4. They are not separate rubric lines; they feed the lines above, and a grader opens them when a line is contested.

Equivalent paths are fine. Each week names a document for the job it is doing that week. The rubric accepts any obviously equivalent path that the README indexes:

Three hard constraints on naming. script/ is singular, and its contents are one-word verbs. docs/change-requests/ is a directory — one CR-nnn file per request, indexed by the change table at the top of CHANGELOG.md, not one giant file. And nothing in your repository may be named after a course file — no chapter, no exercises, no numbered milestone, no project arc. Your repository is a professional artifact and it reads like one. Also: no live secrets, ever. .env.example carries placeholders and the real file is ignored.

D.11 — The AI-use and disclosure policy

This course permits and expects assistant use. The rule is one sentence, and it is the spine of the whole library:

The human stays in the loop where the judgment lives. AI accelerates; you decide, you verify, and you are accountable.

The practical test is not how many characters a model typed. It is this: can you explain every line and every claim in your repository, in your own words, under questions, without the tool in front of you? If not, it does not ship. The portable version, which you should be able to state in an interview: you may not delegate a judgment you cannot defend.

The three zones

Four things are never delegated, in any tier: an architecture decision record, the Successor’s Brief, the retrospective, and the clean-machine test — a model cannot be your tester, and its confident “this should work” is precisely what that test exists to disprove. Those are the artifacts whose entire value is that a human owned a judgment or ran a real trial.

This edition carries one standing AI risk the long edition does not. Your requirements are partly inherited from a Fast-Start brief. An assistant asked to “clean up” or “expand” an inherited requirement set will produce fluent, plausible text that silently re-adds scope you deliberately cut, or restores an actor who does not exist in your project. Every generated requirement edit is checked against the adaptation record in docs/scoping-decision.md before it is committed. That is not paranoia; it is the exact mechanism by which the signature failure of this edition gets into a repository.

The log format

Copy the Week-1 template into docs/ai-usage.md. It has three parts — the policy header written once, the tools you have decided to use, and the entries table that grows all term.

# AI Usage Log — <project name>

**Owner:** <name> · **Policy set:** <YYYY-MM-DD> · **Last entry:** <YYYY-MM-DD>

## Policy
Spine rule. The human stays in the loop where the judgment lives.
The line I do not cross: <one sentence, in your words>

## Tools
| Tool / product | Model or version, as the tool reported it | What I use it for | What I never use it for |

## Entries
| Date | Tool / model | What I asked | What I kept | What I changed | How I verified |

Milestone 1 expects all six entry columns filled. On the final, the columns are the requirement; the exact layout is not — a condensed variant (week, tool, used for, what you changed, how you verified) earns the same points if it carries the same information. What it must always carry is what you rejected, because that is the clearest possible evidence that a human was in the loop.

A bad disclosure:

I used an AI assistant to help with some of the coding and to fix bugs.

A real disclosure:

Notice what the good version does: it names the times the tool was wrong and what you did instead. Do not guess at a model version you cannot see — write what the tool displayed, or write “version not shown.”

This line is graded on specificity, not on abstinence. Nobody is penalized for using assistance well. People are penalized for vagueness — and for undisclosed use, which is not a rubric deduction at all.

Coach’s Note — Your first employer will ask you some version of one question: what is your rule for what you will sign your name to? The ai-usage log is eight weeks of practice answering it with evidence instead of adjectives. Write the row the day it happens — ninety seconds then, or an hour of reconstruction and a weaker answer in Week 8.

D.12 — Academic integrity

You will sign this. It goes at the top of docs/ai-usage.md and 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>

Adopting a Fast-Start brief is not something to disclose defensively. It is the course design, and every brief in Appendix B 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 account for is the failure this edition exists to prevent, and it is the one thing your committee is guaranteed to probe, because they have read the same catalog you did.

What is not acceptable, in any tier:

• submitting code you cannot explain;
• a fabricated test result, measurement, hours-log entry, or user interview;
• an undisclosed third-party component;
• presenting someone else’s project as your own;
• a number in your presentation that no artifact in your repository supports.

These are integrity violations, not rubric deductions. They are handled under your institution’s academic-integrity policy, which governs over anything in this book. If you are ever unsure whether something crosses the line, the cost of asking your instructor is one email, and the cost of not asking is your degree.

“One who is faithful in a very little is also faithful in much, and one who is dishonest in a very little is also dishonest in much” (Luke 16:10, ESV). Everything in this course that looks like paperwork — the honest log, the disclosed defect, the dated verification, the gap you named before anyone found it — is the same discipline in different clothes, and eight weeks does not make it optional. It makes it faster. The standard runs both directions, too: “Let what you say be simply ‘Yes’ or ‘No’” (Matthew 5:37, ESV) rules out inflating your work and the false modesty that hides it. “It’s only eight weeks, it’s nothing really” is no more honest than “it handles anything you throw at it.” Say what is so.

D.13 — The complete final submission checklist

Do this in order, the day before your presentation. The full procedure ships with Chapter 8; this is the checklist.

1. Freeze. Stop writing features on Monday. 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 the twelve rubric lines against that clone — including the accelerated-edition sweep for inherited language — and fix gaps in points-per-hour order. A missing LICENSE is 5 points and four minutes.

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.

5. Publish a release from the tag with real 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 — before you present, never after.

Freeze and audit:

• Feature freeze declared Monday; only docs, audit fixes, and the 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

Prove it:

• Clean-machine test run by a human who is not you, on a machine that is not yours, recorded in docs/test-results.md
• Test suite executed at the submitted tag and the results recorded with the date
• Every open Must disclosed in the README, the release notes, and the defect log

Artifacts present:

• Working software, requirements specification, technical specification (as built), decision records (at least four)
• Test plan, suite, and results traced to requirement IDs; defect log current at the tag
• README, runbook, handoff guide
• Hours log complete for all eight weeks, including the bad ones, with estimate-versus-actual
• Every post-baseline scope change has a CR-nnn file, indexed by the change table in CHANGELOG.md
• CHANGELOG.md entry written and dated; LICENSE present and matching the README
• 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

Gates:

• Secret sweep clean on the working tree and the history; anything found rotated first
• Repository link opened successfully from a logged-out private browser window

Release and submit:

• Annotated tag pushed (never move an existing tag); commit SHA copied
• Release published with real release notes
• Submission block pasted and submitted — before the presentation

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 from D.12, signed>

D.14 — The eight weekly quizzes: 15 percent

One quiz a week, Weeks 1 through 8, auto-graded, drawn from a pool so no two attempts are identical. Eight to twelve items, covering the phase you are supposed to be in that week. Week 4’s is the midterm checkpoint — longer, cumulative over Weeks 1–4, and counted as one of the eight, not as a separate component. At roughly 1.9 percent each, no single quiz can hurt you, and a pattern absolutely will.

The settings the course ships with (your syllabus governs if your instructor changes them):

Unless your syllabus says otherwise, the eight count equally and the 15 percent is their average.

The quizzes exist for two reasons, and the second is the real one. The first is ordinary: they check that the vocabulary of the life cycle is actually in your hands — that you can say what a non-functional requirement is, what a decision record records, what a walking skeleton proves, what a baseline freezes. You will be expected to speak that language in every interview you take next spring.

The second is that they are the early-warning system that catches a slipping week before the milestone does — and in a course where one week is an eighth of the term, the warning has to come fast. A quiz you cannot pass is a week whose reading you skipped, and a week whose reading you skipped is a milestone you probably did not ship. When you find yourself guessing on the Week-3 quiz, that is not a quiz problem. That is the late start, ringing a bell in Week 3 instead of Week 8 — which is the entire mercy of the design.

D.15 — What a grader is actually asking

Strip away the tables and every line of every rubric in this appendix is one question, asked twelve different ways:

Could a competent stranger take this over on a Tuesday afternoon?

They clone it and are running in eleven minutes. Every claim in the README is backed by a requirement ID with criteria they could verify themselves — and every requirement is unmistakably about this project, not about a brief. The architecture document matches the code in front of them, and where it does not, a decision record says when and why. They do not have to hunt for what is broken, because you 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. The hours log has a bad week in it, honestly recorded. The ai-usage log names things you rejected. The retrospective has numbers.

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

That reaction is the grade, and it is also the job. Every professional reputation you will ever have is built out of exactly that reaction, repeated — which is why the contract is shaped this way. Not to measure how clever you are. To measure whether your work can be trusted by somebody who cannot ask you a question.

Coach’s Note — Print this appendix. Put it where you plan your week. Nothing in it will change between now and delivery day, and every point in it is earnable twenty hours at a time. There is no curve, there is no mystery, and there are no surprises in Week 8 — only deadlines, and you have all of them in front of you today.

Related: Appendix A — the Fast-Start Workbench, including the no-admin browser path · Appendix B — the twelve pre-scoped briefs · Appendix C — every artifact on this rubric as a blank template, a worked example, and a deliberately bad version · Appendix E — the glossary. Start the work in Chapter 1; the halfway audit is in Chapter 4; the final and the presentation are specified in Chapter 8.