IDST
Course contents

Tutor notes. For the person running the sessions.

Session 8: tutor notes

Objective: land the plane. Gates passed with evidence on every platform, shipped, scaffolding down, handover pack real, retro done properly, the reveal delivered, and a written independence plan so momentum survives the course ending. The failure mode of every great course is what happens after it.

Before the session

Timings (2h: the fullest session; compressibility notes below)

Time Segment
0:00 Fortnight debrief, triage table below
0:10 Test gate: /ios-qa + web /qa-only + smoke test → triage → /ios-fix → re-QA → /ios-design-review
0:45 Security gate: /cso + the non-negotiables (teeth this time, public DB)
1:05 /ship, then /ios-clean (the decommissioning beat, don't rush it)
1:20 Handover pack: prune the draft → /make-pdf (+/document-release in one line)
1:35 Hardening sweeps: /health, /design-review, /codex, brisk triage
1:50 /retro + /learn + wrongs-list callback
1:55 The reveal, /pair-agent, independence plan, close

If time collapses: Parts 4–5 compress (the pack can be one document instead of a pruned set; the sweeps can become /health plus naming the rest). The gates, the retro, and the reveal do not compress; they're the course.

Triage guide: likely states of the build fortnight

What you'll see The move
Wiring done but web polish unfinished Ideal descope, made formally: record it at the gate. A recorded descope is a better lesson than a quiet one
Wiring never completed The gate runs on what exists (app + database, or web + database); the missing platform becomes the flagship's first step. Honest gates > staged completeness
Vibes-fixed bugs with no cause-sentences Re-run /investigate on the worst one before the gate; "what did we actually fix?"
The fence moved silently The one real told-you-so of the course, spend it kindly, once
Spec-was-wrong list is empty They're being polite. "If Shelf Life were yours forever, what would you change the next session?" unlocks it
It all went great Push depth: hardest bug re-explained by them, and make the gates harder (edge cases, notification timing, weird input into the public table)

PM-to-PM: closure and lessons learned

This session is the closure stage: acceptance (test gate), security assurance, handover (docs pack), decommissioning (/ios-clean), lessons-learned register (/retro + /learn). Say "lessons learned register" out loud once, it's the PRINCE2 artefact /learn is quietly implementing. The gate checklist gets its final rows in this session; the completed document, four plan gates, a sequencing decision, a test gate, a security gate, is their first end-to-end governance record. Frame the PDF pack accordingly: "what was promised, how it was verified, what was delivered."

The security gate has real stakes now

/cso over a public Supabase table is not ceremonial. Likely findings: keys handled fine (the .env pattern held) but input validation thin. Perfect, rule 2 gets its teachable moment on them database: type something weird into the web page together and watch where it lands. If row-level security comes up, it's the flagship's problem, recorded as such.

The /ios-clean beat

Genuinely the best teachable moment of the arc. Do not let it become a throwaway command. Before running it, ask them what the bridge was for; after, show the diff: scaffolding out, product intact. It pays forward into the reveal's toolbelt line: some tools are scaffolding too.

Running the retro

You've run a hundred of these; the only note is restraint: their patterns, their words, you facilitate. The "second time" framing matters. Session 3's retro was one sprint old; this one has a month of receipts. The Session-1-wrongs-list callback is the emotional peak of the course, don't paraphrase it for them; make their read it aloud and watch it land.

The cost check-in is diagnostic, not disciplinary, audit your own setup first (/context, unused-skills sweep), then theirs. Modelling self-audit beats inspecting them.

The reveal: a two-parter

Open vibe-coder-code.md, let their read the numbered rules and their professional names in silence. The second table (projects → methodologies) is where you add the careers line: they have run a sprint-based agile delivery and a gated, multi-platform waterfall delivery end to end, with artefacts, gate checklists, sprint boards, roadmaps, retro outputs, in a public GitHub repo. That's not "more than most CS graduates"; that's more than many working developers. The scaffolding lesson lands here too, told forward: some tools they'll outgrow, like the debug bridge, outgrowing it means the process moved into their head. (If they ask whether you use all fifty commands, tell the truth; it's the best possible answer.)

Independence planning: make it concrete

Vague plans evaporate. Get actual dates: next project's brief written by when? First increment live by when? Which lifecycle, and why, make them defend the choice in one sentence per project on the itch list; that question is the course's whole synthesis. If they pick the flagship (Shelf Life v2, households/auth), that's your home turf: mentor the shape (auth is a spec problem before it's a code problem, who sees what?) and let their own the build. Put a check-in coffee in the calendar for ~3 weeks out. Agree what happens when the Pro subscription lapses (they fund it, you extend it, or they scale down, decide now, not at expiry, or the lapse decides for them).

Afterwards (you)