@terreno/mcp 57.6.0 → 57.7.0

package/dist/docs/versioned/next/implementationPlans/support-agent.md

@@ -1,6 +1,7 @@
 # Implementation Plan: Support answering agent (`@terreno/support`)
 
 **Status:** Draft — awaiting approval (Grow ran unattended; every Decisions row marked `assumed` is a recommended default the reviewer can change before Approve)  
+**Roadmap:** Area=`ai`, Target=`Future`, Impact=`Feature`  
 **Branch:** `cursor/support-agent-grow-fd63`  
 **Owner:** unassigned  
 **Created:** 2026-09-15  

package/dist/docs/versioned/next/implementationPlans/syncdb-codegen.md

@@ -1,7 +1,7 @@
 # Implementation Plan: @terreno/syncdb-codegen
 
 **Status:** Complete — shipped as `syncdb/src/codegen` + `terreno-syncdb-codegen`
-**Roadmap issue:** https://github.com/TerrenoLabs/terreno/issues/1087
+**Roadmap issue:** https://github.com/TerrenoLabs/terreno/issues/1110
 **Branch:** cursor/syncdb-codegen-in-package-746d
 **Owner:**
 **Created:** 2026-07-08

package/dist/docs/versioned/next/implementationPlans/terreno-langfuse-integration.md

@@ -1,7 +1,7 @@
 # @terreno/langfuse
 
 **Roadmap issue:** https://github.com/TerrenoLabs/terreno/issues/1093  
-**Status:** Approved
+**Status:** Complete
 
 > **See also:** Native in-app observability (prompts, traces, evals, experiments, review queue) is specified in [ai-observability.md](./ai-observability.md). This IP remains the **Langfuse Cloud/self-host vendor plugin**. Both plugins may be registered; traces/scores fan out (see that IP).
 

package/dist/docs/versioned/next/implementationPlans/upgrade-guides-and-skill.md

@@ -1,6 +1,6 @@
 # Implementation Plan: Upgrade Guides and the `upgrading-terreno` Skill
 
-**Status:** Approved
+**Status:** Complete
 **Roadmap issue:** https://github.com/TerrenoLabs/terreno/issues/1013
 **Priority:** High
 **Effort:** Big batch

package/dist/docs/versioned/next/reference/api.md

@@ -223,6 +223,22 @@ export const todoRouter = modelRouter("/todos", Todo, {
 
 Do not add `endpoints: (router) => { router.get(...) }` when an action fits.
 
+## modelRouter array operations
+
+When a model has at least one array field, `modelRouter` provides subroutes for adding,
+updating, and removing array items:
+
+| Method | Path | Operation |
+| --- | --- | --- |
+| `POST` | `/:id/:field` | Append an item |
+| `PATCH` | `/:id/:field/:itemId` | Replace or merge an item |
+| `DELETE` | `/:id/:field/:itemId` | Remove an item |
+
+The `field` path must resolve to an array on the document. Requests for scalar, object,
+or unknown fields run the normal update transform and `preUpdate` hook first so consumer
+authorization remains authoritative, then return `400` with code
+`array-operation-field-not-array` if the hook allows the request.
+
 ## MCP tools
 
 Opt a model into Model Context Protocol tools with `mcp` on `modelRouter`. `TerrenoApp` mounts `POST /mcp` when any model has `mcp` or a custom tool is registered.

package/dist/docs/versioned/next/reference/lifecycle-plugin.md

@@ -14,7 +14,7 @@ loops that invoke those stages; they are not stages and must not appear as `stag
 | `terreno-2-pick` | approved task + branch/state | one implemented slice, then Roast, then the next task | Roast, or Brew when the list is done |
 | `terreno-3-roast` | Pick result + current diff | independent requirement/evidence verdict for the current task | emit Pick if tasks remain, else Brew; never invoke Pick; pass a task-scoped briefing; do not spawn two unconstrained reviewers |
 | `terreno-4-brew` | Roast PASS for every in-scope task + branch/evidence | pushed head + PR + product-CI trigger check + review-bot wait + attached evidence | Taste |
-| `terreno-5-taste` | PR + current state | one current-head reaction; before push: pull latest `master`, re-verify last-run failed tests locally, run root `prepush` when present (otherwise affected-package checks) in a no-context subagent, then watch CI | null or fresh Taste |
+| `terreno-5-taste` | PR + current state | one current-head reaction; before push: fetch latest `master` (merge only when needed), re-verify last-run failed tests locally, run root `prepush` when present (otherwise affected-package checks) in a no-context subagent, then watch CI; invoked directly, repeats bounded reactions until terminal | null or fresh Taste |
 
 Outer loops (not stages):
 
@@ -51,7 +51,7 @@ until async review bots (Bugbot, CodeQL, and similar) on the current head have r
 preferring provider CLI watch hooks or harness event subscriptions over sleep polling.
 Taste then waits in a loop for product CI using GitHub CLI (`gh pr checks --watch`,
 `gh run watch`) or CircleCI CLI (`circleci run watch`) until jobs are terminal or the
-wait times out. Before any push, Taste always pulls latest `master`, records last-run
+wait times out. Before any push, Taste fetches latest `master` (merging it only when needed), records last-run
 failed tests and re-verifies them locally, then spawns a
 fresh subagent with no parent conversation. If the repository root defines a `prepush`
 package script, Taste runs it as the authoritative local gate; otherwise it falls back

package/dist/docs/versioned/next/reference/test.md

@@ -148,7 +148,7 @@ the demo compiles. Add a story plus `demoConfig.tsx` registration for new
 components, or an allowlist entry with a specific reason — not "hard to demo".
 The allowlist is limited to shell/providers, React context objects, thin RN
 list wrappers, subcomponents already exercised by a parent story
-(Filter, Table, DateTimeField, HeightField, ConsentFormScreen), and
+(DropdownPanel, Table, DateTimeField, HeightField, ConsentFormScreen), and
 product surfaces that belong in `example-frontend` rather than the isolated
 UI demo (announcements and in-app notifications).
 Standalone picker sheets (`NumberPickerActionSheet`, `DecimalRangeActionSheet`)

package/dist/docs/versioned/next/reference/ui.md

@@ -226,6 +226,69 @@ overrides it:
 | Helper | `{testID}.helper` |
 | Show/hide toggle | `{testID}.visibility-toggle` |
 
+### DropdownPanel
+
+`DropdownPanel` is the compositional dropdown behind the DataTable filter popovers. A
+trigger opens an anchored panel of arbitrary composed content with an optional
+Apply / Clear / Cancel footer, so it also fits non-filter panels (bulk actions, column
+pickers, sort menus).
+
+``````typescript
+<DropdownPanel
+  label="Filters"
+  onApply={applyDraft}
+  onCancel={resetDraft}
+  onClear={clearDraft}
+  onOpenChange={(isOpen) => isOpen && seedDraft()}
+  width={340}
+>
+  <FilterSelectMenu title="Due date" options={DUE_DATE_OPTIONS} value={dueDate} onChange={setDueDate} />
+  <FilterBoolean title="Urgent tasks only" value={urgentOnly} onChange={setUrgentOnly} />
+</DropdownPanel>
+``````
+
+> `Filter` is the former name and stays exported as a deprecated alias (with `FilterProps`)
+> until Terreno 58. The `FilterSelectMenu` / `FilterBoolean` / `FilterAccordion` /
+> `FilterChangesBadge` controls keep their names.
+
+#### Positioning
+
+The panel never renders inside its parent's clipping or stacking context: on web it is
+portaled to `document.body` with fixed positioning, and on native it is teleported to the
+`TerrenoProvider` portal host (falling back to an inline absolute overlay when no host is
+mounted). `computeDropdownPanelLayout` then anchors it to the measured trigger:
+
+| Situation | Behavior |
+| --- | --- |
+| Panel fits beside the trigger | Left edges line up (`align="start"`) |
+| Left-aligned panel would cross the right viewport edge | Right edges line up instead (`align="auto"`, the default) |
+| Panel is wider than the viewport | Narrowed to the viewport minus the 8px screen margins |
+| Less than 160px below the trigger, and more above | Flipped above the trigger |
+| Content taller than the space on screen | Panel body scrolls; the footer stays pinned |
+
+Pass `align="start"` or `align="end"` to pin the side explicitly, and `maxPanelHeight` to
+cap the height below what the viewport allows.
+
+#### Trigger
+
+The default trigger is a `Button` (or a compact icon trigger with `iconOnly`). Style it
+with `triggerVariant` (any `Button` variant), `triggerSize`, and `fullWidth`, or replace
+it entirely with `renderTrigger` when the design needs chrome the button variants do not
+cover:
+
+``````typescript
+<DropdownPanel
+  fullWidth
+  renderTrigger={({isOpen, toggle}) => <MyPill active={isOpen} onPress={toggle} />}
+  width={300}
+>
+  {fields}
+</DropdownPanel>
+``````
+
+`variant` still sets both the trigger and the Apply button; `triggerVariant` and
+`applyButtonVariant` override each independently.
+
 ### GPTChat
 
 Streaming chat surface for `@terreno/ai`. Histories, messages, submit, and optional MCP/tools stay under consumer control.
@@ -811,10 +874,10 @@ columns; web shows one **More filters** popover and native includes them in the
 
 | Platform | Chrome |
 | --- | --- |
-| Web | Toolbar search + per-column `Filter` popovers (`column.filter`) |
+| Web | Toolbar search + per-column `DropdownPanel` popovers (`column.filter`) |
 | Native | Toolbar search + one **Filters** sheet (`Modal`) with the same fields |
 
-Column headers use `Filter` with `iconOnly`, which renders a compact icon trigger
+Column headers use `DropdownPanel` with `iconOnly`, which renders a compact icon trigger
 (24px at the default `triggerSize="sm"`, 32px with `triggerSize="default"`) instead
 of a labeled button. Give it an accessible name with `triggerAccessibilityLabel`.
 

package/dist/docs/versioned/next/tasks/can-as-permission-seam.md

@@ -4,7 +4,7 @@ IP: [can-as-permission-seam.md](../implementationPlans/can-as-permission-seam.md
 
 ## Phase 1 — `assertAllowed`
 
-- [ ] **Task 1.1**: Helper + unit tests
+- [x] **Task 1.1**: Helper + unit tests
   - Delivers: `assertAllowed` implements legacy `checkPermissions` and `accessControl.can()`; double-gate test (access allow + permissions deny → allow)
   - Files: `api/src/rbac/assertAllowed.ts`, `api/src/rbac/assertAllowed.test.ts`
   - Blocked by: none (can land before MCP adapters; executors wiring waits on unified writes if MCP still duplicates checks)
@@ -12,7 +12,7 @@ IP: [can-as-permission-seam.md](../implementationPlans/can-as-permission-seam.md
 
 ## Phase 2 — Hot path
 
-- [ ] **Task 2.1**: Middleware + executors
+- [x] **Task 2.1**: Middleware + executors
   - Delivers: `permissionMiddleware` and `executeCreate/Update/Delete` call `assertAllowed`; `buildAccessPermissions` not used on requests
   - Files: `api/src/permissions.ts`, `api/src/sync/executors.ts`, `api/src/api.ts`, `api/src/rbac/modelRouterAccess.ts`, tests
   - Blocked by: 1.1; unified-mutation-executors Phase 2 so MCP is included automatically
@@ -20,12 +20,12 @@ IP: [can-as-permission-seam.md](../implementationPlans/can-as-permission-seam.md
 
 ## Phase 3 — Consumers and docs
 
-- [ ] **Task 3.1**: example-backend dual config
+- [x] **Task 3.1**: example-backend dual config
   - Delivers: routers with `access` drop redundant AND `permissions` where RBAC is the intent
   - Files: `example-backend/src/**` model routers
   - Blocked by: 2.1
   - Acceptance: example-backend tests pass
-- [ ] **Task 3.2**: Docs + breaking changelog
+- [x] **Task 3.2**: Docs + breaking changelog
   - Files: `docs/reference/api.md`, `docs/how-to/create-a-model.md`, `docs/implementationPlans/rbac-permissions.md` pointer, changelog
   - Blocked by: 2.1
   - Skills: `update-docs`

package/dist/docs/versioned/next/tasks/collection-registry.md

@@ -4,12 +4,12 @@ IP: [collection-registry.md](../implementationPlans/collection-registry.md)
 
 ## Phase 1 — Dual-write catalog
 
-- [ ] **Task 1.1**: `CollectionRegistry` module
+- [x] **Task 1.1**: `CollectionRegistry` module
   - Delivers: `registerCollection`, `replaceCollectionOptions`, `getCollection`, `listCollections`, `clearCollectionRegistry` with unit tests (unknown path no-op, options replace)
   - Files: `api/src/collectionRegistry.ts`, `api/src/collectionRegistry.test.ts`
   - Blocked by: none
   - Acceptance: bun tests for the module pass without wiring modelRouter
-- [ ] **Task 1.2**: Dual-write from `modelRouter`
+- [x] **Task 1.2**: Dual-write from `modelRouter`
   - Delivers: `modelRouter` / `_buildModelRouter` write the catalog in addition to existing `register*` / `update*`
   - Files: `api/src/api.ts`
   - Blocked by: 1.1
@@ -17,12 +17,12 @@ IP: [collection-registry.md](../implementationPlans/collection-registry.md)
 
 ## Phase 2 — Surfaces read the catalog
 
-- [ ] **Task 2.1**: MCP and realtime views
+- [x] **Task 2.1**: MCP and realtime views
   - Delivers: `getMCPRegistry` / realtime finders read `CollectionRegistry`; arrays in those files removed
   - Files: `api/src/mcp/registry.ts`, `api/src/realtime/registry.ts`, related tests
   - Blocked by: 1.2
   - Acceptance: MCP and realtime tests pass; `updateMCPRegistryOptions` updates the shared record
-- [ ] **Task 2.2**: Sync view + keep validation
+- [x] **Task 2.2**: Sync view + keep validation
   - Delivers: sync lookup uses catalog; `registerSync` validation + index promises still run
   - Files: `api/src/sync/registry.ts`, `api/src/sync/*.test.ts`
   - Blocked by: 1.2
@@ -30,12 +30,12 @@ IP: [collection-registry.md](../implementationPlans/collection-registry.md)
 
 ## Phase 3 — Contract
 
-- [ ] **Task 3.1**: Single writer + clear-all
+- [x] **Task 3.1**: Single writer + clear-all
   - Delivers: `modelRouter` only writes `CollectionRegistry`; wrapper register/update/clear functions; tests that used independent clears updated
   - Files: `api/src/api.ts`, registry wrappers, tests
   - Blocked by: 2.1, 2.2
   - Acceptance: one `replaceCollectionOptions` is enough for MCP+sync options identity
-- [ ] **Task 3.2**: Docs + changelog
+- [x] **Task 3.2**: Docs + changelog
   - Files: `docs/explanation/modular-api-design.md`, `docs/reference/api.md`, changelog
   - Blocked by: 3.1
   - Skills: `update-docs`

package/dist/docs/versioned/next/tasks/describe-model-schema.md

@@ -4,12 +4,12 @@ IP: [describe-model-schema.md](../implementationPlans/describe-model-schema.md)
 
 ## Phase 1 — Descriptor + MCP
 
-- [ ] **Task 1.1**: `describeModel` / `describeModelForRouter`
+- [x] **Task 1.1**: `describeModel` / `describeModelForRouter`
   - Delivers: field graph + snapshot tests on a fixture schema
   - Files: `api/src/schemaMetadata.ts`, `api/src/schemaMetadata.test.ts`
   - Blocked by: none
   - Acceptance: snapshots for enum, ref, array, subdocument, system fields
-- [ ] **Task 1.2**: MCP Zod from descriptor
+- [x] **Task 1.2**: MCP Zod from descriptor
   - Delivers: `schemaGenerator.ts` maps `FieldDescription`; no SchemaType switch for kinds already in the descriptor
   - Files: `api/src/mcp/schemaGenerator.ts`, `api/src/mcp/schemaGenerator.test.ts`
   - Blocked by: 1.1
@@ -17,7 +17,7 @@ IP: [describe-model-schema.md](../implementationPlans/describe-model-schema.md)
 
 ## Phase 2 — Admin
 
-- [ ] **Task 2.1**: `extractFieldMeta` from descriptor
+- [x] **Task 2.1**: `extractFieldMeta` from descriptor
   - Delivers: admin config fields built from `describeModel`, not OpenAPI property walk
   - Files: `admin-backend/src/adminApp.ts`, admin-backend tests
   - Blocked by: 1.1
@@ -25,12 +25,12 @@ IP: [describe-model-schema.md](../implementationPlans/describe-model-schema.md)
 
 ## Phase 3 — OpenAPI + docs
 
-- [ ] **Task 3.1**: `getOpenApiSpecForModel` from descriptor
+- [x] **Task 3.1**: `getOpenApiSpecForModel` from descriptor
   - Delivers: OpenAPI properties derived from `ModelDescription`; populate still applied
   - Files: `api/src/populate.ts`, `api/src/openApi.test.ts` / example-backend openapi snapshot if required
   - Blocked by: 1.1
   - Acceptance: OpenAPI tests pass; any snapshot diff is reviewed in the PR
-- [ ] **Task 3.2**: Docs + export
+- [x] **Task 3.2**: Docs + export
   - Files: `docs/explanation/schema-metadata.md`, `docs/reference/api.md`, `docs/how-to/create-a-model.md`, admin reference, `api/src/index.ts`, changelog
   - Blocked by: 1.2, 2.1, 3.1
   - Skills: `update-docs`

package/dist/docs/versioned/next/tasks/migrate-cicd-to-circleci.md

@@ -103,19 +103,21 @@ Research: [`docs/implementationPlans/migrate-cicd-to-circleci-research.md`](../i
   - 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.
-  - Note: Path filters and preview jobs exist. Live Netlify still runs on GHA until `terreno-netlify` is filled; CircleCI skips. Cleanup on PR close is GHA `preview-cleanup.yml`.
+  - Note: CircleCI is the only Netlify deployer; jobs fail when `terreno-netlify` is empty. PR close triggers CircleCI `preview-cleanup` through `preview-cleanup.yml`.
 
 - [ ] **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.
+  - Note: Cutover code landed on branch `move-cd-to-circleci` (GHA deploy workflows disabled; CircleCI deploy jobs fail on empty contexts). Check off after contexts are filled and the acceptance is observed.
 
 - [ ] **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.
+  - Note: Cutover code landed on branch `move-cd-to-circleci` (GHA deploy workflows disabled; CircleCI deploy jobs fail on empty contexts). Check off after contexts are filled and the acceptance is observed.
 
 ## Phase 5: EAS + fingerprint
 
@@ -150,13 +152,14 @@ Research: [`docs/implementationPlans/migrate-cicd-to-circleci-research.md`](../i
   - 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.
-  - Note: Path filters exist. Live GCP still runs on GHA until `terreno-gcp` is filled; CircleCI skips apply.
+  - Note: CircleCI is the only GCP deployer; jobs fail when `terreno-gcp` is empty. `gcp-cd-prod` runs MCP `test:ci` before the MCP deploy.
 
 - [ ] **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.
+  - Note: Cutover code landed on branch `move-cd-to-circleci` (GHA deploy workflows disabled; CircleCI deploy jobs fail on empty contexts). Check off after contexts are filled and the acceptance is observed.
 
 ## Phase 7: npm publish
 
@@ -200,7 +203,7 @@ Research: [`docs/implementationPlans/migrate-cicd-to-circleci-research.md`](../i
   - 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
+- [ ] **Task 9.2**: Replace Dependabot auto-merge + triage + docs-audit (roadmap workflows stay on GitHub Actions, decided 2026-09-26)
   - 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

package/package.json

@@ -11,7 +11,7 @@
     "@modelcontextprotocol/node": "^2.0.0",
     "@modelcontextprotocol/server": "^2.0.0",
     "@sentry/bun": "^10.39.0",
-    "@terreno/api": "57.6.0",
+    "@terreno/api": "57.7.0",
     "express": "^5.2.1",
     "luxon": "^3.7.2",
     "minisearch": "^7.2.0",
@@ -104,5 +104,5 @@
     "test:coverage": "bun run ../scripts/check-coverage.ts"
   },
   "type": "module",
-  "version": "57.6.0"
+  "version": "57.7.0"
 }

package/src/docs/upgrades/57.7.0.md

@@ -0,0 +1,64 @@
+# Upgrading to 57.7.0
+
+**Action required:** No
+**Affected packages:** @terreno/ui
+
+## Summary
+
+Bump every `@terreno/*` package together to `57.7.0`. `@terreno/ui`'s `Filter` is now `DropdownPanel`. Existing `Filter` and `FilterProps` imports keep working until Terreno 58. Panels stay on screen, render through the `TerrenoProvider` portal on native, and accept styled or custom triggers. No Expo upgrade is required if you are already on `57.x`.
+
+## Breaking changes
+
+None
+
+## Deprecations
+
+### `Filter` and `FilterProps`
+
+**What changed**
+
+`Filter` is renamed to `DropdownPanel`. `Filter` and `FilterProps` stay exported as deprecated aliases and are removed in Terreno 58. `FilterSelectMenu`, `FilterBoolean`, `FilterAccordion`, and `FilterChangesBadge` keep their names.
+
+**Why**
+
+The control is a general compositional dropdown (trigger, anchored panel, optional Apply/Clear/Cancel footer), not a filter-only widget.
+
+**Migration**
+
+```tsx
+// Before
+import {Filter} from "@terreno/ui";
+
+<Filter label="Status">{children}</Filter>;
+
+// After
+import {DropdownPanel} from "@terreno/ui";
+
+<DropdownPanel label="Status">{children}</DropdownPanel>;
+```
+
+## Changed behavior
+
+### Panels stay on screen and escape clipping
+
+**What changed**
+
+`DropdownPanel` (including the `Filter` alias) right-aligns to its trigger when a left-aligned panel would cross the right viewport edge, clamps to an 8px screen margin, flips above the trigger when there is no usable room below, and scrolls its body with the footer pinned when the content is taller than the space available. On native it renders through the `TerrenoProvider` portal host, so the panel is no longer clipped inside scroll views or cards. Without a host it stays an inline overlay.
+
+**Why**
+
+Left-aligned panels ran off screen, and inline overlays were clipped by parent scroll views.
+
+**Migration**
+
+No call-site change is required. Pass `align` or `maxPanelHeight` to override the automatic layout. Apps that position their own panels can call `computeDropdownPanelLayout`.
+
+## New capabilities
+
+`DropdownPanel` triggers accept `triggerVariant` (any `Button` variant), `applyButtonVariant`, `triggerSize` on labeled triggers, `fullWidth`, and `renderTrigger` for a fully custom trigger.
+
+## Verification
+
+- `bun add` every `@terreno/*` dependency to `57.7.0`, then `bun run compile` at the app root
+- Open a screen that uses `Filter` or `DropdownPanel` and confirm the panel stays inside the viewport, including near the right edge and inside a scrolling parent
+- Replace `Filter` imports with `DropdownPanel` before upgrading to Terreno 58

package/src/docs/upgrades/58.0.0.md

@@ -2,6 +2,10 @@
 
 This file is a placeholder until Terreno 58 is cut. When that release ships, expand this page into a full upgrade note.
 
+## `Filter` and `FilterProps` are removed
+
+`@terreno/ui` removes the `Filter` and `FilterProps` aliases added as deprecations in 57.7.0. Import `DropdownPanel` and `DropdownPanelProps`. `FilterSelectMenu`, `FilterBoolean`, `FilterAccordion`, and `FilterChangesBadge` keep their names. See [57.7.0](57.7.0.md).
+
 ## HTTP rate limiting defaults on
 
 `TerrenoApp` will enable HTTP rate limiting by default (memory store unless you pass `store`). Apps that must stay unlimited must pass an explicit off once 58 defines that API.

package/src/docs/versioned/next/explanation/loop-engineering.md

@@ -49,7 +49,7 @@ the inner loop until the approved task list is done. Roast never invokes Pick. B
 Taste additionally wait while async review bots are running, preferring provider CLI
 watch hooks or harness event subscriptions over timer polling. Taste also waits in a
 loop for product CI with `gh` or `circleci` until jobs are terminal or the wait times
-out. Before any push it always pulls latest `master`, then records last-run failed tests
+out. Before any push it fetches latest `master` (merging it only when needed), then records last-run failed tests
 and re-verifies them locally, then runs the repository's root
 `prepush` package script in a no-context subagent when present (falling back to affected
 package lint, typecheck, and tests), then pushes and watches CI.
@@ -82,8 +82,8 @@ acceptance criteria. Taste is one reactive iteration, not an unbounded fix-until
 daemon. It waits until async review bots (Bugbot, CodeQL, and similar) on the current
 head have reported, then waits in a loop for product CI using GitHub CLI
 (`gh pr checks --watch`, `gh run watch`) or CircleCI CLI (`circleci run watch`) until
-jobs are terminal or the wait times out. Before any push it always pulls latest
-`master`, records last-run failed tests and re-verifies them locally, then runs root
+jobs are terminal or the wait times out. Before any push it fetches latest
+`master` (merging it only when needed), records last-run failed tests and re-verifies them locally, then runs root
 `prepush` when present in a fresh subagent with no parent
 conversation. If absent, it proves affected-package lint, typecheck, and tests instead.
 It then pushes and watches CI, emits `PASS`, `FAIL`, `BLOCKED`, or `PENDING`, and exits.
@@ -139,6 +139,35 @@ or transports it and Brew excludes it from commits unless repository policy says
 otherwise. Stage results follow the plugin's JSON-schema-backed YAML contract and never
 contain chain-of-thought or transcripts.
 
+## Commits and pushes
+
+Every pushed commit starts a full CI run. Harnesses such as Cursor cloud agents push
+every commit automatically, so commit count turns directly into CI runs. Before these
+rules, one 30-commit dashboard PR had ten "mark slice roasted" commits and ten "harden"
+follow-ups, and `ui-ci` stayed red on every commit after the first.
+
+- One behavior-scoped commit per task, after Roast `PASS`: code, tests, docs, and the
+  task-file mark together. Roast-driven fixes fold into that commit.
+- Progress lives in execution state, not in standalone task-file commits.
+- Pick and Roast never push. Brew pushes once. Taste pushes at most once per reaction.
+- Pick does not continue on a head whose product CI shows a branch-caused failure.
+- Pick lists a behavior's edge cases before coding, so Roast proves them instead of
+  discovering them.
+- Roast runs the gate CI will run (root `prepush`, which mirrors the triggered CI jobs),
+  not only the task's test file.
+- Taste fetches `master` before every push but merges it only when the PR conflicts, a
+  failure traces to base drift, or the branch is otherwise merge-ready.
+
+## Direct invocation
+
+Outer loops (`terreno-planning-loop`, `terreno-taste-sweep`) consume Taste `PENDING`
+and invoke Taste again. When a human invokes Taste directly, no loop is waiting, so a
+`PENDING` would only tell them to come back later. In that case Taste uses
+**standalone entry**: it waits in-process with native watches and reacts again. It
+stops on `PASS`, `BLOCKED`, or `FAIL`, or after 3 fix pushes or 3 hours of waiting,
+which ends as `BLOCKED` with one concrete human action. A directly invoked Brew
+starts Taste as its next stage instead of exiting.
+
 ## Retry and stop rules
 
 - Pick implements one task, Roast proves it, then Pick takes the next unblocked task.

package/src/docs/versioned/next/explanation/repository-settings.md

@@ -51,11 +51,18 @@ as GitHub App checks; they are not CircleCI jobs.
 
 **Path:** Settings → Environments
 
-Same-repo PR jobs in `cd.yml` (`Terraform preview`, `Tasks deploy (preview)`,
-`Backend deploy (preview)`) skip when `head.repo.full_name != github.repository`.
-Also restrict the `gcp-cd-preview` environment (create it on first deploy if missing) with a
-**deployment branch policy** or **required reviewers** so a fork that edits
-`cd.yml` cannot mint a prod WIF token.
+`cd.yml` is disabled; CircleCI `gcp-cd-preview` performs GCP previews and
+halts on fork PRs. While the GitHub WIF provider still exists, keep the
+`gcp-cd-preview` environment restricted with a **deployment branch policy** or
+**required reviewers** so a fork that re-enables `cd.yml` cannot mint a prod
+WIF token.
+
+### Actions secrets for CircleCI hooks
+
+`preview-cleanup.yml` (PR close) and `publish-on-tag.yml` (manual publish demo
+redeploy) start CircleCI pipelines. Set the secret `CIRCLECI_TOKEN` and the
+variable `CIRCLECI_PIPELINE_DEFINITION_ID` under Settings → Secrets and
+variables → Actions.
 
 ## Merge settings
 

package/src/docs/versioned/next/explanation/roadmap-process.md

@@ -88,11 +88,10 @@ half applies:
 | 1 | Announcements | Announcement | Maintainers only | Official release notes, breaking changes, deprecations, and launch updates from the Terreno team. |
 | 2 | Q&A | Question / Answer | Anyone | Ask how to use Terreno. Search existing threads first; accepted answers may become how-to guides in `docs/how-to/`. |
 | 3 | Ideas | Open-ended | Anyone | Feature ideas and improvements before they are shaped. This is the intake funnel — do not open a tracking issue until a maintainer promotes your idea. |
-| 4 | Hacktoberfest | Open-ended | Anyone | Pitch something to build during Hacktoberfest and upvote the ideas you want. Popular, well-scoped ideas become `hacktoberfest` issues anyone can pick up. |
-| 5 | Agents & AI | Open-ended | Anyone | MCP setup, Cursor/Claude skills, agent workflows, and prompt patterns for building with Terreno. |
-| 6 | RFCs | Open-ended | Anyone | Substantial proposals that change public API or add packages. Use the RFC discussion template; accepted RFCs become IPs. |
-| 7 | Show and tell | Open-ended | Anyone | Apps and experiments built with Terreno. Share what you shipped and what friction you hit. |
-| 8 | Docs feedback | Open-ended | Anyone | Report missing or confusing documentation. Link the page URL; recurring feedback becomes docs PRs. |
+| 4 | Agents & AI | Open-ended | Anyone | MCP setup, Cursor/Claude skills, agent workflows, and prompt patterns for building with Terreno. |
+| 5 | RFCs | Open-ended | Anyone | Substantial proposals that change public API or add packages. Use the RFC discussion template; accepted RFCs become IPs. |
+| 6 | Show and tell | Open-ended | Anyone | Apps and experiments built with Terreno. Share what you shipped and what friction you hit. |
+| 7 | Docs feedback | Open-ended | Anyone | Report missing or confusing documentation. Link the page URL; recurring feedback becomes docs PRs. |
 
 ### Pinned posts
 
@@ -127,24 +126,29 @@ When an answer repeats, maintainers turn it into a how-to doc via PR.
 - Do **not** open a feature issue directly — maintainers promote accepted ideas to tracked issues on the [Terreno Roadmap](https://github.com/TerrenoLabs/terreno/projects) board.
 - For API/package-level design, use the **RFCs** category instead.
 - Bugs → [Bug report](https://github.com/TerrenoLabs/terreno/issues/new?template=bug_report.yml).
+- **Hacktoberfest pitches live here too.** Tick the Hacktoberfest box on the form; maintainers apply the [`hacktoberfest`](https://github.com/TerrenoLabs/terreno/discussions?discussions_q=label%3Ahacktoberfest) label. 👍 the pitches you want built.
 ```
 
-#### Hacktoberfest
+#### Hacktoberfest (inside Ideas)
 
-```markdown
-**Pitch Hacktoberfest ideas here, and 👍 the ones you want built.**
-
-1. [Start a Hacktoberfest discussion](https://github.com/TerrenoLabs/terreno/discussions/new?category=hacktoberfest) — the form asks for the idea, area, rough size, and what "done" looks like.
-2. Upvote and comment on other pitches. Upvotes are how maintainers rank them.
-3. Maintainers turn popular, well-scoped ideas into issues labeled [`hacktoberfest`](https://github.com/TerrenoLabs/terreno/issues?q=is%3Aissue+is%3Aopen+label%3Ahacktoberfest) and link them back here. Pick one up by commenting on the issue.
+Hacktoberfest does not get its own category. Pitches are Ideas discussions carrying the
+`hacktoberfest` label, so upvotes, promotion, and search all use the same path as any other
+idea.
 
-Longer-term feature ideas → **Ideas**. Bugs → [Bug report](https://github.com/TerrenoLabs/terreno/issues/new?template=bug_report.yml).
-```
+1. [Start an Ideas discussion](https://github.com/TerrenoLabs/terreno/discussions/new?category=ideas)
+   and tick **This is a Hacktoberfest pitch**. Give the area, rough size, and what "done" looks
+   like.
+2. A maintainer applies the [`hacktoberfest`](https://github.com/TerrenoLabs/terreno/discussions?discussions_q=label%3Ahacktoberfest)
+   label and the matching `area:*` label. Upvotes are how maintainers rank pitches.
+3. Popular, well-scoped pitches become issues labeled
+   [`hacktoberfest`](https://github.com/TerrenoLabs/terreno/issues?q=is%3Aissue+is%3Aopen+label%3Ahacktoberfest),
+   linked back to the discussion. Pick one up by commenting on the issue.
 
-Promotion follows the Ideas path, with one change: a Hacktoberfest idea small enough to finish
+Promotion follows the Ideas path, with one change: a Hacktoberfest pitch small enough to finish
 in a weekend becomes a `hacktoberfest` + `good first issue` work item directly (see
 [GitHub issue lifecycle](../how-to/github-issue-lifecycle.md)) instead of a `Shaping` roadmap
-item. Larger ones go through `roadmap-promote` like any other idea.
+item. Larger ones get `hacktoberfest` + `help wanted` and go through `roadmap-promote` like any
+other idea.
 
 #### Agents & AI
 
@@ -397,10 +401,10 @@ do not claim completion until done.
 
 | Workflow | Trigger | Purpose |
 | -------- | ------- | ------- |
-| [`.github/workflows/triage.yml`](https://github.com/TerrenoLabs/terreno/blob/master/.github/workflows/triage.yml) | Issue opened | `status:needs-triage` + `area:*` from package dropdown + `type:*` from Kind when present |
+| [`.github/workflows/triage.yml`](https://github.com/TerrenoLabs/terreno/blob/master/.github/workflows/triage.yml) | Issue opened | `status:needs-triage` + `area:*` from package dropdown + `type:*` from Kind when present; `area:*` / `type:*` labels the issue was opened with win, so `roadmap:sync` issues are not asked for an area |
 | [`.github/workflows/roadmap-generate.yml`](https://github.com/TerrenoLabs/terreno/blob/master/.github/workflows/roadmap-generate.yml) | Daily + manual | `roadmap:sync --check` for board drift, then regenerate `ROADMAP.md` from the board and open a pull request when it changes |
 | [`.github/workflows/roadmap-sync.yml`](https://github.com/TerrenoLabs/terreno/blob/master/.github/workflows/roadmap-sync.yml) | Taxonomy files change on `master` + manual | Apply labels and reconcile the board's fields and items |
-| [`.github/workflows/roadmap-reconcile.yml`](https://github.com/TerrenoLabs/terreno/blob/master/.github/workflows/roadmap-reconcile.yml) | IP or task files change on `master` + manual | Advance status from IP headers, push to the board, regenerate `ROADMAP.md` |
+| [`.github/workflows/roadmap-reconcile.yml`](https://github.com/TerrenoLabs/terreno/blob/master/.github/workflows/roadmap-reconcile.yml) | IP or task files change on `master` + manual | Advance status from IP headers, add an entry for every new IP, open its tracking issue, push to the board, regenerate `ROADMAP.md` |
 All three share the `roadmap` concurrency group. They write the same board, and interleaving
 them produces confusing partial states. After the group lock is acquired, each job refreshes
 to the latest branch HEAD so a queued `roadmap-sync` cannot overwrite statuses that
@@ -413,7 +417,7 @@ The full loop, each arrow with exactly one writer:
 
 ```
 docs/implementationPlans/*.md ──roadmap:reconcile──▶ roadmap-seed-issues.md
-docs/tasks/*.md                    (Status only)              │
+docs/tasks/*.md              (Status + new entries)           │
                                                          roadmap:sync
                                                               ▼
                                                         Project board
@@ -439,6 +443,24 @@ reported by `--check` and is never overwritten. Cards that are not in
 [`roadmap-seed-issues.md`](roadmap-seed-issues.md) are also `--check` failures; apply does
 not delete them. Maintainers own the board's *state* and `Community interest`.
 
+**New IPs reach the roadmap on merge.** When a merged plan has no entry,
+`roadmap:reconcile --fix` scaffolds one: the title from the IP's H1, the summary from the first
+paragraph of `## Goal`, and links to the IP and its task list (when `docs/tasks/<slug>.md`
+exists). Area, Target, and Impact come from an optional IP header:
+
+```markdown
+**Roadmap:** Area=`api`, Target=`Next`, Impact=`Feature`
+```
+
+Without that header they are inferred: Area from the packages named in the header block
+(default `dx`); Target `Released` for shipped work, `Future` for drafts, `58` when a
+`**Target:**` line names 58, otherwise `Next`; Impact `Breaking` when the `**Target:**` line
+says so, otherwise `Feature`. Edit the scaffolded section afterward if a guess is wrong. The
+workflow then runs `roadmap:sync --create-missing-ip-issues`, which opens a tracking issue
+only for entries backed by an IP. Drafts land as `Shaping`. Moving an entry to `Shipped` also
+moves its Target to `Released`. `ROADMAP.md` links each entry's IP and, when one exists, its
+task list.
+
 **Status automation is monotonic.** `roadmap:reconcile --fix` advances status and applies
 supersessions, but never walks a status backwards and never revives declined work. IP headers
 go stale far more often than boards do — several plans still read `Draft` for work that