Milestone 12 — Integrated Release Candidate & Change Log

“For everything there is a season, and a time for every matter under heaven… a time to seek, and a time to lose; a time to keep, and a time to cast away.” — Ecclesiastes 3:1, 6 (ESV)

Chapter: Chapter 12 — Iteration Two: Integration and the Hard Parts Week: 12 of 16 · roughly 15 hours Due: End of Week 12 Submit: A push to your repository plus the Canvas dropbox — the release tag name and the commit SHA it points at. Where it lands in the final package: CHANGELOG.md at the repository root — both its change table and its release sections; new files in docs/change-requests/; docs/security-review.md, docs/performance.md; the annotated tag itself; updates to docs/requirements.md, docs/defect-log.md, docs/architecture.md, and docs/hours-log.csv. These feed the Week-16 rubric lines for working software, verification evidence, change control and traceability, and release engineering — see Appendix C. AI policy: Open, with the spine rule. An assistant may help you debug across a seam, propose integration tests, and run a first-pass security review. It may not be the source of a claim in docs/security-review.md — every advisory identifier gets verified against https://github.com/advisories or https://osv.dev/. It may not decide a change request; the impact analysis and the disposition are yours, in your words, with your name and date on them. Log every substantive use in docs/ai-usage.md.

The Setup

It is four weeks out. Your components work individually and you have never once run the whole thing as a system on a machine that is not yours.

Meanwhile the requests have been arriving. Your advisor mentioned a shared shopping list. Someone at last week’s demo asked for a mobile version. A user reported a “bug” that is actually a feature nobody ever specified. And the package you have been leaning on for image handling just published an advisory.

This is the week a professional stops adding and starts converging. You will integrate the seams, measure the targets you wrote in Week 4 and have never checked, run a structured security pass, decide what your software does when a dependency dies, and — the part that will define the rest of your term — sit as a change control board of one and give every request a written yes, no, or not yet.

Then you freeze it and tag a release candidate: a specific, immutable claim that this is what I intend to ship unless something disqualifying is found.

You have done this work before in pieces. This week it becomes one system with a version number on it.

One framing before you start, because it changes how you spend the fifteen hours. Every artifact in this milestone is a document a stranger reads without you in the room: a grader in Week 16, an engineer inheriting the repository, an advisor deciding whether your refusal was reasonable. None of them can ask you a follow-up question. So the standard for every file below is not “I would understand this.” It is: a competent stranger, reading only this, reaches the same conclusion I did. That is a much higher bar, and it is the bar the rubric measures.

Learning Targets

You will demonstrate that you can:

• Integrate independently built components and prove the seams hold with tests, not hope.
• Measure system behavior against your own written non-functional targets, with a stated method, a real sample, and a tail statistic.
• Conduct a structured security pass across secrets, input, authentication, authorization, transport, dependencies, and logging — and disposition every finding.
• Design for third-party failure: timeouts, retries, fallbacks, kill switches, and honest user-facing states.
• Perform change control: a three-line impact analysis and a defensible disposition for every request against a baselined scope.
• Cut scope honestly and leave a written trail a stranger can follow from the Week-8 baseline to the delivered system.
• Produce a release candidate: written exit criteria, a clean-clone verification, an annotated tag, and a change log a reviewer can read.

The weekly status block — paste this into your submission comment

Every milestone submission carries these five lines. It takes two minutes, it is the same five lines every week, and it is the difference between an instructor who can help you in Week 6 and one who finds out in Week 14. Copy it into the Canvas submission comment when you submit — not into a document.

Shipped:     what actually works this week, in one line
Cut:         what I dropped or deferred, and where it went (backlog / change request / gone)
Hours:       planned N / actual N        (from docs/hours-log.csv)
Blocked on:  the one thing in my way, or "nothing"
Ship confidence: green | amber | red — if amber or red, the one thing that would move it

Say red when it is red. A red in Week 6 is a conversation and a scope cut. A red discovered in Week 15 is a grade. Nobody has ever been penalised in this course for an honest amber; the only expensive answer is the green that was not true.

Normal Tier

Required deliverables

1. A tagged release candidate. An annotated tag (for example v0.9.0-rc.1) pushed to your repository, pointing at a commit that clones clean, sets up, and passes its test suite using only the documented steps.
2. Written exit criteria, recorded before you evaluated against them, with the pass/fail result for each.
3. Integration evidence. A seam map of your architecture, and at least one integration test per Tier 1 seam (a seam that crosses a process, network, or storage boundary and sits on an acceptance path). Test results recorded.
4. docs/performance.md — every non-functional target from Week 4 measured in a production-like environment with realistic data volume: your deployed instance if you stood one up in Week 9’s medium tier, otherwise a clean, seeded run outside your editor session — started fresh, against the seed set, not against the process you have had open all afternoon. Whichever it was, name it next to the number. Record target, method, environment, sample size, p50, p95, verdict, and action taken. At least one target re-measured after a fix, with both numbers shown.
5. docs/security-review.md — all seven areas from the checklist worked, evidence in every row, every finding either fixed or accepted with a reason. Dependency findings carry a verified advisory ID and a reachability judgment.
6. A third-party failure-mode table in docs/architecture.md covering slow, down, rate-limited, and changed-response for each external dependency — with graceful degradation actually implemented and demonstrated for at least one.
7. docs/change-requests/ — one file per change request since the Week-8 baseline, named CR-0NN-<short-slug>.md in the folder you created in Week 8, each carrying the three-line impact analysis (cost, blast radius, risk in both directions), a disposition, a decider, and a date. At least one REJECT and at least one DEFER with a named destination. Every one of them also gets a row in the change table at the top of CHANGELOG.md.
8. Scope decisions written down. Anything cut is marked Deferred in docs/requirements.md with a date and a CR reference, moved to docs/backlog.md with its estimate and acceptance criteria intact, and noted in the change log. Nothing deleted.
9. CHANGELOG.md — Keep a Changelog format, covering this candidate, with entries traced to requirement and defect IDs and a Known issues section listing what ships broken, with severity and a workaround.
10. Current records. docs/defect-log.md, the traceability matrix, and docs/hours-log.csv updated through Week 12.

The bar, shown twice

Two of these deliverables are graded almost entirely on whether you wrote them like a professional or like a student who ran out of time. Here is each one, both ways.

Exit criteria (deliverable 2).

Weak — a wish list, not a gate:

The app should be working well and mostly bug free before we tag.

Strong — every line is a test somebody else could run and get the same answer you did:

RC exit criteria, written 2026-11-05, evaluated 2026-11-08.

1. All 14 Must-have requirements have a passing acceptance test. — PASS (14/14, run npm test -- acceptance)
2. Zero open defects at Critical or High. — PASS (2 Medium, 3 Low open; see docs/defect-log.md)
3. Security pass complete; every finding fixed or accepted in writing. — PASS (7 areas, 4 findings, 3 fixed, 1 accepted)
4. Every NFR measured; each miss carries a recorded decision. — PASS (NFR-02 missed then fixed; NFR-09 missed, accepted, see CR-021)
5. A clean clone sets up, runs, and passes tests using only README.md. — FAIL on 11-07 (missing migration step), PASS on 11-08

Notice what the strong version costs you: nothing but honesty. It even records a failure and the day it was fixed, which is the most credible thing in the document.

The known-issues entry (deliverable 9).

Weak — technically true, operationally useless:

Some minor issues remain.

Strong — a reader can decide whether it affects them and what to do about it:

Known issues in 0.9.0-rc.1

• DEF-036 (Medium) — the expiring-soon view is not paginated and takes roughly 4 s to render past ~800 items. Workaround: filter by storage location. Planned: 0.9.1.
• DEF-039 (Low) — barcode lookup returns the wrong unit for products sold by weight in some regions; the quantity field must be corrected by hand. Workaround: edit after adding. Planned: backlog B-11.

A grader who reads that trusts the rest of your document more, not less. That is the counterintuitive part, and it is reliably true.

Normal-tier rubric (out of 100)

Medium Tier (+ up to 25% extra credit)

Engineering that raises the floor rather than adding features. Pick what fits your project:

• Performance in CI. A test that fails the build when a named target regresses. A number nobody re-measures drifts.
• Dependency scanning in CI. Your ecosystem’s audit command wired into the pipeline, failing (or warning loudly) on a High or Critical advisory in a reachable path.
• A written threat model. One page: your trust boundaries, what an attacker wants, and the two paths you consider most exposed. STRIDE is a reasonable structure if you want one.
• A chaos rep in the test suite. An automated test that runs your system with a dependency stubbed to fail and asserts the degraded behavior — so the fallback cannot silently rot.
• A kill switch. A configuration flag that disables an integration without a redeploy, exercised in a test and documented in the runbook.
• Cost and rate telemetry. For a metered dependency: calls, tokens or units, and estimated cost per request, logged and summarized. Report what a heavy day would actually cost.
• A second measured target you did not have to. Cold start, memory under load, or import time on a large file. Method and numbers, same rigor.

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

Required: a memo no assistant can write for you. A model can generate an impact analysis. It cannot decide, and it cannot be accountable for the decision — which is the entire content of this deliverable.

Write a two-to-three-page Scope Decision Memo, addressed to your advisor, as docs/scope-decision-memo.md:

• Defend your hardest refusal. Name the single request you turned down that you most wanted to accept. Give the impact analysis, the disposition, and — this is the part that matters — how you communicated it to the person who asked. Write the actual sentence you said or sent. “I’ll try to fit it in” is not an answer, and you must say why.
• Name the yes you now regret. Every project has one: a change accepted in a hallway, before the hours were counted. State what it cost, what it displaced, and what rule you would have needed for the answer to have come out differently.
• Defend the cut. Take the requirement you dropped and argue the case against your own decision as strongly as you can — the strongest version, not a strawman. Then answer it. If you cannot state the opposing case well, you have not actually decided; you have rationalized.
• Make the honesty call. State what ships broken in this candidate, at what severity, with what workaround, and how a user will find out. Then say plainly whether your demo will show the degraded path or hide it.
• Predict Week 16. Given your measured velocity, name the one thing most likely to be unfinished at delivery, and the trigger that would tell you — early enough to matter — that it is happening.

Graded on judgment, honesty, and self-awareness. A memo that admits a mistake and reasons about it well scores higher than one that claims every decision was correct.

Submission

Push to your repository, tag it, and submit the tag name and commit SHA to Canvas. Your repository should look roughly like this by the end of this week:

your-capstone/
├── README.md
├── CHANGELOG.md                    <- new this week
├── LICENSE
├── .env.example                    <- and .env is NOT tracked
├── docs/
│   ├── requirements.md             <- deferrals marked, not deleted
│   ├── architecture.md             <- seam map + third-party failure table
│   ├── change-requests/            <- one file per CR, standing since Week 8
│   ├── performance.md              <- new this week
│   ├── security-review.md          <- new this week
│   ├── defect-log.md
│   ├── backlog.md
│   ├── hours-log.csv
│   ├── ai-usage.md
│   ├── scope-decision-memo.md      <- Hard tier only
│   └── adr/
├── src/
└── tests/
    └── integration/                <- new this week

Verify before you submit:

git tag -n                                   # the annotated tag and its message
git rev-parse v0.9.0-rc.1                    # the SHA you are submitting
git clone --branch v0.9.0-rc.1 <your repo url> /tmp/rc-check

Hints

• Do integration first, all of it, before anything else. It is the only item on the list whose cost you genuinely cannot predict. If it takes eight hours, you want to discover that on Monday, not Saturday.
• Seed realistic data before you measure anything. A performance run against seven hand-typed rows tells you nothing and costs you an hour.
• Report p95, not the average. Averages hide exactly the experience your users complain about.
• Rotate first, clean second. If you find a live credential, the fix is rotation at the provider. Scrubbing history afterward is housekeeping.
• Try the authorization hole yourself. Log in as user B and request user A’s object by ID, directly, not through the UI. This is the single most common serious defect in student capstones.
• Write the impact analysis before you feel a preference. Once you have decided emotionally, the three lines become advocacy.
• When you defer, give it a destination and a size. “Later” is not a disposition. “docs/backlog.md B-07, ~14 h, needs acceptance criteria” is.
• Run code/release-check.sh early in the week, not the night you tag. Its clean-clone check is designed to fail the first time. That failure is the useful part.
• Start CHANGELOG.md from your defect log and requirement IDs, not from git log. Commits record typing; a change log records decisions.
• Templates: code/change-request-log.md, code/changelog-template.md, code/security-pass-checklist.md. Blank forms and worked good-versus-bad examples for all of them are also in Appendix B.

What Mastery Looks Like

A masterful Milestone 12 reads like the work of somebody who has shipped before.

The tag exists and it is annotated, with a message that says what the candidate is. A stranger clones it, runs three documented commands, and the tests pass — because the author already tried that on a machine that was not theirs and fixed what broke.

docs/performance.md contains numbers with methods next to them, including one target that was missed and one that is still missed, with a decision recorded and a reason. Nobody quietly lowered a bar to clear it.

docs/security-review.md contains findings — real ones, because someone actually looked. Each has a disposition. The dependency rows carry advisory identifiers that resolve in a real database, and a column saying whether the vulnerable path is reachable from this project, because the author understands that severity without reachability is theater.

One of the files in docs/change-requests/ is a refusal. Written politely, with a number in it, addressed to somebody whose opinion the author values. It is the most professionally impressive document a student produces all term, and it takes six minutes.

And CHANGELOG.md has a Known issues section that is not empty. That section is the tell. Anyone can list what they finished. A candidate who tells you, unprompted, exactly what is still broken and how to work around it is a candidate who can be trusted with the things they say did work.

Coach’s Note — Somewhere this week you will be tempted to accept a change you cannot afford, because refusing feels like admitting a limit. Here is the reframe: your capacity is not a claim about your talent. It is arithmetic about a semester. The engineer who says “that is fourteen hours and I have thirty-eight left, so no — but here is where I put it so it is not lost” is not admitting weakness. They are demonstrating the single scarcest skill on any engineering team. Practice it now, where the stakes are a grade rather than a quarter.

When You’re Done

• Seam map built; every Tier 1 seam has a passing integration test
• The seven seam failure modes probed deliberately; findings logged as defects
• Every Week-4 performance target measured in a production-like environment with realistic volume — deployed instance, or a clean seeded run outside your editor session, named next to the number
• p50 and p95 recorded with the method; at least one fix re-measured, both numbers shown
• Security pass complete across all seven areas, evidence in every row
• Every advisory ID verified in a real advisory database; reachability judged
• Any leaked credential rotated at the provider, then cleaned up, then documented
• Third-party failure-mode table complete; degradation implemented and demonstrated for at least one dependency
• Every change request since Week 8 has its own file in docs/change-requests/, with a three-line analysis and a disposition, and a row in the CHANGELOG.md change table
• At least one REJECT and one DEFER, each with a reason and a destination
• Scope cuts marked Deferred in the requirements, moved to the backlog, noted in the change log
• Exit criteria written down first, then evaluated
• Clean-clone check passes; annotated tag pushed
• CHANGELOG.md complete, traced to IDs, with a Known issues section
• Defect log, traceability matrix, and hours log current
• docs/ai-usage.md updated with this week’s uses and verifications

A theological footnote. “For everything there is a season, and a time for every matter under heaven… a time to keep, and a time to cast away” (Ecclesiastes 3:1, 6, ESV). The preacher is not being fatalistic; he is being honest about creatures who live in time. A good thing done at the wrong moment is not a good thing, and this week you learn that in your hands rather than in the abstract. There is a season for casting the net wide — you had it in Week 3. There is a season for casting away, and it is now. Notice what Scripture refuses to let you do: it will not let refusal be a shrug. “Let what you say be simply ‘Yes’ or ‘No’; anything more than this comes from evil” (Matthew 5:37, ESV) — the offense is not the no, it is the comfortable ambiguity that spares you a hard conversation at somebody else’s expense. And Jesus, describing a builder, asks whether he “does not first sit down and count the cost, whether he has enough to complete it” (Luke 14:28, ESV); the unfinished tower in that passage is not a monument to low ambition but to uncounted cost. Your vocation this term is not to imagine an unlimited project. It is to serve real neighbors — the user, the successor, the advisor, the classmate — in the finite semester you were actually given, and to hand them something whole. Count the cost. Say the true word. Then finish.