Session 6 of 8
Session 6: Build One: iOS Under Change Control
First of the three build sessions, and the session Shelf Life becomes real: by the end, the first stage of your app runs on your actual iPhone. The plan you baselined in the last session hasn't moved; that's the point of a baseline. This stretch belongs to the iOS roadmap, the app, local-first, exactly as sequenced. But first we lock the site down, because a waterfall build doesn't wander, and in this session you install the guardrails that make sure of it.
Part 1: Lock the site down (~15 min)
Two commands before any code:
/freeze, restrict edits to the app's folder
/guard, full safety mode: destructive-command warnings plus directory-scoped edits
Think of it as fencing the construction site. The plan is baselined; the agent now cannot wander outside the project even if a prompt accidentally invites it to. In PM language this is change control: the plan says what changes; everything else is off-limits until formally agreed otherwise. You'll feel the fence exactly once in this session, and be glad of it.
Part 2: The debug bridge (~15 min)
Building for a phone adds a puzzle: the app runs over there, on the phone, so how does the agent see what's happening inside it? Run:
/ios-sync
It installs a debug bridge into the project, a small piece of scaffolding that lets the agent observe the app while it runs on your device. Scaffolding is the right word: it's part of the construction, not the product, and in Session 8 you'll watch it come down again. The survival kit for everything iOS, what Xcode is, what the simulator is, why the app vanishes off your phone after 7 days (it will, mid-course, the cheatsheet says why and what to do), is the iOS corner cheatsheet. Keep it open right through the build.
Part 3: Build stage 1 (~60 min)
The iOS roadmap's first stage, the list screen and its data. Brief the
agent from the baselined plan (point it at the spec and
plans/roadmap-ios.md; don't re-describe from memory, the documents are
the truth now) and let it build. Notice what the roadmap already settled:
the app is local-first in this stretch, everything lives on the phone, and
the shared database arrives the next session because the sequencing decision
says so. In agile you'd have been deciding that mid-build; here the
decision was made once, reviewed four times, and in this session you just build.
While it works, this session's biggest idea. Recall from Session 2: the agent stops when things look done. Give it a check it can run, and "looks done" becomes "passes the check". On this project the check is a real one:
/ios-qa
A robot tester drives the app on your actual phone, taps, scrolls,
screenshots, and reports what it finds against what the spec says should
happen. (Its web cousin /qa fixed as it found; this one reports,
because a waterfall gate takes recorded findings.) Run it at the end of
the stage. The rhythm for every build session in this stretch:
build from the plan → /ios-qa → evidence, not "done!" → commit
One prompt-ending phrase to make reflexive, in this session and forever: "…and show me the evidence." Test output, screenshots, not assertions. Evidence beats assertion, always.
Part 4: When it breaks (~25 min)
Something in this session will break. Good, you need the technique before the solo stretch. You're a scientist; debugging is the scientific method pointed at code: observe → hypothesise → experiment → conclude. And there's a skill that runs exactly that method:
/investigate the add-item screen crashes when I save an item with no date, here's the error
Watch it work: gathering observations, forming hypotheses, testing them, reporting a root cause before fixing anything. That last part is the power move, it stops symptom-patching (agents love to slap a plaster where you pointed) and it makes you smarter with every bug. Ask "why?" until you actually understand; "explain it like I'm not a programmer" is a completely legitimate prompt.
Two recovery tools for the stretch, both already yours:
- The recovery ladder on the git survival cheatsheet, practise one rung in this session, supervised, so the first time isn't a crisis at 11pm.
- The fence, formally moved. If a fix genuinely needs to touch something outside the frozen folder, that's not a workaround moment, run /unfreeze, say why out loud (that's the paperwork), make the change, /freeze again. In PM language: an exception, managed, the difference between controlled change and scope creep is exactly that the fence moved on purpose, visibly, and moved back.
Commit stage 1, /context-save. The homework in this stretch is the build itself, the rest of the iOS roadmap, solo, one stage per session. Same rhythm every time. The next session: the other two roadmaps, the database and the web page, and the moment the platforms meet.
What you just learned without noticing
Verification loops and change control. "A check the agent can run" is test-driven development wearing work clothes; /ios-qa on a real device is an end-to-end test rig most professionals would envy; and freeze/exception/unfreeze is change management as practised on every serious programme, the discipline that lets big projects move fast because the ground doesn't shift.