docs(roadmap): add Phase 16 (CI dep audit, security & image hygiene); fold in + remove backlog 999.17

.planning/ROADMAP.md

@@ -3,7 +3,7 @@
 ## Milestones
 
 - ✅ **v1.0 MVP** — Phases 1–6 (shipped 2026-06-10) — see [`milestones/v1.0-ROADMAP.md`](milestones/v1.0-ROADMAP.md)
-- 🚧 **v1.1 Operability & Polish** — Phases 7–15 (planning) — mobile test harness, Gitea CI (runs the harness), faster write-back, in-app admin, per-event reminders, guided setup, real lint gate, desktop e2e, doc-only CI skip + markdown lint
+- 🚧 **v1.1 Operability & Polish** — Phases 7–16 (planning) — mobile test harness, Gitea CI (runs the harness), faster write-back, in-app admin, per-event reminders, guided setup, real lint gate, desktop e2e, doc-only CI skip + markdown lint, CI dependency audit + security checks + image hygiene
 
 ## Phases
 
@@ -21,7 +21,7 @@ Full phase detail archived in [`milestones/v1.0-ROADMAP.md`](milestones/v1.0-ROA
 
 </details>
 
-### 🚧 v1.1 Operability & Polish (Phases 7–15)
+### 🚧 v1.1 Operability & Polish (Phases 7–16)
 
 Make FamilySync configurable, administrable, and maintainable for real multi-member use — without hand-editing env files or the database. The new critical path runs **mobile test harness → Gitea CI** (CI consumes the harness specs for UI regression), and the **admin role → reminders / setup wizard** chain (a single `/api/admin` + `/api/setup` route surface carrying the v1.1 DB migration). Faster write-back is a fully independent track.
 
@@ -34,6 +34,7 @@ Make FamilySync configurable, administrable, and maintainable for real multi-mem
 - [x] **Phase 13: Real Lint Gate (ESLint)** - Wire ESLint flat config (typescript-eslint + React) across both apps so the Phase 8 CI lint slot actually fails on violations instead of no-op'ing (completed 2026-06-12)
 - [x] **Phase 14: Desktop E2E Coverage** - Add a Desktop Chrome Playwright profile + make the mobile-authored specs desktop-safe so the Phase 8 regression gate validates desktop, not just mobile (completed 2026-06-12)
 - [x] **Phase 15: Doc-Only CI Skip + Markdown Lint** - Aggregate-gate the slow api/harness CI jobs so doc-only PRs to main merge without running them (no branch-protection deadlock), and add markdownlint to `fast-checks` so docs get a fast format+lint gate (promoted from backlog 999.17) (completed 2026-06-12)
+- [ ] **Phase 16: CI Dependency Audit, Security Checks & Image Hygiene** - Extend Gitea CI with outdated-dependency reporting + vulnerability audit + a baseline of additional security checks, and enforce the dev/prod image boundary so no dev-bypass, secret, or family data ships in published images (absorbs backlog 999.17); independent of the admin chain
 
 ## Phase Details
 
@@ -305,6 +306,32 @@ Plans:
 
 **UI hint**: no
 
+### Phase 16: CI Dependency Audit, Security Checks & Image Hygiene
+
+**Goal**: The CI pipeline surfaces outdated and vulnerable dependencies, runs a baseline of additional security checks, and enforces a clean dev↔prod boundary in the images it publishes — so the two-person household app doesn't silently rot on stale/CVE-bearing packages, and no dev-only affordance, secret, or family-specific data ever ships in a production image. Extends the existing Gitea CI (Phase 8) workflow with dependency/security/image-hygiene gates rather than standing up a separate pipeline. **Absorbs backlog 999.17 (dev/prod image boundary).**
+**Mode:** standard
+**Depends on**: Phase 8 (Gitea CI — adds steps to the existing workflow + publish job; no admin-chain dependency). Independent of Phases 10–12.
+**Requirements**: TBD (define during discuss/plan — likely new `CI-*` / `SEC-*` IDs)
+
+**Candidate scope (to be sharpened in `/gsd-discuss-phase 16`):**
+
+  - **Outdated dependencies:** a CI step that reports dependencies behind their latest (e.g. `pnpm outdated -r`), surfaced on the PR. Decide gating vs advisory, and how to handle the pinned-version table in CLAUDE.md (the stack pins exact versions — "outdated" must not fight intentional pins).
+  - **Vulnerability audit:** `pnpm audit` (or equivalent) against the lockfile, failing on a chosen severity threshold (e.g. high/critical). Decide the threshold and an allowlist/waiver mechanism for unfixable transitive advisories.
+  - **Additional security checks (user is open to these — pick a sensible baseline, avoid over-build):** candidates — secret scanning on the diff (gitleaks/trufflehog), a CodeQL/`eslint-plugin-security` static pass, dependency-review on PRs, Dockerfile/image scan (e.g. trivy) of the published image.
+  - **Dev/prod boundary definition & enforcement (from 999.17):** the `DEV_AUTH_BYPASS` concept (and any dev-only affordance) must be provably confined to local dev — never to production, never baked into published images. Today the guard is runtime-only (`NODE_ENV !== 'production' && DEV_AUTH_BYPASS === 'true'` in `apps/api/src/auth/devBypass.ts`); add (a) explicit documentation of what "dev image" vs "shipped image" means, and (b) build-time / boot-time enforcement (a `production` image refuses to boot — or the build aborts — if dev-bypass is enabled) as defense-in-depth.
+  - **No data/secrets in published images (from 999.17):** audit the Dockerfile(s) + the Phase 8 publish job (`publish.yml`) to confirm `.env`, dev seed SQL, local DB dumps, encryption keys, OIDC secrets, the `DEV_USER` seed, and family-specific fixtures are `.dockerignore`d and never `COPY`'d. Add a CI assertion that fails the publish if a dev-bypass code path is active, a forbidden env/secret is present, or personal/seed data is staged into the image context. The dev-stack seed path (`DEV_USER` id 1 + sample calendar/list data) must be unreachable from the production image/compose.
+  - **Noise control:** these gates are notorious for flaky/advisory-churn failures; decide blocking-on-merge vs warn-only per check, and where results surface (PR annotation vs job log), mirroring Phase 15's gate-aggregation approach.
+
+**Boundary:** Extends the existing Gitea CI workflow + publish job; does not remove dev-bypass (still needed for local verification and the Phase 7/8 harness) and does not add a new external service or a runtime dependency to the app. Automated dependency *upgrades* (e.g. Renovate/Dependabot bots) are a separate concern — decide in discuss whether they're in scope or deferred.
+
+**Plans**: 0 plans (run `/gsd-plan-phase 16` to break down)
+
+Plans:
+
+- [ ] TBD (run `/gsd-discuss-phase 16` then `/gsd-plan-phase 16`)
+
+**UI hint**: no
+
 ## Progress
 
 | Phase | Milestone | Plans Complete | Status   | Completed  |
@@ -324,6 +351,7 @@ Plans:
 | 13. Real Lint Gate (ESLint)      | v1.1 | 3/3   | Complete    | 2026-06-12 |
 | 14. Desktop E2E Coverage         | v1.1 | 1/1 | Complete    | 2026-06-12 |
 | 15. Doc-Only CI Skip + MD Lint   | v1.1 | 3/3 | Complete    | 2026-06-12 |
+| 16. CI Dep Audit, Sec & Img Hyg  | v1.1 | 0/?   | Not started | -       |
 
 ## Backlog
 
@@ -513,26 +541,3 @@ Plans:
 Plans:
 
 - [ ] TBD (promote with /gsd-review-backlog when ready)
-
-### Phase 999.17: Define & enforce the dev/prod boundary in shipped images — dev-bypass and personal data must never reach production artifacts (BACKLOG)
-
-**Goal:** [Captured for future planning] The `DEV_AUTH_BYPASS` concept (and any other dev-only affordance) must be provably confined to local dev — never to production, and never baked into the Docker images CI builds and publishes. Today the guard is runtime-only (`NODE_ENV !== 'production' && DEV_AUTH_BYPASS === 'true'` in `apps/api/src/auth/devBypass.ts`), which is correct but relies on env discipline at deploy time. There is no enforced, documented line between the dev image and the shipped image. Equally important: **none of the operator's data or family-specific context** (seeded dev DB rows, real Fastmail emails, app passwords, encryption keys, OIDC secrets, the dev `DEV_USER`, local `.env` values) may be embedded in published images.
-
-**Options / decisions to make when picking this up:**
-
-- **Define the boundary explicitly:** document what "dev image" vs "shipped/prod image" means — which env vars, build args, seed data, and code paths are dev-only — and make it a referenceable convention (e.g. a `docs/dev-vs-prod.md` + a note in CLAUDE.md / deployment docs).
-- **Build-time enforcement, not just runtime:** consider compiling out or hard-failing on dev-bypass in prod builds (e.g. build arg / env assertion at image build that aborts if `DEV_AUTH_BYPASS` is set, or a startup guard that refuses to boot a `production` image with bypass enabled). Today the only guard is the runtime conditional — a defense-in-depth build/boot check is missing.
-- **No data/secrets in images:** audit the Dockerfile(s) and CI publish job (Phase 8 / `publish.yml`) to confirm `.env`, dev seed SQL, local DB dumps, encryption keys, and family-specific fixtures are `.dockerignore`d and never `COPY`'d. Verify the published image is data-free and seed-free.
-- **CI assertion:** add a check in the publish pipeline that fails the build if a dev-bypass code path is active, a forbidden env/secret is present, or personal data is staged into the image context.
-- **Dev-only seed isolation:** the host-side dev stack seeds `DEV_USER` (id 1) + sample calendar/list data; ensure that seed path is unreachable from the production image and compose.
-
-**Boundary:** This is about the dev↔prod artifact boundary and image hygiene, not about removing dev-bypass (it is needed for local verification and CI harness runs per Phases 7/8). The runtime guard stays; this adds definition, documentation, build/boot enforcement, and a CI safety net.
-
-**Context:** Raised 2026-06-12 during Phase 10 (Admin Role & Settings) discussion — `DEV_USER`/dev-bypass surfaced as the head of the admin chain (first-login-wins bootstrap), prompting the concern that the dev/prod line is under-defined and that no operator/family data should ever ship in CI-built images. Tags: ci, docker, security, dev-bypass, secrets, data-hygiene, deployment.
-
-**Requirements:** TBD
-**Plans:** 0 plans
-
-Plans:
-
-- [ ] TBD (promote with /gsd-review-backlog when ready)