Exercise 4 implementation

exercises/04.conflicting-constraints/01.problem.map-the-tradeoffs/README.mdx

@@ -0,0 +1,48 @@
+# Map the Tradeoffs
+
+👨‍💼 The narrow host-login plan from Exercise 3 solved one problem: returning
+hosts can get back to schedules more reliably. But the broader pressure has not
+gone away.
+
+Some people now want a wider accounts system because it sounds more
+trustworthy, more professional, and more scalable for repeat usage. Others want
+to preserve the product's low-friction advantage and avoid dragging account
+complexity into flows that currently work.
+
+🧝‍♀️ Set the playground to `extra/03.improved-implementation`. Use the planning
+artifacts you have already produced as context:
+
+- <InlineFile file="docs/planning/feature-framing-brief.md" />
+- <InlineFile file="docs/planning/response-constraint-brief.md" />
+- <InlineFile file="docs/planning/ux-invariants.md" />
+- <InlineFile file="docs/planning/implementation-brief.md" />
+
+🐨 Create a dedicated <InlineFile file="docs/planning/tradeoff-map.md" />
+artifact that compares the competing directions in front of the team.
+
+At minimum, compare:
+
+1. The narrow host-focused path
+2. A broader account/login expansion for repeat users
+
+Your map should cover:
+
+1. The priorities each path is trying to optimize
+2. The success criteria each path would claim as justification
+3. The likely harms or regression risks each path creates
+4. The assumptions or evidence gaps hidden inside each argument
+5. The mitigations that could reduce downside, if that path were chosen
+
+Requirements:
+
+- Keep the comparison grounded in the app's real flows on `/`,
+  `/s/{scheduleKey}`, and `/s/{scheduleKey}/{hostKey}`.
+- Include finalized-plan rate, create-flow speed, attendee completion, trust,
+  and implementation/support cost somewhere in your analysis.
+- Be explicit about which constraints are truly competing rather than merely
+  inconvenient.
+- Do not collapse everything into one "balanced" answer yet. Surface the
+  tension first.
+
+💰 Good tradeoff work starts by making the conflict legible. If both options
+sound equally good in your document, you have probably hidden the real cost.

exercises/04.conflicting-constraints/01.problem.map-the-tradeoffs/tradeoff-map.md

@@ -0,0 +1,43 @@
+# Tradeoff Map
+
+This document should make the competing constraints visible before the team
+pretends the decision is obvious.
+
+## Decision context
+
+- What new pressure or request is creating this conflict:
+- Which earlier decision or scope boundary is now under pressure:
+- Which user outcomes are most at risk if the team gets this wrong:
+
+## Option A
+
+- Path name:
+- What this path is trying to optimize:
+- Success criteria this path would claim:
+- Which flows or routes it touches most:
+- Likely harms or regressions it introduces:
+- Key assumptions or missing evidence:
+- Mitigations if this path is chosen:
+
+## Option B
+
+- Path name:
+- What this path is trying to optimize:
+- Success criteria this path would claim:
+- Which flows or routes it touches most:
+- Likely harms or regressions it introduces:
+- Key assumptions or missing evidence:
+- Mitigations if this path is chosen:
+
+## Constraint collisions
+
+- Which priorities are directly in tension:
+- Which route or workflow feels most fragile under this decision:
+- Which costs are immediate versus delayed:
+- Which downside is easiest for a team to underestimate:
+
+## Open questions
+
+- What evidence would most reduce uncertainty:
+- What would make the broader path clearly worth it:
+- What would make the narrower path clearly insufficient:

exercises/04.conflicting-constraints/01.solution.map-the-tradeoffs/README.mdx

@@ -0,0 +1,12 @@
+# Map the Tradeoffs
+
+👨‍💼 Nice work. You made the conflict explicit instead of letting the team talk
+about "better trust" and "low friction" as if they were automatically
+compatible.
+
+🦉 This is the judgment move this exercise is training. Strong engineers do not
+hide the cost of a more ambitious path, and they do not romanticize simplicity
+without naming what it fails to solve. They force both sides of the tradeoff to
+be comparable.
+
+In the next step, you'll stop mapping and start deciding.

exercises/04.conflicting-constraints/01.solution.map-the-tradeoffs/tradeoff-map.md

@@ -0,0 +1,126 @@
+# Tradeoff Map
+
+This document makes the competing constraints visible before the team pretends
+the decision is obvious.
+
+## Decision context
+
+- What new pressure or request is creating this conflict:
+  - The team can now justify a narrow host-login improvement, but stakeholders
+    are pushing to go further and add broader accounts for repeat users.
+- Which earlier decision or scope boundary is now under pressure:
+  - The exercise 2 decision to avoid a full account system and the exercise 3
+    plan to keep login narrowly host-focused.
+- Which user outcomes are most at risk if the team gets this wrong:
+  - Finalized-plan rate
+  - Create-flow completion speed
+  - Attendee submission completion
+  - Host trust that they can reliably get back to the right schedule
+
+## Option A
+
+- Path name:
+  - Stay narrow: host-focused continuity improvement only
+- What this path is trying to optimize:
+  - Better return access for hosts
+  - Lower risk to the create and attendee flows
+  - Smaller implementation and support surface area
+- Success criteria this path would claim:
+  - Returning hosts recover schedules more reliably
+  - Finalized-plan rate holds steady or improves
+  - Create and attendee completion remain effectively unchanged
+- Which flows or routes it touches most:
+  - `/s/{scheduleKey}/{hostKey}` for host management and claiming
+  - A host-only login entry point
+  - Optional post-create continuity prompts on `/`
+- Likely harms or regressions it introduces:
+  - Some repeat users may still feel the product lacks the polish or permanence
+    of a full account system
+  - Hosts may still need to understand both host-link and account-based access
+  - The narrower move may not fully solve long-term repeat-usage expectations
+- Key assumptions or missing evidence:
+  - The real pain is primarily host return access, not universal identity
+  - Most attendee value still comes from fast, no-account participation
+  - The product does not yet need cross-schedule history badly enough to justify
+    broader scope
+- Mitigations if this path is chosen:
+  - Make host-link purpose and claiming behavior clearer in the UI
+  - Keep login optional and host-only
+  - Measure host-return success and revisit if the narrow path proves
+    insufficient
+
+## Option B
+
+- Path name:
+  - Expand to broader repeat-user accounts
+- What this path is trying to optimize:
+  - Stronger sense of trust and permanence
+  - Easier schedule recovery across multiple visits
+  - Future optionality for identity-based features
+- Success criteria this path would claim:
+  - More returning users can find schedules without saved links
+  - Repeat usage feels more durable and professional
+  - The product gains a clearer long-term identity model
+- Which flows or routes it touches most:
+  - `/` because account creation or login prompts tend to leak into creation
+  - `/s/{scheduleKey}` because attendee identity expectations become harder to
+    avoid
+  - `/s/{scheduleKey}/{hostKey}` because host-link access now competes with
+    authenticated ownership
+  - New auth, recovery, and account-management routes
+- Likely harms or regressions it introduces:
+  - Create-flow friction rises as account concepts compete with quick schedule
+    setup
+  - Attendee completion may drop if the public flow feels more account-shaped or
+    less obviously guest-friendly
+  - Support and implementation cost grow materially because the team now owns
+    auth, recovery, identity state, and confusion between access paths
+  - Route purpose becomes easier to blur across public, host-only, and account
+    surfaces
+- Key assumptions or missing evidence:
+  - More identity always equals more trust in this product category
+  - Repeat users actually want accounts enough to offset the added friction
+  - The team can add broader auth without harming mobile-friendly participation
+  - Future optionality is valuable enough right now to justify present cost
+- Mitigations if this path is chosen:
+  - Keep attendee participation explicitly guest-friendly
+  - Preserve host-link fallback during rollout
+  - Gate account prompts away from the first-create and first-respond moments
+  - Add instrumentation and rollback triggers before broad exposure
+
+## Constraint collisions
+
+- Which priorities are directly in tension:
+  - Host-return reliability and future trust signals versus low-friction create
+    and attendee completion
+  - Product permanence versus route clarity and workflow simplicity
+  - Future optionality versus current implementation and support cost
+- Which route or workflow feels most fragile under this decision:
+  - `/s/{scheduleKey}` is the most fragile because its value comes from being
+    obviously lightweight and guest-oriented
+- Which costs are immediate versus delayed:
+  - Immediate costs: auth complexity, support burden, route confusion, create
+    friction
+  - Delayed benefits: stronger repeat-user continuity and future identity-based
+    product expansion
+- Which downside is easiest for a team to underestimate:
+  - Leakage of account expectations into flows that currently succeed precisely
+    because they are simple and no-account
+
+## Open questions
+
+- What evidence would most reduce uncertainty:
+  - How often hosts fail to return without the private host link
+  - Whether attendee completion drops when identity language is introduced
+  - Whether repeat users in this social-planning context actually expect account
+    persistence
+- What would make the broader path clearly worth it:
+  - Repeated evidence that host-return problems materially hurt finalized-plan
+    rate and cannot be solved by a host-only path
+  - Clear demand for cross-schedule history or identity-based recovery from a
+    meaningful share of active users
+- What would make the narrower path clearly insufficient:
+  - Hosts still fail to re-find schedules even after a careful host-only
+    continuity improvement
+  - The product proves that repeat-user continuity matters more than
+    ultra-lightweight first-use participation

exercises/04.conflicting-constraints/02.problem.make-the-call/README.mdx

@@ -0,0 +1,34 @@
+# Make the Call
+
+👨‍💼 You have mapped the conflict. Now the team needs a decision, not another
+round of vague discussion.
+
+🧝‍♀️ Use your existing <InlineFile file="docs/planning/tradeoff-map.md" /> to
+create a dedicated <InlineFile file="docs/planning/tradeoff-decision.md" />
+artifact.
+
+This is the moment to choose which tradeoff the team should make now and to
+justify it clearly enough that other engineers, product partners, and future
+you can understand why.
+
+Your decision brief should cover:
+
+1. Which path should ship now
+2. Why that tradeoff is correct at the current product stage
+3. The success criteria that would prove the decision was right
+4. The downside you are knowingly accepting
+5. The mitigations required to keep the chosen path safe
+6. What stays explicitly deferred and what evidence would reopen it later
+7. The rollback boundary if the decision harms the product
+
+Requirements:
+
+- Use the competing constraints from your tradeoff map rather than re-framing
+  the problem from scratch.
+- Name the constraint you are prioritizing most and the constraint you are
+  willing to disappoint.
+- Keep the reasoning grounded in the scheduler's real routes and flows.
+- Do not defend the decision with vague future optionality alone.
+
+💰 Tradeoff articulation is not "everyone is right." It is "this cost is worth
+paying now, and this other cost is not."

exercises/04.conflicting-constraints/02.problem.make-the-call/tradeoff-decision.md

@@ -0,0 +1,35 @@
+# Tradeoff Decision
+
+This brief should turn the tradeoff map into a clear recommendation the team can
+act on.
+
+## Decision
+
+- Which path should ship now:
+- Why this is the right tradeoff at the current product stage:
+- Which constraint are we prioritizing most:
+- Which constraint are we knowingly not maximizing:
+
+## Success criteria
+
+- What must improve if this decision is right:
+- What must not regress while we pursue it:
+- Which indicators or behaviors would give us confidence:
+
+## Accepted downside
+
+- What cost are we deliberately accepting:
+- Why that cost is preferable to the alternative right now:
+- Which users or workflows are least well served by this decision:
+
+## Mitigations
+
+- How we reduce the main downside of the chosen path:
+- Which guardrails or rollout choices are required:
+- What fallback or rollback boundary we need:
+
+## Deferred path
+
+- What remains deferred for now:
+- What evidence would reopen that path later:
+- What would make us regret this decision: