@terreno/mcp 0.31.0 → 56.0.0-beta.0

package/dist/docs/versioned/next/tasks/deploy-to-gcp.md

@@ -14,31 +14,31 @@ See: [`docs/implementationPlans/deploy-to-gcp.md`](../implementationPlans/deploy
 
 ## Phase 1: Generalize the how-to guides
 
-- [x] **Task 1.1**: Write `docs/how-to/deploy-backend-to-cloud-run.md`
+- [ ] **Task 1.1**: Write `docs/how-to/deploy-backend-to-cloud-run.md`
   - Description: New guide covering: prerequisites (gcloud installed and authenticated, billing enabled, required APIs — `run`, `artifactregistry`, `secretmanager`, `compute`); creating an Artifact Registry repo; building and pushing the backend image; creating Secret Manager secrets for `MONGO_URI`, `TOKEN_SECRET`, `TOKEN_ISSUER`, `REFRESH_TOKEN_SECRET`, `SESSION_SECRET`, and `BETTER_AUTH_SECRET`; creating the runtime service account with least-privilege roles; the `gcloud run deploy` invocation with `--session-affinity`, `--timeout`, `--min-instances`, `--set-secrets`, and `--set-env-vars`; and verification via `curl $SERVICE_URL/health`. Use placeholder variables throughout. Read `example-backend/src/server.ts` and `docs/reference/environment-variables.md` to get the env var list right — do not copy it from this task description without checking.
   - Files: `docs/how-to/deploy-backend-to-cloud-run.md` (new)
   - Depends on: none
   - Acceptance: `rg -i flourish docs/how-to/deploy-backend-to-cloud-run.md` returns nothing; every env var named exists in `docs/reference/environment-variables.md` or the backend source; every `gcloud` flag used appears in `gcloud run deploy --help`.
 
-- [x] **Task 1.2**: Add the production constraints section
+- [ ] **Task 1.2**: Add the production constraints section
   - Description: Add a "Production constraints" section to the backend guide as a symptom → cause → fix table covering at minimum: (a) websockets disconnect every few requests → no session affinity → add `--session-affinity`; (b) long-lived socket connections drop at 5 minutes → default request timeout → raise `--timeout`; (c) realtime and live feature flags stop working → MongoDB is not a replica set → use Atlas or a replica set, because change streams require one; (d) first request after idle is slow and sockets churn → scaled to zero → `--min-instances=1`; (e) browser requests fail CORS → `corsOrigin` in `setupServer` and Better Auth `trustedOrigins` do not include the web origin. Verify claim (c) against `feature-flags` live-update code before writing it.
   - Files: `docs/how-to/deploy-backend-to-cloud-run.md`
   - Depends on: Task 1.1
   - Acceptance: all five rows present with a concrete symptom; the change-streams claim is verified against the source and the source path is cited in the guide.
 
-- [x] **Task 1.3**: Write `docs/how-to/deploy-web-to-gcs-cdn.md`
+- [ ] **Task 1.3**: Write `docs/how-to/deploy-web-to-gcs-cdn.md`
   - Description: New guide covering: building the web bundle (`bunx expo export -p web` — confirm the exact command against `example-frontend/package.json` scripts), the requirement to set `EXPO_PUBLIC_API_URL` at build time because it is inlined into the bundle, creating and configuring the GCS bucket with public read and `notFoundPage=index.html` for client-side routing, the five CDN resources (backend bucket, URL map, static IP, HTTP(S) proxy, forwarding rule), pointing DNS at the IP, and cache invalidation after each deploy. Include a note that this is a static-only path and link [`web-ssr-and-admin-spa`](../implementationPlans/web-ssr-and-admin-spa.md) for the SSR future.
   - Files: `docs/how-to/deploy-web-to-gcs-cdn.md` (new)
   - Depends on: none
   - Acceptance: no Flourish strings; the export command matches an actual script in `example-frontend/package.json`; the guide explains why `EXPO_PUBLIC_API_URL` must be set before building, not after.
 
-- [x] **Task 1.4**: Write the architecture explainer
+- [ ] **Task 1.4**: Write the architecture explainer
   - Description: Create `docs/explanation/deployment-architecture-gcp.md` explaining the reference topology (reuse the mermaid diagram from the IP), what each component is responsible for, why Cloud Run rather than App Engine or GKE, why Atlas rather than self-hosted Mongo, and the tradeoffs of static web hosting versus a server-rendered deployment. Keep it conceptual — no commands.
   - Files: `docs/explanation/deployment-architecture-gcp.md` (new)
   - Depends on: Task 1.1, Task 1.3
   - Acceptance: contains the topology diagram; contains no shell commands; explains at least three explicit tradeoffs.
 
-- [x] **Task 1.5**: Rewire the existing GCP how-to and index
+- [ ] **Task 1.5**: Rewire the existing GCP how-to and index
   - Description: Replace `docs/how-to/deploy-to-gcp.md` with a short index page linking the two new guides and the explainer, preserving the old anchor names where practical so existing links do not break. Update `docs/how-to/README.md` to list the new guides. Check `website/` for any hardcoded reference to the old page path and update it.
   - Files: `docs/how-to/deploy-to-gcp.md`, `docs/how-to/README.md`, `website/` (as needed)
   - Depends on: Task 1.1, Task 1.3, Task 1.4
@@ -58,27 +58,27 @@ See: [`docs/implementationPlans/deploy-to-gcp.md`](../implementationPlans/deploy
   - Depends on: Task 2.1
   - Acceptance: `rg -n "terraform/" --glob '!infra/**' --glob '!terraform/**'` shows no stale paths pointing at moved files; the `cd.yml` workflow references the new location; `bun run rules:check` exits 0 after regenerating rules.
 
-- [x] **Task 2.3**: Parameterize the GCS hosting script
-  - Description: Rewrite `scripts/setup-gcs-hosting.sh` to require `--project`, `--site-name`, `--bucket`, and `--domain` arguments (or positional equivalents) with a usage message and a check that all are present. Remove every hardcoded Flourish project, bucket, and service-account value. Keep the resource-creation logic intact, with HTTPS as the only public serving path. Add a `--dry-run` flag that prints commands without executing them.
+- [ ] **Task 2.3**: Parameterize the GCS hosting script
+  - Description: Rewrite `scripts/setup-gcs-hosting.sh` to require `--project`, `--site-name`, and `--bucket` arguments (or positional equivalents) with a usage message and a check that all are present. Remove every hardcoded Flourish project, bucket, and service-account value. Keep the resource-creation logic intact. Add a `--dry-run` flag that prints commands without executing them.
   - Files: `scripts/setup-gcs-hosting.sh`
   - Depends on: Task 1.3
-  - Acceptance: running with no arguments prints usage and exits non-zero; `--dry-run` produces HTTPS commands containing the supplied values, no port 80 forwarding rule, and no Flourish strings; `rg -i flourish scripts/setup-gcs-hosting.sh` returns nothing.
+  - Acceptance: running with no arguments prints usage and exits non-zero; `--dry-run` produces commands containing the supplied values and no Flourish strings; `rg -i flourish scripts/setup-gcs-hosting.sh` returns nothing.
 
 ## Phase 3: The `deploy-gcp` skill
 
-- [x] **Task 3.1**: Author the skill
+- [ ] **Task 3.1**: Author the skill
   - Description: Create `.rulesync/skills/deploy-gcp/SKILL.md` with frontmatter (`name: deploy-gcp`, a `description` that names the trigger phrases "deploy to GCP", "deploy to Cloud Run", "ship the backend", and `targets: ['*']`). Body sections in this order: When to use / When not to use; Preflight checks (project layout detection, `gcloud config get-value project`, required APIs, replica-set verification of `MONGO_URI`); **Plan and confirm** — print target project, region, service name, and every resource to be created or updated, then stop and require explicit user confirmation before any mutating command; Backend deploy steps; Frontend deploy steps; Verification (`curl $SERVICE_URL/health` expecting `"healthy":true`, fetch web root); Troubleshooting (link the reference file). Include an explicit prohibition: never deploy to a project the user did not name in the request, and never create or modify secrets without echoing which secret names will change.
   - Files: `.rulesync/skills/deploy-gcp/SKILL.md` (new)
   - Depends on: Task 1.1, Task 1.3
   - Acceptance: frontmatter has `name`, `description`, and `targets`; the confirmation gate appears before the first mutating command; every command in the skill also appears in the how-to guides (no skill-only knowledge).
 
-- [x] **Task 3.2**: Add the troubleshooting reference
+- [ ] **Task 3.2**: Add the troubleshooting reference
   - Description: Create `.rulesync/skills/deploy-gcp/references/troubleshooting.md` containing the symptom → cause → fix table from Task 1.2 plus deploy-time failures: image push permission denied, secret access denied at cold start, Cloud Run revision failing health checks because `PORT` is not read from the environment, and CDN serving a stale bundle after deploy. For each, give the exact log line or error message the user will see.
   - Files: `.rulesync/skills/deploy-gcp/references/troubleshooting.md` (new)
   - Depends on: Task 3.1
   - Acceptance: at least nine rows; each row quotes an actual error string rather than paraphrasing.
 
-- [x] **Task 3.3**: Generate skill mirrors
+- [ ] **Task 3.3**: Generate skill mirrors
   - Description: Run `bun run rules` and commit every generated file under `.cursor/skills/`, `.claude/skills/`, `.devin/skills/`, `.github/skills/`, and `.agents/skills/`. Do not hand-edit generated files.
   - Files: generated skill mirrors
   - Depends on: Task 3.1, Task 3.2

package/dist/docs/versioned/next/tasks/deployment-foundation.md

@@ -13,19 +13,19 @@ See: [`docs/implementationPlans/deployment-foundation.md`](../implementationPlan
 
 ## Phase 1: Environment variable reference
 
-- [x] **Task 1.1**: Audit every environment variable in the repo
+- [ ] **Task 1.1**: Audit every environment variable in the repo
   - Description: Run `rg -n "process\.env\.[A-Z_]+" --glob '!node_modules' --glob '!*.test.ts'` and `rg -n "EXPO_PUBLIC_[A-Z_]+"` across the repo. Build a complete list of distinct variables with the file and package where each is read. Also check `Constants.expoConfig?.extra` reads in `rtk/src/constants.ts` (and the syncdb equivalent post-#869) since those are configured through `app.json` rather than the environment. Save the raw findings in the PR body.
   - Files: none (findings in the PR body)
   - Depends on: none
   - Acceptance: the list is generated from grep output, not hand-written; every entry names the reading file; `extra`-based config is listed separately from `process.env` reads.
 
-- [x] **Task 1.2**: Complete `docs/reference/environment-variables.md`
+- [ ] **Task 1.2**: Complete `docs/reference/environment-variables.md`
   - Description: Restructure the page into tables grouped by concern (Database, Auth — JWT, Auth — Better Auth, AI, Storage, Feature flags, Observability, MCP, Client/build-time). Each row: variable, read by (package), required or optional, default, secret (yes/no), and scope (server runtime / client build-time). Add an explicit callout explaining that `EXPO_PUBLIC_*` variables are inlined into the JavaScript bundle at build time — they are not secrets and cannot be changed without rebuilding. Every variable from Task 1.1 must appear exactly once.
   - Files: `docs/reference/environment-variables.md`
   - Depends on: Task 1.1
   - Acceptance: every variable from the Task 1.1 audit appears; no variable is listed that does not appear in the audit; the build-time callout is present; secrets are marked.
 
-- [x] **Task 1.3**: `[RTK]` Update the `.env.example` files
+- [ ] **Task 1.3**: `[RTK]` Update the `.env.example` files
   - Description: Update `example-backend/.env.example` and `example-frontend/.env.example` so each contains every required variable for that app with safe placeholder values and a one-line comment per variable. Verify no real secret values are present. Add the Better Auth variables to the backend example, commented out, with a note pointing at `docs/how-to/configure-better-auth.md`.
   - Files: `example-backend/.env.example`, `example-frontend/.env.example`
   - Depends on: Task 1.2
@@ -33,19 +33,19 @@ See: [`docs/implementationPlans/deployment-foundation.md`](../implementationPlan
 
 ## Phase 2: Deployment baseline
 
-- [x] **Task 2.1**: Write `docs/explanation/deployment-baseline.md`
+- [ ] **Task 2.1**: Write `docs/explanation/deployment-baseline.md`
   - Description: Explainer covering the seven baseline requirements from the IP. For each: what it is, why Terreno needs it, and the symptom when it is missing. Requirements 1, 3, and 5 need reproduced symptoms: (1) run the backend against a standalone `mongod` and quote the actual startup or change-stream error; (3) describe what happens to Socket.io on a platform with a short request timeout — cite the reconnect behavior in the client socket code; (5) build the web bundle with `EXPO_PUBLIC_API_URL` unset, then serve it and quote the resulting client-side failure. Requirement 6 must state that `@terreno/api-health` is part of the baseline (IP question DF4).
   - Files: `docs/explanation/deployment-baseline.md` (new)
   - Depends on: Task 1.2
   - Acceptance: all seven requirements documented; symptoms for 1, 3, and 5 are reproduced and quoted verbatim, not paraphrased.
 
-- [x] **Task 2.2**: Add the web output-mode decision table
+- [ ] **Task 2.2**: Add the web output-mode decision table
   - Description: Add a section to `docs/explanation/deployment-baseline.md` with the three-mode table from the IP (`single`, `static`, `server`) covering output shape, API-route support, SSR support, hosting requirements, and current Terreno status. State explicitly: `single` is today's default, `static` is available now and improves SEO, and `server` requires Expo SDK ≥ 55 while the repo catalog is on `~54.0.29` — link PR #779 and [`web-ssr-and-admin-spa`](../implementationPlans/web-ssr-and-admin-spa.md). Verify the current Expo version from the root `package.json` catalog rather than trusting this description.
   - Files: `docs/explanation/deployment-baseline.md`
   - Depends on: Task 2.1
   - Acceptance: table has all three modes with all five columns; the stated Expo version matches the root catalog; no text implies SSR is currently available.
 
-- [x] **Task 2.3**: `[RTK]` Add the multi-environment section
+- [ ] **Task 2.3**: `[RTK]` Add the multi-environment section
   - Description: Add a section listing exactly what differs between a staging and a production deployment: secret values, `MONGO_URI` (separate cluster or database), `EXPO_PUBLIC_API_URL` (requires a separate web build per environment — call this out, it is the non-obvious one), `corsOrigin`, Better Auth `trustedOrigins` and `BETTER_AUTH_URL`, and feature-flag defaults. Keep it under 40 lines; this is a checklist, not a guide.
   - Files: `docs/explanation/deployment-baseline.md`
   - Depends on: Task 2.2
@@ -53,25 +53,25 @@ See: [`docs/implementationPlans/deployment-foundation.md`](../implementationPlan
 
 ## Phase 3: Backend container
 
-- [x] **Task 3.1**: Verify and fix the backend's port and host binding
+- [ ] **Task 3.1**: Verify and fix the backend's port and host binding
   - Description: Read `example-backend/src/server.ts` and `api/src/expressServer.ts` to determine how the listen port and host are resolved. Confirm the port comes from `process.env.PORT` with a fallback and that the server binds `0.0.0.0` (or Express's default, which is all interfaces — verify rather than assume). If either is wrong for containerized deployment, fix it in the smallest possible change and add a test. If both are already correct, make no code change and record that finding.
   - Files: `example-backend/src/server.ts` and/or `api/src/expressServer.ts` (only if a fix is needed), plus a test
   - Depends on: none
   - Acceptance: running `PORT=9999 bun run backend:dev` serves on 9999; the finding (fixed or already correct) is stated in the PR body with file citations.
 
-- [x] **Task 3.2**: Write the backend Dockerfile
+- [ ] **Task 3.2**: Write the backend Dockerfile
   - Description: Create `example-backend/Dockerfile` as a multi-stage build on `oven/bun:1-slim` (IP question DF2). Stage 1: copy the lockfile and workspace manifests, run `bun install --frozen-lockfile`, then compile the workspace packages the backend depends on (`@terreno/test`, `@terreno/api`, then the rest — mirror the ordering in the root `compile` script). Stage 2: copy only the built output and production dependencies, create and switch to a non-root user, set `ENV NODE_ENV=production`, expose the port, and set the entrypoint. Add a `HEALTHCHECK` hitting the health endpoint. Create `example-backend/.dockerignore` excluding `node_modules`, `.git`, `.env*`, test files, and build caches.
   - Files: `example-backend/Dockerfile` (new), `example-backend/.dockerignore` (new)
   - Depends on: Task 3.1
   - Acceptance: `docker build -f example-backend/Dockerfile .` succeeds from the repo root; the image runs and `curl localhost:$PORT/health` returns `"healthy":true` against an external MongoDB replica set; `docker run` with `--user` unset shows a non-root user via `id`; the final image is under 500 MB.
 
-- [x] **Task 3.3**: Add a Docker build CI job
+- [ ] **Task 3.3**: Add a Docker build CI job
   - Description: Create `.github/workflows/example-backend-docker.yml` that builds the image on pull requests touching `example-backend/**`, `api/**`, `package.json`, or `bun.lock`. Build only — do not push. Use layer caching. Follow the repo's convention of validating required inputs before use even though this job needs no secrets.
   - Files: `.github/workflows/example-backend-docker.yml` (new)
   - Depends on: Task 3.2
   - Acceptance: the workflow parses as valid YAML; the path filter covers all four inputs; the job does not push an image or require registry credentials.
 
-- [x] **Task 3.4**: Reference the Dockerfile from the docs
+- [ ] **Task 3.4**: Reference the Dockerfile from the docs
   - Description: Add a "Containerizing the backend" section to `docs/explanation/deployment-baseline.md` that explains the Dockerfile's structure and links `example-backend/Dockerfile` as the canonical copy rather than duplicating its contents (per IP question DF1). Call out the three details consumers get wrong: reading `PORT` from the environment, running as non-root, and compiling workspace packages in the right order.
   - Files: `docs/explanation/deployment-baseline.md`
   - Depends on: Task 3.2
@@ -79,13 +79,13 @@ See: [`docs/implementationPlans/deployment-foundation.md`](../implementationPlan
 
 ## Phase 4: Web build documentation
 
-- [x] **Task 4.1**: `[RTK]` Write `docs/how-to/build-for-web.md`
+- [ ] **Task 4.1**: `[RTK]` Write `docs/how-to/build-for-web.md`
   - Description: How-to covering: the build command (verify the exact script in `example-frontend/package.json` — do not assume `expo export -p web`), what the output directory contains for the current output mode, setting `EXPO_PUBLIC_API_URL` before the build with an explicit warning that it is inlined into the bundle, the `app.json` `extra` alternative (`BASE_URL`) and how the two interact — check the base-URL resolution priority order in the client package and document it accurately, serving the output locally to verify before deploying, and the SPA-routing requirement (all unknown paths must serve `index.html`) with a note that each host configures this differently. Link the provider guides.
   - Files: `docs/how-to/build-for-web.md` (new), `docs/how-to/README.md`
   - Depends on: Task 2.2
   - Acceptance: the build command matches an actual script; the base-URL priority order matches the client source and cites the file; the local-verification step works; the guide is listed in the how-to index.
 
-- [x] **Task 4.2**: Cross-link the deployment documentation
+- [ ] **Task 4.2**: Cross-link the deployment documentation
   - Description: Add a "Deployment" grouping to `docs/how-to/README.md` and `docs/explanation/README.md` listing the baseline explainer, the web build guide, and the provider guides from [`deploy-to-vercel`](../implementationPlans/deploy-to-vercel.md) and [`deploy-to-gcp`](../implementationPlans/deploy-to-gcp.md). Ensure each provider guide links back to the baseline instead of restating the seven requirements.
   - Files: `docs/how-to/README.md`, `docs/explanation/README.md`
   - Depends on: Task 4.1

package/dist/docs/versioned/next/tasks/docs-reference-coverage.md

@@ -14,19 +14,19 @@ See: [`docs/implementationPlans/docs-reference-coverage.md`](../implementationPl
 
 ## Phase 1: Missing reference pages
 
-- [x] **Task 1.1**: Write `docs/reference/ai.md`
+- [ ] **Task 1.1**: Write `docs/reference/ai.md`
   - Description: Convert `.cursor/rules/ai/00-ai.mdc` into a public reference page. Sections, following `docs/reference/api.md`'s shape: Install; Commands; Architecture (file structure); `AIService` setup and full method table; structured-output helpers (`generateJsonValue`, `generateJsonObject`, `generateJsonArray`) including the JSON-normalization behavior and error logging; temperature presets; the `AIRequest` and `GptHistory` models with field tables; route registrars (`addGptRoutes`, `addGptHistoryRoutes`, `addAiRequestsExplorerRoutes`) with endpoints, methods, and permissions; Langfuse integration; integration example with `setupServer`/`TerrenoApp`; environment variables; conventions; testing (including the mock-model pattern). Verify every symbol against `ai/src/index.ts`. Remove the internal-only conventions that make no sense to a consumer (for example instructions about not mocking `@terreno/api` belong in agent rules, not reference docs — use judgment).
   - Files: `docs/reference/ai.md` (new)
   - Depends on: none
   - Acceptance: every documented symbol appears in `ai/src/index.ts`; the method table lists all `AIService` methods; all three route registrars documented with their permissions; no `.claude/` or `.cursor/` path referenced.
 
-- [x] **Task 1.2**: Write `docs/reference/admin-spa.md`
+- [ ] **Task 1.2**: Write `docs/reference/admin-spa.md`
   - Description: New reference page for `@terreno/admin-spa`, sourced from `admin-spa/README.md` and `admin-spa/src/`. Cover: what the package is (standalone Expo Router web admin SPA plus an Express plugin that serves it), install, the `AdminSpaServeApp` plugin registration with its options, building the SPA, configuring `apiBase`/`routeBase`, how it relates to the embedded `@terreno/admin-frontend` approach and when to choose each, and environment variables. Verify the plugin options against the source and against how `example-backend/src/server.ts` registers it.
   - Files: `docs/reference/admin-spa.md` (new)
   - Depends on: none
   - Acceptance: every option documented exists in the source; includes a "standalone SPA vs embedded screens" decision paragraph; the registration example matches `example-backend/src/server.ts`.
 
-- [x] **Task 1.3**: Write `docs/reference/test.md`
+- [ ] **Task 1.3**: Write `docs/reference/test.md`
   - Description: New reference page for `@terreno/test`. Cover: what it provides (in-memory MongoDB management for bun test suites), install as a dev dependency, the `bunfig.toml` preload pattern, `setupEnvironment()`, the `TERRENO_TEST_USE_MEMORY_MONGO` / `TERRENO_TEST_MONGODB_URI` / `BUN_TEST_DISABLE_DB` environment variables, and the test-helper exports. Source the preload contract from `admin-backend/AGENTS.md`, `api/src/tests/bunSetup.ts`, and the `backend-test-env` skill. Keep it short — one page.
   - Files: `docs/reference/test.md` (new)
   - Depends on: none
@@ -40,7 +40,7 @@ See: [`docs/implementationPlans/docs-reference-coverage.md`](../implementationPl
 
 ## Phase 2: Package READMEs
 
-- [x] **Task 2.1**: Define and apply the README template to the four stubs
+- [ ] **Task 2.1**: Define and apply the README template to the four stubs
   - Description: Write the six-section template from the IP (Title/description, Install, Quick start, What's included, Documentation, License/Contributing) and apply it to the four stub READMEs: `ai/README.md` (source: the new `docs/reference/ai.md`), `admin-backend/README.md` (source: `.cursor/rules/admin-backend/00-admin-backend.mdc` + `docs/reference/admin-backend.md`), `admin-frontend/README.md` (same pattern), `api-health/README.md` (source: `api-health/src/`). Each Quick start must be a complete, runnable snippet — not a fragment. Every link absolute.
   - Files: `ai/README.md`, `admin-backend/README.md`, `admin-frontend/README.md`, `api-health/README.md`
   - Depends on: Task 1.1

package/dist/docs/versioned/next/tasks/oss-governance-baseline.md

@@ -14,37 +14,37 @@ See: [`docs/implementationPlans/oss-governance-baseline.md`](../implementationPl
 
 ## Phase 1: Legal baseline
 
-- [x] **Task 1.1**: Add root `LICENSE` and `NOTICE`
+- [ ] **Task 1.1**: Add root `LICENSE` and `NOTICE`
   - Description: Copy the MIT License text to a new root `LICENSE` (use the standard MIT template; `mcp-server` already ships MIT). Create `NOTICE` containing the project name, the copyright line `Copyright 2026 Flourish Health, Inc.`, and a one-line statement that the project is licensed under MIT. Include acknowledgement of vendored `api/src/vendor/wesleytodd-openapi/` with a pointer to its own `LICENSE`.
   - Files: `LICENSE` (new), `NOTICE` (new)
   - Depends on: none
   - Acceptance: `LICENSE` exists at repo root with standard MIT text; `NOTICE` mentions the vendored openapi code. Do not compare against `api/LICENSE` or `ui/LICENSE` — those remain Apache-2.0 until Task 1.4.
 
-- [x] **Task 1.2**: Audit license coverage across published packages
+- [ ] **Task 1.2**: Audit license coverage across published packages
   - Description: Read `.github/workflows/publish-on-tag.yml` and list every package it publishes. For each one, record in a scratch table: whether a `LICENSE` file exists, whether `package.json` has a `files` array, whether `LICENSE` is included in that array, and the `license` field value. Write the findings as a markdown table in the PR description. Do not fix anything in this task.
   - Files: none (findings go in the PR body)
   - Depends on: none
   - Acceptance: PR body contains a table with one row per published package and the four columns above; the table is derived from the actual repo, not copied from the IP.
 
-- [x] **Task 1.3**: Add `LICENSE` to every published package
+- [ ] **Task 1.3**: Add `LICENSE` to every published package
   - Description: For each package identified in Task 1.2 that lacks a `LICENSE`, create one by copying the root `LICENSE`. Packages to cover: `rtk`, `ai`, `admin-backend`, `admin-frontend`, `admin-spa`, `api-health`, `feature-flags`, `mcp-server`, `test`. Do not create `LICENSE` files in non-published directories (`demo`, `example-frontend`, `example-backend`, `website`, `terraform`).
   - Files: `rtk/LICENSE`, `ai/LICENSE`, `admin-backend/LICENSE`, `admin-frontend/LICENSE`, `admin-spa/LICENSE`, `api-health/LICENSE`, `feature-flags/LICENSE`, `mcp-server/LICENSE`, `test/LICENSE` (all new)
   - Depends on: Task 1.1, Task 1.2
   - Acceptance: every published package directory contains a `LICENSE` identical to the root `LICENSE`.
 
-- [x] **Task 1.4**: Align `license` fields and `files` arrays
+- [ ] **Task 1.4**: Align `license` fields and `files` arrays
   - Description: Set `"license": "MIT"` in the root `package.json` and in every published package's `package.json` (relicense `api`/`ui` from Apache-2.0). For every package that has an explicit `files` array, add `"LICENSE"` to it (`ui`, `rtk`, `admin-frontend`, `admin-spa`, `mcp-server` at minimum — confirm against Task 1.2 findings). Do not otherwise reorder or reformat `package.json`.
   - Files: `package.json`, `ui/package.json`, `rtk/package.json`, `admin-frontend/package.json`, `admin-spa/package.json`, `mcp-server/package.json`, plus any others found in Task 1.2
   - Depends on: Task 1.3
   - Acceptance: `bun pm pack --dry-run` run inside each published package lists `LICENSE` among the packed files; no `package.json` declares a license other than `MIT`.
 
-- [x] **Task 1.5**: Verify relicensing consent for `api` and `ui`
+- [ ] **Task 1.5**: Verify relicensing consent for `api` and `ui`
   - Description: Run `git log --format='%an <%ae>' -- api/ ui/ | sort -u` and list every distinct author. Report the list in the PR body, flagging any address that is not a `@flourish.health` address or a known bot. Do **not** proceed to merge the Apache-2.0 → MIT change for `api`/`ui` if a non-Flourish human contributor appears; instead leave a `TODO` note in the PR body requesting sign-off. (`mcp-server` is already MIT.)
   - Files: none (findings go in the PR body)
   - Depends on: Task 1.4
   - Acceptance: PR body lists all `api`/`ui` authors and explicitly states either "all Flourish/bot — safe to relicense" or names the contributors needing sign-off.
 
-- [x] **Task 1.6**: Add a license-coverage CI check
+- [ ] **Task 1.6**: Add a license-coverage CI check
   - Description: Create `scripts/check-license-coverage.ts` (Bun, TypeScript, `const` arrow functions, explicit return types). It should: read the list of published packages from `.github/workflows/publish-on-tag.yml` (parse job names or a hardcoded list with a comment pointing at the workflow), then for each assert (a) `LICENSE` exists, (b) `package.json` `license` equals the root `package.json` `license`, (c) if a `files` array exists it contains `LICENSE`. Print one line per failure and `process.exit(1)` when any check fails. Add a `check:licenses` script to the root `package.json` and a job to `.github/workflows/repo-policies.yml` that runs it.
   - Files: `scripts/check-license-coverage.ts` (new), `package.json`, `.github/workflows/repo-policies.yml`
   - Depends on: Task 1.4
@@ -52,25 +52,25 @@ See: [`docs/implementationPlans/oss-governance-baseline.md`](../implementationPl
 
 ## Phase 2: Contribution process
 
-- [x] **Task 2.1**: Write `CONTRIBUTING.md`
+- [ ] **Task 2.1**: Write `CONTRIBUTING.md`
   - Description: Create `CONTRIBUTING.md` covering, in this order: (1) Code of Conduct link; (2) ways to contribute (issue, discussion, docs fix, code); (3) development setup — `bun run bootstrap`, Bun version requirement, MongoDB replica-set requirement for `example-backend` (single-node replset is enough, change streams need it), the seeded users `test@example.com` / `superuser@example.com` with password `testpassword123`; (4) per-package commands table pulled from the root `package.json` scripts (`bun run api:test`, `bun run ui:test`, `bun run lint`, `bun run compile`); (5) code style pointers — link `AGENTS.md`, call out the no-barrel-imports rule and `bun run check:no-barrel-imports`, the Luxon requirement, and the logging conventions; (6) test expectations — new features ship with tests, coverage must not drop; (7) the IP process — link `docs/implementationPlans/README.md` and `IP_TEMPLATE.md`, explain when an IP is required (new package, new public API, cross-package change) versus not (bug fix, docs); (8) DCO sign-off instructions (`git commit -s`); (9) PR expectations — draft by default, CI green, screenshots for UI changes.
   - Files: `CONTRIBUTING.md` (new)
   - Depends on: none
   - Acceptance: every command shown in `CONTRIBUTING.md` exists in a `package.json` `scripts` block; the seeded credentials match `example-backend/src/scripts/`; no reference to `.claude/` or other agent-private paths.
 
-- [x] **Task 2.2**: Add `CODE_OF_CONDUCT.md`
+- [ ] **Task 2.2**: Add `CODE_OF_CONDUCT.md`
   - Description: Add Contributor Covenant 2.1 verbatim, with the enforcement contact set to `conduct@terreno.app`. Do not modify the covenant text other than the contact line and the project name.
   - Files: `CODE_OF_CONDUCT.md` (new)
   - Depends on: none
   - Acceptance: file states "Contributor Covenant" and version 2.1; contact address is present and is not a placeholder.
 
-- [x] **Task 2.3**: Add `SECURITY.md`
+- [ ] **Task 2.3**: Add `SECURITY.md`
   - Description: Create `SECURITY.md` with: a supported-versions table (current minor supported; previous minor receives security fixes only), reporting instructions naming GitHub private vulnerability reporting as the primary channel and `security@terreno.app` as fallback, a 5-business-day acknowledgement commitment, a statement that reporters should not open public issues for vulnerabilities, and a note that CodeQL runs on the repo (`.github/workflows/codeql-analysis.yml`).
   - Files: `SECURITY.md` (new)
   - Depends on: none
   - Acceptance: file exists at repo root so GitHub surfaces it under Security → Policy; both reporting channels are named.
 
-- [x] **Task 2.4**: Add a DCO check for external PRs
+- [ ] **Task 2.4**: Add a DCO check for external PRs
   - Description: Add a workflow job (either in `repo-policies.yml` or a new `.github/workflows/dco.yml`) that, for pull requests whose head repository differs from the base repository, verifies every commit message contains a `Signed-off-by:` line matching the commit author. Skip the check for PRs from the same repo and for bot authors (`dependabot[bot]`, `cursor[bot]`). Follow the repo's existing convention of validating required inputs before use.
   - Files: `.github/workflows/dco.yml` (new) or `.github/workflows/repo-policies.yml`
   - Depends on: Task 2.1
@@ -78,19 +78,19 @@ See: [`docs/implementationPlans/oss-governance-baseline.md`](../implementationPl
 
 ## Phase 3: Changelog
 
-- [x] **Task 3.1**: Create the root `CHANGELOG.md` and backfill releases
+- [ ] **Task 3.1**: Create the root `CHANGELOG.md` and backfill releases
   - Description: Create `CHANGELOG.md` in Keep-a-Changelog format with an `## [Unreleased]` section at the top, then one section per released version, newest first. Source the content from `gh release list --limit 40` and `gh release view <tag>` for each release from 0.20.0 to the current version. Group each entry under `Added` / `Changed` / `Fixed` / `Deprecated` / `Removed`. Include a header note that all `@terreno/*` packages are versioned in lockstep and a link to `docs/implementationPlans/oss-launch-program.md` is **not** needed here. Do not invent entries — if a release has no notes, write `- No published release notes.` under that version.
   - Files: `CHANGELOG.md` (new)
   - Depends on: none
   - Acceptance: every version tag returned by `gh release list` between 0.20.0 and current has a section; no section is empty; the file states the lockstep versioning rule.
 
-- [x] **Task 3.2**: Reduce `api/CHANGELOG.md` to a pointer
+- [ ] **Task 3.2**: Reduce `api/CHANGELOG.md` to a pointer
   - Description: Replace the contents of `api/CHANGELOG.md` with a short note that the changelog moved to the repo root, linking `../CHANGELOG.md`. Preserve the historical entries by moving them into the corresponding root `CHANGELOG.md` sections first if they contain detail the GitHub releases lack.
   - Files: `api/CHANGELOG.md`, `CHANGELOG.md`
   - Depends on: Task 3.1
   - Acceptance: `api/CHANGELOG.md` is under 10 lines and links to the root changelog; no historical detail was lost.
 
-- [x] **Task 3.3**: Make changelog updates part of the release process
+- [ ] **Task 3.3**: Make changelog updates part of the release process
   - Description: Edit `.rulesync/skills/release/SKILL.md` to add a required step: before tagging, move `## [Unreleased]` content into a new version section in the root `CHANGELOG.md` with today's date (via Luxon-formatted ISO date), and confirm the section is non-empty. Then run `bun run rules` to regenerate the mirrored skill files under `.cursor/`, `.claude/`, `.devin/`, `.github/`, and `.agents/`.
   - Files: `.rulesync/skills/release/SKILL.md`, plus generated mirrors
   - Depends on: Task 3.1
@@ -98,31 +98,31 @@ See: [`docs/implementationPlans/oss-governance-baseline.md`](../implementationPl
 
 ## Phase 4: GitHub templates
 
-- [x] **Task 4.1**: Add issue forms
+- [ ] **Task 4.1**: Add issue forms
   - Description: Create three GitHub issue forms. `bug_report.yml`: fields for affected package (dropdown listing all published `@terreno/*` packages plus `docs`, `examples`, `mcp`), version, platform (dropdown: iOS / Android / Web / Backend / N/A), reproduction steps (required textarea), expected vs actual, and a checkbox confirming the reporter searched existing issues. `feature_request.yml`: problem statement (required), proposed solution, alternatives considered, and a checkbox asking whether the requester is willing to open a PR. `docs_issue.yml`: page URL, what is wrong or missing, and suggested fix. Add `config.yml` with `blank_issues_enabled: false` and contact links to Discussions (Q&A and Ideas categories) and `SECURITY.md`.
   - Files: `.github/ISSUE_TEMPLATE/bug_report.yml`, `.github/ISSUE_TEMPLATE/feature_request.yml`, `.github/ISSUE_TEMPLATE/docs_issue.yml`, `.github/ISSUE_TEMPLATE/config.yml` (all new)
   - Depends on: Task 2.3
   - Acceptance: all four files parse as valid YAML; the package dropdown in `bug_report.yml` matches the packages published by `publish-on-tag.yml`; `config.yml` disables blank issues.
 
-- [x] **Task 4.2**: Add a PR template
+- [ ] **Task 4.2**: Add a PR template
   - Description: Create `.github/PULL_REQUEST_TEMPLATE.md` with sections: Summary; Related IP or issue; Type of change (checkboxes); Testing performed (with a reminder that frontend changes require screenshots or video per `AGENTS.md`); Checklist (tests added, `bun run lint` passes, `bun run compile` passes, docs updated, changelog `Unreleased` entry added for user-facing changes, DCO signed off). Keep it short enough that contributors actually fill it in — under 40 lines.
   - Files: `.github/PULL_REQUEST_TEMPLATE.md` (new)
   - Depends on: Task 2.1, Task 3.1
   - Acceptance: template is under 40 lines; references the changelog and the frontend-verification requirement.
 
-- [x] **Task 4.3**: Add `CODEOWNERS`
+- [ ] **Task 4.3**: Add `CODEOWNERS`
   - Description: Create `.github/CODEOWNERS` mapping each package directory to its owning team or maintainer, plus a catch-all root owner. Use GitHub team handles if they exist; otherwise use individual maintainer usernames. Include entries for `docs/`, `.github/`, `.rulesync/`, and `terraform/`.
   - Files: `.github/CODEOWNERS` (new)
   - Depends on: none
   - Acceptance: every top-level package directory has an owner; the file has a catch-all `*` line; GitHub's CODEOWNERS validation (visible in repo settings) reports no errors.
 
-- [x] **Task 4.4**: Document required repository settings
+- [ ] **Task 4.4**: Document required repository settings
   - Description: Add a short section to `CONTRIBUTING.md` (or a new `docs/explanation/repository-settings.md` if it exceeds 30 lines) listing the GitHub settings a maintainer must enable manually because they cannot be committed: Discussions enabled with the categories from [`public-roadmap-github.md`](../implementationPlans/public-roadmap-github.md), private vulnerability reporting enabled, branch protection on `master` requiring the CI checks, "Allow squash merging" only, and auto-delete of merged branches.
   - Files: `CONTRIBUTING.md` or `docs/explanation/repository-settings.md`
   - Depends on: Task 2.1
   - Acceptance: the list names each setting and where to find it in the GitHub UI; no setting is described as already enabled unless verified.
 
-- [x] **Task 4.5**: Append the governance section to `README.md`
+- [ ] **Task 4.5**: Append the governance section to `README.md`
   - Description: Add a `## License` section and a `## Contributing` section near the end of `README.md`, plus a license badge next to the existing npm badges. Link `LICENSE`, `CONTRIBUTING.md`, `CODE_OF_CONDUCT.md`, and `SECURITY.md`. Do not modify any other README content — positioning changes belong to a different IP.
   - Files: `README.md`
   - Depends on: Task 1.1, Task 2.1, Task 2.2, Task 2.3

package/dist/docs/versioned/next/tasks/positioning-django-rails-universal.md

@@ -13,19 +13,19 @@ See: [`docs/implementationPlans/positioning-django-rails-universal.md`](../imple
 
 ## Phase 1: Canonical copy
 
-- [x] **Task 1.1**: Write `docs/explanation/positioning.md`
+- [ ] **Task 1.1**: Write `docs/explanation/positioning.md`
   - Description: New explainer containing five clearly-labeled copy blocks in fenced code blocks (so they can be copied verbatim without markdown rendering surprises): `tagline` (one line), `elevator` (2–3 sentences), `pillars` (three bullets, in the order batteries-included / universal-by-default / AI-native), `aiPillar` (2–3 sentences naming both AI layers per IP question PO7 — the MCP tool layer and the `/terreno-*` SDLC pipeline process layer), and `pitch` (~150 words). Then a "Why the Django/Rails analogy" section, then the honest comparison table from the IP. Then a "Language rules" section restating the four rules from the program doc (lead with the analogy, say "universal app", never claim unshipped features, keep superlatives off reference pages) plus a fifth: never describe one AI layer without the other.
   - Files: `docs/explanation/positioning.md` (new)
   - Depends on: none
   - Acceptance: five fenced copy blocks present and labeled; the `aiPillar` block names both the MCP tools and the `/terreno-*` pipeline; comparison table has at least eight rows including at least three honest gaps with IP links; language rules section has all five rules.
 
-- [x] **Task 1.2**: Verify every claim in the comparison table
+- [ ] **Task 1.2**: Verify every claim in the comparison table
   - Description: For each row of the comparison table, confirm the Terreno side exists by finding it in source: `modelRouter` in `api/src/api.ts`, admin packages, `Permissions` in `api/src/permissions.ts`, Better Auth in `api/src/betterAuth*.ts`, MCP tools in `mcp-server/src/tools.ts`, and the SDLC pipeline in `plugins/terreno-planning/skills/`. For each "not shipped" row (background jobs, SSR, RBAC), confirm it is genuinely absent and link the IP or roadmap item tracking it. Correct any row that turns out to be wrong.
   - Files: `docs/explanation/positioning.md`
   - Depends on: Task 1.1
   - Acceptance: every "shipped" row cites a source path; the generator row cites both `mcp-server/src/tools.ts` and `plugins/terreno-planning/`; every "not shipped" row links an IP file that exists in `docs/implementationPlans/`.
 
-- [x] **Task 1.3**: Gate the pipeline claim on its portability work
+- [ ] **Task 1.3**: Gate the pipeline claim on its portability work
   - Description: The `/terreno-*` pipeline currently only runs inside this monorepo (see [`agentic-sdlc-plugin`](../implementationPlans/agentic-sdlc-plugin.md), "It only works here"). Do not publish positioning copy that implies consumers can use it until that IP's Phase 2 is complete. Check the state of `agentic-sdlc-plugin` Task 2.5 before writing the `aiPillar` block; if portability is not done, write the block describing the tool layer only and add a `TODO` in the IP to revisit, rather than making a claim that fails on first use.
   - Files: `docs/explanation/positioning.md`
   - Depends on: Task 1.1
@@ -87,7 +87,7 @@ See: [`docs/implementationPlans/positioning-django-rails-universal.md`](../imple
   - Depends on: Task 1.1
   - Acceptance: every published package has a `description` matching the pattern, plus `repository`, `homepage`, and `bugs` fields; `bun install` still resolves cleanly.
 
-- [x] **Task 5.2**: Document the GitHub repository metadata
+- [ ] **Task 5.2**: Document the GitHub repository metadata
   - Description: The repo description and topics cannot be set from a commit. Add a "Repository metadata" subsection to `docs/explanation/positioning.md` giving the exact description string (the short tagline variant from PO1 option C) and the exact topic list to set: `typescript`, `react-native`, `expo`, `express`, `mongoose`, `framework`, `mcp`, `ai`, `universal-apps`, `full-stack`. Mark it as a maintainer action.
   - Files: `docs/explanation/positioning.md`
   - Depends on: Task 1.1

package/dist/docs/versioned/next/tasks/public-roadmap-github.md

@@ -13,19 +13,19 @@ See: [`docs/implementationPlans/public-roadmap-github.md`](../implementationPlan
 
 ## Phase 1: Discussions
 
-- [x] **Task 1.1**: Document Discussion category setup
+- [ ] **Task 1.1**: Document Discussion category setup
   - Description: Create `docs/explanation/roadmap-process.md`. Start with a "Maintainer setup" section listing the seven Discussion categories from the IP with their exact names, formats (Announcement / Question-Answer / Open-ended), descriptions, and display order. For each, include the description text to paste into the GitHub UI (one to two sentences, written for outside users). Note that Discussions must first be enabled in Settings → General → Features.
   - Files: `docs/explanation/roadmap-process.md` (new)
   - Depends on: none
   - Acceptance: all seven categories are listed with name, format, description, and order; the Announcements category is marked maintainers-only.
 
-- [x] **Task 1.2**: Write the pinned intro posts
+- [ ] **Task 1.2**: Write the pinned intro posts
   - Description: In `docs/explanation/roadmap-process.md`, add a "Pinned posts" section containing the full markdown body for one pinned post per category. Each should say what belongs there, what does not, and where to go instead. The Ideas post must explain that ideas are the intake funnel and that maintainers promote them to issues. The Agents & AI post must point at the MCP setup docs and the skills directory. The Q&A post must link `docs/how-to/` and note that recurring questions become how-to guides.
   - Files: `docs/explanation/roadmap-process.md`
   - Depends on: Task 1.1
   - Acceptance: seven post bodies exist, each under 200 words, each naming an alternative destination for off-topic content.
 
-- [x] **Task 1.3**: Add Discussion templates
+- [ ] **Task 1.3**: Add Discussion templates
   - Description: Create `.github/DISCUSSION_TEMPLATE/rfc.yml` with fields: title guidance, Summary (required), Motivation (required), Detailed design (required), Alternatives considered (required), Drawbacks, Unresolved questions, and a checkbox acknowledging that accepted RFCs become IPs in `docs/implementationPlans/`. Create `.github/DISCUSSION_TEMPLATE/ideas.yml` with: Problem you are hitting (required), What you tried, Rough idea for a solution, and Would you be willing to help implement. Both must set the correct `labels:` and target the right category via the filename convention.
   - Files: `.github/DISCUSSION_TEMPLATE/rfc.yml` (new), `.github/DISCUSSION_TEMPLATE/ideas.yml` (new)
   - Depends on: Task 1.1
@@ -33,13 +33,13 @@ See: [`docs/implementationPlans/public-roadmap-github.md`](../implementationPlan
 
 ## Phase 2: Project board
 
-- [x] **Task 2.1**: Document Project board setup
+- [ ] **Task 2.1**: Document Project board setup
   - Description: Add a "Project board" section to `docs/explanation/roadmap-process.md` specifying: the Project name (`Terreno Roadmap`), whether it is repo- or org-level, the six fields with their exact types and option values from the IP, and the four views with their layout, grouping, and filters. Include the `gh project` commands a maintainer can run for the parts the CLI supports, and mark the rest as UI-only.
   - Files: `docs/explanation/roadmap-process.md`
   - Depends on: Task 1.1
   - Acceptance: all six fields and four views are specified precisely enough to recreate without further decisions; option values match the IP tables exactly.
 
-- [x] **Task 2.2**: Write the tracking-issue bodies for this program's IPs
+- [ ] **Task 2.2**: Write the tracking-issue bodies for this program's IPs
   - Description: Create `docs/explanation/roadmap-seed-issues.md` containing one ready-to-paste issue body per IP listed in `docs/implementationPlans/oss-launch-program.md`. Each body must include: a one-paragraph summary written for an outside reader (not internal shorthand), a link to the IP file, a link to the task file, the RTK deprecation flag, the dependencies, and the labels and Project field values to set (`Area`, `Target`, `Impact`, `IP`). Read each IP file to write its summary — do not paraphrase from the program index alone.
   - Files: `docs/explanation/roadmap-seed-issues.md` (new)
   - Depends on: Task 2.1
@@ -47,19 +47,19 @@ See: [`docs/implementationPlans/public-roadmap-github.md`](../implementationPlan
 
 ## Phase 3: Labels and triage
 
-- [x] **Task 3.1**: Define the label set as data
+- [ ] **Task 3.1**: Define the label set as data
   - Description: Create `.github/labels.yml` listing every label from the IP taxonomy with `name`, `color`, and `description`. Use a consistent color family per prefix (for example one hue for `area:`, another for `type:`, another for `status:`, and distinct colors for the bare labels). Add a "Labels" section to `docs/explanation/roadmap-process.md` explaining that `.github/labels.yml` is the source of truth and how to apply it (`gh label create` loop or a label-sync action), plus which GitHub default labels to delete.
   - Files: `.github/labels.yml` (new), `docs/explanation/roadmap-process.md`
   - Depends on: Task 1.1
   - Acceptance: `.github/labels.yml` parses as valid YAML and contains every label in the IP taxonomy table with no duplicates; colors are valid six-digit hex without `#`.
 
-- [x] **Task 3.2**: Add the triage workflow
+- [ ] **Task 3.2**: Add the triage workflow
   - Description: Create `.github/workflows/triage.yml`. On `issues: [opened]`, add the `status:needs-triage` label. Then read the issue body for the package dropdown value rendered by the issue forms and map it to the matching `area:*` label (for example `@terreno/api` → `area:api`, `docs` → `area:docs`). Implement the mapping in an inline `actions/github-script` step with an explicit lookup object; if no match is found, add no area label and leave a comment asking the reporter to specify. Validate required inputs before use per the repo convention.
   - Files: `.github/workflows/triage.yml` (new)
   - Depends on: Task 3.1
   - Acceptance: workflow parses as valid YAML; the mapping object covers every option in `bug_report.yml`'s package dropdown; the no-match path does not throw.
 
-- [x] **Task 3.3**: Document the backfill triage pass
+- [ ] **Task 3.3**: Document the backfill triage pass
   - Description: Add a "One-time backfill" section to `docs/explanation/roadmap-process.md` describing how to triage existing open issues and PRs onto the new taxonomy: run `gh issue list --state open --limit 200 --json number,title,labels`, assign one `area:` and one `type:` label each, add anything still relevant to the board with `Status = Inbox`, and close or label `status:wontfix` anything stale beyond six months. Include the read-only `gh` commands for producing the working list.
   - Files: `docs/explanation/roadmap-process.md`
   - Depends on: Task 3.1
@@ -67,25 +67,25 @@ See: [`docs/implementationPlans/public-roadmap-github.md`](../implementationPlan
 
 ## Phase 4: Roadmap generation
 
-- [x] **Task 4.1**: Write the roadmap generator
+- [ ] **Task 4.1**: Write the roadmap generator
   - Description: Create `scripts/generate-roadmap.ts` (Bun, TypeScript, `const` arrow functions with explicit return types, no new dependencies). It queries the GitHub GraphQL API for the `Terreno Roadmap` ProjectV2 items and their field values, then writes `ROADMAP.md`: a header explaining that the board is the source of truth and that no dates are promised, then sections grouped by `Target` (current release first, then `Next`, then `Future`), and within each, subsections by `Area`. Each item renders as a bullet with its title, issue link, `Impact`, and an IP link when the `IP` field is set. Exclude items with `Status` of `Declined`. Read the token from `GITHUB_TOKEN` and the project number from `TERRENO_PROJECT_NUMBER`; fail with a clear message listing missing variables when either is absent. Use Luxon for the generated-at timestamp.
   - Files: `scripts/generate-roadmap.ts` (new), `package.json` (add a `roadmap:generate` script)
   - Depends on: Task 2.1
   - Acceptance: running with both env vars unset prints an error naming both and exits non-zero; with a valid token it writes a `ROADMAP.md` matching the described structure; `bun run lint` passes.
 
-- [x] **Task 4.2**: Add the roadmap workflow
+- [ ] **Task 4.2**: Add the roadmap workflow
   - Description: Create `.github/workflows/roadmap-generate.yml` running on `schedule` (daily) and `workflow_dispatch`. Validate `GITHUB_TOKEN`/PAT and `TERRENO_PROJECT_NUMBER` at job start with the repo's fail-fast pattern. Run `bun run roadmap:generate`, then commit and push `ROADMAP.md` only if `git diff --quiet` reports changes. Use a bot identity for the commit.
   - Files: `.github/workflows/roadmap-generate.yml` (new)
   - Depends on: Task 4.1
   - Acceptance: workflow parses as valid YAML; the secret-validation step lists every required variable; the commit step is conditional on a real diff.
 
-- [x] **Task 4.3**: Seed `ROADMAP.md` and link it
+- [ ] **Task 4.3**: Seed `ROADMAP.md` and link it
   - Description: Commit an initial hand-written `ROADMAP.md` (the generator will overwrite it later) built from the IPs in `docs/implementationPlans/oss-launch-program.md` plus the active plans in `PLAN_INDEX.md`. Add a note at the top that it is generated from the Project board. Link it from `README.md` and add it to the docs site sidebar in `website/docusaurus.config.ts` (or the sidebars file if navigation is defined there — check both).
   - Files: `ROADMAP.md` (new), `README.md`, `website/docusaurus.config.ts` or `website/sidebars.ts`
   - Depends on: Task 4.1
   - Acceptance: `ROADMAP.md` lists every IP in the program with a `Target`; the docs site builds (`bun run website:build`) with the new nav entry; the README links it.
 
-- [x] **Task 4.4**: Add the docs feedback footer link
+- [ ] **Task 4.4**: Add the docs feedback footer link
   - Description: In `website/docusaurus.config.ts`, add a footer link (or theme config item) pointing at the Docs feedback Discussions category. If Docusaurus's `editUrl` mechanism is the better fit for per-page feedback, add the discussion link alongside the existing `editUrl` rather than replacing it.
   - Files: `website/docusaurus.config.ts`
   - Depends on: Task 1.1
@@ -93,19 +93,19 @@ See: [`docs/implementationPlans/public-roadmap-github.md`](../implementationPlan
 
 ## Phase 5: Linear bridge
 
-- [x] **Task 5.1**: Document the Linear bridge rules
+- [ ] **Task 5.1**: Document the Linear bridge rules
   - Description: Add a "Linear bridge" section to `docs/explanation/roadmap-process.md` covering: which artifacts live where (GitHub = public discussion, issues, roadmap state; Linear = sprint execution; `docs/implementationPlans/` = design), the one-way GitHub → Linear intake triggered by the `tracked` label, the rule that Linear status is not synced back and that GitHub state changes via `Fixes #NNN` on merge, how internally-originated public work gets a manual GitHub issue, and an explicit statement that internal-only Linear work is never mirrored. Explain *why* status is not two-way synced.
   - Files: `docs/explanation/roadmap-process.md`
   - Depends on: Task 3.1
   - Acceptance: the section states the direction of every sync, names the trigger label, and gives the reason two-way status sync was rejected.
 
-- [x] **Task 5.2**: Document the intake flow in `CONTRIBUTING.md`
+- [ ] **Task 5.2**: Document the intake flow in `CONTRIBUTING.md`
   - Description: Add a "How work gets planned" section to `CONTRIBUTING.md`, under 30 lines: file an Ideas discussion → maintainer promotes to an issue → issue is triaged onto the roadmap board → substantial work gets an IP → implementation. Add the RFC path for public API changes and new packages. Link `ROADMAP.md`, the Discussions categories, and `docs/implementationPlans/README.md`.
   - Files: `CONTRIBUTING.md`
   - Depends on: Task 5.1
   - Acceptance: the section is under 30 lines, links all three destinations, and matches the flow diagram in the IP.
 
-- [x] **Task 5.3**: Add the release announcement step
+- [ ] **Task 5.3**: Add the release announcement step
   - Description: Edit `.rulesync/skills/release/SKILL.md` to add a step: after publishing a release that includes breaking changes or deprecations, post a discussion in the Announcements category summarizing the change, linking the changelog section and the relevant upgrade note in `mcp-server/src/docs/upgrades/`. Regenerate mirrors with `bun run rules`.
   - Files: `.rulesync/skills/release/SKILL.md` plus generated mirrors
   - Depends on: Task 1.1

package/dist/docs/versioned/next/tasks/rtk-to-syncdb-migration-docs.md

@@ -2,9 +2,9 @@
 
 See: [`docs/implementationPlans/rtk-to-syncdb-migration-docs.md`](../implementationPlans/rtk-to-syncdb-migration-docs.md)
 
-**RTK deprecation flag:** **Blocked.** Do not start any task in this file until a `@terreno/syncdb` package is merged into `master`. PR [#869](https://github.com/flourishhealth/terreno/pull/869) was the delivery vehicle but is **closed, not merged** (checked 2026-08-09) and no `syncdb/` package exists on `master`. Verify with `git log --oneline master | rg -i syncdb` before beginning.
+**RTK deprecation flag:** **Unblocked on `release-56.0.0`.** `@terreno/syncdb` lives on the `release-56.0.0` launch branch (`syncdb/`), not `master` and not PR #869 (closed). This work is authored on and targets `release-56.0.0`. Verify with `git ls-tree origin/release-56.0.0 --name-only | rg -i syncdb`.
 
-**Migration strategy (decision M6, reaffirmed 2026-08-09):** this IP ships *context for an AI agent to perform the migration*, not a migration script or codemod. The deliverables are the syncdb reference, a guide built from verified before/after pairs, and the `upgrading-terreno` skill that drives an agent through a per-screen `USE_SYNCDB` rollout. See the "Migration strategy: AI-context-first" section in the IP. Do not author a codemod as the primary path.
+**Migration strategy (decision M6, reaffirmed 2026-08-09):** ship *context for an AI agent to perform the migration* (syncdb reference + verified before/after pairs + the `upgrading-terreno` skill), not a codemod. See the "Migration strategy: AI-context-first" section in the IP.
 
 ## Instructions for the implementing agent
 
@@ -16,19 +16,19 @@ See: [`docs/implementationPlans/rtk-to-syncdb-migration-docs.md`](../implementat
 
 ## Phase 1: Reconcile with merged #869
 
-- [ ] **Task 1.1**: Inventory the merged syncdb public API
+- [x] **Task 1.1**: Inventory the merged syncdb public API
   - Description: Read the merged `syncdb/src/index.ts` and every module it re-exports. Produce `docs/implementationPlans/syncdb-api-inventory.md` (a temporary working document, deleted in Task 6.6) listing every exported symbol with its signature, a one-line description, and the source file. Separately list: the client config options, every React hook, every client method, the conflict-resolution API, the sync-status API, and the codegen CLI surface. Also record whether local-first is the only mode or an opt-in (IP blocking question M7) and whether `bun run sdk` still works (M5).
   - Files: `docs/implementationPlans/syncdb-api-inventory.md` (new, temporary)
   - Depends on: PR #869 merged
   - Acceptance: every symbol in the inventory is greppable in `syncdb/src/`; M5 and M7 are answered with a file-and-line citation.
 
-- [ ] **Task 1.2**: Correct the IP surface map against reality
+- [x] **Task 1.2**: Correct the IP surface map against reality
   - Description: Compare the inventory from Task 1.1 to the "Documentation surface map" and "Known RTK-shaped surfaces" tables in the IP and in `docs/implementationPlans/oss-launch-program.md`. Update both files where reality differs. Add rows for any surface #869 introduced that neither table anticipated (for example new socket events, new backend routes under `api/src/sync/`, `excludeArchivedPlugin`, tenant/organization permission helpers). Report the deltas in the PR body.
   - Files: `docs/implementationPlans/rtk-to-syncdb-migration-docs.md`, `docs/implementationPlans/oss-launch-program.md`
   - Depends on: Task 1.1
   - Acceptance: both surface maps match the merged code; every added row cites a file path; the PR body lists what changed from the pre-merge hypothesis.
 
-- [ ] **Task 1.3**: Capture the reference migration from #869
+- [x] **Task 1.3**: Capture the reference migration from #869
   - Description: `git log` the #869 merge and extract the diff for `example-frontend` — the actual RTK → syncdb migration of the todos flow. Save the before/after pairs (store setup, one read hook, one write hook, conflict UI, sync status UI) into the working inventory doc. These become the code samples for the migration guide. Note anything the reference migration did *not* cover (auth, feature flags, other screens).
   - Files: `docs/implementationPlans/syncdb-api-inventory.md`
   - Depends on: Task 1.1
@@ -36,7 +36,7 @@ See: [`docs/implementationPlans/rtk-to-syncdb-migration-docs.md`](../implementat
 
 ## Phase 2: Reference documentation
 
-- [ ] **Task 2.1**: Write `docs/reference/syncdb.md`
+- [x] **Task 2.1**: Write `docs/reference/syncdb.md`
   - Description: New reference page following the structure of `docs/reference/rtk.md` (read it first for tone and section ordering). Sections: installation and peer dependencies; `createSyncDbClient` config table (every option, type, default, description); provider setup; read hooks; mutation hooks; conflict API; sync-status API; the Redux bridge if it shipped; codegen; environment variables. Every option in the config table must come from the inventory. Include a runnable example per hook.
   - Files: `docs/reference/syncdb.md` (new)
   - Depends on: Task 1.1
@@ -56,25 +56,25 @@ See: [`docs/implementationPlans/rtk-to-syncdb-migration-docs.md`](../implementat
 
 ## Phase 3: Migration guide
 
-- [ ] **Task 3.1**: Draft the migration guide skeleton with verified samples
+- [x] **Task 3.1**: Draft the migration guide skeleton with verified samples
   - Description: Create `docs/how-to/migrate-rtk-to-syncdb.md` with the eleven sections from the IP. Populate sections 2–4 (install/configure, reads, writes) using the before/after pairs captured in Task 1.3. For section 4, explicitly list the RTK-era code that should be **deleted** after migrating (manual optimistic updates, `isLoading` spinners on writes, refetch-after-mutate patterns) — this is the part consumers get wrong.
   - Files: `docs/how-to/migrate-rtk-to-syncdb.md` (new)
   - Depends on: Task 1.3, Task 2.1
   - Acceptance: sections 1–4 complete; every code block traceable to a real file; section 4 has a "delete this" list.
 
-- [ ] **Task 3.2**: Document conflicts and sync status
+- [x] **Task 3.2**: Document conflicts and sync status
   - Description: Complete sections 5 and 6. Explain what a conflict is in this system, exactly when one is produced (cite the server-side 409/nack path in `api/src/sync/`), the two v1 resolution strategies, and the minimum UI a consumer must build. For sync status, show how to replace request-level loading UX with sync-state UX. Use the `example-frontend` implementation as the reference; if it has no conflict UI, say so and link a follow-up issue rather than inventing one.
   - Files: `docs/how-to/migrate-rtk-to-syncdb.md`
   - Depends on: Task 3.1
   - Acceptance: the conflict trigger is cited to a source file; both strategies documented; the minimum-UI requirement is concrete (named components or hooks).
 
-- [ ] **Task 3.3**: Document the auth migration
+- [x] **Task 3.3**: Document the auth migration
   - Description: Complete section 7. Cover: `generateAuthSlice` → Better Auth session, token storage differences on native versus web, the socket auth handshake changes from #869 (pluggable socket auth, Better Auth bearer sessions, session revalidation, `sync:auth-expired`), required backend config (`BETTER_AUTH_SECRET`, `BETTER_AUTH_URL`, `trustedOrigins`), and the cross-domain cookie requirements. State clearly that auth can be migrated *before* the data layer (IP question M3) and give the two-step order.
   - Files: `docs/how-to/migrate-rtk-to-syncdb.md`
   - Depends on: Task 3.2
   - Acceptance: every env var named exists in `docs/reference/environment-variables.md` after this IP; the `sync:auth-expired` event is cited to source; the two-step order is stated in the first paragraph of the section.
 
-- [ ] **Task 3.4**: Document codegen, feature flags, rollback, and the checklist
+- [x] **Task 3.4**: Document codegen, feature flags, rollback, and the checklist
   - Description: Complete sections 8–11. Codegen: whether `bun run sdk` is unchanged (answer from Task 1.1), what the generated file looks like now, and the update to `openapi-config.ts`. Feature flags: how the OpenFeature provider is fed post-migration. Rollback: per-screen rollback via `USE_SYNCDB` and what state is left behind (IndexedDB contents, outbox entries) when rolling back. Checklist: a copy-pasteable ordered checklist covering everything in sections 1–10.
   - Files: `docs/how-to/migrate-rtk-to-syncdb.md`, `docs/how-to/README.md`
   - Depends on: Task 3.3