Finish exercise 3

Author: kentcdodds

exercises/01.building-an-mvp/04.problem.implementation/README.mdx

@@ -1,6 +1,39 @@
 # Implementation
 
-👨‍💼 It's time to implement the MVP (if you have time)!
+👨‍💼 You now have enough product and technical clarity to build a focused first
+version of the scheduler.
 
-Set the playground to the starter project. Feed your planning documentation to
-your agent, and let 'er rip!
+🧝‍♀️ Set the playground to `extra/01.starter`. Treat your planning artifacts as
+the source of truth:
+
+- <InlineFile file="discovery-brief.md" />
+- <InlineFile file="discovery-meeting-transcript.md" />
+- <InlineFile file="implementation-brief.md" />
+- <InlineFile file="implementation-meeting-transcript.md" />
+
+🐨 Ask your agent to implement the MVP from those constraints, not to expand the
+product beyond the brief.
+
+Focus on these questions while building:
+
+1. Which routes and flows are truly required for the MVP to work?
+2. Which deferred requirements should stay out, even if the starter makes them
+   easy to add?
+3. Which implementation choices keep the product simple now without making the
+   next likely changes painful later?
+
+Requirements:
+
+- Start from `extra/01.starter`. Do not rebuild the app from scratch.
+- Keep the no-account participation and host-link model intact for MVP.
+- Build only the minimum route and UI surface needed for:
+  - schedule creation
+  - attendee response
+  - host management
+- Keep product behavior and copy realistic and in-world.
+- Notice where implementation pressure forces tradeoffs or brief deviations so
+  you can evaluate them in the next step.
+
+💰 This step is not about shipping the biggest version you can imagine. It is
+about seeing whether your earlier clarity produces a coherent MVP once code is
+involved.

exercises/01.building-an-mvp/04.solution.implementation/README.mdx

@@ -1,4 +1,24 @@
 # Implementation
 
-👨‍💼 How'd your agent do? Evaluate the implementation against the planning
-documentation.
+👨‍💼 Now evaluate how the implementation held up once it encountered real code
+constraints.
+
+🦉 Good implementation is not "the agent built a lot." It is whether the shipped
+MVP still reflects the scope, assumptions, and tradeoffs you defined before the
+build started.
+
+Use these references:
+
+- <InlineFile file="discovery-brief.md" />
+- <InlineFile file="discovery-meeting-transcript.md" />
+- <InlineFile file="implementation-brief.md" />
+- <InlineFile file="implementation-meeting-transcript.md" />
+
+Review the implementation against these questions:
+
+1. Did the shipped routes and flows match the intended MVP?
+2. Which planning decisions survived implementation unchanged?
+3. Where did the implementation diverge from the brief, and were those changes
+   justified?
+4. Did any deferred or out-of-scope behavior sneak back into the product?
+5. What would you tighten before calling this MVP ready to learn from?

exercises/03.protect-the-user-experience/02.problem.frame-the-change/change-brief.md

@@ -1,7 +1,7 @@
 # Implementation Brief
 
-This brief should turn the UX invariants into a concrete implementation plan for
-a narrow host-login rollout.
+This brief should frame the already-justified login change and turn the UX
+invariants into a concrete implementation plan for a narrow host-login rollout.
 
 ## Goal and boundaries