01.04 exercise solution

exercises/01.building-an-mvp/02.solution.stakeholder-meeting/discovery-brief.md

@@ -36,6 +36,12 @@ This document now captures clarified answers and decisions before implementation
   - Home route (`/`): host selects start/end dates with standard date inputs and initial available schedule slots, then clicks "Create schedule"
   - Host dashboard route (`/s/{scheduleKey}/{hostKey}`): host can copy/share both links (public schedule link and private host dashboard link), edit schedule details/date/slot availability, and review attendee responses
   - Attendee schedule route (`/s/{scheduleKey}`): attendees enter name and select available slots; this route must be especially mobile friendly
+- What should the schedule grid interaction feel like?
+  - Spreadsheet-like and high-velocity on desktop (Excel-like selection model), while preserving touch-friendly behavior on mobile
+- What temporal granularity and coverage are required in MVP?
+  - Full-day host availability selection (not business-hours-only), with configurable slot increments of 15, 30, or 60 minutes
+- What timezone behavior is required for trust?
+  - Explicit timezone-safe rendering and conversion across host and attendee views, with unambiguous final plan output
 - Why build instead of just adopting existing tools?
   - Existing tools like when2meet.com, whenavailable.com, and Doodle validate demand, but we still need a tighter completion-first UX and agent-native workflows (AI agents using MCP to create, update, and finalize plans with users)
 
@@ -50,7 +56,8 @@ This document now captures clarified answers and decisions before implementation
   - Many polls created, but few result in a confirmed plan
 - What UX quality bar should support the success metric?
   - Availability selection should feel spreadsheet-fast: like selecting time-slot cells in Excel on desktop, with clear visual state and low interaction friction
-  - Proposed implementation direction from product/developer facilitation: on mobile, tap-to-select plus draggable corner handle expansion with edge auto-scroll
+  - Selected state must be visually obvious at a glance (high-contrast fill/border and clear active-range affordance)
+  - Brett's mobile direction: match Google Docs/Google Sheets touch behavior where selecting a cell reveals a drag handle that can expand or shrink the current selection (with edge auto-scroll when dragging near viewport boundaries)
   - Overall product aesthetics should feel friendly and colorful (primarily blues/greens) without losing a minimalistic, clean interface
   - Route transitions should be direct and explicit: create on `/`, manage on `/s/{scheduleKey}/{hostKey}`, collect attendee availability on `/s/{scheduleKey}`
 
@@ -66,6 +73,7 @@ This document now captures clarified answers and decisions before implementation
   - Use the existing web stack with lightweight sharing links and a mobile-first web experience
   - Preserve an interaction model that supports drag selection and future MCP-triggered scheduling actions without complex rewrites
   - Route model should keep host and attendee capabilities clearly separated while preserving easy sharing
+  - Preserve in-world realism in this step: avoid workshop/training/meta language in product-facing behavior and copy
 
 ### Risk clarity
 
@@ -84,7 +92,7 @@ This document now captures clarified answers and decisions before implementation
   - Frictionless response flow with clearer status tracking
   - Avoid mandatory account creation in MVP; use private host link access for management
   - Limit v1 to a narrow set of social planning flows
-  - Adopt proven interaction patterns: desktop cell selection inspired by spreadsheet tools, and mobile selection behavior similar to Google Sheets (tap cell, drag corner dot to expand, edge-drag auto-scroll)
+  - Adopt proven interaction patterns: desktop cell selection inspired by spreadsheet tools, and mobile selection behavior modeled after Google Docs/Google Sheets (select cell, drag handle to expand or shrink selection, edge-drag auto-scroll)
   - Make route purpose explicit in UI copy and provide clear copy/share controls for both schedule and host links
 
 ## Questions asked in the meeting
@@ -131,7 +139,7 @@ This document now captures clarified answers and decisions before implementation
 - How do those competitor experiences feel in real use?
   - Familiar enough to start quickly, but clunky on phones and still weak on clear finalization confidence
 - What should mobile time-slot selection feel like?
-  - Kody's proposed direction validated by user feedback: similar to Google Sheets mobile selection (tap a start cell, drag a corner handle to expand selected slots, auto-scroll near view edges)
+  - Brett's preferred direction, reinforced by user feedback: similar to Google Docs/Google Sheets mobile selection (tap a start cell, drag a corner handle to expand or shrink selected slots, auto-scroll near view edges)
 - Which route is most sensitive to mobile usability quality?
   - `/s/{scheduleKey}` attendee submission flow, because most invitees respond on phones
 
@@ -157,7 +165,7 @@ This document now captures clarified answers and decisions before implementation
 
 - Assumption:
   - Why we believe this:
-    - Familiar spreadsheet-like slot selection (desktop) and Google Sheets-like touch selection (mobile) will reduce cognitive load and improve completion rates
+    - Familiar spreadsheet-like slot selection (desktop) and Google Docs/Google Sheets-style touch selection with drag-handle expand/shrink behavior (mobile) will reduce cognitive load and improve completion rates
   - How we will validate it:
     - Track response-completion and error-correction rates across desktop and mobile cohorts, and compare against baseline interaction prototypes
 

exercises/01.building-an-mvp/02.solution.stakeholder-meeting/meeting-transcript.md

@@ -168,24 +168,38 @@ people will go back to chat.
 👤 Una: Also, most people in my groups will respond on their phones, not desktop.
 If the mobile experience is clunky, they simply will not finish availability.
 
-🐨 Kody: Mobile usage is core for this audience. I want to design that interaction
-intentionally.
+🐨 Kody: Mobile usage is core for this audience. Before we lock implementation
+details, I want to hear the product bar from your side. Brett, what should this
+feel like in real use on desktop and mobile?
 
-👤 Una: Agreed. If mobile feels awkward, people will not finish.
+💼 Brett: Desktop should feel fast and deliberate, like people are working in a
+spreadsheet instead of poking at a form. I want slot selection to feel
+Excel-like.
 
-🐨 Kody: Great call. So mobile-first UX is not optional; it is part of core
-viability.
+💼 Brett: On mobile, I do not expect literal desktop behavior, but I do expect the
+same confidence. I want it to feel like Google Docs and Google Sheets on mobile:
+tap a cell, get the drag handle, then drag to expand or shrink the current
+selection.
 
-🐨 Kody: One direction I would propose is a spreadsheet-like model: select time
-slots like Excel cells on desktop, then on mobile tap a cell and drag a corner
-handle like Google Sheets to expand the range.
+👤 Una: That maps to how people in my groups behave. If I can tap a start slot and
+use a handle to expand or shrink naturally, I will finish. If selection feels
+fiddly, I will stop.
 
-🐨 Kody: If the drag reaches near the edge, we should auto-scroll so people can
-continue selecting without lifting their finger. Does that match what would feel
-natural?
+🐨 Kody: That helps. On temporal scope, where do you want the MVP boundary: only
+business hours, or full-day support?
 
-👤 Una: Yes, that would feel natural. The key is that it stays obvious and easy to
-control.
+💼 Brett: Full-day support. Social plans are not 9-to-5. Also, hosts need control
+over precision: 15-minute, 30-minute, or 60-minute increments depending on the
+event.
+
+🐨 Kody: Great. What should we treat as non-negotiable for timezone behavior?
+
+💼 Brett: Timezone clarity is a trust issue, not a polish issue. I want canonical
+UTC storage under the hood, host timezone metadata persisted with the schedule,
+and explicit timezone context in host and attendee views.
+
+👤 Una: Yes. If timezone display is ambiguous, people will blame the product even
+if selection was easy.
 
 🐨 Kody: Is a native mobile app on the table for this MVP?
 
@@ -200,35 +214,33 @@ required account is friction that will kill response rates.
 
 💼 Brett: Agreed. We can add accounts later, but for MVP we need low friction.
 
-🐨 Kody: Then we can have anyone create a schedule and issue a private host link
-to manage event details and view results.
-
-👤 Una: That works. As long as the host link is clear and easy to find again.
-
-🐨 Kody: Let’s make routes explicit so implementation and UX stay aligned. On the
-home page (`/`), the host should pick start/end dates using standard date
-inputs, select the time slots they want in the schedule, then tap a "Create
-schedule" button. Does that match the expected first step?
+🐨 Kody: For ownership and access, what is your preferred MVP behavior?
 
-💼 Brett: Yes, that is exactly the creation flow we need.
+💼 Brett: Keep it no-account for participation, and issue a private host link on
+create. That keeps response friction low while still giving the host control.
 
-🐨 Kody: After create, we should route to the host dashboard at
-`/s/{scheduleKey}/{hostKey}`.
+👤 Una: That works. As long as the host link is clear and easy to find again.
 
-💼 Brett: Correct. That page must make it easy to copy/share both links: the
-public attendee schedule link and the private host dashboard link.
+🐨 Kody: I want to confirm route responsibilities so implementation stays clean.
+How do you want each route to behave?
 
-🐨 Kody: And on that same host dashboard, hosts need clear controls to edit the
-date range and available slot times, plus a live view of attendee responses.
+💼 Brett: Home (`/`) is creation: date range, slot selection, create action.
+After create, route to `/s/{scheduleKey}/{hostKey}` for host management.
 
-💼 Brett: Yes. If host edits are awkward, coordination falls apart.
+💼 Brett: Host dashboard must support easy copy/share for both links, schedule
+editing (including increment and full-day availability controls), and clear
+response review.
 
-🐨 Kody: The attendee route should be `/s/{scheduleKey}`, which is the link hosts
-send out.
+💼 Brett: Public attendee participation should stay at `/s/{scheduleKey}`.
 
 👤 Una: Perfect. On that page, attendees should enter their name and mark the
 time slots they can do. That flow has to be very mobile friendly.
 
+🐨 Kody: Any language/style guardrails we should enforce in the product copy?
+
+💼 Brett: Keep everything in-world and product-real. No internal process language
+in the user-facing flow.
+
 🐨 Kody: What constraints should shape scope immediately?
 
 💼 Brett: I want this to feel premium right away. I know that is not a hard
@@ -239,26 +251,27 @@ constraint, but it is where my head goes first.
 💼 Brett: Hard constraints are two-week window and no extra headcount. If we
 overreach with this release, we will miss the timeline.
 
-🐨 Kody: Given those constraints, I recommend no heavy integrations in v1 and a
-focus on the core planning loop first.
-
-💼 Brett: That makes sense. I do not love deferring integrations, but with this
-timeline I agree.
+🐨 Kody: Given those constraints, how do you want to handle integrations for v1?
 
-🐨 Kody: What can we defer without invalidating learning?
+💼 Brett: Keep the core loop first and defer heavy integrations. We can still
+design for future integration points, but we should not build them now.
 
-🐨 Kody: If we keep adding "nice-to-have" scope now, we reduce our chance of
-actually validating the core loop in this release.
+🐨 Kody: Which items are the right first deferrals without hurting the learning
+goal?
 
-💼 Brett: Calendar sync and advanced recurring events are what I would defer
-first, even though I keep wanting them in the product.
+💼 Brett: Calendar sync and advanced recurring events are first to defer. They are
+valuable, but they are not required to validate whether people can actually
+finalize plans through this flow.
 
-🐨 Kody: Highest-likelihood technical failure mode?
+🐨 Kody: From your perspectives, what is the highest-likelihood technical failure
+mode in this release?
 
-🐨 Kody: Given Una's point, poor mobile UX is the biggest technical risk.
+👤 Una: Poor mobile UX, easily. If participation is clunky on phones, completion
+drops immediately. Timezone clarity still matters, but mobile friction is the
+first thing that will break adoption.
 
-👤 Una: I agree. If the mobile flow is clunky, people will not complete
-availability. Timezone clarity still matters, but it is not the top risk.
+💼 Brett: From the business side I agree. If mobile completion is weak, the funnel
+falls apart before we can learn anything meaningful about finalization rates.
 
 🐨 Kody: Biggest product risks?
 
@@ -273,7 +286,7 @@ If we can stay disciplined there, we should learn fast.
 
 👤 Una: Please make sure key actions are thumb-friendly and obvious on mobile.
 
-🐨 Kody: I want to record assumptions so we can test them:
+🐨 Kody: Can I record these as assumptions for validation?
 1) people will use this if it beats chat coordination,
 2) no-calendar-sync is acceptable in v1,
 3) a narrow set of social planning flows is enough to validate viability.

exercises/01.building-an-mvp/03.solution.select-starter-architecture/discovery-brief.md

@@ -36,6 +36,12 @@ This document now captures clarified answers and decisions before implementation
   - Home route (`/`): host selects start/end dates with standard date inputs and initial available schedule slots, then clicks "Create schedule"
   - Host dashboard route (`/s/{scheduleKey}/{hostKey}`): host can copy/share both links (public schedule link and private host dashboard link), edit schedule details/date/slot availability, and review attendee responses
   - Attendee schedule route (`/s/{scheduleKey}`): attendees enter name and select available slots; this route must be especially mobile friendly
+- What should the schedule grid interaction feel like?
+  - Spreadsheet-like and high-velocity on desktop (Excel-like selection model), while preserving touch-friendly behavior on mobile
+- What temporal granularity and coverage are required in MVP?
+  - Full-day host availability selection (not business-hours-only), with configurable slot increments of 15, 30, or 60 minutes
+- What timezone behavior is required for trust?
+  - Explicit timezone-safe rendering and conversion across host and attendee views, with unambiguous final plan output
 - Why build instead of just adopting existing tools?
   - Existing tools like when2meet.com, whenavailable.com, and Doodle validate demand, but we still need a tighter completion-first UX and agent-native workflows (AI agents using MCP to create, update, and finalize plans with users)
 
@@ -50,7 +56,8 @@ This document now captures clarified answers and decisions before implementation
   - Many polls created, but few result in a confirmed plan
 - What UX quality bar should support the success metric?
   - Availability selection should feel spreadsheet-fast: like selecting time-slot cells in Excel on desktop, with clear visual state and low interaction friction
-  - Proposed implementation direction from product/developer facilitation: on mobile, tap-to-select plus draggable corner handle expansion with edge auto-scroll
+  - Selected state must be visually obvious at a glance (high-contrast fill/border and clear active-range affordance)
+  - Brett's mobile direction: match Google Docs/Google Sheets touch behavior where selecting a cell reveals a drag handle that can expand or shrink the current selection (with edge auto-scroll when dragging near viewport boundaries)
   - Overall product aesthetics should feel friendly and colorful (primarily blues/greens) without losing a minimalistic, clean interface
   - Route transitions should be direct and explicit: create on `/`, manage on `/s/{scheduleKey}/{hostKey}`, collect attendee availability on `/s/{scheduleKey}`
 
@@ -66,6 +73,7 @@ This document now captures clarified answers and decisions before implementation
   - Use the existing web stack with lightweight sharing links and a mobile-first web experience
   - Preserve an interaction model that supports drag selection and future MCP-triggered scheduling actions without complex rewrites
   - Route model should keep host and attendee capabilities clearly separated while preserving easy sharing
+  - Preserve in-world realism in this step: avoid workshop/training/meta language in product-facing behavior and copy
 
 ### Risk clarity
 
@@ -84,7 +92,7 @@ This document now captures clarified answers and decisions before implementation
   - Frictionless response flow with clearer status tracking
   - Avoid mandatory account creation in MVP; use private host link access for management
   - Limit v1 to a narrow set of social planning flows
-  - Adopt proven interaction patterns: desktop cell selection inspired by spreadsheet tools, and mobile selection behavior similar to Google Sheets (tap cell, drag corner dot to expand, edge-drag auto-scroll)
+  - Adopt proven interaction patterns: desktop cell selection inspired by spreadsheet tools, and mobile selection behavior modeled after Google Docs/Google Sheets (select cell, drag handle to expand or shrink selection, edge-drag auto-scroll)
   - Make route purpose explicit in UI copy and provide clear copy/share controls for both schedule and host links
 
 ## Questions asked in the meeting
@@ -131,7 +139,7 @@ This document now captures clarified answers and decisions before implementation
 - How do those competitor experiences feel in real use?
   - Familiar enough to start quickly, but clunky on phones and still weak on clear finalization confidence
 - What should mobile time-slot selection feel like?
-  - Kody's proposed direction validated by user feedback: similar to Google Sheets mobile selection (tap a start cell, drag a corner handle to expand selected slots, auto-scroll near view edges)
+  - Brett's preferred direction, reinforced by user feedback: similar to Google Docs/Google Sheets mobile selection (tap a start cell, drag a corner handle to expand or shrink selected slots, auto-scroll near view edges)
 - Which route is most sensitive to mobile usability quality?
   - `/s/{scheduleKey}` attendee submission flow, because most invitees respond on phones
 
@@ -157,7 +165,7 @@ This document now captures clarified answers and decisions before implementation
 
 - Assumption:
   - Why we believe this:
-    - Familiar spreadsheet-like slot selection (desktop) and Google Sheets-like touch selection (mobile) will reduce cognitive load and improve completion rates
+    - Familiar spreadsheet-like slot selection (desktop) and Google Docs/Google Sheets-style touch selection with drag-handle expand/shrink behavior (mobile) will reduce cognitive load and improve completion rates
   - How we will validate it:
     - Track response-completion and error-correction rates across desktop and mobile cohorts, and compare against baseline interaction prototypes