@terreno/mcp 57.20.0 → 58.0.0-beta.1

package/src/docs/versioned/57.2.0/tasks/examples-demo-coverage.md

@@ -1,113 +0,0 @@
-# Task List: Examples, Demo, and Test Coverage
-
-See: [`docs/implementationPlans/examples-demo-coverage.md`](../implementationPlans/examples-demo-coverage.md)
-
-**RTK deprecation flag:** **Partial.** Tasks marked `[RTK]` touch the example apps' data layer and must wait for PR #869. Demo-app and coverage-infrastructure tasks are `@terreno/ui`-only or CI-only and are safe to implement now.
-
-## Instructions for the implementing agent
-
-- Derive the missing-component list from `ui/src/index.tsx` at implementation time. The list in the IP is a snapshot and will be stale.
-- When a component turns out to be hard to demo because of a bug, fix the bug and note it — that is a valuable side effect of this work, not a distraction.
-- Per IP decision E4, enforce the existing 95% threshold immediately. Packages below threshold must catch up before CI passes — do not introduce a ratchet floors file.
-- Follow the existing story conventions: read several files in `demo/stories/` first and match their structure, and use only `@terreno/ui` components inside stories.
-- Run `bun run lint`, `bun run demo:compile`, and `bun run ui:test` before each commit.
-
-## Phase 1: Demo coverage — audit and P0
-
-- [ ] **Task 1.1**: Audit demo story coverage
-  - Description: Extract the list of components exported from `ui/src/index.tsx`. Extract the list of components registered in `demo/demoConfig.tsx`. Produce the difference. Classify each missing component as P0 (demonstrates a pillar: AI, auth, responsive layout), P1 (common in real apps), P2 (uncommon), or "cannot be demoed in isolation" with a reason. Report the full table in the PR body.
-  - Files: none (findings in the PR body)
-  - Depends on: none
-  - Acceptance: the table is derived from the two actual source files; every missing component has a classification; every "cannot be demoed" entry has a stated reason.
-
-- [ ] **Task 1.2**: Add P0 stories
-  - Description: Write stories for every P0 component from Task 1.1 (expected to include `GPTChat`, `SocialLoginButton`, and `SplitPage` — confirm against the audit). Each story shows multiple states where the component supports them: default, loading, error, disabled, and any variant enumerations. `GPTChat` needs a story that works without a live backend — use a static message list rather than wiring a real AI call. `SocialLoginButton` needs all three providers and both variants. `SplitPage` needs a story demonstrating the responsive breakpoint behavior. Register each in `demoConfig.tsx`.
-  - Files: `demo/stories/*.stories.tsx` (new), `demo/demoConfig.tsx`
-  - Depends on: Task 1.1
-  - Acceptance: every P0 component has a story reachable in the running demo (`bun run demo:start`, port 8085); each shows at least two states; `GPTChat`'s story renders with no backend running; `bun run demo:compile` passes.
-
-- [ ] **Task 1.3**: Add the demo coverage check
-  - Description: Create `scripts/check-demo-coverage.ts` (Bun, TypeScript, `const` arrow functions with explicit return types). It parses the export list from `ui/src/index.tsx` and the registered components from `demo/demoConfig.tsx`, then fails with a list of unstoried components. Support an allowlist file or an in-script allowlist where each entry requires a comment explaining why the component cannot be demoed. Add a `check:demo-coverage` script to the root `package.json` and wire it into `.github/workflows/ui-demo-ci.yml`.
-  - Files: `scripts/check-demo-coverage.ts` (new), `package.json`, `.github/workflows/ui-demo-ci.yml`
-  - Depends on: Task 1.2
-  - Acceptance: the check passes with the current allowlist; adding a new export to `ui/src/index.tsx` without a story makes it fail and name the component; the CI job runs it.
-
-- [ ] **Task 1.4**: Make the demo's `test:ci` real
-  - Description: `demo/package.json`'s `test:ci` is currently `echo 'No tests'`. Replace it with something meaningful: at minimum a smoke test that every registered story renders without throwing, using the `renderWithTheme` helper from `@terreno/ui`'s test utilities. This catches the most common demo breakage — a story that crashes after a component's props change.
-  - Files: `demo/package.json`, `demo/**` test files (new)
-  - Depends on: Task 1.2
-  - Acceptance: `bun run --filter 'terreno-demo' test:ci` runs real tests and passes; deliberately breaking one story's props makes it fail; the test iterates the registered stories rather than a hardcoded list.
-
-## Phase 2: Remaining demo stories
-
-- [ ] **Task 2.1**: Add P1 stories
-  - Description: Write stories for every P1 component from the Task 1.1 audit (expected to include `ActionSheet`, `ModalSheet`, `FilePickerButton`, and `Image`). Interactive components need a story that can actually be triggered from the demo UI, not just a static render. Register each in `demoConfig.tsx`.
-  - Files: `demo/stories/*.stories.tsx` (new), `demo/demoConfig.tsx`
-  - Depends on: Task 1.3
-  - Acceptance: every P1 component has a story; interactive components can be opened and dismissed in the running demo; `bun run demo:compile` passes.
-
-- [ ] **Task 2.2**: Add P2 stories and close the allowlist
-  - Description: Write stories for the remaining P2 components. For any component that genuinely cannot be demoed in isolation, add it to the allowlist with a specific reason (not "hard to demo"). The goal is an empty or near-empty gap list with a justified allowlist.
-  - Files: `demo/stories/*.stories.tsx` (new), `demo/demoConfig.tsx`, the allowlist
-  - Depends on: Task 2.1
-  - Acceptance: `bun run check:demo-coverage` passes with no unstoried, unallowlisted components; every allowlist entry has a specific reason.
-
-## Phase 3: Coverage enforcement
-
-- [ ] **Task 3.1**: Measure current coverage per package
-  - Description: Run every published package's `test:coverage` on a clean `master` and record the actual coverage. Report which packages are below the 95% threshold in the PR body. This is a planning step — do not lower the threshold or add exemptions.
-  - Files: none (findings in the PR body)
-  - Depends on: none
-  - Acceptance: every published package has a measured coverage value; packages below 95% are listed with their gap.
-
-- [ ] **Task 3.2**: Wire the threshold into every package CI
-  - Description: Add `scripts/check-coverage.ts` (default 95% threshold) to every published package's CI — either the existing dedicated workflow or the new matrix job from Task 3.3. Packages below threshold when this lands will fail CI until catch-up work merges; track that in the implementation PR.
-  - Files: `.github/workflows/ui-ci.yml`, `ai-ci.yml`, `admin-spa-ci.yml`, `.github/workflows/packages-ci.yml`, package `package.json` files as needed
-  - Depends on: Task 3.1
-  - Acceptance: every published package's CI runs the coverage check at 95%; no package has a permanent exemption.
-
-- [ ] **Task 3.3**: Add the matrix CI job for uncovered packages
-  - Description: Per IP question E3, create `.github/workflows/packages-ci.yml` with a matrix over the published packages that lack a dedicated workflow (`admin-backend`, `feature-flags`, `api-health`, `test` — verify the current set against `.github/workflows/`). Each matrix entry runs compile, lint, tests, and the coverage check. Use path filters so the job only runs for the affected package where practical. Follow the repo's required-input validation convention.
-  - Files: `.github/workflows/packages-ci.yml` (new)
-  - Depends on: Task 3.2
-  - Acceptance: the workflow parses as valid YAML; the matrix covers exactly the published packages without their own workflow; each entry runs compile, lint, test, and coverage at 95%.
-
-- [ ] **Task 3.4**: Catch up packages below threshold
-  - Description: For each package measured below 95% in Task 3.1, add tests until `scripts/check-coverage.ts` passes. This may be a separate PR if the gap is large; do not merge the CI wiring until every package passes or the IP owner explicitly defers a package with a linked issue.
-  - Files: package test files as needed
-  - Depends on: Task 3.2
-  - Acceptance: `bun run check-coverage` (or per-package equivalent) passes at 95% for every published package.
-
-## Phase 4: Codecov
-
-- [ ] **Task 4.1**: Configure Codecov
-  - Description: Add `codecov.yml` configuring per-package flags so each package's coverage is reported separately, a target of "auto" with a small allowed threshold so trivial deltas do not fail PRs, and comment settings that post the delta on pull requests. Add the upload step to every package CI workflow. Note in the file where the `CODECOV_TOKEN` secret must be configured (a maintainer action for a public repo, though public repos often need no token — verify current Codecov requirements before documenting).
-  - Files: `codecov.yml` (new), every package CI workflow
-  - Depends on: Task 3.4
-  - Acceptance: `codecov.yml` is valid; every package workflow uploads with a distinct flag; the token requirement is documented accurately for a public repo.
-
-- [ ] **Task 4.2**: Add the coverage badge
-  - Description: Add a Codecov badge to `README.md` next to the existing npm and license badges. Add a "Testing and coverage" section to `CONTRIBUTING.md` explaining: the 95% coverage expectation for new code, that coverage must not drop in a PR, and how to run coverage locally per package.
-  - Files: `README.md`, `CONTRIBUTING.md`
-  - Depends on: Task 4.1
-  - Acceptance: the badge renders and reflects real coverage; the contributing section explains the 95% threshold and gives the local command.
-
-## Phase 5: Example feature matrix
-
-- [ ] **Task 5.1**: `[RTK]` Audit example app feature coverage
-  - Description: Build the capability matrix from the IP by reading `example-backend/src/` and `example-frontend/app/`. Resolve every `?`: does an example actually exercise AI structured output, Better Auth, and (after #869) syncdb local-first behavior? For each capability, cite the file that exercises it or record it as a gap. Include capabilities that are not shipped (RBAC, background jobs) marked as such with links to their IPs.
-  - Files: `docs/explanation/example-coverage.md` (new)
-  - Depends on: PR #869 merged
-  - Acceptance: no `?` remains; every "yes" cites a file path; every gap is explicit; unshipped capabilities link their IPs.
-
-- [ ] **Task 5.2**: `[RTK]` Fill the highest-value example gaps
-  - Description: For each gap found in Task 5.1, either add the example or record it as a known gap with an issue. Prioritize capabilities the launch documentation depends on — if a tutorial or reference page describes something with no working example, that is the highest priority because the docs claim will be tested by readers. Do not add examples for unshipped features.
-  - Files: `example-backend/src/**`, `example-frontend/app/**`, `docs/explanation/example-coverage.md`
-  - Depends on: Task 5.1
-  - Acceptance: every gap that a launch document depends on is filled with a working example; remaining gaps are recorded with issue links; both example apps still pass their CI.
-
-- [ ] **Task 5.3**: Link the matrix into the contribution process
-  - Description: Add a note to `CONTRIBUTING.md` and the PR template: when adding a framework capability, add or update the example that exercises it and update `docs/explanation/example-coverage.md`. This is what keeps the matrix true. Link the matrix from `docs/explanation/README.md`.
-  - Files: `CONTRIBUTING.md`, `.github/PULL_REQUEST_TEMPLATE.md`, `docs/explanation/README.md`
-  - Depends on: Task 5.1
-  - Acceptance: both the contributing guide and the PR template reference the requirement; the matrix is linked from the explanation index.

package/src/docs/versioned/57.2.0/tasks/feature-flags-openfeature.md

@@ -1,77 +0,0 @@
-# Feature Flags → OpenFeature — Task List
-
-See `docs/implementationPlans/feature-flags-openfeature.md` for full details.
-
-## Phase 0: Catalog & deps
-
-- [x] **0.1** Add `@openfeature/server-sdk`, `@openfeature/web-sdk`, `@openfeature/react-sdk`, `@openfeature/core` to the root `package.json` `catalog` (pin minor; check latest at time of work). Verify with `bun install` from root.
-
-## Phase 1: Backend OpenFeature integration
-
-- [x] **1.1** Add `@openfeature/server-sdk` (catalog version) to `feature-flags/package.json` dependencies. Run `bun install`.
-- [x] **1.2** Add `defaultVariant` field to `FeatureFlag` schema (`feature-flags/src/featureFlagModel.ts`) with description and validation. **No getter** — use a `pre("save")` hook that populates `defaultVariant` when undefined (boolean → "off"; variant → first variant key). Validation: if set, boolean must be `"on"`/`"off"`; variant must be one of `variants[].key`. Add `defaultVariant` to `featureFlagAdminConfig.listFields`.
-- [x] **1.3** Update `FeatureFlagDocument` type in `feature-flags/src/types.ts` with optional `defaultVariant`. Add `FlagDefinition` and `FlagConfigurationResponse` interfaces.
-- [x] **1.4** Create `feature-flags/src/openFeatureProvider.ts` exporting `MongoFeatureFlagProvider` implementing OpenFeature's `Provider` interface. Use `findOneOrNone` (per repo rule — never `findOne`). Returns `FLAG_NOT_FOUND` / `TYPE_MISMATCH` `ResolutionDetails` shapes for missing or wrong-type flags. Delegates the targeting math to existing `evaluateFlag()`.
-- [x] **1.5** Update `FeatureFlagsApp.register()` (`feature-flags/src/featureFlagsApp.ts`): construct provider, call `OpenFeature.setProvider(domain, provider)` (default domain `"feature-flags"`), register new `/flagConfiguration` route, keep `/evaluate` with `Deprecation: true` + `Sunset: <90d>` headers + one-shot warn log.
-- [x] **1.6** Add `buildFlagDefinition(flag, targetingKey, user, segments)` helper. **Critical filter**: `/flagConfiguration` matches today's `evaluateAllFlags` filter (`archived: $ne true, enabled: true`) — disabled flags are omitted entirely. Every returned `FlagDefinition` has `disabled: false`.
-- [x] **1.7** Update `FeatureFlagsOptions` type (`feature-flags/src/types.ts`) to add `liveUpdates` and `openFeatureDomain` fields.
-- [x] **1.8** Update `feature-flags/src/index.ts` to export `MongoFeatureFlagProvider`, `FlagDefinition`, `FlagConfigurationResponse`.
-- [x] **1.9** Add `feature-flags/src/tests/openFeatureProvider.test.ts` covering: boolean and variant resolution; disabled flag returns default + reason "DISABLED"; `TYPE_MISMATCH` on wrong-type call; `FLAG_NOT_FOUND` on missing flag; rule-match path; segment-match path; deterministic-hash path; missing `targetingKey`; variant default fallback; `resolveNumberEvaluation` and `resolveObjectEvaluation` return `FLAG_NOT_FOUND`.
-- [x] **1.10** Extend `feature-flags/src/tests/featureFlagsApp.test.ts`: `/flagConfiguration` returns the right shape for both flag types; **explicitly verifies disabled flags are OMITTED**; verifies `defaultVariant` flows through; verifies `/evaluate` still works AND now includes `Deprecation` + `Sunset` headers. Add `featureFlagModel.test.ts` (or extend existing tests) with: legacy doc (no `defaultVariant`) can be saved and the hook populates a default; explicit `defaultVariant: "on"` on boolean passes; `defaultVariant: "bad"` on boolean is rejected.
-- [x] **1.11** Run `bun run --filter=@terreno/feature-flags compile test lint`. Fix issues.
-
-## Phase 2: Frontend OpenFeature integration
-
-- [x] **2.0 (blocking spike)** Verify `@openfeature/react-sdk` works under React Native. Write a tiny `bun test` using `@testing-library/react-native` that wraps a component in `<OpenFeatureProvider>` with a `TypedInMemoryProvider` and asserts `useBooleanFlagValue("k", false)` returns `true` after `PROVIDER_READY`. If it fails on RN, fall back to importing only from `@openfeature/web-sdk` and writing a thin React adapter inside `@terreno/rtk` that uses `useSyncExternalStore` against the OF client's event emitter. Do not proceed to 2.1 until this is green.
-- [x] **2.1** Add `@openfeature/web-sdk` + `@openfeature/react-sdk` as **peerDependencies** (NOT direct deps) in `rtk/package.json`. Add `@openfeature/core` as a direct dep for types. Run `bun install` from root.
-- [x] **2.2** Create `rtk/src/useTerrenoFeatureFlags.ts`. Critical behaviors:
-  - RTK Query endpoint cache key includes `userId` so user switching invalidates cache.
-  - On data success, `await OpenFeature.setProvider(domain, new TypedInMemoryProvider(data))`; subscribe to `PROVIDER_READY` via `client.addHandler`.
-  - `isLoading` stays `true` until BOTH RTK has data AND `PROVIDER_READY` has fired (gated by a ref-tracked boolean).
-  - On `userId` change: `OpenFeature.setContext(domain, {targetingKey: userId})` BEFORE the refetch resolves.
-  - Module-level ref counter for provider lifetime; do not clear provider on individual unmount; clear only when count returns to zero (last consumer leaves).
-  - StrictMode safety: ref tracks in-flight `setProvider` promise to dedupe double-effect.
-  - If `options.socket` is provided, subscribe to `socketEventName ?? "featureFlagsChanged"` → `refetch()`. Cleanup on unmount.
-  - Return `{flags, isLoading, error, refetch, client}`.
-- [x] **2.3** Rewrite `rtk/src/useFeatureFlags.ts` as a BC wrapper over `useTerrenoFeatureFlags`. Preserve overloaded signature (`string | UseFeatureFlagsOptions`). `getFlag` uses `client.getBooleanValue(key, false)`. `getVariant` returns `null` when `!flags[key]` (the flag is disabled/missing — disabled flags are filtered out of `/flagConfiguration`); otherwise returns `client.getStringValue(key, "") || null`. Build `flatFlags: Record<string, boolean | string | null>` from the raw `FlagConfiguration` map by projecting each `FlagDefinition`: boolean → `variants[defaultVariant]`, variant → `defaultVariant`. Add explicit type tests.
-- [x] **2.4** Update `rtk/src/index.ts` to export `useTerrenoFeatureFlags` and its types. Do **not** re-export OpenFeature hooks (consumers add `@openfeature/react-sdk` directly).
-- [x] **2.5** Update `rtk/src/useFeatureFlags.test.ts` to match the new wire shape. Cover: legacy options shape (string), modern options shape (object), `skip`, `getFlag`/`getVariant` for boolean and variant flags, `null` on disabled/missing, timing logs preserved, **snapshot test** locking the `flatFlags` projection so `profile.tsx`'s render output is byte-identical to before.
-- [x] **2.6** Add `rtk/src/useTerrenoFeatureFlags.test.ts` covering: provider is set on success; `isLoading` stays `true` until `PROVIDER_READY`; domain isolation (default provider not affected); refetch path; no-op when `skip: true`; `userId` change triggers context + refetch + provider replacement; StrictMode double-mount does not double-set provider; ref count prevents premature provider clearing; socket event triggers refetch.
-- [x] **2.7** Run `bun run --filter=@terreno/rtk compile test lint`. Fix issues.
-
-## Phase 3: Live updates (opt-in)
-
-- [x] **3.1** In `FeatureFlagsApp.register()`, when `options.liveUpdates?.socketIoServer` is provided (accept either a value or a `() => Server | null` getter — example-backend's `io` is lazily initialized), start `FeatureFlag.watch([], {fullDocument: "updateLookup"})`. On each change, emit `featureFlagsChanged` (configurable event name) plus call `provider.emitConfigurationChanged()`. Log on stream `error`; one auto-reconnect attempt, then disable + warn.
-- [x] **3.2** Add `feature-flags/src/tests/featureFlagsApp.liveUpdates.test.ts`. Test approach: **mock `FeatureFlag.watch`** to return a fake `EventEmitter` with the change-stream interface (`on`, `close`). The tests do NOT spin up a replica-set Mongo. Cover: emission on insert/update/delete (via emitting fake change events), custom event name, error handler logs a warn, double-error disables the stream.
-- [x] **3.3** In `useTerrenoFeatureFlags`, when `options.socket` is provided, subscribe to `options.socketEventName ?? "featureFlagsChanged"` and call `refetch()` on each event. Cleanup on unmount. Acknowledge that the emit is global broadcast (all connected clients) — no PII in the payload.
-- [x] **3.4** Add a test in `useTerrenoFeatureFlags.test.ts` proving: when a fake `EventEmitter` socket emits the event, the hook refetches and OF consumers re-render.
-- [x] **3.5** Document the Mongoose replica-set requirement (production must use a replica set, including single-node replica set) and Socket.io wiring in `docs/how-to/add-feature-flags.md` (new "Live updates" section). Also document the broadcast scope (flag-key payload visible to every authenticated socket) — acceptable since flag keys ship to every authed client via `/flagConfiguration` anyway.
-
-## Phase 4: Example apps + docs + SDK regen
-
-- [x] **4.1** Update `example-backend` `FeatureFlagsApp` construction to pass `liveUpdates: {socketIoServer: () => io}` — use a getter, since `example-backend/src/websockets.ts:24` initializes `io` lazily during `connectToWebsockets`.
-- [x] **4.2** Update `example-backend/src/scripts/seed-feature-flags.ts`: add `defaultVariant` to each `SEED_FLAGS` entry (`"off"` for boolean flags; for the `profile-layout` variant flag, `"compact"`). **Bump the seed**: either add a `seedVersion` field to FeatureFlag (skip if too invasive) OR add an idempotent "patch missing defaultVariant" upsert at the top of the script that updates existing docs in dev DBs to populate the new field. Document the dev-db backfill in the migration note.
-- [x] **4.3** Update `example-frontend/app/_layout.tsx` to wrap children in `<OpenFeatureProvider domain="feature-flags">` and call `useTerrenoFeatureFlags(terrenoApi, {socket, userId})` once user is authenticated.
-- [x] **4.4** Update `example-frontend/app/(tabs)/profile.tsx`: add a small section that uses `useBooleanFlagDetails("dark-mode-toggle", false)` and renders `reason` alongside value — verifies OF metadata is plumbed through and proves the `reason` field shape downstream.
-- [x] **4.5** Add `example-frontend/types/openfeature.d.ts` demonstrating the type-safe flag keys augmentation. Reference it from the docs.
-- [ ] **4.6** Regenerate frontend SDK: `cd example-frontend && bun run sdk`. Verify the new endpoint is in `openApiSdk.ts` and document that consumers should NOT call the generated hook directly; use `useTerrenoFeatureFlags`/`useFeatureFlags` instead.
-- [x] **4.7** Update `docs/reference/feature-flags.md`: new endpoint shape, `MongoFeatureFlagProvider` export, `defaultVariant` field semantics, recommended OF hooks for new code, BC notes, **number/object flag types not supported** (always returns default), **type-safe flag keys drift warning**, dev-db backfill note for existing seeded flags.
-- [x] **4.8** Update `docs/how-to/add-feature-flags.md`: recommend OF hooks for new code; show `useFeatureFlags` only in a "BC / migration" section.
-- [x] **4.9** Add a short note at the top of `docs/implementationPlans/feature-flags.md` linking to this new IP.
-- [x] **4.10** Add `example-frontend/e2e/feature-flags.spec.ts` Playwright test:
-  - Login as admin
-  - PATCH a flag via `/feature-flags/flags/:id` (e.g., toggle `enabled` on `todo-summary-card`)
-  - Within ~5s, assert the example-frontend's todos screen shows/hides the summary card accordingly **without** a page reload
-  - Verifies the full live-update loop (change stream → socket emit → hook refetch → OF re-render)
-  - Skip the test if the test environment does not have a Mongo replica set (use `test.skip` with a clear message) so CI doesn't fail when devs run without one.
-- [ ] **4.11** Run full workspace check: `bun run lint && bun run compile && bun run test`. Run example stack manually (`bun run backend:dev` + `bun run frontend:web`) and verify the profile screen shows flags identical to before.
-
-## Definition of Done
-
-- All workspace tests pass.
-- `example-frontend` runs end-to-end with seeded flags, showing identical values to before the migration.
-- Admin edits to a flag (via the admin panel) propagate to an open example-frontend session within ~1 second without a manual refresh.
-- A consumer using only `useFeatureFlags(api)` requires zero code changes.
-- A consumer can now also use `useBooleanFlagValue("key", false)` directly from `@openfeature/react-sdk`.
-- Type-safe flag keys augmentation is documented and demonstrated in `example-frontend`.
-- The legacy `/evaluate` endpoint still works, returns the old shape, and includes a `Deprecation` header.

package/src/docs/versioned/57.2.0/tasks/infra-mcp.md

@@ -1,43 +0,0 @@
-# Tasks: Infrastructure MCP server (`@terreno/infra-mcp`)
-
-Plan: [docs/implementationPlans/infra-mcp.md](../implementationPlans/infra-mcp.md)
-Status: Blocked — Phase 1 RBAC wiring depends on the RBAC module PR ([rbac-permissions.md](../implementationPlans/rbac-permissions.md)). Scaffold/adapter tasks marked (unblocked) can start now.
-
-## Phase 1 — Read-only core
-
-- [ ] (unblocked) Scaffold `infra-mcp/` workspace package: package.json (catalog deps), tsconfig, biome, bun test setup, root workspace + catalog entries (zod 4, `@modelcontextprotocol/server`, `@better-auth/oauth-provider`, `@better-auth/mcp`)
-- [ ] (unblocked) `src/config.ts`: `defineInfraMcp` config schema (zod), secret resolution (env/Secret Manager), boot validation
-- [ ] (unblocked) `src/server.ts`: Express/TerrenoApp server with SDK v2 `/mcp` endpoint (`createMcpHandler`, `legacy: "stateless"`, `toNodeHandler`) + `/health`
-- [ ] (unblocked) `src/auth.ts`: Better Auth OAuth 2.1 setup — authorization server, RFC 9728 protected-resource metadata, bearer verification middleware; login page flow verified with Cursor and Claude Code
-- [ ] `src/access.ts`: `infraStatements`, default roles (`infra-readonly`, `infra-operator`), `createAccess` wiring, `Mcp-Name`-keyed authz middleware, per-user filtered `tools/list` (**blocked on RBAC PR**)
-- [ ] `src/models/infraAuditLog.ts` + audit middleware around `tools/call` (statuses: allowed/denied/confirmed/rejected/error; per-tool arg redaction)
-- [ ] (unblocked) Integration adapter types + registry (`src/integrations/types.ts`, `registry.ts`)
-- [ ] (unblocked) GCP native adapter (ADC): `gcp_query_logs`, `gcp_list_log_names`, `gcp_query_metrics`, `gcp_list_error_groups`, `gcp_list_cloud_run_services`, `gcp_get_cloud_run_service`
-- [ ] (unblocked) Sentry native adapter (REST + static token): `sentry_search_issues`, `sentry_get_issue`, `sentry_list_issue_events`, `sentry_get_event`
-- [ ] (unblocked) Mongo native adapter (read URI): `mongo_list_collections`, `mongo_collection_schema`, `mongo_find`, `mongo_aggregate` (reject `$out`/`$merge`). Extract the shared read-query/schema logic from `mcp-server/src/local/tools/databaseQuery.ts` + `databaseSchema.ts` into a reusable module both packages import — do not fork copies into infra-mcp (per architectural review)
-- [ ] Admin panel registration (`@terreno/admin-backend`): Users, InfraAuditLog (read-only)
-- [ ] Terraform: `infra_mcp_service` Cloud Run module instance, Artifact Registry, runtime SA with viewer/logging IAM only
-- [ ] Tests: authz matrix (role × tool × tools/list filtering), adapter handlers, audit records, legacy-client fallback
-- [ ] Deploy + end-to-end verification from a real MCP client; docs: `.cursor/rules/infra-mcp/00-infra-mcp.mdc`, AGENTS.md/CLAUDE.md package lists
-- [ ] Roadmap: open the tracking issue from [roadmap-seed-issues.md](../explanation/roadmap-seed-issues.md#infra-mcp) once the IP is Approved, add it to the Terreno Roadmap board, and register `@terreno/infra-mcp` → `area:mcp` in `scripts/issueAreaLabels.ts` + the bug-report package dropdown when the package lands
-
-## Phase 2 — Write tier + machine callers
-
-- [ ] `confirmWrite` elicitation wrapper; fail-closed behavior for clients without elicitation support
-- [ ] Config override (`confirmWrites: false`) gated by `infra:writeUnconfirmed`; tests for both paths
-- [ ] Write tools: `sentry_resolve_issue`, `sentry_assign_issue`, `gcp_rollback_cloud_run_revision`, `gcp_update_cloud_run_traffic`, `mongo_update_one`, `mongo_delete_one`; widen runtime SA IAM minimally
-- [ ] Service tokens: spike Better Auth `apiKey` plugin; fallback `ServiceToken` model; machine users (`isServiceAccount`) with role assignment; admin surface (token shown once)
-- [ ] Cloud agent migration: `INFRA_MCP_URL` + service token in agent environments; verify log-digging flows; remove `GCP_SA_*` injection; update AGENTS.md Cursor Cloud instructions
-
-## Phase 3 — Proxied adapters + remaining vendors
-
-- [ ] `ProxiedAdapter`: `@modelcontextprotocol/client` (stdio + HTTP), deny-by-default `allowedTools` with mandatory tier annotations, tool name prefixing, upstream lifecycle management
-- [ ] Reference proxied integration (`@sentry/mcp-server` stdio or `@google-cloud/observability-mcp`) with parity tests against native tools
-- [ ] Expo/EAS native adapter (`EXPO_TOKEN`): build status, update status, submission status (read); trigger tools deferred to write expansion
-- [ ] Vercel native adapter (API token): deployments, logs, project info (read)
-
-## Phase 4 — OSS packaging
-
-- [ ] `defineInfraMcp` config reference + quickstart docs (website); one-man-shop deploy path (container anywhere)
-- [ ] Publish `@terreno/infra-mcp`; changelog + upgrade notes
-- [ ] Dogfood writeup: our deployment as the reference architecture

package/src/docs/versioned/57.2.0/tasks/migrate-cicd-to-circleci.md

@@ -1,219 +0,0 @@
-# Task List: Migrate CI/CD to CircleCI
-
-See: [`docs/implementationPlans/migrate-cicd-to-circleci.md`](../implementationPlans/migrate-cicd-to-circleci.md)  
-Research: [`docs/implementationPlans/migrate-cicd-to-circleci-research.md`](../implementationPlans/migrate-cicd-to-circleci-research.md)
-
-## Instructions for the implementing agent
-
-- Dual-run every phase: CircleCI green → flip required checks → delete GHA twin. Never enable tag publish on both systems.
-- Do not store plaintext GCP JSON keys in CircleCI if OIDC is available; migrate `preview-cleanup` off `GCP_SA_KEY`.
-- Pin orb versions (including `circleci/node` with Bun support ≥7.2.0).
-- Prefer path parameters that mirror existing GHA path filters.
-- Update docs in the same PR that changes the source of truth for how CI runs.
-- After Phase 0, confirm CircleCI project follows the GitHub default branch `master`.
-
-## Phase 0: Prerequisites
-
-- [ ] **Task 0.1**: Confirm CircleCI org/plan and project link
-  - Description: Verify the requester-created CircleCI organization, plan, and that `TerrenoLabs/terreno` is connected with permission to report GitHub checks. Enable **dynamic config** / setup workflows for the project. Record org slug + project slug in the IP header or how-to doc.
-  - Files: `docs/how-to/circleci.md` (stub OK)
-  - Depends on: none (human prerequisite)
-  - Acceptance: a manual “hello” pipeline can be triggered from the project; dynamic config is enabled.
-  - Note: hello scaffold merged (#1052). Dynamic config + org slug still need maintainer confirmation.
-
-- [ ] **Task 0.2**: Create CircleCI Contexts (empty shells)
-  - Description: Create contexts named in the IP (`terreno-npm`, `terreno-netlify`, `terreno-expo`, `terreno-gcp`, `terreno-e2e`, `terreno-release`, `terreno-agentic`, `terreno-github-api`). Document which GitHub secrets map into each. Do not paste secret values into the repo.
-  - Files: `docs/how-to/circleci.md`
-  - Depends on: Task 0.1
-  - Acceptance: contexts exist; mapping table is complete; access restrictions noted for `terreno-release`.
-  - Note: mapping table documented in how-to; contexts themselves are still a human step.
-
-- [x] **Task 0.3**: Inventory required GitHub checks
-  - Description: List current branch-protection required checks and map each to the GHA job `name:` and the future CircleCI job name. Start from `docs/explanation/repository-settings.md` and live settings.
-  - Files: `docs/how-to/circleci.md` or a short table in the IP
-  - Depends on: none
-  - Acceptance: table covers policies, rulesync, package CI, fingerprint, and CD-related checks.
-
-## Phase 1: Foundation
-
-- [x] **Task 1.1**: Add setup + continue config skeleton
-  - Description: Create `.circleci/config.yml` with `setup: true` using `circleci/path-filtering` (and `circleci/continuation`). Create `.circleci/continue-config.yml` with parameters for each package/area and a no-op `config-ok` job that always runs.
-  - Files: `.circleci/config.yml`, `.circleci/continue-config.yml`
-  - Depends on: Task 0.1
-  - Acceptance: push triggers setup → continuation; `config-ok` is green.
-
-- [x] **Task 1.2**: Shared Bun + cache commands
-  - Description: Add reusable commands (inline or orb) for installing Bun via `circleci/node`, `bun install --frozen-lockfile`, and cache keys equivalent to today’s GHA bun cache. Pin Bun policy (`latest` vs pin) consistently with EAS jobs that need a pin.
-  - Files: `.circleci/continue-config.yml`
-  - Depends on: Task 1.1
-  - Acceptance: a sample job restores cache on second run; install is frozen-lockfile.
-
-- [x] **Task 1.3**: Path-filter mapping
-  - Description: Encode path → parameter mapping for api, ai, ui, rtk, comms, mcp-server, admin-*, example-*, demo, docs/website, terraform, e2e-relevant sets, matching current workflow path filters.
-  - Files: `.circleci/config.yml`
-  - Depends on: Task 1.1
-  - Acceptance: a docs-only change sets docs/deploy params without setting `run-api`.
-  - Note: deploy path params omitted until Phase 4+.
-
-## Phase 2: Package CI + policy
-
-- [x] **Task 2.1**: Port package CI jobs
-  - Description: Port api/ai/rtk/ui/ui-demo/comms/mcp-server/example-frontend/example-backend(+script)/admin-spa CI to CircleCI jobs gated by path params. Include Mongo service where GHA used it. Fix mcp branch filter to `master`.
-  - Files: `.circleci/continue-config.yml`, possibly package scripts unchanged
-  - Depends on: Task 1.2, Task 1.3
-  - Acceptance: dual-run green for each package on a change that touches it; GHA still required.
-
-- [x] **Task 2.2**: Port Docker build-only job
-  - Description: Port `example-backend-docker.yml` to CircleCI remote Docker / machine with layer caching replacement for `type=gha`.
-  - Files: `.circleci/continue-config.yml`
-  - Depends on: Task 2.1
-  - Acceptance: PR touching `example-backend/**` builds the image without pushing.
-
-- [x] **Task 2.3**: Port repo-policies + rulesync + DCO
-  - Description: Port `repo-policies.yml`, `rulesync-check.yml`, and fork DCO checks. DCO must use GitHub API via `terreno-github-api` context.
-  - Files: `.circleci/continue-config.yml`
-  - Depends on: Task 0.2, Task 1.2
-  - Acceptance: intentional barrel-import / dirty rulesync / missing DCO on a fork PR fails the CircleCI job.
-  - Note: DCO skips cleanly if `GITHUB_TOKEN` unset until context is created.
-
-- [ ] **Task 2.4**: Dual-run cutover for Phase 2
-  - Description: Add CircleCI checks to branch protection; remove GHA package/policy workflows once trusted; delete corresponding `.github/workflows/*-ci.yml` and policy workflows.
-  - Files: `.github/workflows/*`, `docs/explanation/repository-settings.md`
-  - Depends on: Task 2.1, Task 2.2, Task 2.3
-  - Acceptance: required checks are CircleCI-only for these surfaces; GHA files gone.
-
-## Phase 3: Playwright E2E
-
-- [x] **Task 3.1**: Port `e2e-ci` and `admin-spa-integration`
-  - Description: Mongo replica set, E2E secrets context, Playwright browsers, artifact store for reports. Skip Dependabot-equivalent if applicable.
-  - Files: `.circleci/continue-config.yml`
-  - Depends on: Task 2.1, Task 0.2
-  - Acceptance: matrix (or equivalent) passes on master; artifacts downloadable.
-
-- [ ] **Task 3.2**: Dual-run cutover for E2E
-  - Description: Flip required checks if any; delete GHA e2e/admin-spa-integration workflows.
-  - Files: `.github/workflows/e2e-ci.yml`, `admin-spa-integration.yml`, `admin-spa-ci.yml` as applicable
-  - Depends on: Task 3.1
-  - Acceptance: GHA twins deleted; CircleCI owns e2e.
-
-## Phase 4: Netlify deploys
-
-- [ ] **Task 4.1**: Port demo / frontend-example / docs Netlify workflows
-  - Description: Build + `netlify-cli` deploy prod/preview; preserve alias naming (`pr-N`); recreate GitHub Deployment statuses via API if still desired.
-  - Files: `.circleci/continue-config.yml`
-  - Depends on: Task 0.2, Task 1.3
-  - Acceptance: preview deploy URL posted or visible; prod deploy on master path filter.
-
-- [ ] **Task 4.2**: Preview cleanup port
-  - Description: On PR close, clean Netlify/GCP preview resources from CircleCI (webhook or GitHub App → pipeline). Prefer OIDC over `GCP_SA_KEY`.
-  - Files: `.circleci/continue-config.yml`
-  - Depends on: Task 4.1
-  - Acceptance: closing a PR removes preview resources; no orphaned Cloud Run `pr-N` services in a test PR.
-
-- [ ] **Task 4.3**: Dual-run cutover for Netlify
-  - Description: Delete GHA deploy workflows after CircleCI trusted.
-  - Files: `.github/workflows/demo-deploy.yml`, `frontend-example-deploy.yml`, `docs-deploy.yml`, `preview-cleanup.yml`
-  - Depends on: Task 4.1, Task 4.2
-  - Acceptance: GHA deploy twins deleted.
-
-## Phase 5: EAS + fingerprint
-
-- [ ] **Task 5.1**: Relocate CI scripts
-  - Description: Move EAS/fingerprint shell scripts from `.github/workflows/scripts/` to `scripts/ci/` (or `.circleci/scripts/`) and update callers.
-  - Files: `scripts/ci/*`, old script paths
-  - Depends on: none
-  - Acceptance: scripts runnable locally with documented env; no broken references.
-
-- [ ] **Task 5.2**: Port eas-pr, eas-dev-build, fingerprint-gate
-  - Description: CircleCI jobs using `EXPO_TOKEN`; PR comments and label gate via GitHub API; manual pipeline for eas-dev-build.
-  - Files: `.circleci/continue-config.yml`
-  - Depends on: Task 5.1, Task 0.2
-  - Acceptance: fingerprint change fails until `fingerprint-acknowledged`; EAS update/build path works on a test PR.
-
-- [ ] **Task 5.3**: Dual-run cutover for EAS
-  - Description: Delete GHA eas/fingerprint workflows after trust.
-  - Files: `.github/workflows/eas-pr.yml`, `eas-dev-build.yml`, `fingerprint-gate.yml`
-  - Depends on: Task 5.2
-  - Acceptance: GHA twins deleted; CircleCI checks required where fingerprint was required.
-
-## Phase 6: GCP CD + OIDC
-
-- [ ] **Task 6.1**: Add CircleCI OIDC provider in terraform
-  - Description: Extend or add module so GCP trusts CircleCI OIDC alongside GitHub during dual-run. Wire terreno terraform root; document outputs for CircleCI project settings.
-  - Files: `terraform/modules/**`, terreno/Flourish terraform roots, `terraform/README.md`
-  - Depends on: Task 0.1
-  - Acceptance: `gcloud` auth from a CircleCI job succeeds with WIF (no JSON key).
-
-- [ ] **Task 6.2**: Port `cd.yml`
-  - Description: Path-filtered terraform fmt/preview/apply + Docker build/push + Cloud Run deploys + mcp-test/deploy. Preserve concurrency semantics (do not cancel in-flight prod applies).
-  - Files: `.circleci/continue-config.yml`
-  - Depends on: Task 6.1
-  - Acceptance: terraform preview on PR; apply+deploy on master for a safe test path; GitHub Deployment records optional but documented.
-
-- [ ] **Task 6.3**: Dual-run cutover for CD
-  - Description: Single deployer: disable GHA `cd.yml` when CircleCI CD is required; remove GitHub OIDC provider only after GHA CD is gone (or keep read-only if other repos need it — document).
-  - Files: `.github/workflows/cd.yml`, terraform OIDC
-  - Depends on: Task 6.2
-  - Acceptance: only CircleCI performs terreno CD; no double apply.
-
-## Phase 7: npm publish
-
-- [ ] **Task 7.1**: Port publish-on-tag + manual feature-flags publish
-  - Description: Reproduce package publish graph, upgrade-docs gate, version bump, Zoom notify, demo dispatch, docs version cut. Use `terreno-release` + `terreno-npm` contexts.
-  - Files: `.circleci/continue-config.yml`
-  - Depends on: Task 0.2, Task 2.1
-  - Acceptance: dry-run or package-by-package rehearsal documented; Zoom path tested against a sandbox webhook if available.
-
-- [ ] **Task 7.2**: Single-writer tag cutover
-  - Description: In one coordinated change: enable CircleCI tag pipeline; delete/disable `.github/workflows/publish-on-tag.yml` and manual GHA publish; verify no double publish.
-  - Files: `.github/workflows/publish-on-tag.yml`, `publish-feature-flags-manual.yml`
-  - Depends on: Task 7.1
-  - Acceptance: next tag publishes once from CircleCI only.
-
-## Phase 8: Mobile (post-v1, required for CC1)
-
-- [ ] **Task 8.1**: Port Maestro + Appium Android
-  - Description: Port `maestro-e2e` and Android half of `demo-appium-ci` to CircleCI Linux VM with emulator strategy documented.
-  - Files: `.circleci/continue-config.yml`
-  - Depends on: Task 5.2
-  - Acceptance: manual pipeline runs Android Appium and Maestro successfully.
-
-- [ ] **Task 8.2**: Port Appium iOS on CircleCI macOS
-  - Description: Select macOS resource class/image with Working WDA; port iOS job; compare flake rate to GHA `macos-15`.
-  - Files: `.circleci/continue-config.yml`
-  - Depends on: Task 8.1
-  - Acceptance: iOS Appium green on a representative run; then delete GHA Appium workflow.
-
-## Phase 9: GitHub-native + agentic replacements
-
-- [ ] **Task 9.1**: Replace CodeQL workflow
-  - Description: Implement SARIF upload to GitHub Code Scanning from CircleCI or an approved SAST substitute; delete `codeql-analysis.yml` only when coverage is accepted.
-  - Files: `.circleci/continue-config.yml`, `.github/workflows/codeql-analysis.yml`
-  - Depends on: Task 0.2
-  - Acceptance: Security tab still receives results **or** explicit maintainer sign-off on alternative.
-
-- [ ] **Task 9.2**: Replace Dependabot auto-merge + triage + roadmap-generate + docs-audit
-  - Description: Implement CircleCI (or Renovate) equivalents; wire issue/schedule triggers without leaving required logic on GHA.
-  - Files: `.circleci/continue-config.yml`, corresponding GHA deletions
-  - Depends on: Task 0.2
-  - Acceptance: each former workflow’s acceptance behavior has an owner on CircleCI; GHA files deleted.
-
-- [ ] **Task 9.3**: Replace architectural review + gh-aw agentics
-  - Description: Per lockfile (`update-rules`, `update-docs`, daily improvers) and `architectural-pr-review` / `agentics-maintenance`: either port to CircleCI scheduled/PR pipelines with the same scripts or **retire** with maintainer sign-off. CC1 forbids leaving them on GHA.
-  - Files: `.github/workflows/*lock*`, `architectural-pr-review.yml`, `agentics-maintenance.yml`, `.circleci/continue-config.yml`
-  - Depends on: Task 0.2
-  - Acceptance: written retire-or-port decision for each; no gh-aw workflows remain if ported/retired.
-
-## Phase 10: Cleanup
-
-- [ ] **Task 10.1**: Docs sweep
-  - Description: Update CONTRIBUTING, repository-settings, terraform README, deploy guides, AGENTS/Cursor Cloud CI notes to CircleCI-first. Remove stale GHA instructions.
-  - Files: `docs/**`, `CONTRIBUTING.md`, `AGENTS.md` / rules as needed
-  - Depends on: Phases 2–7 at minimum; 8–9 for full CC1
-  - Acceptance: `rg -n "GitHub Actions" docs/explanation/repository-settings.md` and deploy docs reflect CircleCI as source of truth.
-
-- [ ] **Task 10.2**: Final GHA workflow purge + IP close
-  - Description: Ensure `.github/workflows` has no CI/CD yml left (except intentionally empty dir or README). Set the IP `**Status:**` to Complete and archive the IP.
-  - Files: `.github/workflows/`, `docs/implementationPlans/migrate-cicd-to-circleci.md`
-  - Depends on: Task 9.3, Task 10.1, Task 8.2
-  - Acceptance: `ls .github/workflows/*.yml` is empty (or only an agreed stub); IP status Complete.

package/src/docs/versioned/57.2.0/tasks/model-router-mcp.md

@@ -1,105 +0,0 @@
-# Tasks: modelRouter MCP Tools
-
-*Structured task breakdown for automated implementation. Each task should be independently implementable and testable.*
-
----
-
-### Phase 1: Core MCP Infrastructure
-
-- [x] **Task 1.1**: Define MCP types and interfaces
-  - Description: Create `MCPConfig` interface (with `methods` defaulting to `['list', 'read']`, `excludeFields` for hiding sensitive fields, `maxLimit` defaulting to 50), `MCPRegistryEntry`, and add `mcp?: MCPConfig` to `ModelRouterOptions`. Create the `api/src/mcp/` directory structure.
-  - Files: `api/src/mcp/types.ts`, `api/src/mcp/index.ts`, `api/src/api.ts` (add mcp to ModelRouterOptions)
-  - Depends on: none
-  - Acceptance: Types compile, existing tests still pass, `mcp` is an optional field on `ModelRouterOptions`
-
-- [x] **Task 1.2**: Build MCP tool registry
-  - Description: Create a global registry that collects MCP tool entries as `modelRouter()` is called. When a modelRouter has `mcp` config, it pushes an entry to the registry. Export `getMCPRegistry()` from `@terreno/api`. Vercel AI SDK wrapping lives in `getMCPTools()` on `@terreno/ai`.
-  - Files: `api/src/mcp/registry.ts`, `api/src/mcp/index.ts`, `api/src/api.ts` (register in modelRouter function)
-  - Depends on: Task 1.1
-  - Acceptance: Calling `modelRouter(Todo, { ..., mcp: { methods: ['list', 'read'] } })` adds entries to the registry. `getMCPRegistry()` returns those entries.
-
-- [x] **Task 1.3**: Generate Zod schemas from Mongoose models
-  - Description: Build a utility that converts a Mongoose model's schema into Zod schemas suitable for MCP tool `inputSchema`. Handle common field types (String, Number, Boolean, Date, ObjectId, Array, Mixed). Generate separate schemas for create (required fields), update (all optional + id required), read (id + optional populate), list (queryFields + pagination), and delete (id only). Respect `excludeFields` — omit listed fields from all generated schemas.
-  - Files: `api/src/mcp/schemaGenerator.ts`, `api/src/mcp/schemaGenerator.test.ts`
-  - Depends on: Task 1.1
-  - Acceptance: Given a Mongoose model, produces valid Zod schemas for each CRUD method. Tests cover all common field types. `excludeFields` removes specified fields from schemas.
-
-- [x] **Task 1.4**: Generate MCP tool definitions from registry entries
-  - Description: Build tool generator that takes an `MCPRegistryEntry` and produces both `@modelcontextprotocol/sdk` `Tool` objects (JSON Schema input) and Vercel `ai` SDK `CoreTool` objects. Auto-generate descriptions from model name, fields, and queryFields. Apply `toolPrefix` naming (`{prefix}_{method}`). Only generate tools for methods listed in `mcp.methods`.
-  - Files: `api/src/mcp/toolGenerator.ts`, `api/src/mcp/toolGenerator.test.ts`
-  - Depends on: Task 1.2, Task 1.3
-  - Acceptance: Registry entry with `methods: ['list', 'read']` produces exactly `todos_list` and `todos_read` tools with correct schemas and descriptions.
-
-- [x] **Task 1.5**: Implement MCP tool handlers (CRUD execution)
-  - Description: Build the execute functions for each CRUD tool. Each handler: (1) extracts user from auth context, (2) checks permissions via `checkPermissions()`, (3) for read/update/delete: loads document and checks object-level permissions, (4) applies queryFilter and population for list, (5) enforces `maxLimit` cap on list results (default 50), (6) runs pre/post hooks, (7) strips `excludeFields` from response data, (8) serializes via `mcpResponseHandler` or default. Reuse internal logic from REST handlers but decoupled from Express req/res.
-  - Files: `api/src/mcp/handlers.ts`, `api/src/mcp/handlers.test.ts`
-  - Depends on: Task 1.4
-  - Acceptance: Each CRUD handler works with correct permission checks, population, filtering. List enforces maxLimit. excludeFields are stripped from responses. Tests cover: successful CRUD, permission denied (403), not found (404), validation errors, owner filtering, population, maxLimit enforcement, excludeFields stripping.
-
-- [x] **Task 1.6**: Auth-agnostic user extraction for MCP
-  - Description: Build middleware/utility that extracts user from MCP transport headers using whichever auth provider is configured (JWT via passport or Better Auth via `auth.api.getSession()`). Should mirror `authenticateMiddleware` behavior but work with raw headers instead of Express req.
-  - Files: `api/src/mcp/auth.ts`, `api/src/mcp/auth.test.ts`
-  - Depends on: Task 1.1
-  - Acceptance: Given headers with a valid JWT, returns User. Given headers with a valid Better Auth session token, returns User. Given no/invalid headers with `allowAnonymous: false`, returns null. Works with both auth providers.
-
-- [x] **Task 1.7**: Mount MCP server in TerrenoApp
-  - Description: In `TerrenoApp`'s startup flow, check if the MCP registry has any entries. If so, create an `McpServer` instance from `@modelcontextprotocol/sdk`, register all tools from the registry, set up `StreamableHTTPServerTransport`, and mount on `/mcp`. Wire up `ListToolsRequestSchema` and `CallToolRequestSchema` handlers.
-  - Files: `api/src/mcp/server.ts`, `api/src/expressServer.ts` (or TerrenoApp equivalent — integrate into startup)
-  - Depends on: Task 1.4, Task 1.5, Task 1.6
-  - Acceptance: Starting a TerrenoApp with MCP-configured models auto-mounts `/mcp`. MCP clients can list tools and call them. No MCP config = no `/mcp` endpoint.
-
-- [x] **Task 1.8**: Integration tests
-  - Description: End-to-end tests that spin up a TerrenoApp with MCP-configured models and test the full flow: MCP client connects, lists tools, performs CRUD via tool calls, verifies permissions block unauthorized access, verifies population and query filtering work.
-  - Files: `api/src/mcp/integration.test.ts`
-  - Depends on: Task 1.7
-  - Acceptance: Full CRUD lifecycle works over MCP. Permission denials return appropriate errors. Owner filtering restricts results. Population returns nested data.
-
-- [x] **Task 1.9**: Export public API
-  - Description: Export `MCPConfig` and MCP registry/server helpers from `@terreno/api`. Export `getMCPTools()` from `@terreno/ai` so the Vercel `ai` SDK stays out of `@terreno/api`.
-  - Files: `api/src/index.ts`, `ai/src/index.ts`, `ai/src/service/getMCPTools.ts`
-  - Depends on: Task 1.7
-  - Acceptance: Consumers can `import { MCPConfig } from "@terreno/api"` and `import { getMCPTools } from "@terreno/ai"`.
-
----
-
-### Phase 2: Frontend Integration
-
-- [x] **Task 2.1**: `useTerrenoChat` hook
-  - Description: Create a hook wrapping `@ai-sdk/react`'s `useChat()` pre-configured for a Terreno MCP backend. Handles Bearer token injection from auth state (reads from Redux store — JWT token or Better Auth session). Accepts `baseURL` and optional `tools` override.
-  - Files: `rtk/src/useTerrenoChat.ts`
-  - Depends on: Task 1.7
-  - Acceptance: Hook connects to MCP-enabled backend, streams responses with tool calls, injects auth token automatically.
-
-- [x] **Task 2.2**: `useMCPTools` hook
-  - Description: Create a hook that discovers available MCP tools from the backend via JSON-RPC call to /mcp endpoint. Caches result. Returns typed tool list.
-  - Files: `rtk/src/useMCPTools.ts`
-  - Depends on: Task 1.7
-  - Acceptance: Hook returns list of available tools with names, descriptions, and input schemas. Handles connection errors gracefully.
-
-- [x] **Task 2.3**: Export frontend public API
-  - Description: Export `useTerrenoChat` and `useMCPTools` from `@terreno/rtk`. Add `@ai-sdk/react` and `ai` as dependencies.
-  - Files: `rtk/src/index.ts`, `rtk/package.json`
-  - Depends on: Task 2.1, Task 2.2
-  - Acceptance: Consumers can `import { useTerrenoChat, useMCPTools } from "@terreno/rtk"`.
-
----
-
-### Phase 3: Examples & Polish
-
-- [x] **Task 3.1**: Add MCP config to example backend models
-  - Description: Add `mcp` config to the existing Todo and User models in `example-backend`. Todos: read-only (`list`, `read`) with excludeFields. Users: read-only (`list`, `read`) with sensitive fields excluded.
-  - Files: `example-backend/src/api/todos.ts`, `example-backend/src/api/users.ts`
-  - Depends on: Task 1.9
-  - Acceptance: Starting example-backend mounts `/mcp` with todo and user tools. MCP client can list and call them.
-
-- [x] **Task 3.2**: Demo chat screen in example frontend
-  - Description: Add a simple chat screen to `example-frontend` that uses `useTerrenoChat()` to connect to the MCP-enabled backend. Show tool calls inline (e.g., "Searching todos..." with results). Navigation from home screen.
-  - Files: `example-frontend/app/chat.tsx`, `example-frontend/app/_layout.tsx` (add nav)
-  - Depends on: Task 2.3, Task 3.1
-  - Acceptance: User can chat with the AI, which calls MCP tools to query/modify data. Tool calls and results visible in the UI.
-
-- [x] **Task 3.3**: Refine auto-generated tool descriptions
-  - Description: Improve description generation quality. Include field types, required vs optional, enum values, ref model names. Test with multiple model shapes to ensure descriptions are helpful for LLMs.
-  - Files: `api/src/mcp/toolGenerator.ts`, `api/src/mcp/toolGenerator.test.ts`
-  - Depends on: Task 1.4
-  - Acceptance: Descriptions include actionable detail. LLM can understand what each tool does and what inputs are expected without additional context.