Repo Checkpoint 2Fall, Sunday of week 10·4%·Rubric
Repo Checkpoint 3Winter, Sunday of week 5·4%·Rubric
Repo Checkpoint 4Winter, Sunday of week 10·4%·Rubric
Up to 48 hours late loses one rubric band on each criterion. After that it scores zero, unless you contacted the instructors before the deadline with a documented reason.
Four times a year, in weeks 5 and 10 of fall and winter, the instruction team reviews your repository at a commit you name, and may leave feedback in it as issues or pull request comments. You submit one PDF of the repository’s living docs, the six documents listed below, at that commit, with a cover that names the commit and links your milestone’s evidence. Graders check continuous integration (CI), the history, and the milestone in the repository itself, so the documents must match the code.
You produce the repository. The four subsections below are the criteria the rubric applies at every checkpoint, under the same names; then comes the checkpoint’s milestone, which the Milestone met criterion scores. The repository holds what an AI tool or a successor needs to work on the product, and nothing about the team: team documents (the charter, the retrospectives, the Definition of Shipped, and any postmortem on a non-technical incident) live where your team keeps its own files, and the handoff document where your partner keeps project documents.
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 pull request history dressed up after the fact.
Five of the six living docs, each describing the code at the named commit:
docs/requirements.md: the problem statement; functional and non-functional requirements, with an acceptance criterion wherever the behavior isn’t obvious (a finished functional requirement can name its test in CI instead); the limits you did not choose, under Constraints; success metrics; non-goals; open questions. Guide: Requirements.
docs/design.md: the system as it exists, with its context, key diagrams, interfaces and contracts, the data model, the deployment shape, decisions deferred on purpose, and open technical questions. Guide: Technical design.
README.md: a quickstart from a clean clone to a running system. Reference: makeareadme.com.
AI context file: AGENTS.md, CLAUDE.md, or your tool’s equivalent, pointing at these documents rather than copying them. If you keep several, the others point at AGENTS.md, since two instruction files that disagree are worse than one. Reference: agents.md.
Graders compare one recent feature with docs/design.md and one document in the PDF with the same file at the commit, and read the Constraints section of docs/requirements.md.
The sixth living doc, docs/risks.md, is the one risk register, covering business, technical, and team risks, ranked, each with an owner, plus every external prerequisite (an approval, an account, a review, recruitment) with who asked for it and when, updated between checkpoints. Write each risk as a fact about the project, without blame; a problem between teammates goes to your Teaching Assistant (TA). Guide: Project Risks.
Graders check first that docs/risks.md is the only register and that every risk in it has a rank and an owner.
CI runs your tests on every pull request and passed on the named commit, and at least one test fails when the behavior it covers breaks. Break something on a branch once and watch CI go red, so you know it can.
CI is whatever proves, on every pull request, that the work still builds and still does what it should. For example:
A workflow that builds the app and runs its tests.
For a game, a headless engine build plus the tests.
For firmware, a build for the target board and unit tests on the host or an emulator.
For a pipeline, a run on a small sample dataset that checks a known result, not merely that it exits zero.
For a notebook, a run top to bottom that fails when a cell errors or a key result changes.
If you contribute to an open-source project, that project’s CI on your pull requests; before your first one, its build-and-test command, documented in your fork and passing on the named commit.
If none of these fits your work, agree with your partner or mentor what proves, on every pull request, that it still works, and say so in README.md.
At Repo Checkpoint 1, a project may have little worth testing yet: the partner asked for research and planning first, or the first build is a prototype the team expects to throw away. That’s fine when README.md says why and what will trigger the first tests; until then, CI builds the project and checks that the quickstart works. From Repo Checkpoint 2 on, CI runs tests.
The safety net is review gates on changes that are expensive to undo (schema, authentication, deployment, migrations), somewhere to exercise changes before they reach users (a staging or preview environment, a store beta track, a test device, a run on sample data), and a documented rollback path, sized to how your team works: the more you delegate to AI tools, the more the automated checks must catch before a change merges.
The README.md quickstart works from a clean clone: graders follow it first, so follow it yourself before you submit.
Contribution Traceability and Version Control Hygiene
Nothing reaches the default branch except through a reviewed pull request, and the history meets the five items of a history a maintainer could inherit. Each student’s code arrives through pull requests under their own account, other work sits where CONTRIBUTING.md says it lives, and the Contribution lines in your sprint notes match that record. Graders check whether each student’s work can be attributed; how much each did is graded in your individual contribution.
Due fall week 5. Milestone met scores each item below, and Submission complete scores the PDF itself. Agree the production target now: an account, a hosting decision, or a review can take weeks.
CI: passed on the named commit, in a form of CI that fits your work. With no product code yet, it runs on a scaffold: your stack’s starter project, with at least one test that fails when the scaffold breaks. Where README.md says why there are no tests yet and what will trigger the first ones, a build and a check that the quickstart works stand in for the test. Evidence: a link on the cover to the run.
Board: every item in the current sprint has an owner and a status. Evidence: a link on the cover to the board.
Production target: one paragraph says where the walking skeleton (the thinnest end-to-end slice of your system that works) will run, as What Deployed Means in Fall defines it for your project; who owns the account or infrastructure; and who agreed it, your partner or, without one, your mentor. Add what applies: if you contribute to an open-source project, which maintainer reviews your first pull request; if you run a pipeline on data, which sample data it may use and, if the real run happens on a single workstation, who outside the team will run it there. With no deployment planned, the paragraph says why and what ships instead, so the instruction team can agree an equivalent milestone with you. Evidence: the deployment section of docs/design.md.
Approval: if the target needs one, an entry names it, who is asking for it, and when they asked. Evidence: an entry in docs/risks.md.
Inherited-codebase audit: if you start in an existing codebase, your audit covers everything listed under The Inherited-Codebase Audit. Evidence: a document in the PDF, after the living docs.
Build Health and Safety Net asks for less at this checkpoint: staging and rollback can be a plan in docs/risks.md or README.md, saying where changes will be exercised before they reach users and how a bad change will be undone, each with the date it lands; and with no product code yet, the README.md quickstart may start only the scaffold.
If you start in an existing codebase (a predecessor team’s, your partner’s, or an open-source project you contribute to), its decisions, tests, debt, and review process are yours before you write a line. Audit it in fall weeks 1 to 5, covering:
what runs and how, and what does not;
the state of the tests and the CI;
the dependencies and their age;
the open risks and the known debt;
the predecessor team’s handoff document and the forward-looking section of their project retrospective, if there is one;
the open-source project’s contribution rules, if it is one;
what you will change first.
Put what the audit finds that the code depends on where the next person looks: constraints in docs/requirements.md; conventions and pitfalls in whichever living doc covers them, such as CONTRIBUTING.md, docs/design.md, or the AI context file; and a decision to keep or replace something in docs/design.md.
Due fall week 10. Milestone met scores each item below.
Walking skeleton deployed: the walking skeleton (the thinnest end-to-end slice of your system that works) is deployed from the named commit to the target docs/design.md recorded at Repo Checkpoint 1, or one agreed since and recorded there, as What Deployed Means in Fall defines deployed for your project. Evidence: a link on the cover to what that section names for your project.
Definition of Shipped v0: a draft of every item the Definition of Shipped asks for, whether or not your partner has agreed it yet. Evidence: a document in the PDF, after the living docs.
Due winter week 5. Milestone met scores each item below.
Integration: every story your board shows as done runs end to end through your real system, with no part of your own code replaced by a stub (a placeholder that returns canned answers). Evidence: the board, linked on the cover, where each done story says how to run it: its steps or its test.
CI: at least one test in the CI run on the named commit covers one of those stories. Evidence: a link on the cover to the run.
Real-user session scheduled: an entry gives the session’s date, the participant’s role (not their name), and who confirmed it. Evidence: an external prerequisite in docs/risks.md.
Due winter week 10. Milestone met scores each item below.
Release candidate: a release built from the named commit (a tagged version, a store build, or a release page) installs or deploys for someone outside the team, a grader included, using only README.md. Evidence: a link on the cover to the release.
Real-user session: notes from at least one session, giving the participant’s role (not their name), what they tried, what went wrong or confused them, and the issue or change each finding produced. Evidence: a document in the PDF, after the living docs.
Repo Checkpoint 1 records where your walking skeleton will run in week 10, and Repo Checkpoint 2 checks that it does. Deployed means the thinnest working slice of your system is where the real one will live, and someone outside the team can reach it. What that looks like depends on what you build. For example:
A web app or API serves requests at its production URL. Evidence: a link on the cover to the URL.
A mobile app, game, desktop app, or firmware build installs on a device outside the team from the channel docs/design.md names (a store test track, a release page, a device image). Evidence: a link on the cover to the build’s page on that channel.
A data pipeline runs end to end on sample data in the compute environment the real run will use, such as your partner’s cluster, a university high-performance computing cluster, or a cloud allocation. If that is a single workstation, someone outside the team, such as your partner or a member of their group, runs it there. Evidence: a link on the cover to the job’s log or output, or to the issue in your repository where that person reports the run.
A notebook or analysis reruns top to bottom from a clean environment on the machine of someone outside the team, from README.md alone. Evidence: a link on the cover to the issue in your repository where that person reports the run.
If you contribute to an open-source project, your first pull request is open in its repository. Evidence: a link on the cover to the pull request.
If none of these describes what you build, the production target paragraph in docs/design.md says what deployed means for it, and your partner or mentor agrees it there.
If something outside your control means none of this can happen by week 10, agree the milestone you’ll show instead with the instruction team at Repo Checkpoint 1, and say on the cover what it waits on. For example:
The data agreement isn’t signed, so the pipeline runs on synthetic data shaped like the real data; the cover links that run and names the agreement’s status and owner.
The partner’s IT review hasn’t started, so the skeleton runs on your own hosting; the cover links it and says when the review was requested.
The partner asked for a research and planning phase before any build, so the milestone is what that phase produces, agreed with the partner and the instruction team.
No deployment, by agreement: Repo Checkpoint 2 checks that agreed milestone instead. Evidence: the cover names that milestone and links its evidence.
One PDF. Its cover is the one Submitting Your Work describes, plus the repository URL, the full hash of the commit you want graded, the links your milestone names, and, for any milestone item not yet met, who owns it and the date it will be met. Then come the six living docs at that commit, rendered, in this order: docs/requirements.md, docs/design.md, docs/risks.md, README.md, CONTRIBUTING.md, and the AI context file; then any document your milestone names. Push that commit before you submit, so graders can reach it.
At Repo Checkpoint 1, only Submission complete and Milestone met carry points; the other four are marked at zero, so you see where your repository stands on them before they count.
Rubric: 100 points across 6 criteria
Criterion
Ratings
Submission complete50 points
Exceeds Expectations (50)The cover names the repository URL and the full hash of the named commit, and the PDF carries all six living docs (docs/requirements.md, docs/design.md, docs/risks.md, README.md, CONTRIBUTING.md, and the AI context file), rendered and matching that commit. Where an NDA walkthrough stands in, a document the partner keeps out of the PDF does not count against the team, and a sanitized PDF matches the commit if it differs only in what was redacted.
Meets Expectations (40)One of the six living docs is missing from the PDF, not rendered, or does not match the named commit. Where an NDA walkthrough stands in, a document the partner keeps out of the PDF does not count against the team, and a sanitized PDF matches the commit if it differs only in what was redacted.
Does Not Meet Expectations (10)The cover lacks the repository URL or the full commit hash, or two or more of the six living docs are missing from the PDF, not rendered, or do not match the named commit. Where an NDA walkthrough stands in, a document the partner keeps out of the PDF does not count against the team, and a sanitized PDF matches the commit if it differs only in what was redacted.
Milestone met50 pointsOutcomes: SO2
Exceeds Expectations (50)Every milestone item for this checkpoint is met, with its evidence: CI (the run on the named commit, linked on the cover), board (linked on the cover), production target (the deployment section of docs/design.md), approval, if the target needs one (an entry in docs/risks.md), and, for a team starting in an existing codebase, the inherited-codebase audit (a document in the PDF). Where an NDA walkthrough stands in, a document the partner keeps out of the PDF does not count against the team, and a sanitized PDF matches the commit if it differs only in what was redacted.
Meets Expectations (40)One milestone item is unmet or only demonstrable with help, and the cover names it with an owner and a date to close it (e.g., the production target is recorded but nobody has agreed it yet, the approval it needs is named in docs/risks.md but nobody has asked for it yet, or the audit leaves out an item it asks for).
Does Not Meet Expectations (10)Two or more milestone items are unmet, or one is unmet and the cover names no owner and date to close it.
Docs current and consistent with the code0 pointsOutcomes: SO2
Exceeds Expectations (0)The five documents this criterion covers (docs/requirements.md, docs/design.md, README.md, CONTRIBUTING.md, and the AI context file, such as AGENTS.md or CLAUDE.md) exist, are in the PDF, rendered and matching the named commit, and pass the spot-check: docs/design.md describes the system that exists, and docs/requirements.md gives an acceptance criterion wherever a requirement's behavior is not obvious (for a finished functional requirement, the name of its test in CI will do), and lists under Constraints the limits the team did not choose. Whether the README.md quickstart runs is scored under Build health. Where an NDA walkthrough stands in, a document the partner keeps out of the PDF does not count against the team, and a sanitized PDF matches the commit if it differs only in what was redacted.
Meets Expectations (0)One of the five is absent from the repository or has drifted from the code, one is missing from the PDF, not rendered, or does not match the named commit, or some are missing sections. Where an NDA walkthrough stands in, a document the partner keeps out of the PDF does not count against the team, and a sanitized PDF matches the commit if it differs only in what was redacted.
Does Not Meet Expectations (0)Two or more of the five are absent from the repository or have drifted from the code, or two or more are missing from the PDF, not rendered, or do not match the named commit. Where an NDA walkthrough stands in, a document the partner keeps out of the PDF does not count against the team, and a sanitized PDF matches the commit if it differs only in what was redacted.
Risk register0 points
Exceeds Expectations (0)docs/risks.md is the single risk register, with risks, each ranked and with an owner; it is in the PDF, rendered and matching the named commit, and no duplicate register exists elsewhere. Where an NDA walkthrough stands in, a document the partner keeps out of the PDF does not count against the team, and a sanitized PDF matches the commit if it differs only in what was redacted.
Meets Expectations (0)Risks are tracked but incompletely: ranking or owners missing on some risks, a second register exists, or docs/risks.md is missing from the PDF, not rendered, or does not match the named commit. Where an NDA walkthrough stands in, a document the partner keeps out of the PDF does not count against the team, and a sanitized PDF matches the commit if it differs only in what was redacted.
Does Not Meet Expectations (0)No docs/risks.md or an empty one, or a register with neither ranking nor owners. Where an NDA walkthrough stands in, a document the partner keeps out of the PDF does not count against the team, and a sanitized PDF matches the commit if it differs only in what was redacted.
Build health and safety net0 pointsOutcomes: SO6
Exceeds Expectations (0)CI runs the tests on every pull request (if you contribute to an open-source project, that project's CI on your pull requests, or the build-and-test command your fork documents until your first one); at least one test would fail if the feature it covers broke; a grader can follow the quickstart cold. The checks match how much the team delegates: review gates on the changes that are expensive to undo (schema, authentication, deployment, migrations), and docs/risks.md or README.md names where changes will be exercised before they reach users (a staging or preview environment, a store beta track, a dedicated test device, a run on sample data) and how a bad change will be undone, each with the date it lands.
Meets Expectations (0)CI and tests exist, but the quickstart runs only with a step README.md does not give, or the checks have visible gaps relative to how the team works: no gate on a hard-to-undo path, or no plan for where changes will be exercised before they reach users or how a bad change will be undone; or CI builds the project and checks the quickstart but no tests exist yet, and README.md says why and what will trigger the first tests.
Does Not Meet Expectations (0)CI is absent, tests are absent and README.md does not say why and what will trigger the first ones, tests exist but none would fail if the feature it covers broke, the quickstart does not work, or nothing gates a hard-to-undo change and there is no plan to undo one.
Contribution traceability and version control hygiene0 pointsOutcomes: SO5
Exceeds Expectations (0)Each student's work is attributable over the period: code through reviewed PRs under real accounts, other work where CONTRIBUTING.md says it lives, and the Contribution lines in the sprint notes match that record. The history is one a maintainer could inherit: nothing lands on the default branch outside a pull request; no live secrets, build artifacts, or dependency directories are in the history (if a secret leaked, it was revoked or rotated, and the commit that removed it says so); commit messages say what changed and why, with noisy branches squashed on merge; nobody force-pushes the default branch; and large binaries are out of Git or in Git LFS.
Meets Expectations (0)Most students' work is traceable, but some of it cannot be attributed, or the history misses any of those items (direct commits to the default branch, committed build artifacts or dependency directories, commit messages that do not say what changed and why, noisy branches merged unsquashed, a force-push to the default branch, large binaries outside Git LFS).
Does Not Meet Expectations (0)Contribution cannot be traced to individuals over the period, or a secret was committed and never rotated.
Docs current and consistent with the code25 pointsOutcomes: SO2
Exceeds Expectations (25)The five documents this criterion covers (docs/requirements.md, docs/design.md, README.md, CONTRIBUTING.md, and the AI context file, such as AGENTS.md or CLAUDE.md) exist, are in the PDF, rendered and matching the named commit, and pass the spot-check: docs/design.md describes the system that exists, and docs/requirements.md gives an acceptance criterion wherever a requirement's behavior is not obvious (for a finished functional requirement, the name of its test in CI will do), and lists under Constraints the limits the team did not choose. Whether the README.md quickstart runs is scored under Build health. Where an NDA walkthrough stands in, a document the partner keeps out of the PDF does not count against the team, and a sanitized PDF matches the commit if it differs only in what was redacted.
Meets Expectations (20)One of the five is absent from the repository or has drifted from the code, one is missing from the PDF, not rendered, or does not match the named commit, or some are missing sections. Where an NDA walkthrough stands in, a document the partner keeps out of the PDF does not count against the team, and a sanitized PDF matches the commit if it differs only in what was redacted.
Does Not Meet Expectations (5)Two or more of the five are absent from the repository or have drifted from the code, or two or more are missing from the PDF, not rendered, or do not match the named commit. Where an NDA walkthrough stands in, a document the partner keeps out of the PDF does not count against the team, and a sanitized PDF matches the commit if it differs only in what was redacted.
Risk register15 points
Exceeds Expectations (15)docs/risks.md is the single risk register, changed since the last checkpoint, ranked, and with owners; it is in the PDF, rendered and matching the named commit, and no duplicate register exists elsewhere. Where an NDA walkthrough stands in, a document the partner keeps out of the PDF does not count against the team, and a sanitized PDF matches the commit if it differs only in what was redacted.
Meets Expectations (12)Risks are tracked but incompletely: ranking or owners missing on some risks, the register has not changed since the last checkpoint, a second register exists, or docs/risks.md is missing from the PDF, not rendered, or does not match the named commit. Where an NDA walkthrough stands in, a document the partner keeps out of the PDF does not count against the team, and a sanitized PDF matches the commit if it differs only in what was redacted.
Does Not Meet Expectations (3)No docs/risks.md or an empty one, or a register with neither ranking nor owners. Where an NDA walkthrough stands in, a document the partner keeps out of the PDF does not count against the team, and a sanitized PDF matches the commit if it differs only in what was redacted.
Build health and safety net20 pointsOutcomes: SO6
Exceeds Expectations (20)CI passed on the named commit and runs the tests on every pull request (if you contribute to an open-source project, that project's CI on your pull requests, or the build-and-test command your fork documents until your first one); at least one test would fail if the feature it covers broke; a grader can follow the quickstart cold. The checks match how much the team delegates: review gates on the changes that are expensive to undo (schema, authentication, deployment, migrations), changes exercised somewhere other than production before they reach users (a staging or preview environment, a store beta track, a dedicated test device, a run on sample data), and a documented rollback path.
Meets Expectations (16)CI and tests exist, but the quickstart runs only with a step README.md does not give, or the checks have visible gaps relative to how the team works: no gate on a hard-to-undo path, nowhere to exercise changes before they reach users, or no documented rollback path.
Does Not Meet Expectations (4)CI is absent or red, no test would fail if the feature it covers broke, the quickstart does not work, or changes reach production with no gate and no rollback path.
Contribution traceability and version control hygiene15 pointsOutcomes: SO5
Exceeds Expectations (15)Each student's work is attributable over the period: code through reviewed PRs under real accounts, other work where CONTRIBUTING.md says it lives, and the Contribution lines in the sprint notes match that record. The history is one a maintainer could inherit: nothing lands on the default branch outside a pull request; no live secrets, build artifacts, or dependency directories are in the history (if a secret leaked, it was revoked or rotated, and the commit that removed it says so); commit messages say what changed and why, with noisy branches squashed on merge; nobody force-pushes the default branch; and large binaries are out of Git or in Git LFS.
Meets Expectations (12)Most students' work is traceable, but some of it cannot be attributed, or the history misses any of those items (direct commits to the default branch, committed build artifacts or dependency directories, commit messages that do not say what changed and why, noisy branches merged unsquashed, a force-push to the default branch, large binaries outside Git LFS).
Does Not Meet Expectations (3)Contribution cannot be traced to individuals over the period, or a secret was committed and never rotated.
Milestone met25 pointsOutcomes: SO2
Exceeds Expectations (25)Every milestone item for this checkpoint is met, with its evidence: the walking skeleton deployed from the named commit, or the equivalent milestone agreed at Repo Checkpoint 1 (linked on the cover) and the Definition of Shipped v0 (a document in the PDF). Where an NDA walkthrough stands in, a document the partner keeps out of the PDF does not count against the team, and a sanitized PDF matches the commit if it differs only in what was redacted.
Meets Expectations (20)One milestone item is unmet or only demonstrable with help, and the cover names it with an owner and a date to close it (e.g., the skeleton runs but not in the production target docs/design.md records, or the Definition of Shipped v0 draft in the PDF leaves out an item it asks for).
Does Not Meet Expectations (5)Two or more milestone items are unmet, or one is unmet and the cover names no owner and date to close it.
Docs current and consistent with the code25 pointsOutcomes: SO2
Exceeds Expectations (25)The five documents this criterion covers (docs/requirements.md, docs/design.md, README.md, CONTRIBUTING.md, and the AI context file, such as AGENTS.md or CLAUDE.md) exist, are in the PDF, rendered and matching the named commit, and pass the spot-check: docs/design.md describes the system that exists, and docs/requirements.md gives an acceptance criterion wherever a requirement's behavior is not obvious (for a finished functional requirement, the name of its test in CI will do), and lists under Constraints the limits the team did not choose. Whether the README.md quickstart runs is scored under Build health. Where an NDA walkthrough stands in, a document the partner keeps out of the PDF does not count against the team, and a sanitized PDF matches the commit if it differs only in what was redacted.
Meets Expectations (20)One of the five is absent from the repository or has drifted from the code, one is missing from the PDF, not rendered, or does not match the named commit, or some are missing sections. Where an NDA walkthrough stands in, a document the partner keeps out of the PDF does not count against the team, and a sanitized PDF matches the commit if it differs only in what was redacted.
Does Not Meet Expectations (5)Two or more of the five are absent from the repository or have drifted from the code, or two or more are missing from the PDF, not rendered, or do not match the named commit. Where an NDA walkthrough stands in, a document the partner keeps out of the PDF does not count against the team, and a sanitized PDF matches the commit if it differs only in what was redacted.
Risk register15 points
Exceeds Expectations (15)docs/risks.md is the single risk register, changed since the last checkpoint, ranked, and with owners; it is in the PDF, rendered and matching the named commit, and no duplicate register exists elsewhere. Where an NDA walkthrough stands in, a document the partner keeps out of the PDF does not count against the team, and a sanitized PDF matches the commit if it differs only in what was redacted.
Meets Expectations (12)Risks are tracked but incompletely: ranking or owners missing on some risks, the register has not changed since the last checkpoint, a second register exists, or docs/risks.md is missing from the PDF, not rendered, or does not match the named commit. Where an NDA walkthrough stands in, a document the partner keeps out of the PDF does not count against the team, and a sanitized PDF matches the commit if it differs only in what was redacted.
Does Not Meet Expectations (3)No docs/risks.md or an empty one, or a register with neither ranking nor owners. Where an NDA walkthrough stands in, a document the partner keeps out of the PDF does not count against the team, and a sanitized PDF matches the commit if it differs only in what was redacted.
Build health and safety net20 pointsOutcomes: SO6
Exceeds Expectations (20)CI passed on the named commit and runs the tests on every pull request (if you contribute to an open-source project, that project's CI on your pull requests, or the build-and-test command your fork documents until your first one); at least one test would fail if the feature it covers broke; a grader can follow the quickstart cold. The checks match how much the team delegates: review gates on the changes that are expensive to undo (schema, authentication, deployment, migrations), changes exercised somewhere other than production before they reach users (a staging or preview environment, a store beta track, a dedicated test device, a run on sample data), and a documented rollback path.
Meets Expectations (16)CI and tests exist, but the quickstart runs only with a step README.md does not give, or the checks have visible gaps relative to how the team works: no gate on a hard-to-undo path, nowhere to exercise changes before they reach users, or no documented rollback path.
Does Not Meet Expectations (4)CI is absent or red, no test would fail if the feature it covers broke, the quickstart does not work, or changes reach production with no gate and no rollback path.
Contribution traceability and version control hygiene15 pointsOutcomes: SO5
Exceeds Expectations (15)Each student's work is attributable over the period: code through reviewed PRs under real accounts, other work where CONTRIBUTING.md says it lives, and the Contribution lines in the sprint notes match that record. The history is one a maintainer could inherit: nothing lands on the default branch outside a pull request; no live secrets, build artifacts, or dependency directories are in the history (if a secret leaked, it was revoked or rotated, and the commit that removed it says so); commit messages say what changed and why, with noisy branches squashed on merge; nobody force-pushes the default branch; and large binaries are out of Git or in Git LFS.
Meets Expectations (12)Most students' work is traceable, but some of it cannot be attributed, or the history misses any of those items (direct commits to the default branch, committed build artifacts or dependency directories, commit messages that do not say what changed and why, noisy branches merged unsquashed, a force-push to the default branch, large binaries outside Git LFS).
Does Not Meet Expectations (3)Contribution cannot be traced to individuals over the period, or a secret was committed and never rotated.
Milestone met25 pointsOutcomes: SO2
Exceeds Expectations (25)Every milestone item for this checkpoint is met, with its evidence: integration at the named commit (the board, linked on the cover, where each done story says how to run it), CI (the run on the named commit, linked on the cover), and the real-user session scheduled (an entry in docs/risks.md).
Meets Expectations (20)One milestone item is unmet or only demonstrable with help, and the cover names it with an owner and a date to close it (e.g., a story the board shows as done still has part of the team's own code replaced by a stub, no test in the run covers any of those stories, or the real-user session is planned but has no date or participant yet).
Does Not Meet Expectations (5)Two or more milestone items are unmet, or one is unmet and the cover names no owner and date to close it.
Docs current and consistent with the code25 pointsOutcomes: SO2
Exceeds Expectations (25)The five documents this criterion covers (docs/requirements.md, docs/design.md, README.md, CONTRIBUTING.md, and the AI context file, such as AGENTS.md or CLAUDE.md) exist, are in the PDF, rendered and matching the named commit, and pass the spot-check: docs/design.md describes the system that exists, and docs/requirements.md gives an acceptance criterion wherever a requirement's behavior is not obvious (for a finished functional requirement, the name of its test in CI will do), and lists under Constraints the limits the team did not choose. Whether the README.md quickstart runs is scored under Build health. Where an NDA walkthrough stands in, a document the partner keeps out of the PDF does not count against the team, and a sanitized PDF matches the commit if it differs only in what was redacted.
Meets Expectations (20)One of the five is absent from the repository or has drifted from the code, one is missing from the PDF, not rendered, or does not match the named commit, or some are missing sections. Where an NDA walkthrough stands in, a document the partner keeps out of the PDF does not count against the team, and a sanitized PDF matches the commit if it differs only in what was redacted.
Does Not Meet Expectations (5)Two or more of the five are absent from the repository or have drifted from the code, or two or more are missing from the PDF, not rendered, or do not match the named commit. Where an NDA walkthrough stands in, a document the partner keeps out of the PDF does not count against the team, and a sanitized PDF matches the commit if it differs only in what was redacted.
Risk register15 points
Exceeds Expectations (15)docs/risks.md is the single risk register, changed since the last checkpoint, ranked, and with owners; it is in the PDF, rendered and matching the named commit, and no duplicate register exists elsewhere. Where an NDA walkthrough stands in, a document the partner keeps out of the PDF does not count against the team, and a sanitized PDF matches the commit if it differs only in what was redacted.
Meets Expectations (12)Risks are tracked but incompletely: ranking or owners missing on some risks, the register has not changed since the last checkpoint, a second register exists, or docs/risks.md is missing from the PDF, not rendered, or does not match the named commit. Where an NDA walkthrough stands in, a document the partner keeps out of the PDF does not count against the team, and a sanitized PDF matches the commit if it differs only in what was redacted.
Does Not Meet Expectations (3)No docs/risks.md or an empty one, or a register with neither ranking nor owners. Where an NDA walkthrough stands in, a document the partner keeps out of the PDF does not count against the team, and a sanitized PDF matches the commit if it differs only in what was redacted.
Build health and safety net20 pointsOutcomes: SO6
Exceeds Expectations (20)CI passed on the named commit and runs the tests on every pull request (if you contribute to an open-source project, that project's CI on your pull requests, or the build-and-test command your fork documents until your first one); at least one test would fail if the feature it covers broke; a grader can follow the quickstart cold. The checks match how much the team delegates: review gates on the changes that are expensive to undo (schema, authentication, deployment, migrations), changes exercised somewhere other than production before they reach users (a staging or preview environment, a store beta track, a dedicated test device, a run on sample data), and a documented rollback path.
Meets Expectations (16)CI and tests exist, but the quickstart runs only with a step README.md does not give, or the checks have visible gaps relative to how the team works: no gate on a hard-to-undo path, nowhere to exercise changes before they reach users, or no documented rollback path.
Does Not Meet Expectations (4)CI is absent or red, no test would fail if the feature it covers broke, the quickstart does not work, or changes reach production with no gate and no rollback path.
Contribution traceability and version control hygiene15 pointsOutcomes: SO5
Exceeds Expectations (15)Each student's work is attributable over the period: code through reviewed PRs under real accounts, other work where CONTRIBUTING.md says it lives, and the Contribution lines in the sprint notes match that record. The history is one a maintainer could inherit: nothing lands on the default branch outside a pull request; no live secrets, build artifacts, or dependency directories are in the history (if a secret leaked, it was revoked or rotated, and the commit that removed it says so); commit messages say what changed and why, with noisy branches squashed on merge; nobody force-pushes the default branch; and large binaries are out of Git or in Git LFS.
Meets Expectations (12)Most students' work is traceable, but some of it cannot be attributed, or the history misses any of those items (direct commits to the default branch, committed build artifacts or dependency directories, commit messages that do not say what changed and why, noisy branches merged unsquashed, a force-push to the default branch, large binaries outside Git LFS).
Does Not Meet Expectations (3)Contribution cannot be traced to individuals over the period, or a secret was committed and never rotated.
Milestone met25 pointsOutcomes: SO2
Exceeds Expectations (25)Every milestone item for this checkpoint is met, with its evidence: the release candidate built from the named commit (linked on the cover) and the real-user session (notes in the PDF). Where an NDA walkthrough stands in, a document the partner keeps out of the PDF does not count against the team, and a sanitized PDF matches the commit if it differs only in what was redacted.
Meets Expectations (20)One milestone item is unmet or only demonstrable with help, and the cover names it with an owner and a date to close it (e.g., the install needs a step README.md does not give, or the session notes leave out what the participant tried or the change a finding produced).
Does Not Meet Expectations (5)Two or more milestone items are unmet, or one is unmet and the cover names no owner and date to close it.