Tutor notes. For the person running the sessions.
Session 5: tutor notes
Objective: they experience four honest gate reviews and makes real accept/defer/reject calls with reasons, plus a cross-platform design system, an architecture diagram, and three session-sized roadmaps, ending in a baselined plan. The deep goal: findings-triage becomes them judgement, exercised at capstone stakes, having already watched /autoplan do it automatically at slice stakes.
Timings (2h)
| Time | Segment |
|---|---|
| 0:00 | Homework review, their marked-up spec list (feed it to the eng gate) |
| 0:10 | /plan-tune |
| 0:20 | Gates 1–4, ~13 min each, keep them moving |
| 1:15 | /design-consultation + /diagram |
| 1:40 | Three roadmaps + sequencing decision |
| 1:55 | Baseline commit, /context-save, close the planning half |
PM-to-PM: this is an end-stage assessment
Run it like one, gently. Each gate: entry criteria (spec committed), evidence (the spec itself), a decision, a sign-off on the checklist. The four lenses map roughly to business justification (CEO), technical assurance (eng), user acceptance (design), and maintainability (DevEx). "Tolerances" get their moment the next session with /freeze; this session's word is baseline: use it and mean it. If they ask why so formal for a fridge app: "because it's the only project small enough to do formality right. You learn sterile technique on things that won't die."
Playing the board without steamrolling their
You've chaired a hundred of these; they haven't sat one. The discipline is restraint:
- The skill raises findings; they rule on each one, out loud, with a reason. You only intervene when they're about to accept scope creep or reject something that will genuinely bite.
- Celebrate the first defensible reject, disagreeing with a reviewer, with a reason, is graduation-level behaviour arriving early.
- Watch for rubber-stamping around gate 3 (fatigue). If every finding is getting accepted without discussion, pause, tea, then ask them to argue against the next finding before ruling. Advocatus diaboli resets the muscle.
The gates are token-hungry
Four interactive reviews in one session makes this one of the two heaviest gstack sessions of the course (Session 2's /autoplan-plus-deploy is the other). Run the gates early in the session against the 5-hour window; if allowance gets tight, gates 3 and 4 can be shortened (accept the skill's top findings only), but never skipped, or the delegation lesson collapses: "you've seen the automated board; in this session you are the board" only works if they actually sits the chairs.
Design studio notes
- /design-consultation produces previews: make them choose between real options rather than nod at the first. Choosing is the transferable skill.
- One system, two homes: push every choice through "does this work on the phone AND in the browser?" If it proposes a motion language for an expiry tracker, that's this session's best over-engineering laugh, and a triage example.
- The /diagram output is a deliverable: filed, committed, referenced at the Session 8 test gate. It's also their first sight of the capstone as three boxes and a database, let that picture do the "why waterfall" argument one more time, silently. Excalidraw file means they can edit it later, mention it, don't do it in this session.
Facilitating the roadmaps
Claude drafts; they judge. The two failure modes to catch:
- Stages that aren't session-sized. "Build the list screen" is an session; "build the app" is not. Make them challenge any stage they couldn't describe the QA check for, no named check, not a stage.
- Gantt-shaped fiction. If Claude produces dependencies, percentages, or dates, strip them: three short lists of stages, each with an evidence check, is the deliverable. Resist your own urge to produce the beautiful plan, theirs, session-sized, honest.
The sequencing decision (iOS local-first → backend/web/wiring → gate) is the old "database first, web second, wiring last" advice promoted into course content, they should be able to say why that order, in one sentence per step, before it goes on the checklist.
Sticking points
- "Why four separate reviews? /autoplan did this in one command.", the inversion is the lesson: "it did, for a slice you could rebuild in a session. This plan spends three build sessions. Delegation is priced by the cost of a wrong ruling." Different lenses catch different failures; at these stakes they need to see each lens themselves.
- The plan changes during a gate and they want to re-run earlier gates. Judgement call, PM hat on: material change → yes, quick re-check; cosmetic → note and move on. Teaching moment about proportionate governance either way.
- Design opinions (yours) leaking in. You're the board, not the designer. Their app, their palette, even the amber you'd never pick.
- End-of-block fatigue. It's session five of five. The roadmap part is deliberately light and Claude-driven; if energy is gone after the gates, the design studio can compress before the roadmaps do, the roadmaps are load-bearing for the rest of the course.