Update documentation

docs/decisions/0007-authentication-recovery-deletion.md

@@ -0,0 +1,24 @@
+# 0007 — Authentication, account recovery, and data-deletion behavior
+
+**Status:** Decided
+**Resolves:** GitHub issue "Confirm authentication, account recovery, and data-deletion behavior"
+
+## Context
+
+This reads like an account-system question, but per [0001](0001-local-only-architecture.md) (no backend, no remote login) and [0004](0004-primary-user-caregiver-role.md) (no caregiver account/role), there is no account system to design. What's actually being asked: what gates access to the app on-device, what happens if that gate fails, and what "deleting your data" means with no server involved.
+
+## Decision
+
+**Authentication:** No username/password, no signup, no server-side session. App-level lock via the device's own biometric (Face ID/Touch ID/fingerprint) with the OS's built-in passcode fallback, backed by Keychain (iOS) / Keystore (Android) — this is the local-database-encryption/biometric-unlock decision already made in `architecture-plan.md`, referenced here rather than re-decided.
+
+**Account recovery:** Doesn't apply in the traditional sense — there's no password to reset. The real scenario is lockout: biometric fails or is unavailable. Use the OS's native fallback (device passcode) rather than building a custom in-app PIN-reset flow — this is what "keep technology in a supporting role" means in practice, and it's a well-tested mechanism users already understand from every other app on their phone.
+
+If someone loses the device entirely without ever having made an encrypted backup ([0003](0003-device-encryption-exports-backups.md)), the journal is unrecoverable. That's an accepted risk, consistent with 0003's stance on forgotten passphrases — not something to engineer around, but something to say plainly during onboarding: *"this stays on your phone — back it up if you want a copy that survives losing the phone."*
+
+**Data deletion:** No server-side deletion process is needed, because there's no server copy. Build an explicit in-app "Delete all my data" action that wipes the local encrypted database immediately, in addition to what a normal app uninstall already does implicitly. Explicit and discoverable beats relying on someone knowing to uninstall the app — matches the plain-language, user-control principle and directly satisfies the MVP exit criteria checklist item on documented deletion behavior.
+
+## Consequences
+
+- No auth backend to build, test, or secure — this scope was already effectively closed by [0001](0001-local-only-architecture.md); this record just makes it explicit for the specific auth/recovery/deletion questions the brief raised separately.
+- One small feature to add: an in-app "Delete all data" control, not just relying on uninstall.
+- Onboarding copy needs one honest line about backup being the user's responsibility if they want loss-resilience beyond the device itself.

docs/decisions/0008-first-vertical-slice.md

@@ -0,0 +1,24 @@
+# 0008 — First representative vertical slice
+
+**Status:** Decided
+**Resolves:** GitHub issue "Choose the first representative vertical slice for design and development"
+
+## Context
+
+The brief calls for validating one full Phase 1 section end-to-end — data model through a shipped, tested, accessible screen — before building out the rest of Phase 1. This determines what a new contributor's first real ticket looks like, so it's worth deciding before recruiting rather than after.
+
+## Decision
+
+**Build Caregiver/Emergency Contacts first.** Name, relationship, phone, email; add/edit/delete list.
+
+## Rationale
+
+- It's the simplest true instance of the repeatable-entry pattern — four plain text fields, no sensitive-field exclusions to reason about (contrast [0006](0006-excluded-field-safety-boundary.md), which governs Your Information and Medical Portals), no derived calculations, no conditional logic.
+- Phase 1's ticket list already calls for a **generic repeatable-entry CRUD pattern** "built once, reused everywhere" — Health Care Providers, Allergies, Chronic Conditions, Hospitalizations, Family History, and others are all variants of the same shape. Proving that pattern out on the lowest-complexity case first means the slice validates the reusable component, not just one screen.
+- It touches the full stack that matters for Phase 1: the encrypted local database, the biometric-unlock app shell, the generic CRUD component, and one screen a user actually sees — without the extra decisions Your Information carries (SSN exclusion, insurance sub-fields) or Medical Portals carries (username/password exclusion).
+- Its output feeds directly into the "Keep with me" emergency screen ([0005](0005-grab-and-go-emergency-access.md)), so shipping it end-to-end also produces something immediately useful, not just a technical proof.
+
+## Consequences
+
+- This becomes the first ticket handed to a new contributor — a good "start here" story for onboarding: small, real, and it establishes the pattern everything else in Phase 1 copies.
+- The generic CRUD component ticket should be scoped and built alongside this slice, not after it — building Contacts without generalizing the pattern would mean redoing the work on the next list screen.

docs/decisions/0009-hosting-support-incident-ownership.md

@@ -0,0 +1,28 @@
+# 0009 — Hosting, support, incident response, and long-term maintenance ownership
+
+**Status:** Open — needs a named owner, not a technical call
+**Resolves:** GitHub issue "Decide who owns hosting, support, incident response, and long-term maintenance"
+
+## Context
+
+This is an organizational decision, not an engineering one — laid out here so Jesse and Paul have what's needed to bring it to Roberta and Ruby for Good's leadership, not to pre-decide it.
+
+## What the local-only decision already narrowed
+
+Per [0001](0001-local-only-architecture.md), there's no patient-data server in MVP — no database to back up, no uptime SLA for the core product, no patient-data breach surface on a server Along With You runs. That's a real reduction in what "hosting" has to mean here compared to a networked app. What's left to own is smaller than it would otherwise be, but not zero:
+
+- **The org's public website / donation page** (Rails, in this same repo) — hosting, domain renewal, and whatever bill that carries.
+- **App store distribution** — an Apple Developer account and a Google Play Console account, both of which cost money annually and require a named account holder. This is a common single point of failure for volunteer projects: if the one person with the login leaves, nobody can ship an update until access is recovered.
+- **Security/incident contact** — if someone (a researcher, a user, anyone) reports a vulnerability or a data-handling concern, who receives that report and decides what happens next?
+- **General maintenance continuity** — architecture and security posture ownership between Ruby for Good's hackathon-style sprints, called out explicitly as a risk in the team's own Open Questions doc.
+
+## What needs a decision
+
+- Named individual(s) — not "the team" — holding the Apple/Google developer accounts, with a documented second person as backup.
+- Named security/incident contact, same backup requirement.
+- Confirmation of who already owns Ruby for Good's broader web hosting, and whether this project's site/donation page rides on that existing arrangement or needs its own.
+- What happens to all of the above if a current owner becomes unavailable — a short written continuity note, not a full plan.
+
+## Why this matters before more devs join
+
+More contributors means more surface area for "who do I ask" and more risk that undocumented tribal knowledge (who has the Apple account password, who gets pinged if something breaks) stays with one or two people. Worth a short written answer, even an informal one, before the contributor base grows past the people who already know it by default.

docs/decisions/0010-account-creation.md

@@ -0,0 +1,16 @@
+# 0010 — Whether the organization or its partners create accounts for users
+
+**Status:** Decided
+**Resolves:** GitHub issue "Decide whether the organization or its partners create accounts for users"
+
+## Decision
+
+**No accounts exist, so neither the organization nor any partner creates one.** This follows directly from [0001](0001-local-only-architecture.md) (no backend, no remote login) and [0007](0007-authentication-recovery-deletion.md) (no username/password, no signup). The app is downloaded from the App Store / Play Store and used immediately — self-serve, same as any consumer app with local-only storage. There's no signup flow to design and no provisioning process for the org or a partner clinic to run.
+
+## Related, but different question
+
+Whether a partner (e.g. the Dewberry Cancer Center) ever hands out the app through a special channel — a code, a link, TestFlight, enterprise distribution — is a **distribution** question, not an account-creation one. Nothing here rules that out; it just isn't the same decision. Worth its own ticket if the team wants app distribution to go through a partner rather than the public app stores.
+
+## Consequences
+
+Closes cleanly alongside [0007](0007-authentication-recovery-deletion.md) — both resolve to "no accounts" once [0001](0001-local-only-architecture.md) is ratified. No onboarding/signup screens to design for Phase 0.

docs/decisions/README.md

@@ -12,6 +12,10 @@ Each record has a status. **Decided** means treat it as settled — don't re-lit
 | [0004](0004-primary-user-caregiver-role.md) | Primary MVP user and caregiver role | Decided, with open sub-questions |
 | [0005](0005-grab-and-go-emergency-access.md) | What "grab and go" access means digitally | Decided |
 | [0006](0006-excluded-field-safety-boundary.md) | Excluded-field safety boundary (SSN, portal passwords, alarm code, key/wallet location) | Needs formal sign-off |
+| [0007](0007-authentication-recovery-deletion.md) | Authentication, account recovery, and data-deletion behavior | Decided |
+| [0008](0008-first-vertical-slice.md) | First representative vertical slice (Caregiver/Emergency Contacts) | Decided |
+| [0009](0009-hosting-support-incident-ownership.md) | Hosting, support, incident response, and long-term maintenance ownership | **Open** — needs a named owner from leadership, not a technical decision |
+| [0010](0010-account-creation.md) | Whether the org or partners create accounts for users | Decided |
 
 ## Related, not duplicated here