IDST
Course contents

Session 8 of 8

Session 8: The Test Gate, the Ship & Graduation

Eight sessions ago you had never written software. In this session a product you planned across five sessions and built across three platforms faces its gates, and in waterfall, "it exists" isn't the end: a project is done when it passes its gates and hands over its deliverables. Then the hardening sweeps, the retrospective with receipts, one reveal, and a graduation. Full session; let's go.

Part 1: The formal test gate (~30 min)

The build claims to be finished, on three platforms. The test gate is where that claim faces evidence, same shape as Session 5's gates: real evidence, a recorded decision, your sign-off on the stage-gate checklist.

/ios-qa, the full pass: every screen, every spec requirement, on the real phone.

/qa-only, the web page's recorded pass. Session 1's report-only robot, and now you see why it never fixed anything: a gate takes findings written down, not quietly patched.

And the integration evidence: the cross-platform smoke test, performed and recorded, add on the phone, appears in the browser, and back.

Triage the findings (you know the drill). For confirmed iOS bugs, meet the finisher:

/ios-fix

It hunts down and fixes iOS bugs autonomously, but you re-run the QA afterwards, because the gate takes evidence, not reassurance. Then the visual half:

/ios-design-review

A designer's-eye audit on the actual hardware, spacing, hierarchy, consistency against the design system from Session 5, which the web page must also still be wearing. The gate passes only when the reports say what the spec says, on every platform.

Part 2: The security gate (~20 min)

Different lens, same discipline:

/cso

A Chief Security Officer's review of the whole project, and unlike a local-only app, yours has a public-facing database, so in this session this review has real teeth. The non-negotiables it checks for are yours for life:

  1. Secrets never go in prompts or repos. A key in a public repo is found by scanning bots in minutes, measured, not folklore. And git remembers deleted files forever; if a secret ever lands in a repo, the secret is dead: revoke it, do not just delete it.
  2. Never trust input from strangers. The moment software accepts input from the public, someone weird will type something weird, and your database now accepts input from anyone with the URL. This rule stopped being theoretical the session the backend went up; in this session it gets checked properly.
  3. You own what you ship. If your app misbehaves, "the AI wrote it" is not a defence anyone accepts. Same rule as session one; it has teeth now.

Part 3: Ship and strike the scaffolding (~15 min)

Two gates passed. Now:

/ship

Tests, review, version, changelog, commit, push, the same ritual as session one, on a real multi-platform product. (That review step exists on its own too: /review runs the pre-landing review without the ship, for when you want the verdict before committing to the ritual.) Then something waterfall does that nothing else in this course does. The debug bridge from Session 6, the scaffolding that let the agent see inside your phone, was construction equipment, and construction is over:

/ios-clean

Watch it strike the scaffolding: the bridge comes out, cleanly, leaving only product. In PM language this is decommissioning at closure, and it's weirdly satisfying, the software equivalent of the crane leaving the site because the building stands on its own.

Part 4: The handover pack (~15 min)

A waterfall project's last deliverable is its documentation, the pack that would let a stranger (including future-you) own this product without you in the room. You drafted it in homework with /document-generate; in this session, prune it with the CLAUDE.md test, would removing this page cause a future owner to make mistakes?, then bundle the record:

/make-pdf, the spec, the gate checklist, the three roadmaps, and the docs, as one polished PDF

That PDF is the project file: what was promised, how it was verified, what was delivered. And one sibling worth meeting:

/document-release, updates docs for what actually shipped. Waterfall writes docs at handover; agile writes them per release. You ran both cadences this course, same deliverable, different clock.

Part 5: The hardening sweeps (~20 min)

Before software meets strangers, professionals sweep it. Three sweeps live, triage as you go, you know how:

/health, the code-quality dashboard. You haven't read most of your capstone's code; this is the X-ray that says whether it's sound anyway.

/design-review, the designer's eye on the live web page: visual inconsistency, spacing, anything that reads as "AI made this", found and fixed.

/codex, the whole project reviewed by a different AI model entirely. Different models have different blind spots; a second reviewer catches what the first can't see. Notice the disagreements, they're the interesting part, and the verdict on each is, as always, yours.

Three more to know by name for your own projects, each is one command and one session: /benchmark (plants a speed baseline so future slowness gets caught), /devex-review (audits the repo as a workplace), /landing-report (the shipping paper trail, self-writing).

Part 6: Retro, reveal & graduation (~35 min)

/retro

Second time, the first closed your agile project on Session 3. This one has eight sessions of receipts: with LOG.md and the spec-was-wrong list open, what went well (name it or you won't repeat it), what was harder than it should have been (patterns, not incidents), what surprised you (surprises are where your model of the world was wrong, the most valuable list in the room). /learn banks it.

Your spec-was-wrong list deserves its own minute: every item on it is a thing no amount of better planning would have caught, you had to live with the product to learn it. That's not a failure of waterfall; it's the boundary of it. You've now felt both sides: agile's speed, paid for in decisions made twice; waterfall's certainty, paid for in every lesson on that list. Which lifecycle for your next project, and why, that's the actual graduation exam, and you set it yourself.

Then read back your Session-1 wrongs list, aloud. Every item on it, you now have a named technique for. That list was the course. You debugged your own learning.

The reveal. Open the vibe coder's code: the rules you've been following since session one, now with each one's real professional name next to it. Below that, a second table: your three projects, with their real names. One-shot is what the trade calls prototyping. Agile sprints run most of the world's software. Waterfall and its gates run the regulated rest. You didn't take a course on vibe coding with some engineering sprinkled in. You took a software engineering course, and ran three delivery methodologies end to end. The agent was the trick that made it fun. Welcome to the profession; it was never about typing code.

One last first, as a graduation gift:

/pair-agent

A remote agent, paired with your browser, working alongside you. You started this course learning to direct one agent; you're leaving it as someone who can direct a team of them. That's not the future of the profession; it's the present, and you're standing in it.

Then the plan, in writing:

Close: final commit. Final /context-save: addressed to future-you, opening the next project. Some ceremony is allowed.

What you just learned without noticing

Test gates, security hygiene, documentation as a deliverable, project closure, and retrospectives, the full back half of a delivery lifecycle, which almost nobody gets taught because almost nobody closes projects properly. And in this session you also noticed, which was the point all along.