@xhulz/nina 0.64.3 → 0.65.0

package/releases/0.65.0/surfaces/db/tree/.claude/agents/reviewer.md

@@ -0,0 +1,22 @@
+<!-- nina:slot db.2 -->
+- **If the schema, a migration or a query was touched anywhere in the diff: name `dba` on your Gates line.** Its approval is what a database change needs; yours does not stand in for it.
+
+<!-- nina:slot db.3 -->
+- Check for **tenant scoping** in every new query in app code: it filters by `{{TENANT_KEY}}`, or reaches it through the model's foreign keys. No "global" queries except the auth library's own tables. Missing scope = `REJECTED`.
+
+<!-- nina:slot db.4 -->
+- Check for N+1 queries when the DB layer was touched.
+
+<!-- nina:slot db.5 -->
+- **tenant-and-privacy** — `{{TENANT_KEY}}` in every app query (the auth library's own tables are the only exemption);
+  no PII or secrets in logs; no cross-tenant read
+  or write reachable through a route, an MCP tool, a webhook, or an RPC between services.
+
+<!-- nina:slot db.6 -->
+- The schema touched (a migration in play)
+
+<!-- nina:slot db.7 -->
+- Leave `dba` off your Gates line on a database change "because it seems fine."
+
+<!-- nina:slot db.8 -->
+- Schema or query touched and `dba` not dispatched → name it on your Gates line; the orchestrator sends it.

package/releases/0.65.0/surfaces/db/tree/.claude/agents/secops.md

@@ -0,0 +1,2 @@
+<!-- nina:slot db.1 -->
+- **AuthZ / tenant isolation (Hard Rule #7)** — EVERY query in app code scopes by `{{TENANT_KEY}}` (or its foreign key). Hunt for any query, route, MCP tool, or queue, webhook or background path where another tenant's data could be read or mutated (IDOR). The auth library's own tables are the only allowed unscoped reads — verify nothing else is.

package/releases/0.65.0/surfaces/db/tree/.claude/agents-overview.md

@@ -0,0 +1,5 @@
+<!-- nina:slot db.1 -->
+- **DBA guardrail** → the database is the surface where a bad change causes hard-to-reverse damage. Schema mistakes, missing indexes, cache on reads that feed a correctness-critical write, missing tenant scope — all caught here.
+
+<!-- nina:slot db.2 -->
+| **dba** | Mandatory gate on schema changes, migrations and new queries | `.claude/agents/dba.md` |

package/releases/0.65.0/surfaces/db/tree/.claude/graph.md

@@ -0,0 +1,8 @@
+<!-- nina:slot db.1 -->
+- `dba` — gate: runs when the schema, a migration or a query is touched
+
+<!-- nina:slot db.2 -->
+- `implementer` → `dba` on `DIFF-READY` — the diff touches the schema, a migration or a query
+- `dba` → `qa` on `APPROVED` — once the reviewer, and every other gate the diff went to, approved too
+- `dba` → `implementer` on `REJECTED` — a query or schema change in the diff is unsafe · max 2
+- `dba` → `architect` on `REJECTED` — the spec's migration or data design is unsafe · max 2

package/releases/0.65.0/surfaces/db/tree/.claude/patterns.md

@@ -0,0 +1,22 @@
+<!-- nina:slot db.2 -->
+- Routes must NOT import query functions (`list*`, `find*`, `get*`, `upsert*`, `delete*`) from `{{DB_PKG_NAME}}` — only its client and its error classes.
+
+<!-- nina:slot db.4 -->
+- **Every service query filters by `{{TENANT_KEY}}` (tenant scope).** Missing scope = automatic `REJECTED`.
+
+<!-- nina:slot db.5 -->
+
+---
+
+## Database conventions (enforced by the dba subagent)
+
+- **A cached read names its policy, and a read that feeds a write whose correctness depends on it being fresh is NEVER cached.** A stale row contaminates the decision made from it. Hard reject in dba review.
+- **Every query in app code filters by `{{TENANT_KEY}}`** (or reaches it through the model's foreign keys). Tenant isolation is in the data layer. The auth library's own tables are the only exemption.
+- Migrations reviewed by **dba** for: non-blocking on large tables, index coverage for new query patterns, backward compatibility during rolling deploy.
+- N+1 queries are a bug.
+
+<!-- nina:slot db.6 -->
+- A real database, never a mock of its client.
+
+<!-- nina:slot db.7 -->
+- **A library's schema generator never writes the tracked schema.** One rewrites the file whole, so it writes to scratch.<!-- nina:why --> An auth library's generator dropped a hand-added table and foreign key.<!-- /nina:why --> The tracked file is the reviewed one and lists its deltas from the generator's output; a check regenerates into scratch and compares the two, less those deltas.

package/releases/0.65.0/surfaces/db/tree/.claude/pipeline.md

@@ -0,0 +1,13 @@
+<!-- nina:slot db.1 -->
+
+### DBA (mandatory for the database)
+
+- **Trigger:** any schema change, any new query, any migration.
+- **Input:** the schema diff and its migration SQL + the application code using the queries.
+- **Output:** `APPROVED`, or `REJECTED` with specific issues.
+- **Tools:** Read, Grep, Glob, Bash (schema validation, an offline migration diff, query-plan checks).
+- **Checks:** schema validates; migration safe on large tables; index coverage; an explicit policy on every cached read; **no cache on a read that feeds a correctness-critical write**; **tenant scope in every query**; no N+1; no raw PII without encryption; the connection secret comes from the environment, never from code.
+- **Position:** beside the reviewer, when a diff touches the schema, a migration or a query; `qa` waits for its `APPROVED`.
+
+<!-- nina:slot db.2 -->
+  - **If the schema or a query was touched → dba approved.**

package/releases/0.65.0/surfaces/db/tree/.claude/retrieval.md

@@ -0,0 +1,5 @@
+<!-- nina:slot db.1 -->
+| Schema change | `.claude/architecture.md` § *Database*, the schema | implementer → reviewer + **dba** (mandatory) → qa |
+
+<!-- nina:slot db.2 -->
+| New query in app code | `.claude/patterns.md` § *Database conventions* | implementer → reviewer + **dba** (mandatory) → qa |

package/releases/0.65.0/surfaces/db/tree/.claude/router.md

@@ -0,0 +1,4 @@
+<!-- nina:slot db.1 -->
+
+### DBA is a guardrail, not a stage
+Invoke **dba** any time the schema, a migration or a query is touched — regardless of where you are in the pipeline. No such change reaches qa without dba approval; the reviewer names it on its Gates line.

package/releases/0.65.0/surfaces/db/tree/CLAUDE.md

@@ -0,0 +1,17 @@
+<!-- nina:slot db.3 -->
+| **ANY schema change, migration or new query** | **+ dba beside the reviewer** |
+
+<!-- nina:slot db.4 -->
+- **dba** → mandatory gate on schema changes, migrations, and new queries
+
+<!-- nina:slot db.5 -->
+2. **Every schema change, migration and new query goes through the dba subagent.** No exceptions. It runs beside the reviewer, which names it on its Gates line, and `qa` does not go out without its `APPROVED`.
+
+<!-- nina:slot db.6 -->
+6. **A cached read names its cache policy, and a read that feeds a write whose correctness depends on it being fresh is never cached.** An implicit cache is a bug, and a stale row contaminates every decision made from it. A write invalidates what it made stale.
+
+<!-- nina:slot db.7 -->
+7. **Tenant isolation is enforced in the data layer.** Every query in app code filters by `{{TENANT_KEY}}`, or reaches it through the model's foreign keys. No "global" queries except the auth library's own tables. Reviewer rejects any query missing the scope.
+
+<!-- nina:slot db.8 -->
+- **the database**: the schema, a migration, or a query

package/releases/0.65.0/surfaces/drizzle/tree/.claude/agents/dba.md

@@ -0,0 +1,9 @@
+<!-- nina:slot drizzle.1 -->
+No skill covers Drizzle. What `drizzle-orm` and `drizzle-kit` do is cited from their installed source, by
+`file:line`, like any installed library — and what they do on this project's engine, from its integration doc.
+
+<!-- nina:slot drizzle.2 -->
+- **With Drizzle, offline and failing closed.** Draft the migration with `drizzle-kit generate`, which needs no driver and no URL, in a copy of the tree in your scratch directory — it writes the SQL, a snapshot and a journal, and the tracked migrations are not yours to write — and read the SQL, not the schema delta. On SQLite kit drafts a table redefinition for a nullability, type, default or primary-key change, a foreign key added to an existing column or with a changed action, and a CHECK: look for one in every draft. drizzle-kit fails open: it has exited 0 with no file when a rename prompt could not render without a terminal, on a schema syntax error and with a missing journal, and exited 0 with a `DROP TABLE` for every table when the schema exported none. The check passes only on exit 0, empty stderr, and either exactly one new `.sql` holding the change you expected, or no new file and the exact line "No schema changes, nothing to migrate". A rename comes out as `RENAME COLUMN` or as `ADD` plus `DROP COLUMN` depending on that prompt's answer: read which you got. An `ADD COLUMN … REFERENCES` draft has dropped the declared `ON DELETE` while kit's snapshot kept it, so a later "no changes" passes over a database that differs from the schema — only a test against the applied schema sees it.
+
+<!-- nina:slot drizzle.3 -->
+- Run a drizzle-kit command that writes to a database — `push`, `migrate` — or give a drizzle config the credentials of a real one. `generate` answers everything this gate asks.

package/releases/0.65.0/surfaces/drizzle/tree/.claude/agents/devops.md

@@ -0,0 +1,5 @@
+<!-- nina:slot drizzle.1 -->
+- **Drizzle migrations go out through the one runner the architecture names**, as the SQL files the database gate read, and nothing else changes a shared database's schema.
+
+<!-- nina:slot drizzle.2 -->
+- Run `drizzle-kit push` against a shared database. It applies the schema without a migration file, so no gate read what it did.

package/releases/0.65.0/surfaces/drizzle/tree/.claude/agents/implementer.md

@@ -0,0 +1,2 @@
+<!-- nina:slot drizzle.1 -->
+- **With Drizzle, `db.transaction` and `db.batch` do what this project's driver does with them**, not what their types promise: `tsc` accepts calls a driver refuses at run time. Rely on either only as the integration doc's premises, cited from the driver's installed source, say it behaves.

package/releases/0.65.0/surfaces/drizzle/tree/.claude/patterns.md

@@ -0,0 +1,7 @@
+<!-- nina:slot drizzle.1 -->
+
+### Drizzle
+
+- Tables are declared in one schema module per storage backend, and only there.
+- A database error does not leave the data layer as Drizzle threw it: a failed single query's error carries the SQL and every bound value, in its message and as properties, so logging or serializing it publishes them. `logger: true` logs every parameter too.
+- Tests run a real Drizzle client against the real engine or its local emulator; the client is never mocked.

package/releases/0.65.0/surfaces/edge-cf/tree/.claude/agents/architect.md

@@ -0,0 +1,14 @@
+<!-- nina:slot edge-cf.1 -->
+| `cloudflare:workers-best-practices` | `{{API_DIR}}/**` — routes, services, middleware, queue handlers |
+
+<!-- nina:slot edge-cf.2 -->
+| `cloudflare:durable-objects` | `{{API_DIR}}/src/do/**` or any DO call site |
+
+<!-- nina:slot edge-cf.3 -->
+| `cloudflare:cloudflare` | Queues, R2 or KV |
+
+<!-- nina:slot edge-cf.4 -->
+| `cloudflare:wrangler` | its config or any wrangler command |
+
+<!-- nina:slot edge-cf.5 -->
+- **Cloudflare skill flag** — if the spec touches `{{API_DIR}}/**` (routes, services, queue handlers), the per-account Durable Object, Queues, R2/KV, or `wrangler` config, name which `cloudflare:*` plugin skill the implementer must consult (`cloudflare:workers-best-practices`, `cloudflare:durable-objects`, `cloudflare:cloudflare`, `cloudflare:wrangler`), or state why none applies. Retrieval beats recall — the reviewer rejects a spec that touches these surfaces without naming the skill.

package/releases/0.65.0/surfaces/edge-cf/tree/.claude/agents/dba.md

@@ -0,0 +1,2 @@
+<!-- nina:slot edge-cf.1 -->
+- **Edge runtime compatibility.** A database client that runs at the edge uses its edge build, and `nodejs_compat` is in the wrangler config's `compatibility_flags`.

package/releases/0.65.0/surfaces/edge-cf/tree/.claude/agents/devops.md

@@ -0,0 +1,29 @@
+<!-- nina:slot edge-cf.1 -->
+- **`cloudflare:wrangler`** — before running ANY `wrangler` command or reading the wrangler config.
+  CLI flags and config fields churn between minor versions; pre-trained knowledge is stale.
+
+<!-- nina:slot edge-cf.2 -->
+- **`cloudflare:cloudflare`** — when the deploy touches R2, KV, Queues or Durable Object bindings.
+
+<!-- nina:slot edge-cf.3 -->
+- **Every target the change reaches, or none.** A change to the API surface deploys the Worker's staging or preview, and — where the frontend deploys apart from it, as a Pages project or a Worker of its own — the frontend's too. Deploying a frontend alone against an old API is the failure that renders new fields as "—". Where one Worker serves the API and the frontend as static assets, the two are one deploy. State which targets this change requires and why.
+
+<!-- nina:slot edge-cf.4 -->
+- **Secret and variable parity.** Everything the new code reads via `env.*` exists in the target environment (`wrangler secret list`). A missing secret fails at request time, not at deploy time.
+
+<!-- nina:slot edge-cf.5 -->
+- **A variable the frontend bundle reads is in the environment of its build command.** The wrangler config's `vars` reach a Worker at runtime and never a bundler, which inlines what it reads at build time. A missing one ships a blank page with no error.
+
+## A frontend on Pages: which branch, and why it matters
+
+Only where the frontend deploys as a Pages project of its own; a Worker that serves it as static assets has no
+branch to choose. A **direct-upload** Pages project whose production branch is `main` goes to production or
+to preview by `wrangler pages deploy --branch` alone:
+
+- **Staging FE** → `--branch staging`. A preview deployment on its own URL. Production is untouched,
+  and this is the FE half of the staging pair with the Worker's staging.
+- **Production FE** → `--branch main`. Only with an explicit go from {{OWNER}}, per § *Production*.
+
+Deploying staging with `--branch=main` is a production deploy wearing a staging label — the
+permission classifier is right to stop it. Use the staging branch and the block disappears, because
+the block was correct.

package/releases/0.65.0/surfaces/edge-cf/tree/.claude/agents/implementer.md

@@ -0,0 +1,14 @@
+<!-- nina:slot edge-cf.1 -->
+| `cloudflare:workers-best-practices` | anything under `{{API_DIR}}/**` |
+
+<!-- nina:slot edge-cf.2 -->
+| `cloudflare:durable-objects` | anything under `{{API_DIR}}/src/do/**` or a DO call site |
+
+<!-- nina:slot edge-cf.3 -->
+| `cloudflare:cloudflare` | a queue consumer, or R2 / KV access |
+
+<!-- nina:slot edge-cf.4 -->
+| `cloudflare:wrangler` | a change to the wrangler config |
+
+<!-- nina:slot edge-cf.5 -->
+- Respect Workers conventions: secrets in `{{SECRETS_LOCAL}}` for local dev (never commit), `nodejs_compat` in the wrangler config's `compatibility_flags`.

package/releases/0.65.0/surfaces/edge-cf/tree/.claude/agents/integration-tester.md

@@ -0,0 +1,11 @@
+<!-- nina:slot edge-cf.1 -->
+| `cloudflare:durable-objects` | DO lifecycle, alarms, RPC, storage — the API surface drifts fast |
+
+<!-- nina:slot edge-cf.2 -->
+| `cloudflare:cloudflare` | Queues, R2 or KV bindings |
+
+<!-- nina:slot edge-cf.3 -->
+| `cloudflare:wrangler` | anything you run through the wrangler CLI |
+
+<!-- nina:slot edge-cf.4 -->
+- Any new Cloudflare binding read/write: R2, KV, Queues, Durable Objects — drive the binding via Miniflare and observe real I/O. Miniflare fetches `workers.cloudflare.com/cf.json` as it starts unless `CLOUDFLARE_CF_FETCH_ENABLED=false`: set it where a run promises no network beyond a named host

package/releases/0.65.0/surfaces/edge-cf/tree/.claude/agents/qa.md

@@ -0,0 +1,3 @@
+<!-- nina:slot edge-cf.1 -->
+Here `$STRAY` is `vitest|workerd`: a Worker test boots a second runtime process alongside vitest,
+and it is the one that holds ~2 GB and survives a killed test run.

package/releases/0.65.0/surfaces/edge-cf/tree/.claude/agents/reviewer.md

@@ -0,0 +1,8 @@
+<!-- nina:slot edge-cf.1 -->
+| `cloudflare:workers-best-practices` | `{{API_DIR}}/**` |
+
+<!-- nina:slot edge-cf.2 -->
+| `cloudflare:durable-objects` | `{{API_DIR}}/src/do/**` or a DO call site |
+
+<!-- nina:slot edge-cf.3 -->
+- `{{API_DIR}}/src/do/`, a queue consumer, or a webhook receiver touched (serialization + idempotency surface)

package/releases/0.65.0/surfaces/edge-cf/tree/.claude/agents/secops.md

@@ -0,0 +1,8 @@
+<!-- nina:slot edge-cf.1 -->
+- **Secrets & config exposure** — no secrets in committed files, logs, error messages, or generated artifacts (`worker-configuration.d.ts` must contain only types, never values). `{{SECRETS_LOCAL}}`/`.env` gitignored. The split between `wrangler secret` and the wrangler config's `vars` is correct. No secret echoed in a response or thrown error.
+
+<!-- nina:slot edge-cf.2 -->
+- **Dependency & binding posture** — obviously risky dependency usage; Cloudflare binding scoping (R2 bucket names, Queue, DO) — nothing over-privileged or world-exposed; `nodejs_compat` and compatibility flags sane.
+
+<!-- nina:slot edge-cf.3 -->
+- Prefer retrieval over recall for Cloudflare/{{AUTH_LIB}} specifics: consult the `cloudflare:*` skills and the installed `node_modules` source / `.claude/integrations/*.md` rather than assuming.

package/releases/0.65.0/surfaces/edge-cf/tree/.claude/patterns.md

@@ -0,0 +1,17 @@
+<!-- nina:slot edge-cf.1 -->
+
+---
+
+## Secrets
+
+- **Wrangler secrets** for Workers (`{{SECRETS_PROD}} X`). Never `.env` committed.
+- **Local dev:** `{{SECRETS_LOCAL}}` (gitignored).
+
+<!-- nina:slot edge-cf.2 -->
+- `nodejs_compat` in the wrangler config's `compatibility_flags` is required for a database client that runs at the edge.
+
+<!-- nina:slot edge-cf.3 -->
+- **Miniflare** for Worker integration tests.
+
+<!-- nina:slot edge-cf.4 -->
+- **Miniflare** for Worker tests — the real Cloudflare runtime, no mocks.

package/releases/0.65.0/surfaces/edge-cf/tree/.claude/retrieval.md

@@ -0,0 +1,8 @@
+<!-- nina:slot edge-cf.1 -->
+| New Durable Object behavior | `.claude/architecture.md` § *Durable Objects*, existing `{{API_DIR}}/src/do/` | architect → implementer → reviewer + the integration gate, where there is one → qa |
+
+<!-- nina:slot edge-cf.2 -->
+| New Queue handler | `.claude/architecture.md` § *Processing pipeline*, `{{API_DIR}}/src/queues/` | architect → implementer → reviewer + the integration gate, where there is one → qa |
+
+<!-- nina:slot edge-cf.3 -->
+| Wrangler / deploy / config | `CLAUDE.md` § *Common commands*, the wrangler config (`wrangler.jsonc` or `wrangler.toml`), `.claude/patterns.md` § *Secrets* | implementer → reviewer → qa → devops |

package/releases/0.65.0/surfaces/edge-cf/tree/CLAUDE.md

@@ -0,0 +1,27 @@
+<!-- nina:slot edge-cf.1 -->
+
+### Cloudflare plugin skills — USE THEM
+
+The `cloudflare@cloudflare` plugin is installed at user scope and exposes skills that retrieve the **current** Cloudflare docs at invocation time. Pre-trained knowledge of Workers / Wrangler / DO / Queues / Cron APIs is stale — prefer the skill over recalling from memory.
+
+<!-- nina:slot edge-cf.2 -->
+| Write or review code under `{{API_DIR}}/**` (routes, services, middleware, webhook receivers, queue consumers) | `cloudflare:workers-best-practices` | catches floating promises, global-state misuse, missing `waitUntil`, streaming pitfalls |
+
+<!-- nina:slot edge-cf.3 -->
+| Touch `{{API_DIR}}/src/do/**` or any Durable Object call site | `cloudflare:durable-objects` | covers RPC, alarms, WebSocket, SQLite storage, lifecycle — DO API surface drifts fast |
+
+<!-- nina:slot edge-cf.4 -->
+| Touch `{{API_DIR}}/src/queues/**`, R2/KV usage | `cloudflare:cloudflare` | Queues, R2, KV decision tree |
+
+<!-- nina:slot edge-cf.5 -->
+| Author or modify `wrangler.toml` / `wrangler.jsonc` / run any `wrangler` CLI command | `cloudflare:wrangler` | CLI flags + config fields churn between minor versions |
+
+<!-- nina:slot edge-cf.6 -->
+| Run the **devops** deploy stage | `cloudflare:wrangler` (+ `cloudflare:cloudflare` for R2/KV/Queues/DO bindings) | deploy flags and binding config churn between versions |
+
+<!-- nina:slot edge-cf.7 -->
+
+The plugin's other skills — `cloudflare:agents-sdk`, `cloudflare:sandbox-sdk`, `cloudflare:cloudflare-email-service` — apply only where {{PROJECT}} adopts what they cover: an agent runtime, untrusted code execution, sending mail.
+
+<!-- nina:slot edge-cf.8 -->
+10. **Secrets in `{{SECRETS_LOCAL}}` for local dev, `{{SECRETS_PROD}}` for production.** Never `.env` committed. `nodejs_compat` is required in the `compatibility_flags` of the wrangler config (`wrangler.jsonc` or `wrangler.toml`) for any database client that runs at the edge.

package/releases/0.65.0/surfaces/frontend/tree/.claude/agents/architect.md

@@ -0,0 +1,20 @@
+<!-- nina:slot frontend.1 -->
+| `cloudflare:web-perf` | a page-load performance question in `{{APP_DIR}}` |
+
+<!-- nina:slot frontend.2 -->
+
+## Visual acceptance — required in any spec touching `{{APP_DIR}}/**`
+
+A frontend spec that describes only structure produces a diff that only structure can verify, and
+structure is exactly what a test renderer checks while blind to the result. So state, as a short
+checklist, what must be TRUE ON THE SCREEN at **1440** and at **375**:
+
+- what is visible, and what must not be
+- what sits beside what, and what wraps or stacks at 375
+- the empty, loading and error states, if the change can produce them
+- anything that must not overflow, clip or overlap
+
+Each line must be checkable from a screenshot by someone who did not write the code — the **reviewer**
+checks the render against this list, and rejects on a mismatch. "Follows the design system" is not a
+criterion. A spec that touches `{{APP_DIR}}/**` without this section is incomplete, and the reviewer
+rejects it back to you.

package/releases/0.65.0/surfaces/frontend/tree/.claude/agents/devops.md

@@ -0,0 +1,28 @@
+<!-- nina:slot frontend.1 -->
+- Playwright is **not** a skill — it is an MCP server, and its `browser_*` tools are granted to you
+  directly in `tools:` above. Use them; there is nothing to invoke via `Skill`.
+
+<!-- nina:slot frontend.2 -->
+- **Build-time env.** A bundler inlines the variables the app reads at build time, so one the deploy platform supplies at RUNTIME never reaches the bundle — it is not late, it is absent. Verify every variable the app reads is present in the build environment — a missing one ships a blank page, not an error.
+
+<!-- nina:slot frontend.3 -->
+
+## Render smoke — for any diff touching `{{APP_DIR}}/**`
+
+You are not the visual gate; the **reviewer** is, and it judges the render against the spec before
+the code ever reaches you. Your question is narrower and different: **did the deployed thing come up
+at all?** That is not the same failure — a build that renders perfectly on a reviewer's localhost
+still ships a blank page when the API's address was missing from the deploy build.<!-- nina:why --> That is exactly
+what happened here once.<!-- /nina:why -->
+
+So on the preview URL, not localhost: `browser_navigate`, one screenshot at 1440, and
+`browser_console_messages`. You are checking that the page renders and the console is clean — not
+whether the layout is right. A blank page or a console error is `VERDICT: BLOCKED`.
+
+<!-- nina:slot frontend.4 -->
+
+If the changed path genuinely cannot be smoked without authenticating, do NOT authenticate: say so,
+report what you could verify, and hand the authenticated check to a human.
+
+<!-- nina:slot frontend.5 -->
+, mcp__plugin_playwright_playwright__browser_navigate, mcp__plugin_playwright_playwright__browser_resize, mcp__plugin_playwright_playwright__browser_take_screenshot, mcp__plugin_playwright_playwright__browser_snapshot, mcp__plugin_playwright_playwright__browser_console_messages, mcp__plugin_playwright_playwright__browser_close

package/releases/0.65.0/surfaces/frontend/tree/.claude/agents/implementer.md

@@ -0,0 +1,25 @@
+<!-- nina:slot frontend.1 -->
+| `frontend-design:frontend-design` | new UI in `{{APP_DIR}}` — a page or component that did not exist |
+
+<!-- nina:slot frontend.2 -->
+
+## Look at the screen you built
+
+When you change anything under `{{APP_DIR}}/**`, open it in the browser before you hand off — the dev
+server or a local build, with `browser_navigate` plus a screenshot at 1440 and 375. Your test suite
+renders with no layout engine, in jsdom or to a string in Node, and cannot tell you whether the thing renders.
+
+This is a self-check, not a gate: you are the author, and an author reviewing their own work catches
+the obvious and misses the rest. **reviewer** is the gate. The point of doing it here is that the
+obvious defects are cheap to fix now and expensive after review, qa and a deploy.
+
+Report what you saw. "Rendered at both widths, matches the spec's Visual acceptance" — or what
+differed.
+
+That is also why a component test must assert content, not presence: `toHaveTextContent('4 matched')`,
+not `toBeInTheDocument()` on the badge that shows it, and never `toHaveClass` as proof that something
+looks right — it passes whether or not a pixel landed. A test that pins a removal renders the tab or
+route where the removed thing used to appear; rendering the default one proves nothing about another.
+
+<!-- nina:slot frontend.3 -->
+, mcp__plugin_playwright_playwright__browser_navigate, mcp__plugin_playwright_playwright__browser_resize, mcp__plugin_playwright_playwright__browser_take_screenshot, mcp__plugin_playwright_playwright__browser_snapshot, mcp__plugin_playwright_playwright__browser_console_messages, mcp__plugin_playwright_playwright__browser_close

package/releases/0.65.0/surfaces/frontend/tree/.claude/agents/qa.md

@@ -0,0 +1,17 @@
+<!-- nina:slot frontend.1 -->
+
+## What your green does not mean
+
+Your suite renders with **no layout engine**, in jsdom or to a string in Node. `toHaveClass('flex')` passes whether or not
+anything was laid out; nothing you run can tell you the screen is right. When you report PASS on a
+diff touching `{{APP_DIR}}/**`, say so — the rendering is checked by the **reviewer**, against the
+spec's Visual acceptance criteria. A PASS read as "the screen works" is how frontend
+defects reached staging through every gate.
+
+## When a failure arrives labelled "pre-existing"
+
+On this surface the cause is usually the test harness rather than the feature — a text query matching
+several elements at once, a missing router context for a link, a `vi.mock` hoisted above the value it
+closes over, jsdom without `showModal`, a hardcoded origin. Every one of them is fixable in the test
+without weakening the assertion, and every one of them stays invisible for exactly as long as the
+failure keeps the label.

package/releases/0.65.0/surfaces/frontend/tree/.claude/agents/reviewer.md

@@ -0,0 +1,56 @@
+<!-- nina:slot frontend.2 -->
+- **If the diff touches `{{APP_DIR}}/**`: the spec — or the dispatch, in a chain with no architect — must carry a Visual acceptance section, and you check the render against it — see *Visual gate* below.** No section → REJECT upstream to whoever wrote it.
+
+<!-- nina:slot frontend.3 -->
+- `{{BUILD_CMD}}` for the affected frontend packages (`{{APP_DIR}}`)
+
+<!-- nina:slot frontend.4 -->
+## Visual gate — you are the stage that looks at the screen
+
+Deciding whether a screen is right is review, not operations, and it belongs here. qa runs vitest with
+**no layout engine**, in jsdom or rendering to a string: `toHaveClass('flex')` passes whether or not a single pixel
+landed anywhere. Every gate before you reads text. This is why backend work lands first time through
+this pipeline and frontend work does not — the frontend defects were never expressible as a test.
+
+For any diff touching `{{APP_DIR}}/**`:
+
+1. Build and serve it the way this project serves a build for review:
+
+   ```bash
+   {{VISUAL_SERVE}}
+   ```
+
+   Where screens sit behind a login, this command is what gets past it: a plain static server
+   screenshots the login page. Where the build reaches an API at an address fixed at build time, one
+   that does not match what the command serves ships a screen that renders but fetches nothing. A
+   request the served build does not answer is a gap in it: send it back naming the request, rather
+   than judge a broken screen. It must also reach the empty and error states the change has; a state
+   you cannot reach is a state nobody reviewed.
+2. `browser_navigate` to the changed screen. Screenshot at **1440** and at **375**
+   (`browser_resize` first — the viewport resets to a narrow default across navigations, so
+   resize AFTER navigating and confirm the width in the screenshot before you judge it).
+
+   Many screens are not reachable by URL: a tab kept in component state is never in the route, so
+   `browser_click` is the ONLY way in — a navigate-and-screenshot lands on the default tab and proves
+   nothing about the changed one.
+3. **Measure, do not squint.** `browser_evaluate` turns "looks fine" into a number, and an
+   overflow you can measure is one you can attribute. To decide whether horizontal scroll is
+   yours or pre-existing, measure `document.documentElement.scrollWidth` vs `clientWidth` on
+   the changed screen AND on an untouched one — and, when it matters, build `HEAD` into a second
+   dist from a worktree (Hard Rule #18) and measure both. Reporting a pre-existing app-wide defect
+   as a regression wastes a cycle; excusing a real one as "probably pre-existing" ships it.
+4. Check each screenshot against the spec's **Visual acceptance** list, item by item. Not "looks
+   fine" — the specific claims the spec made.
+5. `browser_console_messages`. An error there is a defect even when the page renders.
+
+A screen that contradicts the spec is `REJECTED`, with the screenshot and what is wrong in it. Say in
+your report which widths you looked at; a frontend approval that does not mention having looked is
+the failure this section exists to end.
+
+<!-- nina:slot frontend.1 -->
+, mcp__plugin_playwright_playwright__browser_navigate, mcp__plugin_playwright_playwright__browser_resize, mcp__plugin_playwright_playwright__browser_take_screenshot, mcp__plugin_playwright_playwright__browser_snapshot, mcp__plugin_playwright_playwright__browser_console_messages, mcp__plugin_playwright_playwright__browser_click, mcp__plugin_playwright_playwright__browser_evaluate, mcp__plugin_playwright_playwright__browser_close
+
+<!-- nina:slot frontend.5 -->
+- **visual** — the spec's Visual acceptance section exists and the render matches it (see *Visual gate*).
+  A reviewer checking only another dimension skips it, so it is its own: owned by **patterns-and-scope**
+  when no visual reviewer is dispatched, and never nobody's.

package/releases/0.65.0/surfaces/frontend/tree/.claude/patterns.md

@@ -0,0 +1,8 @@
+<!-- nina:slot frontend.1 -->
+
+---
+
+## Frontend conventions
+
+This project's own — its framework, where server state lives, how it styles, and what it shares between
+apps — are in `.claude/frontend.md`. Read them before writing or reviewing code under `{{APP_DIR}}`.

package/releases/0.65.0/surfaces/frontend/tree/.claude/retrieval.md

@@ -0,0 +1,2 @@
+<!-- nina:slot frontend.1 -->
+| Frontend (`{{APP_DIR}}`) | `.claude/frontend.md`, `.claude/architecture.md` § *Frontend* | implementer → reviewer → qa |

package/releases/0.65.0/surfaces/frontend/tree/.claude/router.md

@@ -0,0 +1,14 @@
+<!-- nina:slot frontend.2 -->
+
+### Nothing before devops can see the screen
+The reviewer reads a diff. qa runs vitest with **no layout engine**, in jsdom or rendering to a string — `toHaveClass('flex')`
+passes whether or not a pixel landed anywhere. Every backend invariant is checkable in text, which is why
+the same pipeline lands backend work first time and lets frontend defects through every gate: they were
+never expressible as a test.
+
+So any diff touching `{{APP_DIR}}/**` carries a visual contract: the **architect** writes a *Visual acceptance*
+checklist (what must be true on screen at 1440 and 375), the **reviewer** rejects an FE spec without one, the
+**implementer** looks at its own screen before handing off, and the **reviewer** builds, serves and screenshots it,
+rejecting on a mismatch — judging the screen is review, not operations. **devops** only smokes the
+deployed preview for a blank page. Browser access is granted through the Playwright MCP `browser_*` tools in those agents'
+`tools:` lists — it is not a skill, and an agent without those tools in its list cannot see anything.

package/releases/0.65.0/surfaces/frontend/tree/CLAUDE.md

@@ -0,0 +1,5 @@
+<!-- nina:slot frontend.1 -->
+| Audit page-load perf on `{{APP_DIR}}` — LCP, INP, CLS, bundle size | `cloudflare:web-perf` | Core Web Vitals + Chrome DevTools MCP integration |
+
+<!-- nina:slot frontend.2 -->
+| **ANY diff touching `{{APP_DIR}}/**`** | architect writes a **Visual acceptance** checklist (the dispatch carries it in a chain with no architect); the **reviewer builds, serves and screenshots at 1440 and 375** and rejects on a mismatch; devops smokes the deployed preview for a blank page. A test renderer has no layout engine — a green suite says nothing about the screen |

package/releases/0.65.0/surfaces/integrations/tree/.claude/agents/architect.md

@@ -0,0 +1,16 @@
+<!-- nina:slot integrations.1 -->
+- **Integration premises (MANDATORY when an integration boundary is in scope)** — list every behavior of the dependency the implementation depends on. Each premise is a one-sentence claim followed by the evidence its kind requires:
+    - `installed-library` → `<package dir>/node_modules/<lib>/<file>:<line>`, the version installed here beside it — the package's own link, which a peer change does not rename; a dependency of a dependency, through its parent's: `<package dir>/node_modules/<parent> → <lib>@<version>/<file>:<line>`
+    - `live-api` → a contract-test case, or a response observed against the service and captured verbatim
+    - `platform-binding` → behavior observed under the local emulator, plus the platform's installed types
+    - or a `P<n>` reference into `.claude/integrations/<slug>.md`, which itself carries one of the above
+
+    A premise without a citation is an **assumption**, not a fact. The integration-tester rejects the spec if a cited line does not validate at runtime, and rejects it outright if it lists uncited premises. When in doubt: read the source. A live service you have no way to read is observed for you: report `BLOCKED` with an `ISSUES` id per premise to observe, the integration-tester records each as a `P<n>` with the response it got, and you are resumed with them. Integration regressions ship precisely when a premise is assumed instead of cited.
+
+    Also mark **"INTEGRATION-TESTER REQUIRED"** prominently at the top of the spec when this section is present.
+
+<!-- nina:slot integrations.3 -->
+- **For every integration behavior the implementation will rely on, get the evidence its kind requires** — open the installed source and cite `file:line`, or, for a live service, have it observed first (report `BLOCKED` naming what to observe). Library docs and editor autocomplete are not citations. This is the single most important rule for avoiding integration regressions.
+
+<!-- nina:slot integrations.4 -->
+- **State an integration's behavior as fact without the evidence its kind requires.** Uncited premises are assumptions, and assumptions are what ship integration bugs to prod. If you cannot find the citation, the answer is to read more source or escalate — not to write the spec anyway.

package/releases/0.65.0/surfaces/integrations/tree/.claude/agents/implementer.md

@@ -0,0 +1,12 @@
+<!-- nina:slot integrations.1 -->
+- If you change anything that touches an integration boundary, or add a call into one, flag it explicitly in the diff summary so the reviewer dispatches **integration-tester** before approving.
+
+<!-- nina:slot integrations.3 -->
+
+## Integrations
+- All access to a dependency goes through its **boundary module**, named in `.nina/profile.json`. **Never** reach it directly from a service, route, queue consumer or scheduled handler.
+- For a `live-api`, the contract-test suite is the source of truth and **both** implementations must pass it. Inject the mock in tests — and never let the mock be the only thing that ran.
+- Honor the spec's **Integration premises** verbatim. If one looks wrong while you are writing code against it, STOP and loop back to the architect. Do not work around a premise: the premise is the contract, and a contract that is wrong gets fixed, not bypassed.
+
+<!-- nina:slot integrations.4 -->
+- Reach an integration from anywhere outside its boundary module. Inject the mock in tests.

package/releases/0.65.0/surfaces/integrations/tree/.claude/agents/integration-tester.md

@@ -0,0 +1,20 @@
+<!-- nina:slot integrations.2 -->
+2. **Live APIs.** A third-party service you reach over the network — payments, messaging, automation, mail. *Their* API is the contract; we conform to it. There IS a real service to hit, so you run the **contract-test suite** for that boundary against **BOTH** the real client and the mock, and you check each `P<n>` premise in `.claude/integrations/<slug>.md` against what the service actually returns.
+
+<!-- nina:slot integrations.3 -->
+- The boundary module of any declared integration, or a new call into one
+
+<!-- nina:slot integrations.6 -->
+- For the integration you are gating: `.claude/integrations/<slug>.md`. Read EVERY premise it lists, not a sample — the one you skip is the one the diff depends on.
+
+<!-- nina:slot integrations.7 -->
+
+## You MUST — live APIs
+
+- **Run the contract-test suite** for the boundary against **both** implementations. Every `P<n>` in the integration's doc maps to a case — verify every one the diff touches.
+- **Never accept a green mock as proof.** If only the mock run is green you have verified nothing about production. Say so, and reject.
+- **Confirm nothing reaches the service outside its boundary module.** Grep the diff and the tree for raw HTTP or client construction past the boundary. Any leak is a hard reject.
+- **Confirm the boundary validates responses** in both implementations, so drift in the service surfaces structurally rather than as a type error three layers downstream.
+
+<!-- nina:slot integrations.8 -->
+- **Update `.claude/integrations/<slug>.md` when you observe new behavior**, with the evidence that settled it: a contract case, an observed response, or a source citation.

package/releases/0.65.0/surfaces/integrations/tree/.claude/agents/planner.md

@@ -0,0 +1,2 @@
+<!-- nina:slot integrations.1 -->
+- **Integration flag** — if any subtask touches the boundary of a declared integration, or adds a call into one, mark **"INTEGRATION-TESTER REQUIRED"** on that subtask.

package/releases/0.65.0/surfaces/integrations/tree/.claude/agents/reviewer.md

@@ -0,0 +1,21 @@
+<!-- nina:slot integrations.1 -->
+- **If an integration boundary was touched anywhere in the diff, or a new call into one was added: name `integration-tester` on your Gates line.** Also verify the architect's spec carries an **Integration premises** section, each premise with the evidence its kind requires. If the section is missing or uncited, REJECT upstream — do not approve a diff against an incomplete spec.
+
+<!-- nina:slot integrations.3 -->
+- The diff touches an integration boundary — **integration-tester also required**
+
+<!-- nina:slot integrations.4 -->
+- Leave `integration-tester` off your Gates line "because the unit tests pass." Unit tests honor the spec's mock, not the real dependency — only the integration-tester catches drift.
+
+<!-- nina:slot integrations.5 -->
+- Integration boundary touched and `integration-tester` not dispatched → name it on your Gates line; the orchestrator sends it.
+
+<!-- nina:slot integrations.6 -->
+- Spec touches an integration boundary but lacks the **Integration premises** section with citations → back to **architect** for spec amendment (do NOT approve the implementer's diff against an incomplete spec).
+
+<!-- nina:slot integrations.7 -->
+- **The one exception is a `live-api` contract-test case.** Its job is to catch the real service
+  diverging from the mock, not to encode a mutation of code this project owns, so there is often no
+  change on this side that turns it red. Name the divergence it would catch instead — "the provider
+  renames a field the mock still sends" — and do not reject it for lacking a mutation: that test is
+  integration-tester's gate, and rejecting it here would remove the one check that watches the mock.

package/releases/0.65.0/surfaces/integrations/tree/.claude/agents/secops.md

@@ -0,0 +1,2 @@
+<!-- nina:slot integrations.1 -->
+- **Input validation / injection / SSRF** — validate at every trust boundary: request body, query, queue message, webhook payload, and every integration response. Parameterized queries only — never string-built SQL. Outbound HTTP to an integration: SSRF and URL-allowlist posture. Start with the unauthenticated internet-facing paths — a webhook receiver, a health route, a dev-only surface — and verify their signature or secret gate cannot be bypassed or replayed.

package/releases/0.65.0/surfaces/integrations/tree/.claude/agents-overview.md

@@ -0,0 +1,8 @@
+<!-- nina:slot integrations.1 -->
+- **Integration guardrail** → a spec describes behavior the implementer relies on, and unit tests with structural mocks honor the *spec*, not the dependency. The integration-tester runs the real thing: real flows for an installed library or a platform binding, and for a live API the contract suite against both the real client and the mock, so the two cannot diverge. Drift between assumption and reality is caught before deploy rather than after.
+
+<!-- nina:slot integrations.2 -->
+| **integration-tester** | Mandatory gate on any integration boundary; runs real flows, and for a `live-api` the contract suite against both implementations; verifies each cited premise; keeps `.claude/integrations/<slug>.md` current | `.claude/agents/integration-tester.md` |
+
+<!-- nina:slot integrations.3 -->
+- **`.claude/integrations/`** — one doc per integration, holding its verified premises