@terreno/mcp 0.29.0 → 0.31.0

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
 
-- [ ] **Task 1.1**: Document Discussion category setup
+- [x] **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.
 
-- [ ] **Task 1.2**: Write the pinned intro posts
+- [x] **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.
 
-- [ ] **Task 1.3**: Add Discussion templates
+- [x] **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
 
-- [ ] **Task 2.1**: Document Project board setup
+- [x] **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.
 
-- [ ] **Task 2.2**: Write the tracking-issue bodies for this program's IPs
+- [x] **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
 
-- [ ] **Task 3.1**: Define the label set as data
+- [x] **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 `#`.
 
-- [ ] **Task 3.2**: Add the triage workflow
+- [x] **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.
 
-- [ ] **Task 3.3**: Document the backfill triage pass
+- [x] **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
 
-- [ ] **Task 4.1**: Write the roadmap generator
+- [x] **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.
 
-- [ ] **Task 4.2**: Add the roadmap workflow
+- [x] **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.
 
-- [ ] **Task 4.3**: Seed `ROADMAP.md` and link it
+- [x] **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.
 
-- [ ] **Task 4.4**: Add the docs feedback footer link
+- [x] **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
 
-- [ ] **Task 5.1**: Document the Linear bridge rules
+- [x] **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.
 
-- [ ] **Task 5.2**: Document the intake flow in `CONTRIBUTING.md`
+- [x] **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.
 
-- [ ] **Task 5.3**: Add the release announcement step
+- [x] **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,7 +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 PR [#869](https://github.com/flourishhealth/terreno/pull/869) is merged into `master`. Verify with `git log --oneline master | rg -i syncdb` before beginning.
+**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.
+
+**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.
 
 ## Instructions for the implementing agent
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@terreno/mcp",
-  "version": "0.29.0",
+  "version": "0.31.0",
   "description": "MCP server for Terreno - provides documentation, tools, and prompts for building full-stack apps",
   "type": "module",
   "main": "dist/index.js",
@@ -27,9 +27,9 @@
   "dependencies": {
     "@modelcontextprotocol/sdk": "^1.27.0",
     "@sentry/bun": "^10.39.0",
-    "@terreno/api": "0.29.0",
+    "@terreno/api": "0.31.0",
     "minisearch": "^7.2.0",
-    "mongoose": "8.23.0"
+    "mongoose": "9.7.4"
   },
   "devDependencies": {
     "@biomejs/biome": "^2.3.6",
@@ -38,6 +38,7 @@
     "typescript": "~5.9.2"
   },
   "files": [
+    "LICENSE",
     "dist",
     "src/docs"
   ],

package/src/docs/templates/bootstrap/backend/types/models/userTypes.template.md

@@ -1,16 +1,17 @@
-/// <reference types="passport-local-mongoose" />
 import type {APIErrorConstructor} from "@terreno/api";
 import type mongoose from "mongoose";
-import type {Document, FilterQuery, Model} from "mongoose";
+import type {Document, Model} from "mongoose";
+
+type ModelQuery<T> = Partial<Record<keyof T, unknown>> & Record<string, unknown>;
 
 export interface DefaultStatics<T> {
   findOneOrNone(
-    query: FilterQuery<T>,
+    query: ModelQuery<T>,
     errorArgs?: Partial<APIErrorConstructor>
   ): Promise<(Document & T) | null>;
 
   findExactlyOne(
-    query: FilterQuery<T>,
+    query: ModelQuery<T>,
     errorArgs?: Partial<APIErrorConstructor>
   ): Promise<Document & T>;
 }

package/src/docs/templates/tools/model.template.md

@@ -5,9 +5,11 @@ interface {{Name}}Document extends mongoose.Document {
 {{interfaceFields}}
 }
 
+type ModelQuery<T> = Partial<Record<keyof T, unknown>> & Record<string, unknown>;
+
 interface {{Name}}Model extends mongoose.Model<{{Name}}Document> {
-  findOneOrNone(query: mongoose.FilterQuery<{{Name}}Document>): Promise<{{Name}}Document | null>;
-  findExactlyOne(query: mongoose.FilterQuery<{{Name}}Document>): Promise<{{Name}}Document>;
+  findOneOrNone(query: ModelQuery<{{Name}}Document>): Promise<{{Name}}Document | null>;
+  findExactlyOne(query: ModelQuery<{{Name}}Document>): Promise<{{Name}}Document>;
 }
 
 const {{lowerName}}Schema = new mongoose.Schema<{{Name}}Document, {{Name}}Model>(

package/src/docs/upgrades/0.31.0.md

@@ -0,0 +1,60 @@
+# 0.31.0
+
+Terreno packages move in lockstep. Nothing in this release removes or renames a public
+export, so most apps upgrade by bumping the `@terreno/*` versions and running:
+
+- `bun run compile` and `bun run lint` at the repo root
+- `cd <your frontend> && bun run sdk` after any `@terreno/api` route or model surface change
+
+## Mongoose 9 is now supported (Mongoose 8 still works)
+
+Every published package that talks to Mongoose (`api`, `test`, `admin-backend`, `ai`,
+`feature-flags`) widened its peer dependency to `^8.0.0 || ^9.0.0`. Terreno itself
+develops against Mongoose 9.7.4.
+
+You can stay on Mongoose 8 with no changes. If you upgrade your app to Mongoose 9, the
+changes that mattered inside Terreno will most likely matter in your code too:
+
+```typescript
+// Before (Mongoose 8)
+await Model.findOneAndUpdate(filter, update, {new: true});
+
+// After (Mongoose 9)
+await Model.findOneAndUpdate(filter, update, {returnDocument: "after"});
+```
+
+- Aggregation-pipeline updates must pass `updatePipeline: true` to `updateMany`.
+- Query middleware no longer takes the legacy `next()` callback — use the async form.
+- Array schema paths expose `getEmbeddedSchemaType()`; the private `caster` property is gone.
+- Mongoose 9 ships its own types, so `@types/mongodb` and
+  `@types/passport-local-mongoose` should be removed from your dev dependencies.
+- Pin `bson` to `7.2.0` if your lockfile resolves an older copy alongside Mongoose 9.
+
+Mongoose 9 requires Node >= 20.19.0. Terreno's root `package.json` now declares that
+engine range for local development.
+
+## `@terreno/api` type changes
+
+Both changes widen or relax types; they are source-compatible for normal usage, but
+explicit annotations may need updating:
+
+- `modelRouter` now accepts `Model<T, any, any, any, any, any>` instead of `Model<T>`,
+  so models with custom query helpers, methods, or virtuals no longer need a cast.
+- `findOneOrNoneFor(model, query)` takes `ModelQuery<T>` (a partial record keyed by the
+  document fields) instead of Mongoose's `FilterQuery<T>`. If you were building a
+  `FilterQuery<T>` value to pass in, it still works; if you were annotating the variable
+  as `FilterQuery<T>` and relying on operator typing, switch to `ModelQuery<T>`.
+
+## `@terreno/admin-backend` array field metadata
+
+`GET /admin/config` derives array item metadata (`itemType`, `itemRef`, `itemEnum`) from
+Mongoose's public `getEmbeddedSchemaType()` when available, falling back to the Mongoose 8
+`caster` shape. `itemEnum` is only emitted when the embedded enum is an array, so an enum
+declared as an object map no longer produces a malformed `itemEnum`. Admin clients that
+read `itemEnum` should treat it as optional.
+
+## License changed from Apache-2.0 to MIT
+
+All published `@terreno/*` packages are now MIT licensed and ship a `LICENSE` file in the
+package tarball. No code change is required; update any license inventory or attribution
+list that pinned Terreno as Apache-2.0.

package/src/docs/versioned/0.29.0/explanation/README.md

@@ -0,0 +1,14 @@
+# Explanation
+
+Understanding-oriented documentation: concepts, architecture, and context.
+
+## Contents
+
+- [AI-powered workflows](ai-workflows.md) — Autonomous documentation, testing, and maintenance workflows
+- [Authentication architecture](authentication.md) — How JWT, OAuth, and token refresh work
+- [Configuration system](configuration-system.md) — Runtime configuration with database persistence
+- [Dependency management](dependency-management.md) — Dependabot, auto-merge, and security practices
+- [GCP hosting architecture](gcp-hosting-architecture.md) — Static site hosting with GCS and Cloud CDN
+- [Modular API design](modular-api-design.md) — 🚧 Why TerrenoApp replaces setupServer
+- [modelRouter actions](model-router-actions.md) — Named collection and instance operations on modelRouter
+- [No barrel imports](no-barrel-imports.md) — Import concrete modules, not `index` re-export barrels

package/src/docs/versioned/0.29.0/explanation/explicit-any-policy.md

@@ -0,0 +1,88 @@
+# Explicit `any` policy
+
+Terreno discourages `any` in TypeScript. Biome blocks **new** unsuppressed explicit `any` at lint time; this document describes how we inventory existing usages and track remediation.
+
+## Why
+
+- **Type safety**: `any` disables checking and hides bugs at compile time.
+- **Refactor confidence**: precise types make API and UI changes safer.
+- **Consistency**: one convention for when `any` is acceptable and how it is documented.
+
+Prefer `unknown` (and narrow) or a precise type. Use `as unknown as T` over `as any as T` when a cast is unavoidable.
+
+## Allowed uses
+
+Explicit `any` is acceptable only at **framework or library boundaries** where types are not expressible in TypeScript today, for example:
+
+- Mongoose `Schema<any, …>` accepting arbitrary consumer schemas (`api/src/plugins.ts`)
+- RTK Query `Api<any, any, any, any>` in generic middleware (`rtk/src/offlineMiddleware.ts`)
+- Dynamic RTK hook lookup where endpoint names are not statically known (`admin-frontend`)
+- Test mocks with type-erased doubles (`*.test.ts`, `*.isolated.tsx`)
+
+Every allowed use must be **lint-clean** and **documented** (see below).
+
+## Remediation status
+
+The audit script (`bun run check:explicit-any`) classifies each explicit `any`:
+
+| Status | Meaning |
+|--------|---------|
+| `violation` | No `biome-ignore` — fails Biome lint |
+| `suppressed-only` | Has `biome-ignore` but missing `// noExplicitAny:` rationale |
+| `fully-documented` | Has both `biome-ignore` and `// noExplicitAny:` |
+| `file-blanket` | File-level `biome-ignore-all` without file-level `noExplicitAny:` |
+| `out-of-scope` | In Biome-excluded source (e.g. `api/src/populate.ts`) |
+
+## How to document an `any`
+
+When `any` cannot be removed, add **both** comments on the line above (or a file header for tests):
+
+```typescript
+// noExplicitAny: RTK Query generates hook names dynamically; not statically expressible
+// biome-ignore lint/suspicious/noExplicitAny: dynamic hook lookup on RTK Query enhanced API
+const hook = (api as any)[`useGet${name}Query`];
+```
+
+For test files with many mocks, a file-level header is fine:
+
+```typescript
+// noExplicitAny: test mocks use type-erased RTK Query API doubles
+// biome-ignore-all lint/suspicious/noExplicitAny: test mock typing
+```
+
+## Commands
+
+```bash
+bun run check:explicit-any                         # summary report
+bun run check:explicit-any:json                    # JSON inventory
+bun run check:explicit-any:baseline                # fail if counts regress vs baseline
+bun run check:explicit-any -- --undocumented       # only suppressed-but-undocumented
+bun run check:explicit-any -- --list --undocumented  # file:line list for remediation
+bun run check:explicit-any -- --production-only --undocumented --list
+bun run check:explicit-any -- --package=api        # filter to one package
+bun run check:explicit-any -- --include-excluded   # include Biome-excluded files
+bun run check:explicit-any -- --write-baseline     # refresh scripts/check-explicit-any/baseline.json
+bun run check:explicit-any:remediate               # auto-add missing noExplicitAny: comments
+```
+
+## Enforcement
+
+| Layer | What it does |
+|-------|----------------|
+| **Biome `noExplicitAny: error`** | Blocks new unsuppressed `any` in every linted package |
+| **`bun run check:explicit-any:baseline`** | CI ratchet — total, undocumented, and violation counts must not increase |
+| **`bun run lint`** | Per-package lint including `noExplicitAny` |
+
+Baseline file: `scripts/check-explicit-any/baseline.json`. After intentional reductions (removing or properly documenting `any`), refresh with `--write-baseline` and commit the updated baseline.
+
+## Remediation workflow
+
+1. Run `bun run check:explicit-any -- --list --undocumented --production-only` for a work queue.
+2. For each hit, either **replace** `any` with a proper type or **document** with `noExplicitAny:` + `biome-ignore`.
+3. Prefer line-level suppressions over file-level `biome-ignore-all` in production code.
+4. Run `bun run check:explicit-any:baseline` before opening a PR.
+5. If counts decreased, run `--write-baseline` and commit the new baseline.
+
+## Exclusions
+
+The audit skips generated and template files (`openApiSdk.ts`, `*.template.ts`). Biome-excluded paths (see `!!` patterns in `biome.jsonc`) are omitted unless `--include-excluded` is passed.

package/src/docs/versioned/0.29.0/explanation/no-barrel-imports.md

@@ -0,0 +1,49 @@
+# No barrel imports
+
+Terreno avoids **barrel imports** — imports that resolve through an `index.ts` / `index.tsx` file that only re-exports other modules.
+
+## Why
+
+- **Clearer dependencies**: each import names the file that defines the symbol.
+- **Faster tooling**: bundlers and TypeScript do less re-export chasing.
+- **Fewer cycles**: internal barrels (especially package `index` files) are a common source of circular dependencies.
+
+## Allowed
+
+- **Published package APIs** — cross-package imports like `@terreno/api`, `@terreno/ui`, and `@terreno/rtk` use each package's public `src/index` entry. That is intentional.
+- **Package public entry files** — `api/src/index.ts`, `ui/src/index.tsx`, etc. may re-export for npm consumers. Do not import those barrels from *inside* the same package.
+- **Expo Router routes** — `app/**/index.tsx` files are route entries, not barrels.
+
+## Not allowed
+
+Internal barrel `index` files do not exist in this repo — the Biome `noBarrelFile` override bans creating them, so a directory import like `../models` has nothing to resolve to and fails to compile.
+
+Importing a directory that resolves to a re-exporting index file:
+
+```typescript
+// Bad — resolves to models/index.ts
+import {User} from "../models";
+
+// Good — imports the defining module
+import {User} from "../models/user";
+```
+
+```typescript
+// Bad — store/index.ts was a barrel of sdk/appState/utils
+import {useGetMeQuery} from "@/store";
+
+// Good
+import {useGetMeQuery} from "@/store/sdk";
+import store, {useAppDispatch} from "@/store/index";
+```
+
+## Enforcement
+
+No generation step is required — internal barrel `index` files are banned outright, so there is never a list of barrels to keep in sync.
+
+- **Biome `noBarrelFile` override** (root `biome.jsonc`): bans internal barrel `index.ts` / `index.tsx` files during lint. Package public entries (`src/index.ts[x]`) and Expo Router routes (`app/**`) are exempt.
+- **Biome plugin**: `biome/plugins/no-barrel-imports.grit` — a small static GritQL plugin that flags path-alias directory imports (`@/store`, `@components`, …) in the packages that define those aliases (`example-frontend`, `admin-spa`, `demo`).
+- **CI**: `bun run check:no-barrel-imports` — resolution-based safety net that fails if any internal barrel index file exists or any import resolves through one (see root `package.json` → `terreno.policies.noBarrelImports`).
+- **AI rules**: `.rulesync/rules/00-root.md` and package `.ai/guidelines/core.md` files
+
+When scaffolding new code (MCP bootstrap, examples), always generate direct module paths — never `models/index`, `@/store`, or `@components` without a concrete file.

package/src/docs/versioned/0.29.0/implementationPlans/PLAN_INDEX.md

@@ -0,0 +1,75 @@
+# Implementation plan index
+
+Tracks active and completed implementation plans (IP) for Terreno. File paths are relative to `docs/implementationPlans/`.
+
+## Programs
+
+Umbrella plans that coordinate several IPs.
+
+| Program | Status | Created | IPs |
+|---------|--------|---------|-----|
+| [Open source launch](oss-launch-program.md) | Draft — decisions recorded; Vercel spike open | 2026-07-27 | 15 |
+
+## Active
+
+| Plan | Status | Created | Tasks |
+|------|--------|---------|-------|
+| [Admin UI v2 — Django-parity admin](admin-ui-v2-django-parity.md) | Approved | 2026-06-15 | [tasks](../tasks/admin-ui-v2-django-parity.md) |
+| [RBAC Permissions](rbac-permissions.md) | Draft (API design) | 2026-07-08 | TBD |
+| [SyncDB Local-First Data Layer](syncdb-local-first.md) | In progress ([PR #869](https://github.com/flourishhealth/terreno/pull/869)) | 2026-07-13 | [tasks](../tasks/syncdb-local-first.md) |
+| [MCP Boost parity](mcp-boost-parity.md) | In progress ([PR #802](https://github.com/flourishhealth/terreno/pull/802)) | 2026-06-21 | TBD |
+
+## Open source launch IPs
+
+All part of the [launch program](oss-launch-program.md). The **RTK flag** column marks dependence on the `@terreno/rtk` → `@terreno/syncdb` migration in PR #869: `None` is safe to implement now, `Partial` has some blocked tasks, `Blocked` cannot start until #869 merges.
+
+### Wave 0 — unblocked
+
+| Plan | Status | RTK flag | Tasks |
+|------|--------|----------|-------|
+| [OSS governance baseline](oss-governance-baseline.md) | Draft | None | [tasks](../tasks/oss-governance-baseline.md) |
+| [Public roadmap on GitHub](public-roadmap-github.md) | Draft | None | [tasks](../tasks/public-roadmap-github.md) |
+| [Deploy to GCP (generalized)](deploy-to-gcp.md) | Draft | None | [tasks](../tasks/deploy-to-gcp.md) |
+| [Agentic SDLC plugin (`/terreno-*`)](agentic-sdlc-plugin.md) | Draft | Partial | [tasks](../tasks/agentic-sdlc-plugin.md) |
+
+### Wave 1 — gated on PR #869
+
+| Plan | Status | RTK flag | Tasks |
+|------|--------|----------|-------|
+| [RTK deprecation and syncdb migration docs](rtk-to-syncdb-migration-docs.md) | Draft | **Blocked** (gating IP) | [tasks](../tasks/rtk-to-syncdb-migration-docs.md) |
+| [Positioning — Django/Rails for TypeScript](positioning-django-rails-universal.md) | Draft | Partial | [tasks](../tasks/positioning-django-rails-universal.md) |
+| [Reference documentation coverage](docs-reference-coverage.md) | Draft | Blocked | [tasks](../tasks/docs-reference-coverage.md) |
+| [AI-first tutorials](docs-tutorials-ai-first.md) | Draft | Blocked | [tasks](../tasks/docs-tutorials-ai-first.md) |
+| [Deployment foundation](deployment-foundation.md) | Draft | Partial | [tasks](../tasks/deployment-foundation.md) |
+| [Deploy to Vercel](deploy-to-vercel.md) | Draft | Partial | [tasks](../tasks/deploy-to-vercel.md) |
+| [Upgrade guides and skill](upgrade-guides-and-skill.md) | Draft | Blocked | [tasks](../tasks/upgrade-guides-and-skill.md) |
+| [The AI development loop (Boost)](ai-dev-loop-boost.md) | Draft | Partial | [tasks](../tasks/ai-dev-loop-boost.md) |
+| [Dogfooding run and launch blog post](build-terreno-app-validation.md) | Draft | Blocked | [tasks](../tasks/build-terreno-app-validation.md) |
+| [Examples, demo, and test coverage](examples-demo-coverage.md) | Draft | Partial | [tasks](../tasks/examples-demo-coverage.md) |
+
+### Wave 2 — independent
+
+| Plan | Status | RTK flag | Tasks |
+|------|--------|----------|-------|
+| [Web SSR and admin SPA](web-ssr-and-admin-spa.md) | Draft | Partial | [tasks](../tasks/web-ssr-and-admin-spa.md) |
+
+## Completed
+
+| Plan | Status | Created | Tasks |
+|------|--------|---------|-------|
+| [APIError redesign — standards-first extension of Error](apierror-standard-error-redesign.md) | Complete | 2026-07-28 | n/a |
+
+## Deferred / Closed
+
+*(Plans parked or superseded.)*
+
+## Backlog
+
+*(Links to ideas not yet promoted to a full IP.)*
+
+| Idea | Notes |
+|------|-------|
+| [Langfuse integration](terreno-langfuse-integration.md) | AI observability plugin |
+| [modelRouter MCP tools](model-router-mcp.md) | MCP surface for consumer app APIs |
+| [Offline mode](offline-mode.md) | Superseded in large part by [syncdb](syncdb-local-first.md) — confirm and close |
+| [modelRouter actions](model-router-actions.md) | — |