Repo Checkpoints

Submission

Team

Due

Fall and winter, around weeks 5 and 10

Weight

4% each, 8% per term

There is no requirements document assignment and no technical design document assignment in this course. Those documents exist, but they live in your repository under docs/, they stay current because your team (and your AI tools) need them current, and we grade them in place. A checkpoint is a staff review of the repository as it actually is: no export, no upload, no drift between the document and the code.

What the Repository Must Contain (the living docs)

• docs/requirements.md: what the product must do and how you will know, with acceptance criteria for current priorities. Updated as scope changes; git history is the change log.
• docs/design.md: the system view someone would need to contribute safely: context, key diagrams, interfaces and contracts, deployment shape.
• docs/rfcs/ or docs/adr/: recorded decisions. Either directory is fine, and so is both; several published agent skill sets write to docs/adr/ by default, and fighting your tooling over a directory name is a waste of a term. See the ADR guide.
• docs/risks.md: one risk register for the whole project (process, product, and technical risks together), ranked, with owners. This is the only risk register; do not maintain copies elsewhere.
• README.md: an honest quickstart that a new contributor (or grader) can actually follow.
• CONTRIBUTING.md and the AI context file (AGENTS.md, CLAUDE.md, or your tool’s equivalent) from your Team Charter. AGENTS.md is the cross-tool convention and the safest default; per-tool files should point at it rather than duplicate it, because two instruction files disagreeing with each other is worse than none.

What CI Must Do

Every project category needs continuous integration, but “have a GitHub Actions workflow” is the wrong requirement: a team contributing upstream to someone else’s repository cannot satisfy it, and a research team can satisfy it while testing nothing. The minimum is stated as outcomes:

1. Every change reaches the default branch through a pull request that someone other than the author approved.
2. An automated check runs on every pull request, and it can actually fail. A check that passes unconditionally is not a check. Break something on a branch once and watch it go red, so you know.
3. The check runs your tests, and at least one test fails if the behavior it covers breaks.
4. A stranger can go from a clean clone to a running system using only the README.

What that looks like depends on your category:

Category	Realization
New Product or Game, Consultancy	A workflow that installs from a lockfile, builds, lints, and runs the test suite on every pull request
FOSS	Upstream’s CI passes on your pull request, and your fork documents the build-and-test command a maintainer expects you to have run before submitting
Research	The pipeline runs end to end on a small sample dataset in CI, with at least one test asserting a known result rather than the pipeline merely exiting zero

Term Gates

Each term’s second checkpoint carries a gate that pulls the year’s risk forward:

Checkpoint	Gate
Fall, week 5	Rails stood up: repo, CI, board, living docs exist and are real, and the week 10 production target is written down and agreed with your partner
Fall, week 10	“Hello, production”: a walking skeleton (the thinnest end-to-end slice of your system that actually runs) deployed to a production-like environment (or: first upstream PR submitted for FOSS; pipeline runs end to end on sample data for research), plus a Definition of Shipped v0 draft
Winter, week 5	Integration health: the skeleton has organs; CI meaningful; real-user session scheduled
Winter, week 10	Release candidate: installable/deployable by a stranger, plus evidence of at least one real-user session

The gates exist because the spring outcome bar is won or lost on lead times that start now. See the Shipping guide for your category’s path.

Agree the production target in week 5, not week 9

“Hello, production” is the one gate your team may not be able to meet alone: it can need an account, a hosting decision, a security review, or a maintainer’s willingness to look at your pull request, and every one of those is somebody else’s calendar. So the week 5 checkpoint asks you to record what “deployed” will mean for this project, in docs/design.md under deployment: where the skeleton will run, who owns the account or infrastructure, what approval is needed, and who is asking for it. One paragraph, agreed with your partner or mentor.

Teams that discover in week 9 that their partner never intended to give them a production environment do not fail because they built badly. They fail because nobody asked in week 5. If the answer is “there will be no deployment”, that is a fine answer, and it needs to be written down then, so staff can agree an equivalent gate while there is still time to hit it.

Rubric (100 points per checkpoint)

Criterion	Points	Outcome
Living docs current and consistent with the code (spot-checked: does docs/design.md describe the system that exists?)	25	SO2
Term gate met (see table above)	25	SO2
Build health and safety net: CI green, tests exist and test something real, quickstart works, and the net matches how much the team delegates (review gates on the paths that are hard to undo, a staging or preview environment, a documented rollback path)	20	SO6
Decision and risk hygiene: RFCs/ADRs recorded, single risk register alive and ranked	15	SO1
Contribution traceability and git hygiene: work is attributable per student (PRs authored and reviewed under real accounts, contribution lines in sprint notes matching the record), and the history is one a maintainer could inherit	15	SO5

AI use: AI may draft and maintain the living docs from your code and history, and may write the CI configuration; the checkpoint grades the repository, not who typed it. What fails the checkpoint is evidence that is not real: a green badge from a workflow that runs nothing, a requirements document describing features the code does not have, or a PR history dressed up after the fact.

Each criterion has one thing graders check first, so you can check it yourself:

• Living docs: one recent feature, compared against docs/design.md. If the doc describes a system that no longer exists, this criterion is where it shows.
• Term gate: met or not met, judged against the table above and nothing else.
• Build health: the safety net is judged relative to how your team works, not against a fixed tool list. A team that delegates heavily to AI tools needs tighter automated gates than a team writing most code by hand, and neither approach is penalized: what is graded is whether the net catches what your way of working lets through. Gates belong on the changes that are expensive to undo (schema, authentication, deployment, migrations), not spread uniformly. A team with no CI that hand-merges agent output to production fails this regardless of whether anything has broken yet.
• Decision and risk hygiene: does the risk register have owners and a ranking, and is there exactly one of it?
• Contribution traceability: this grades whether the infrastructure for attribution exists, not whether every student contributed. Individual non-contribution is handled by the individual modifier and never double-counted here.

What “a history a maintainer could inherit” means is spelled out in the git and GitHub guide; the checkpoint checks the five items listed there.

If your project is under NDA

The checkpoint is a 15-minute screen-shared walkthrough in your cohort check-in instead of an asynchronous review. A designated student drives; the TA follows the same checklist against the live repo, in a fixed order (quickstart, CI, docs spot-check, risk register, PR list), and retains nothing. Where the partner permits, a sanitized evidence pack (docs snapshot, redacted PR list, CI screenshots) supports the review. Identical criteria, identical points.

Why this replaces document assignments

A submitted PDF is a snapshot that starts rotting at upload time. A repository is either healthy or it is not, and your project partner, your future maintainers, and your AI tools all consume the repository, not the PDF. Grading the real thing aligns the course with how you actually work.

Activities That Prepare This

Checkpoints happen four times across fall and winter, and each gate needs different preparation, so the recommendations are grouped by gate rather than offered as one list.

Fall week 5, rails stood up: Describe your Architecture and User Story Mapping for the living docs; Kanban Board Setup and Definition of Done once, for the gate and build health; Audit Your Safety Net for the safety-net half.

Fall week 10, “hello, production”: Deployment Plan, Plan Prototype, and Software Release and Versioning for the gate; Put a Browser Agent on Your Critical Flow for build health.

Winter week 5, integration health: Test Plan and Wire an Accessibility Audit Into CI for build health; Find Users then Engage Users for the scheduled real-user session; Risk Management Plan for risk hygiene.

Winter week 10, release candidate: Test with an Assistive Technology User and Run an Acceptance Pass for the real-user evidence; Describe your API Reference for the living docs; Fishbone Diagram for risk hygiene.

By project category. The gate lists above are the same for everyone; these are the ones your category specifically needs.

Category	Activities
FOSS	Analyze a FOSS Project before the fall week 5 gate, to learn the upstream review culture while the stakes are low; Software Release and Versioning for upstream conventions
Research	Define Your Research Questions and Map Your External Approvals in fall weeks 1 to 2; Reproduce Your Baseline before winter week 5; Make Your Artifact Reproducible and Keep an Experiment Log for winter week 10
Consultancy	Map Your External Approvals for the partner’s IT and security review, which is the single most common reason a consultancy project misses its gate; Stakeholder Mapping; Deployment Plan for the staging instance in the partner’s environment
New Product or Game	Lean Canvas and Hypothesis Testing in fall; Plan Prototype for the week 10 gate; Find Users then Engage Users for the winter real-user gate

Browse design and planning when these run out.