odd-studio 1.0.0

package/templates/docs/personas/example-persona.md

@@ -0,0 +1,108 @@
+---
+# EXAMPLE PERSONA — Read this, then delete this file and create your own
+# Use /odd → *persona in Claude Code to build personas interactively
+---
+
+# Rachel — Volunteer Coordinator
+> Persona created with ODD Studio. Acid-test persona: YES.
+
+---
+
+## Identity
+Rachel is the sole volunteer coordinator for a regional food bank that runs weekly distribution events across three sites. She manages a roster of 140 active volunteers and coordinates 8–12 events per month. She reports to the operations director and works closely with site managers at each location.
+
+She has been in this role for four years and knows most of her volunteers personally. She has never used dedicated volunteer management software — her current system is a shared Google Sheet and a WhatsApp group for each site.
+
+---
+
+## Current Reality
+A typical coordination week: Rachel checks the Google Sheet on Monday to see which upcoming shifts have gaps. She messages volunteers individually via WhatsApp to fill open spots, manually updating the sheet when someone confirms. By Thursday she usually has most shifts covered but is still chasing 3–5 people who haven't replied.
+
+On event morning, she phones the site manager with the final roster. If a volunteer drops out that morning, she works through her phone contacts trying to find a replacement. She has never been able to produce an accessible record of each volunteer's certifications — she keeps notes in her head.
+
+Her biggest frustration: spending 40% of her coordination time on communication admin rather than relationship-building.
+
+---
+
+## Technical Context
+- Primary device: iPhone 12. Does almost all coordination work on her phone.
+- Desktop: work laptop (Windows), used mainly for email and the Google Sheet
+- Connectivity: reliable mobile data, good wifi at the office
+- Technical confidence: comfortable with common apps, resistant to learning complex systems, will abandon anything that requires more than a few minutes to understand
+- Current tools: Google Sheets, WhatsApp, Gmail, Eventbrite (for public-facing signup)
+
+---
+
+## Constraints
+**Time:** Coordination is a part-time role (22 hours/week). She squeezes tasks into short windows — during her commute, between meetings, waiting to pick up her kids.
+
+**Attention:** Rarely has uninterrupted time to use the system. Must be able to start an action, be interrupted, and return to it without losing progress.
+
+**Access restrictions:** Rachel must not see volunteers' full home addresses — only their general area and emergency contact. DBS certificate status is visible to her; the full certificate details are not.
+
+**Regulatory:** Volunteers under 18 require parental consent records. Certain activities (food handling, driving) require specific certifications that must be current.
+
+**Cognitive load:** At peak times (event morning, Thursday evening before a Friday event) she is managing 6–8 simultaneous conversations and has zero tolerance for slow or confusing interfaces.
+
+---
+
+## Trigger Patterns
+**Routine (weekly, planned):** Monday morning. Reviewing next week's shifts. Calm, unhurried. Has time to think.
+
+**Reactive (mid-week):** Filling specific gaps. A volunteer has cancelled. She needs to find a replacement quickly, filter by availability and certification, and send an assignment in under 2 minutes.
+
+**Urgent (event morning):** Last-minute dropout. She needs the roster in front of her immediately, the ability to call a replacement from within the system, and confirmation that the site manager has been notified — all within 5 minutes.
+
+**Administrative (monthly):** Reviewing volunteer hours and certifications. She has time and is sitting at a desktop.
+
+---
+
+## Success Definition
+A working week where she spends less than 2 hours on coordination admin and more than 4 hours on volunteer relationship-building and event preparation.
+
+At a system level: she opens the app on Monday morning and sees exactly which shifts need filling, with a filtered list of available volunteers for each gap. She makes assignments in under 10 minutes. Volunteers receive automatic confirmations. She never has to chase a reply that the system could have handled.
+
+She would recommend this system to another coordinator if: it works flawlessly on her phone, saves her at least 3 hours per week in the first month, and her volunteers find it easy to use.
+
+---
+
+## Failure Tolerance
+**During routine use:** Moderate. Will investigate if something doesn't work immediately. Will ask for help if stuck for more than 2 minutes.
+
+**During reactive use:** Low. If the replacement-finding workflow requires more than 3 taps or takes more than 30 seconds to load, she will go back to WhatsApp.
+
+**During urgent use:** Zero. If the system fails on event morning, she needs to be able to operate entirely without it. The system must never block her from doing her job manually.
+
+**Consequence of system failure at worst moment:** A volunteer no-show that the site manager wasn't warned about. This has real operational consequences for the food bank's beneficiaries.
+
+---
+
+## Paired Relationships
+Rachel is paired with **Volunteers** (the people she coordinates) and **Site Managers** (who receive the rosters she produces).
+
+**What Rachel sees that volunteers must NOT see:**
+- Other volunteers' contact details, certifications, or availability patterns
+- Internal notes about a volunteer's reliability history
+- The full volunteer roster for an event (volunteers see only their own assignment)
+
+**What site managers see that Rachel manages:**
+- Full event roster with volunteer names, certifications, and contact details
+- Dietary/accessibility requirements for event logistics
+- They do NOT see the coordination history or volunteer correspondence
+
+---
+
+## Acid-Test Assessment
+**Rachel is the acid-test persona.** Her constraint stack:
+- Mobile-only for most use
+- Time-pressured (short, interrupted windows)
+- Must never be blocked from working manually
+- Manages sensitive personal data with role-based restrictions
+- Zero tolerance for slowness at urgent moments
+- Regulatory obligations (DBS, certification currency)
+
+If the system works for Rachel — under her constraints, across all her trigger patterns — it will work for every other persona in this system.
+
+---
+
+*Build outcomes for Rachel first. If your outcomes pass Rachel's verification steps, everything downstream will hold.*

package/templates/docs/plan.md

@@ -0,0 +1,73 @@
+# Master Implementation Plan
+> Generated by ODD Studio — Outcome-Driven Development
+> Complete this in Claude Code using `/odd` → `*plan`
+
+## Project Summary
+_What this system is, who it is for, and what it makes possible. 2–3 sentences._
+
+---
+
+## People This System Serves
+_One line per persona: name, role, and the single most important constraint._
+_Note the acid-test persona (most constrained user)._
+
+| Persona | Role | Key Constraint | Acid-Test? |
+|---------|------|---------------|------------|
+| | | | |
+
+---
+
+## Phase A — Foundation (Shared Infrastructure)
+_What must be built before any outcome can work. Written in domain terms, not technical terms._
+
+**What Phase A delivers:**
+-
+
+**Phase A verification milestone:**
+_"Phase A is complete when I can [do specific thing] in my browser."_
+
+---
+
+## Phase B — [Name this by what it delivers]
+_Outcomes in this phase and their dependencies._
+
+**Outcomes:**
+- [ ] **[Outcome Name]** — _one sentence description_
+- [ ] **[Outcome Name]** — _one sentence description_
+
+**Independent outcomes in this phase (can build in any order):**
+-
+
+**Phase B verification milestone:**
+_"Phase B is complete when I can [do specific thing] in my browser."_
+
+---
+
+## Build Order — Why This Sequence
+_Plain-language explanation a non-technical person can follow and explain to others._
+
+---
+
+## Integration Checkpoints
+_The handshake tests that run at the end of each phase._
+
+**End of Phase B:**
+- [ ] _Make a [thing] in Outcome X. Check it appears correctly in Outcome Y._
+
+---
+
+## Current Status
+
+| Phase | Status |
+|-------|--------|
+| Phase A — Foundation | ⬜ Not started |
+| Phase B | ⬜ Not started |
+
+**Last session:** —
+**Next session:** —
+
+---
+
+## Session Handover Notes
+_Most recent first. One line per session._
+