docs: start milestone v1.1 Operability & Polish

.planning/PROJECT.md

@@ -8,6 +8,20 @@ FamilySync is a self-hosted, Dockerized family organization hub for a two-person
 
 The household can see and co-edit one color-coded family calendar (shared + each member's personal) and shared lists from a single low-friction PWA — cross-ecosystem, no app store, no per-member calendar credential juggling.
 
+## Current Milestone: v1.1 Operability & Polish
+
+**Goal:** Make FamilySync configurable, administrable, and maintainable for real multi-member use — guided setup, in-app admin, per-event reminders, faster write-back, CI/CD, and mobile test coverage — without hand-editing env files or the database.
+
+**Target features:**
+- **Per-event reminders** — reminder selector on the event form (incl. "none"), serialized as VALARM; scheduler honors each event's lead instead of a hardcoded 15-min, and fires nothing when an event has no alarm (was backlog 999.4)
+- **Admin Settings section** — role-gated UI to manage per-member Fastmail app passwords and designate the shared calendar, replacing manual DB writes (was backlog 999.10)
+- **Initial setup wizard** — first-run validated bootstrap of env vars, VAPID keypair, DB connection, and first app password (was backlog 999.11)
+- **Faster write-back** — event-driven outbox drain so edits land in ~1s instead of up to ~15s, preserving the optimistic-202 durability guarantees (was backlog 999.13)
+- **Gitea CI** — full regression (lint/typecheck/unit/API-integration against a MariaDB service container) on PR to main + build/publish Docker image (was backlog 999.14)
+- **Mobile-browser testing** — mobile viewport + authenticated PWA harness so the assistant can catch mobile-only defects (was backlog 999.12)
+
+Deferred to backlog: self-service provider onboarding (999.5) and provider abstraction (999.1). Admin-managed credentials (999.10) partially cover the multi-member credential gap in the interim.
+
 ## Requirements
 
 ### Validated
@@ -100,4 +114,4 @@ This document evolves at phase transitions and milestone boundaries.
 4. Update Context with current state
 
 ---
-*Last updated: 2026-06-10 after v1.0 MVP milestone (shipped — PR #1)*
+*Last updated: 2026-06-10 — started milestone v1.1 Operability & Polish*

.planning/STATE.md

@@ -1,17 +1,16 @@
 ---
 gsd_state_version: 1.0
-milestone: v1.0
-milestone_name: milestone
-status: Awaiting next milestone
-stopped_at: "v1.0 MVP shipped (Gitea PR #1) and archived 2026-06-10"
-last_updated: "2026-06-10T21:42:55.525Z"
-last_activity: 2026-06-10 — Milestone v1.0 completed and archived
+milestone: v1.1
+milestone_name: Operability & Polish
+status: planning
+last_updated: "2026-06-10T22:50:59.197Z"
+last_activity: 2026-06-10
 progress:
-  total_phases: 6
-  completed_phases: 6
-  total_plans: 42
-  completed_plans: 42
-  percent: 100
+  total_phases: 0
+  completed_phases: 0
+  total_plans: 0
+  completed_plans: 0
+  percent: 0
 ---
 
 # Project State
@@ -25,10 +24,10 @@ See: .planning/PROJECT.md (updated 2026-06-10)
 
 ## Current Position
 
-Phase: Milestone v1.0 complete
+Phase: Not started (defining requirements)
 Plan: —
-Status: Awaiting next milestone
-Last activity: 2026-06-10 — Milestone v1.0 completed and archived
+Status: Defining requirements
+Last activity: 2026-06-10 — Milestone v1.1 started
 
 ## Performance Metrics