Spec: Capture `savings_goals` via the Stack-Type Picker (supersedes #101's questionnaire UI)

[brendaasfjnso]

Spec: Capture savings_goals via the Stack-Type Picker (supersedes #101's questionnaire UI)

Epic: 5 — Savings Goals
Related: #101 (original standalone questionnaire — superseded), #102 (savings_goals schema/API — retained, options redefined)

What changed from #101/#102

The standalone "What are you saving for?" purpose questionnaire (12 cards: vacations, tuition, down payment, etc.) is not being built. Instead, the existing "What kind of stack?" screen — already live at /new in the app — becomes the source of savings_goals data. Its 4 options are the new goal values:

• saving_stack
• savings_credit_fund
• goal_savings
• collective_fund

This screen already sits before stack creation (user picks a type → advances into the type-specific form, e.g. /new/goal). No new step, no new screen — we're just wiring the existing selection into Supabase.

Design status: already built and live. Reference: https://deploy-preview-150--app-stacks.netlify.app/new — no design work remains for this ticket.

Net effect on scope: #101's FE 8h / Design 8h is no longer needed — the screen exists. Remaining work is BE (mostly #102 as-is, with a redefined option set) plus a small FE hook to call the save endpoint on selection.

---

Behavior

• Trigger: User selects a card on the /new "What kind of stack?" screen.
• On selection: call PUT /users/me/goals with the chosen type, then navigate to the type-specific creation form as it already does today. Non-blocking — if the save fails, log it and proceed with navigation regardless.
• Accumulate, don't overwrite: since a user may create multiple stack types over time (a genuine signal for the matching engine), each selection is added to the user's goals array rather than replacing it. ["goal_savings"] → user later creates a Saving stack → ["goal_savings", "saving_stack"]. Dedupe on write.
• No "Skip for now" — picking a type is mandatory to proceed with stack creation, so there's no partial/incomplete state to preserve. completed_at from [5.2] Savings goals data model & storage #102's original design is no longer meaningful here and can be dropped or left set on first write (see open question).

Schema (from #102, option set redefined)

savings_goals {
  user_id: FK → users
  goals: text[]   -- values now: saving_stack | savings_credit_fund | goal_savings | collective_fund
  updated_at: timestamp
}

completed_at is dropped — nothing to "complete" or gate, since selection is mandatory and one-shot per creation.

Scope note: only Stack Creators make this selection and populate goals. Stack Joiners never see or contribute to this data — there's no substitute prompt for them (see Joiner flow below).

API (from #102, unchanged shape)

• PUT /users/me/goals — append the selected type to the user's goals array (dedup), update updated_at.
• GET /users/me/goals — fetch current user's accumulated goals (profile display + future matching engine input).

Acceptance Criteria

• Selecting a card on /new calls PUT /users/me/goals with the corresponding type value before navigating onward
• Selection navigation behaves exactly as it does today — the save is additive, not a new blocking step
• goals array accumulates distinct types across multiple stack creations, deduped
• goals values validated against the 4-value enum above; reject unknown values
• Responses viewable on profile/settings (Epic 6) via GET /users/me/goals

---

Decisions (resolved)

• Stack Joiner flow: dropped. Only Stack Creators populate savings_goals — [5.1] Savings goals questionnaire UI #101's questionnaire step in the joiner flow (accept invite → set wallet → questionnaire → enter stack) is cut entirely; joiners get no substitute prompt.
• completed_at: dropped from the schema.
• Design/FE hours from [5.1] Savings goals questionnaire UI #101: design is already complete (see reference link above) — no design work remains on this ticket. FE scope is limited to the save-on-select hook.
• Matching engine (5.3) signal: keep the 4 stack-type values for now; richer purpose-based data is not being pursued at this time.