baldart 3.14.1 → 3.16.0

package/CHANGELOG.md

@@ -5,6 +5,85 @@ All notable changes to BALDART will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [3.16.0] - 2026-05-23
+
+The `/new` orchestrator becomes specialist-aware: it now reads `owner_agent` from each card YAML and dispatches the right implementation agent — `coder` for backend/logic, `ui-expert` for UI cards, with `plan`/`visual-designer`/`motion-expert` reserved as stubs that fall back to `coder` with a WARN. UI cards (`owner_agent: ui-expert`) receive a dedicated mission briefing that enforces the registry-first BLOCKING cascade (read `${paths.design_system}/INDEX.md` + `tokens-reference.md` + per-component specs BEFORE coding), the implementation-only constraint (no mockup redesign — STOP and ask on registry conflicts), and the Post-Intervention Coherence Check (reconcile INDEX + components + tokens in the same commit). The PRD side enforces the contract end-to-end: `owner_agent` is now a mandatory enum on every child card, UI cards have UI-only scope (logic moves to a sibling `coder` card), and the validation phase blocks commit on enum violations + warns on mixed-scope UI cards.
+
+Until now, every card from `/new` was spawned to the generic `coder` agent regardless of `owner_agent`, and mockups arrived as a textual "match this reference" hint without triggering the registry/tokens/specs cascade that `ui-expert` mandates. The symptom reported by users: graphical code generated from mockups was "not quite right" — wrong shadows, off-scale font sizes, off-palette colors. Root cause: the right specialist existed and PRD cards declared it (`owner_agent: ui-expert`), but the dispatcher never read the field.
+
+### Added — Agent router + UI specialist briefing
+
+- **§ Agent Routing section in [framework/.claude/skills/new/SKILL.md](framework/.claude/skills/new/SKILL.md)** between Pre-flight and Per-card pipeline. Documents the `owner_agent` → spawn-target mapping in a single table (coder | ui-expert | plan | visual-designer | motion-expert → resolved agent + briefing variant) with a cross-reference list of the 5 layers that must stay in lockstep (template, prd.md enum, prd-card-writer rule, validation-phase check, REGISTRY.md decision tree).
+- **Step 6b "Agent dispatch (router)" in Phase 2** of [framework/.claude/skills/new/SKILL.md](framework/.claude/skills/new/SKILL.md). Reads `card.owner_agent`, resolves the spawn target via a switch with explicit fallbacks: `coder` → coder briefing; `ui-expert` → ui-expert briefing; `plan`/`visual-designer`/`motion-expert` → coder briefing + WARN ("specialized briefing not yet implemented"); empty/`claude`/missing → coder briefing + WARN; unknown value → HALT and ask the user. The resolved spawn + briefing pair is logged in the tracker as the audit trail.
+- **`[UI-ONLY]` mission briefing sections** in Phase 2 step 7 of [framework/.claude/skills/new/SKILL.md](framework/.claude/skills/new/SKILL.md). Three new sections inserted between "Design Reference" and "File Permissions", included ONLY when the router resolves `briefing = "ui-expert"`:
+  - **Registry-first BLOCKING pre-work** — reproduces verbatim the cascade defined in [framework/.claude/agents/ui-expert.md](framework/.claude/agents/ui-expert.md) § "Registry-first pre-work (BLOCKING)": read `INDEX.md` + `tokens-reference.md` + `components/<Name>.md` for every primitive in scope, declare which Authority Matrix rows govern the card in the first response. Orchestrator rejects the implementation if the declaration is missing.
+  - **Implementation-only constraint** — explicit DO NOTs: don't redesign the mockup, don't silently adapt registry-conflicting details (STOP + `[DS-DRIFT] mockup-vs-registry` log + ask the user), don't extend scope into business logic / API / state / validation (split-into-sibling-card is upstream PRD concern).
+  - **Post-Intervention Coherence Check** — citation of [framework/agents/design-system-protocol.md](framework/agents/design-system-protocol.md) § "Post-Intervention Coherence Check": reconcile `INDEX.md` (drift code `DS_INDEX_DRIFT`) + `components/<Name>.md` (`DS_COMPONENT_STALE`) + `tokens-reference.md` (`DS_TOKENS_DRIFT`) in the same commit. The completion report MUST include a `design_system_coherence:` block enumerating the artifacts updated.
+- **`[UI-ONLY]` design-system conformance step in Phase 2.5** of [framework/.claude/skills/new/SKILL.md](framework/.claude/skills/new/SKILL.md). New row in the Completeness Check verification depth, runs only when `briefing = "ui-expert"` AND `features.has_design_system: true`. Greps changed files for hardcoded design values that bypass the registry (hex colors, `rgb(`, inline `box-shadow:` offsets, raw px/rem `border-radius:`/`font-size:`/spacing); verifies the `design_system_coherence:` block in the completion report; verifies new primitives ship their `components/<Name>.md` spec in the same commit; verifies new tokens land in `tokens-reference.md`. Each gap classified Partial → fix-coder sub-loop.
+
+### Added — PRD-side enforcement (split-scope + mandatory enum)
+
+- **§ MANDATORY Card Rules (Rule A + Rule B)** in [framework/.claude/skills/prd/references/backlog-phase.md](framework/.claude/skills/prd/references/backlog-phase.md). New section between MANDATORY Card Structure and Specialist Audits. **Rule A**: every child card MUST declare `owner_agent` with one of the five enum values; missing/empty/placeholder/non-enum BLOCKS commit. **Rule B**: cards with `owner_agent: ui-expert` MUST be UI-only — components, layout, styling, motion, accessibility — and MUST NOT bundle business logic, API integration, state management, validation logic, or backend changes; mixed steps split into a `ui-expert` card (visual, consumes mocked contract) + a `coder` card (logic, API, state) wired via `depends_on:`/`blocks:`. Ships a canonical Login feature split example (bad: single mixed card; good: `FEAT-XXXX-02` UI + `FEAT-XXXX-01` logic).
+- **§ Agent Specialization Rules in [framework/.claude/agents/prd-card-writer.md](framework/.claude/agents/prd-card-writer.md)** before Card Atomicity Rules. The same Rule A + Rule B formulated from the agent writer's POV (which value to pick per work type, what NOT to bundle, when not to assign `ui-expert` to a tight-knit mixed card). Cross-references the backlog-phase split example for canonical guidance.
+- **§ Step 6 Agent Specialization Audit (new step 0)** in [framework/.claude/skills/prd/references/validation-phase.md](framework/.claude/skills/prd/references/validation-phase.md). Runs FIRST, before the Field Name Audit. Step 0a: `owner_agent` enum check (BLOCKING) — halts the audit on missing/empty/placeholder/non-enum with an actionable message. Step 0b: UI-only scope heuristic (WARN, soft gate) — for each `ui-expert` card, greps `scope.summary` + `requirements` + `acceptance_criteria` for logic markers (`api call`, `endpoint`, `route handler`, `state machine`, `validation logic`, `business rule`, `database`, `migration`, `prisma`, `auth flow`, `token storage`, `webhook`, `cron`) and emits `[UI-SCOPE-WARN]` lines for human review. Intentionally soft: legitimate UI references to mocked contracts ("consumes `useAuth()` mock") don't trip the WARN thanks to the consume/mock/contract-reference exception.
+- **§ Card-template fields updated** in [framework/.claude/skills/prd/assets/card-template.yml](framework/.claude/skills/prd/assets/card-template.yml). The placeholder `owner_agent: claude` is replaced with `owner_agent: <REQUIRED — coder | ui-expert | plan | visual-designer | motion-expert>` so a card left at the placeholder fails validation. A leading comment block documents each enum value (one line each) and a comment under `scope:` reminds the writer of the UI-only constraint for `ui-expert` cards.
+- **§ Epic-template aligned to the tracker-only contract** in [framework/.claude/skills/prd/assets/epic-template.yml](framework/.claude/skills/prd/assets/epic-template.yml). `owner_agent` changes from the legacy `claude` placeholder to `""` (empty string) with an inline comment clarifying that epics are tracker-only — the dispatcher skips them and the validation-phase enum-check exempts them — so the empty value is the correct signal that no specialist is assigned to an epic. Prevents the false-positive of writing a child enum value (e.g. `coder`) on an epic and implying it carries implementation work.
+
+### Notes
+
+- **No new `baldart.config.yml` keys** — the schema-change propagation rule does not apply to this release. The router consumes an existing field (`owner_agent`) already present in the PRD card schema.
+- **Backwards compatibility for cards written before v3.16.0.** The dispatcher accepts `owner_agent: ""` / missing / legacy `claude` value via the WARN-and-fallback-to-coder branch, so existing backlogs keep working — the WARN surfaces the gap on first use without blocking. New PRD sessions on v3.16.0+ produce enum-compliant cards from the start; the validation phase's enum BLOCKER applies only to NEW cards generated under v3.16.0+.
+- **Specialist briefings for `plan` / `visual-designer` / `motion-expert` are stubs** in this release — they fall back to the coder briefing with a WARN. Specialized briefings will follow in future iterations without further schema changes (the router structure is already in place).
+- **`ui-expert` in `/new` is implementation-only by design** — refinement of the mockup remains a PRD-phase responsibility (the `ui-design-phase` skill handles design decisions). If the implementation step finds a mockup-vs-registry conflict, `ui-expert` STOPs and asks the user; it does not auto-adapt the mockup. This boundary is documented in the `[UI-ONLY] Implementation-only constraint` briefing section.
+- **REGISTRY.md decision tree** in [framework/.claude/agents/REGISTRY.md](framework/.claude/agents/REGISTRY.md) gains a header note clarifying that `/new` dispatches by `owner_agent` (not by re-running the decision tree) — the tree remains authoritative for ad-hoc spawns and for `prd-card-writer`'s writing decisions, with a lockstep-with-skill warning to keep the 5 layers in sync.
+- **Verification is manual** (no test suite — `npm test` remains a no-op stub). Dogfood scenarios to run after install: (1) `/new <CARD-ID>` on a card with `owner_agent: coder` → identical behavior to v3.15.x (no regression); (2) `/new <CARD-ID>` on a card with `owner_agent: ui-expert` + valorized `links.design` → `ui-expert` is spawned (not coder), the briefing contains the BLOCKING cascade verbatim, the implementation reads `INDEX.md` + `tokens-reference.md` + `components/<Name>.md` BEFORE coding, the completion report ships the `design_system_coherence:` block, the commit reconciles the three design-system sources; (3) `/new` on a legacy card with `owner_agent: claude` or missing field → fallback to coder + WARN line in tracker; (4) `/prd` on a feature involving login (UI + logic) → produces TWO cards (`UI-LOGIN-*` ui-expert + `LOGIC-LOGIN-*` coder) wired via `depends_on:` rather than one mixed coder card; (5) PRD validation phase on a card with `owner_agent: ""` → enum BLOCKER, commit refused.
+
+## [3.15.0] - 2026-05-23
+
+Two changes ship together. **(1) PRD becomes mockup-aware** — formal intake of existing mockups between Kickoff and Discovery, with a per-screen decision tree in Step 3 that skips generation for screens already covered. **(2) Framework becomes stack-aware** — four new `stack.*` cardinal scalars (`database`, `auth_provider`, `framework`, `deployment`) drive vocabulary, gate sections, anti-pattern checklists, and deploy commands across `/prd`, `coder`, `api-perf-cost-auditor`, `/new`, `code-reviewer`, `security-reviewer`, `bug`. Project-identity assumptions previously hard-coded (mayo personas, real test credentials, Italian merchant business names) are removed from the framework and now resolved from `identity.audience_segments[]` + `.baldart/overlays/prd.md`. Sanitization sweep removed all PII (phone numbers, real usernames, real passwords, real store names) from the published payload.
+
+### Added — Mockup-aware PRD
+
+- **Step 1.6 — Mockup Intake** in [framework/.claude/skills/prd/references/discovery-phase.md](framework/.claude/skills/prd/references/discovery-phase.md). New mandatory step between Kickoff (Step 1) and Discovery (Step 2). Asks the user "Hai dei mockup a disposizione?" — if yes, asks for format (chat images / local paths / mixed), STOPs, and on receipt: copies local files into `${paths.prd_dir}/<slug>/mockups/` (with collision-safe rename), analyzes every mockup against the **Mockup analysis schema** (screens, user_flow, components, states_visible, copy_excerpts, gaps, design_system_alignment with violations when `features.has_design_system: true`), and populates `## UI Design` in the state file before entering Discovery. If "no", marks `mockups.status: none` and proceeds with the standard flow — fully backwards-compatible for projects without mockups.
+- **Step 3 decision tree (Full / Hybrid / Skip)** in [framework/.claude/skills/prd/references/ui-design-phase.md](framework/.claude/skills/prd/references/ui-design-phase.md). Replaces the legacy "skip if UI N/A" precondition. The tree reads `mockups.status` + `screens_in_scope[]` from the state file and routes per-screen: covered-by-mockups screens skip 3a (options) and 3b (generation) — only Component Registry Lookup, approval gate (3c), and inventory (3d) run; uncovered screens invoke the `ui-design` subskill scoped to that single screen, passing the existing mockups as "design language anchor" so the new screen stays consistent. Includes a canonical 5-screen example (3 covered + 2 new) showing exactly which subskill invocations happen and how the final inventory merges.
+- **"Design Reference & Mockup Inventory" section in the PRD template** ([framework/.claude/skills/prd/assets/prd-template.md](framework/.claude/skills/prd/assets/prd-template.md)). New section inserted between Documentation Impact and Section 1 (Problem Statement). Tracks `mockups.status`, `step_3_mode`, the screen inventory table (mapping each screen to its user story + mockup path + origin), the component-mapping table when a design system is in play (reused + new components + token violations), and the source-files traceability list (original user paths → canonical `mockups/` paths, or `chat://image-N` for inline images).
+- **Mockup-aware fields in the state template** ([framework/.claude/skills/prd/assets/state-template.md](framework/.claude/skills/prd/assets/state-template.md)). Extends `## UI Design` with `mockups.{status,format,original_paths,canonical_paths}`, `mockup_analysis.{screens,user_flow,design_system_alignment}`, `step_3_mode`, `design.html_path`, `screens_in_scope`, `ui_inventory`. Single source of truth for everything Step 1.6 produces and Step 3 + PRD Writing consume.
+- **PRD writing acknowledges mockup canonicality** in [framework/.claude/skills/prd/references/prd-writing-phase.md](framework/.claude/skills/prd/references/prd-writing-phase.md). The canonical sources resolution step now adds the `mockups/` directory as a canonical visual reference when `mockups.status` ∈ {`provided`, `partial`}, and the PRD sections checklist includes a new "Design Reference & Mockup Inventory" entry plus revised UI Specifications guidance to avoid duplication.
+- **Hard Rule 16 (Mockup Intake) + Step 1.6 in the flow overview + progress-bar row** in [framework/.claude/skills/prd/SKILL.md](framework/.claude/skills/prd/SKILL.md). Codifies the new step as MANDATORY in the hard-rules section, adds the row `1.6 Mockup intake` to both the in-progress and completed progress-bar templates (with the `Mockup` and `Step 3 mode` summary lines), and adds a "Mockup-driven pre-population" note to the Quick Reference Comprehension Dimensions explaining how dimension 5 (UI impact) and partially dimension 2 (User journey) are pre-resolved from `mockup_analysis` when mockups are provided.
+- **New-Screen Check during Discovery** in [framework/.claude/skills/prd/references/discovery-phase.md](framework/.claude/skills/prd/references/discovery-phase.md). When a user answer reveals a UI screen NOT in `mockup_analysis.screens[]`, the skill no longer treats it as a generic scope expansion (which would offer `/prd-add`). Instead it appends the screen to `screens_in_scope[]` with `covered_by_mockups: false` and logs inline that Step 3 will generate that single screen in Hybrid mode. The Scope Expansion Check still applies for non-UI entities (new endpoints, roles, collections).
+
+### Added — Stack-aware framework
+
+- **Four new `stack.*` scalar keys** in [framework/templates/baldart.config.template.yml](framework/templates/baldart.config.template.yml): `stack.database` (enum: firestore/supabase/postgres/mysql/mongodb/dynamodb/sqlite/none), `stack.auth_provider` (firebase-auth/supabase-auth/clerk/auth0/cognito/nextauth/lucia/custom/none), `stack.framework` (nextjs/remix/sveltekit/astro/nuxt/rails/django/fastapi/express/none), `stack.deployment` (vercel/firebase/aws/gcp/cloudflare/render/fly/self-hosted/none). Empty string preserves the always-ask contract — skills prompt the user when a needed scalar is unset and suggest `npx baldart configure`.
+- **`baldart configure` autodetection + prompts for the 4 stack scalars** in [src/commands/configure.js](src/commands/configure.js). Autodetection probes `package.json` deps (`firebase`/`@supabase/*`/`pg`/`mongoose`/`@clerk/*`/`@auth0/*`/`next-auth`/`lucia`/`@aws-sdk/client-cognito-identity-provider`/`next`/`@remix-run/*`/`@sveltejs/kit`/`astro`/`nuxt`/`express`), file presence (`vercel.json`/`firebase.json`/`wrangler.toml`/`fly.toml`/`render.yaml`/`Gemfile`/`manage.py`/`requirements.txt`), and content patterns (Django/FastAPI in requirements, rails gem in Gemfile). Detected values pre-fill the interactive prompt. AUTODETECTED box surfaces all 4 values to the user.
+- **`baldart update` schema-drift detector covers scalar `stack.*` keys** in [src/commands/update.js](src/commands/update.js). Extends the existing detector (which already flagged missing `features.*`, `paths.*`, `git.*` keys after an update) to enumerate `tpl.stack[*]` and report only the string-typed top-level scalars as `stack.<key>`. Sub-object keys (`charting`/`animation`/`testing`/`monorepo`/`design_system_signals`) are intentionally ignored — their drift is handled by their dedicated configure prompts. On missing scalars, the detector auto-offers `baldart configure`.
+- **Database vocabulary branching in PRD writing** in [framework/.claude/skills/prd/references/prd-writing-phase.md](framework/.claude/skills/prd/references/prd-writing-phase.md). The Schema Verification Gate header now reads "MANDATORY if feature touches the persistence layer" instead of "if feature touches Firestore"; vocabulary adapts ({entity} = collection|table, {field} = field|column); the schema-registry path resolves via overlay → `stack.database` convention (Firestore `field-registry.json`, SQL `prisma/schema.prisma` or migrations dir, Mongo collection markdown). The PRD-template's Section 5 "Data Model" now ships **5 variants** (Firestore Composite, Relational B-tree+RLS, MongoDB compound, DynamoDB GSI/LSI, None) — the writer keeps only the variant matching `stack.database`.
+- **api-perf-gate refactored as universal-core + stack addenda** in [framework/.claude/skills/prd/references/api-perf-gate.md](framework/.claude/skills/prd/references/api-perf-gate.md). Gate 5 (keyword scan): universal keywords + "Stack-specific keyword addenda" table activated only by the matching `stack.database`. Gates 1–3: universal checklist + "Stack-specific addenda" per `stack.database` (firestore listener/index/ID-hotspot rules, postgres/supabase RLS+EXPLAIN+JSONB rules, mongo compound-field-order+embed rules, dynamodb GSI+hot-partition rules) and per `stack.framework` (nextjs Route Handler `revalidate`/`use cache`, remix `headers`+`shouldRevalidate`, sveltekit runtime declaration, astro `prerender`). Reference Data section split into "Database pricing & cost-model snapshots" (4 stacks), "Runtime limits by `stack.deployment`" (Vercel/Cloudflare/AWS/Firebase table), "Framework caching primitives by `stack.framework`" (4 frameworks). User cites only the variant matching their config.
+- **coder.md Database Index Invariant** in [framework/.claude/agents/coder.md](framework/.claude/agents/coder.md). Renamed from "Firestore Index Invariant"; ships per-stack instructions (Firestore composite + `firestore.indexes.json`, Postgres/Supabase `EXPLAIN` + migration with covering/GIN/RLS, MongoDB `createIndex` with equality→range→sort field order, DynamoDB GSI/LSI in CDK/Terraform, None/unset → skip with warning).
+- **prd-card-writer Field Grounding Rule per-stack registry resolution** in [framework/.claude/agents/prd-card-writer.md](framework/.claude/agents/prd-card-writer.md). The Grep target for field verification is no longer hard-coded to `docs/references/field-registry.json` — it resolves via `.baldart/overlays/prd.md § Schema Registry` first, then by convention matching `stack.database` (Firestore field-registry, Prisma schema, SQL migrations, Mongo collection docs, DynamoDB table definition). Universal identifiers (`id`/`uuid`/PK, `createdAt`/`created_at`, `updatedAt`/`updated_at`) are exempt regardless of stack.
+- **api-perf-cost-auditor reads stack scalars at session start** in [framework/.claude/agents/api-perf-cost-auditor.md](framework/.claude/agents/api-perf-cost-auditor.md). The agent's "Project Context" section is no longer hard-coded to "Next.js 16 + Firestore + Vercel Fluid Compute" — it now lists universal hard rules + addenda tables for `stack.framework`, `stack.database`, `stack.deployment`, and cites the resolved values in every audit header so the user knows which variant applied. Perf budgets move out of the agent into `${paths.references_dir}/perf-budgets.md` (consumer-owned); absence is flagged as a `BUDGETS_GAP` warning instead of using framework-baked numbers.
+- **security-reviewer multi-stack access-rule coverage** in [framework/.claude/agents/security-reviewer.md](framework/.claude/agents/security-reviewer.md). Rule 6 (cloud/infra risks) lists the access-rule variant per `stack.database`: Firebase security rules, Supabase RLS policies, MongoDB validators + collection access, DynamoDB IAM policies, Postgres GRANT/REVOKE + RLS.
+- **`/new` Production Readiness Checklist becomes stack-aware** in [framework/.claude/skills/new/SKILL.md](framework/.claude/skills/new/SKILL.md). Detection table and auto-executable commands branch on `stack.deployment` + `stack.database`. Firebase commands are no longer the default — they're one branch among many (vercel deploy, supabase db push, CDK/Terraform apply, firebase deploy). When `stack.deployment` is empty, the skill infers from config-file presence and falls back to asking the user — never auto-executes a guess.
+- **`/new` end-to-end flow generalized for non-Firestore stacks** in [framework/.claude/skills/new/SKILL.md](framework/.claude/skills/new/SKILL.md). Five additional spots got the same treatment so a Supabase / Postgres / Mongo / DynamoDB project doesn't see Firestore-only instructions: pre-flight `data_fields` warning triggers on `db_indexes` (any dialect) and reads "touches the persistence layer" instead of "touches Firestore"; Codex parallel-conflict analyzer asks about same-{entity} writes in the project's vocabulary; DEEP-review trigger keys off `db_indexes` (legacy `firestore_indexes` still recognized); the Coder Briefing's index section ships per-`stack.database` instructions (Firestore JSON snippet, SQL migration / Prisma `@@index`, Mongo `createIndex`, DynamoDB GSI/LSI in IaC) and explicitly tells the agent which artifact to stage; post-implementation verification of compound queries branches into 4 dialects with their own missing-index severity; Docs Routing Reminder uses `{entity}` vocabulary and points at the stack-matched index artifact; and the post-deploy "DB Index Verification" section (previously Firestore-only with curl to the Firestore REST API) now opens with a Skip rule and 4 dialect variants (Firestore REST API, Postgres `pg_indexes` + `pg_stat_progress_create_index`, Mongo `getIndexes` + `currentOp`, DynamoDB `describe-table` GSI status). The Firestore variant retains its full procedure verbatim — no regression for Firestore consumers.
+- **bug/logging-patterns.md framework-agnostic** in [framework/.claude/skills/bug/references/logging-patterns.md](framework/.claude/skills/bug/references/logging-patterns.md). The Next.js 16 logging section is now one of four (Next.js, Remix, SvelteKit, Astro/Nuxt) plus a generic `pino`/`winston` fallback. DB-tracing env var examples document the per-stack equivalent (`DEBUG_FIRESTORE=true`, `SUPABASE_DEBUG=true`, `DEBUG=knex:query`, `DEBUG=mongoose:*`).
+- **Persona references generalized to `identity.audience_segments[]`** in [framework/.claude/skills/prd/references/discovery-phase.md](framework/.claude/skills/prd/references/discovery-phase.md), [framework/.claude/skills/prd/references/prd-writing-phase.md](framework/.claude/skills/prd/references/prd-writing-phase.md), [framework/.claude/skills/prd/references/audit-phase.md](framework/.claude/skills/prd/references/audit-phase.md), [framework/.claude/skills/prd/assets/card-template.yml](framework/.claude/skills/prd/assets/card-template.yml), [framework/.claude/skills/prd/assets/epic-template.yml](framework/.claude/skills/prd/assets/epic-template.yml), [framework/.claude/skills/prd/assets/prd-template.md](framework/.claude/skills/prd/assets/prd-template.md). Hard-coded persona literals (`CUSTOMER`/`MERCHANT`/`MERCHANT_STAFF`/`SUPER_ADMIN`) are gone from the framework — replaced by `{{from identity.audience_segments[]}}` placeholders and explicit instructions to loop over the project-declared segments. AC grouping in PRD writing now reads "one group per persona drawn from `identity.audience_segments[]`, plus cross-cutting groups".
+- **`db_indexes` field replaces `firestore_indexes` in card YAML** in [framework/.claude/skills/prd/assets/card-template.yml](framework/.claude/skills/prd/assets/card-template.yml). The card template renames the section; entries gain a `dialect` field matching `stack.database` and a `kind` field (composite/covering/partial/GIN/GSI/LSI/unique/fulltext). The legacy `firestore_indexes` name remains accepted as an alias so v3.14.x cards keep working — the validator in [framework/.claude/skills/prd/references/validation-phase.md](framework/.claude/skills/prd/references/validation-phase.md) recognizes both. Metric `has_firestore_indexes_pct` in [framework/.claude/skills/prd/SKILL.md](framework/.claude/skills/prd/SKILL.md) renamed to `has_db_indexes_pct`.
+- **PROJECT-CONFIGURATION.md § 4.4 documents the 4 new scalars** in [framework/docs/PROJECT-CONFIGURATION.md](framework/docs/PROJECT-CONFIGURATION.md). New "Stack-cardinal scalars" subsection enumerates the 8 skills/agents that branch on them, the always-ask contract on empty values, and the schema-drift detector behavior.
+
+### Removed — PII sanitization
+
+- **Test credentials (phone, username, password, store name) removed from the published payload.** [framework/.claude/skills/prd/references/discovery-phase.md](framework/.claude/skills/prd/references/discovery-phase.md), [framework/.claude/skills/prd/assets/prd-template.md](framework/.claude/skills/prd/assets/prd-template.md), [framework/.claude/skills/prd/assets/card-template.yml](framework/.claude/skills/prd/assets/card-template.yml) no longer ship any real credential as "example". The discovery Test Strategy step now (a) consults `.baldart/overlays/prd.md § Test Credentials` first, (b) asks the user one structured question per persona if the overlay is silent, (c) stores a credential REFERENCE (secret-manager path, `.env.test:VAR_NAME`) in the state file instead of the literal secret, and (d) explicitly forbids the framework from carrying real PII.
+
+### Notes
+
+- **One CLI change — `baldart configure`.** v3.15.0 adds autodetection + prompts for the 4 `stack.*` scalars and extends the `baldart update` schema-drift detector to flag missing scalar `stack.*` keys. Consumers upgrading from v3.14.x get the new prompts on the next `baldart configure` invocation; the detector triggers automatically on the next `baldart update`.
+- **The schema-change propagation rule applied end-to-end** for the 4 new scalars: template ✓, configure prompt ✓, update detector ✓, doctor not extended (the always-ask contract in skills already covers the empty case), CHANGELOG ✓.
+- **Backwards-compatibility for v3.14.x cards.** Cards with the legacy `firestore_indexes` field still validate (the writer-side renamed it to `db_indexes`, but the validator and downstream agents accept both names). Cards with `type: firestore` in `data_sources` are equivalent to `type: db, db_dialect: firestore`.
+- **Active PRD sessions started under v3.14.x** do not have `## UI Design` populated with the mockup fields; the skill treats `pending`/missing as `mockups.status: none` and falls into the Full Step-3 branch (legacy behavior). New sessions on v3.15.0+ pick up Step 1.6 automatically.
+- **Step 3 Hybrid mode preserves the design-system cascade.** When `features.has_design_system: true`, the BLOCKING reads of `${paths.design_system}/INDEX.md` + `tokens-reference.md` run BOTH in Step 1.6 (during mockup analysis, to flag violations early) AND in Step 3 (during per-screen Component Registry Lookup, to validate covered + new screens uniformly). Violations bubble up to the unified 3c approval gate.
+- **Sanitization is final, not a heuristic.** Grep across `framework/` for `3486417303`, `antonio.baldassarre2336`, `bRkS2bzqyesK`, `Bar Roma` returns zero hits after this release. Consumers who already had `.baldart/overlays/prd.md` with their real credentials are unaffected — the overlay never leaves the consumer repo.
+- **Verification is manual** (no test suite — `npm test` is no-op stub). Scenarios to dogfood after install: (1) `npx baldart update` on a v3.14.x consumer → schema-drift detector flags 4 new `stack.*` keys → `baldart configure` autodetection pre-fills them; (2) `/prd` on a Supabase project (`stack.database: supabase`) → Schema Verification Gate uses Variant B (Relational), api-perf-gate adds postgres+supabase addenda, audit-phase enforces RLS; (3) `/prd` on a Firestore project (`stack.database: firestore`) → behavior identical to v3.14.x (no regression); (4) `/prd` with mockups → mockup intake + Hybrid Step 3; (5) `/new` on a Cloudflare deployment (`stack.deployment: cloudflare`) → no `firebase deploy` commands proposed.
+
 ## [3.14.1] - 2026-05-23
 
 Hotfix for the `.framework/` gitignore self-heal shipped in v3.14.0. The detector misread `git check-ignore -v` output: when `check-ignore` matched a negation pattern (`!.framework`), it still reported the match, and `checkFrameworkIgnored` flagged the path as ignored. The result: every consumer who hit the self-heal on first run got `.framework/ is STILL ignored after auto-heal` and `process.exit(1)` — the heal *had* actually worked (the negation was in place), but the verifier didn't recognize its own fix. Reported during the v3.13.0 → v3.14.0 update in a downstream consumer.

package/VERSION

@@ -1 +1 @@
-3.14.1
+3.16.0

package/framework/.claude/agents/REGISTRY.md

@@ -37,6 +37,16 @@ Quick-reference for all custom agents. Use this to route tasks to the right spec
 
 ## Decision Tree
 
+> **Note**: when invoked from the `/new` skill, agent assignment is NOT taken
+> from this tree — `/new` reads `owner_agent` directly from each card YAML
+> (enum: `coder | ui-expert | plan | visual-designer | motion-expert`, set
+> by `prd-card-writer`). This tree is the source for HUMAN routing (when
+> spawning an agent ad-hoc) and for prd-card-writer's WRITING decisions.
+> If you change agent capabilities here, keep the enum in
+> `framework/.claude/agents/prd.md:538` and the router in
+> `framework/.claude/skills/new/SKILL.md` § Agent Routing in lockstep —
+> drift between layers silently mis-routes cards.
+
 ```
 Need to understand existing code?      --> codebase-architect (MANDATORY)
 Have a plan to review?                 --> plan-auditor

package/framework/.claude/agents/api-perf-cost-auditor.md

@@ -39,16 +39,53 @@ To prevent context bloat:
 - Max **5 search_docs MCP calls**.
 - Never read files outside `git diff --name-only` (or scope passed by orchestrator) unless tracing a callgraph that proves a regression.
 
-## Project Context (Next.js 16 + Firestore + Vercel Fluid Compute)
-
-- Default runtime: Fluid Compute (Node.js 24 LTS). Edge runtime is **not** the recommended default.
-- Vercel Functions billing: Active CPU + provisioned memory + invocations. **Not** wall-clock GB-s.
-- Firestore is the dominant cost driver. Hard rules from AGENTS.md NFR Performance:
-  - Every `where()` MUST include `.limit()`.
-  - Pagination MUST be cursor-based (`startAfter()`), never offset-based.
-  - No `getDoc()` in loops — batch with `getAll()` / `getDocs()`.
-  - Composite queries require updated `firestore.indexes.json` in same commit.
-- Project performance budgets: API route p99 < 2s (lightweight < 500ms), ≤ 50 Firestore reads / route, bundle ≤ 250KB gzipped.
+## Project Context (read from `baldart.config.yml`)
+
+Read `stack.framework`, `stack.database`, `stack.deployment` at the start of
+every audit. The rules below adapt automatically; cite the resolved values in
+your findings header so the user knows which variant you applied.
+
+**Universal hard rules** (apply to any stack):
+- Every list query MUST include a `limit` (or equivalent pagination size).
+- Pagination MUST be cursor/keyset-based, never offset-based on hot paths.
+- No N+1 reads in loops — batch / join / `$lookup` / `getAll` per stack.
+- Multi-attribute queries require their matching index shipped in the same commit
+  as the query (see Database Index Invariant in coder.md per `stack.database`).
+
+**Stack-specific addenda** (apply only when matching):
+
+- `stack.framework: nextjs` → Default runtime Fluid Compute (Node.js 24 LTS).
+  Edge runtime is not the recommended default. GET Route Handlers are dynamic
+  by default since v15 — opt in to caching via `revalidate` / `'use cache'`.
+- `stack.framework: remix` → Set `headers` for Cache-Control explicitly.
+  Rely on CDN-level caching.
+- `stack.framework: sveltekit` → Choose Edge vs Node runtime per route;
+  declare `prerender` for static pages.
+
+- `stack.database: firestore` → Hard rules from AGENTS.md NFR Performance:
+  every `where()` includes `.limit()`; pagination uses `startAfter()`; no
+  `getDoc()` in loops; composite queries update `firestore.indexes.json` in
+  the same commit.
+- `stack.database: postgres | supabase | mysql | sqlite` → `EXPLAIN` every
+  new query on a >10k-row table; surface Seq Scan as a HIGH finding.
+  Supabase: every new table needs RLS aligned with the auth contract (CRITICAL).
+- `stack.database: mongodb` → Compound index field order: equality → range →
+  sort. Aggregations on hot paths must use indexes (no `$match` after
+  `$project` that strips the indexed field).
+- `stack.database: dynamodb` → Every non-PK access pattern has a GSI / LSI.
+  Reject `FilterExpression` on hot paths.
+
+- `stack.deployment: vercel` → Active CPU + provisioned memory + invocations
+  billing (not wall-clock GB-s). Payload limit 4.5 MB. Max duration 300s
+  Hobby / 800s Pro.
+- `stack.deployment: cloudflare` → 30s CPU per request; 100 MB payload.
+- `stack.deployment: aws` → Lambda 6 MB sync / 256 KB async, max 900s.
+- `stack.deployment: firebase` → 32 MB payload, max 540s (gen 2).
+
+**Project performance budgets** are NOT hard-coded here. They live in
+`${paths.references_dir}/perf-budgets.md` (consumer-owned). If that file does
+not exist, derive ad-hoc defaults from the stack snapshot above and flag the
+absence in your audit summary as a `BUDGETS_GAP` warning.
 
 ## Scope Boundary (MUST — read first)
 

package/framework/.claude/agents/coder.md

@@ -161,16 +161,67 @@ This rule is enforced by:
 - `.claude/skills/new/SKILL.md § Phase 3.7 trigger #6` (mutation-after-helper
   call invokes per-card `/codexreview` before commit).
 
-## Firestore Index Invariant (MUST)
-
-When writing or modifying Firestore queries that use `where()` + `orderBy()` on different fields, or multiple `where()` on different fields:
-
-1. **Check `firestore.indexes.json`** — does a composite index exist for this exact query pattern (collection, fields, order)?
-2. **If missing**: add the index to `firestore.indexes.json` and stage it with your commit. Use the existing entries as format reference.
-3. **For dynamic queries** (`let query = ...; if (x) query = query.where(...)`) — add a JSDoc comment above the function: `/** @requires-index: collectionGroup(field1 ASC, field2 DESC) */`
-4. **Remember**: all-equality queries (only `==` filters, no `orderBy` on a different field) do NOT need composite indexes. Only compound queries mixing equality + inequality/range + orderBy on different fields need them.
-
-Missing indexes cause **500 errors in production** (Firestore FAILED_PRECONDITION, error code 9) that are invisible until runtime.
+## Database Index Invariant (MUST)
+
+When writing or modifying queries that combine filters and orderings on
+different attributes, ensure the matching index exists and ships in the same
+commit as the query. Apply the variant matching `stack.database` from
+`baldart.config.yml`:
+
+**Variant — Firestore (`stack.database: firestore`)**
+
+Where `where()` + `orderBy()` on different fields, or multiple `where()` on
+different fields:
+
+1. Check `firestore.indexes.json` for a composite index matching the exact
+   pattern (collection, fields, order).
+2. If missing: add it and stage with your commit.
+3. For dynamic queries (`let query = ...; if (x) query = query.where(...)`)
+   add a JSDoc: `/** @requires-index: collectionGroup(field1 ASC, field2 DESC) */`
+4. All-equality queries (only `==` filters, no `orderBy` on a different
+   field) do NOT need composite indexes.
+
+Missing indexes cause **500 errors in production** (`FAILED_PRECONDITION`,
+error code 9) invisible until runtime.
+
+**Variant — Relational (`stack.database` ∈ {postgres, supabase, mysql, sqlite})**
+
+When the query uses `WHERE col_a = ? AND col_b > ? ORDER BY col_c`, or any
+JOIN/sort/filter combination that can produce a sequential scan on a hot
+table:
+
+1. Run `EXPLAIN` (or `EXPLAIN ANALYZE` in dev) on the new query. Verify the
+   planner picks an Index Scan or Index Only Scan, not Seq Scan, on tables
+   with >10k rows.
+2. If a Seq Scan appears: add a composite or covering index in a new migration
+   (`migrations/<ts>_add_<entity>_<purpose>_idx.sql`, or
+   `prisma migrate dev` / `supabase migration new` per project conventions).
+3. Stage the migration with the same commit as the query change.
+4. For JSONB queries: ensure a GIN index exists on the JSONB column when
+   the query filters on it.
+5. For Supabase: every new table also requires an RLS policy aligned with the
+   PRD permissions section.
+
+**Variant — MongoDB (`stack.database: mongodb`)**
+
+1. Check the collection's indexes via `db.<collection>.getIndexes()` (or the
+   schema file the project uses as registry).
+2. For compound queries, ensure the index field order follows
+   equality → range → sort.
+3. Add the index in code (`createIndex`) or migration, in the same commit.
+
+**Variant — DynamoDB (`stack.database: dynamodb`)**
+
+1. Every non-PK access pattern needs either a GSI or LSI declared in the
+   table definition (CDK / Terraform / SAM template).
+2. Update the table definition in the same commit as the new query.
+3. Avoid `FilterExpression` on hot paths — pick a GSI instead.
+
+**Variant — None / unset**
+
+If `stack.database` is empty or `"none"`, skip this section. If you encounter
+persistence code while `stack.database` is empty, surface a warning suggesting
+`npx baldart configure`.
 
 ## Incremental Verification (MUST)
 

package/framework/.claude/agents/prd-card-writer.md

@@ -15,7 +15,15 @@ You are **PRD Card Writer** — a specialist agent that converts an approved PRD
 1. **Read the PRD `## Schema Verification` section** (generated during Step 4 of the PRD skill).
    Every field you write MUST appear in that table with status `✅ existing` or `🆕 new`.
 
-2. **For each `✅ existing` field**: call `Grep("fieldName", "docs/references/field-registry.json")`.
+2. **For each `✅ existing` field**: call `Grep("fieldName", <schema-registry-path>)`.
+   The registry path is resolved per the project:
+   - `.baldart/overlays/prd.md § Schema Registry` defines it explicitly when present;
+   - otherwise the convention follows `stack.database`:
+     - firestore → `${paths.references_dir}/field-registry.json`
+     - postgres/supabase/mysql/sqlite → `prisma/schema.prisma` OR `${paths.references_dir}/schema.md` OR the latest migration under the project's migrations dir;
+     - mongodb → `${paths.references_dir}/collections/<name>.md` or a JSON schema file in the validator dir;
+     - dynamodb → the CDK / Terraform table definition file.
+   Then:
    - ≥1 match → set `ts_verified: true` in the card's `data_fields` entry.
    - 0 matches → HALT. Do NOT use this field. Ask: "Field not found in registry — is it new or a typo?"
 
@@ -23,9 +31,9 @@ You are **PRD Card Writer** — a specialist agent that converts an approved PRD
 
 4. **NEVER invent a field name** not in the Schema Verification snapshot, even if it "sounds right".
 
-5. **Exempt from verification** (do not include in `data_fields`): `id`, `createdAt`, `updatedAt`.
+5. **Exempt from verification** (do not include in `data_fields`): the project's universal identifiers — `id`/`uuid`/PK, `createdAt`/`created_at`, `updatedAt`/`updated_at`.
 
-6. **Populate `data_fields`** for every card that reads/writes Firestore documents (see Required Fields).
+6. **Populate `data_fields`** for every card that reads/writes the persistence layer (see Required Fields).
 
 ## Mission
 
@@ -48,6 +56,69 @@ You produce:
 4. **Scan existing backlog** — `backlog/*.yml` to find the highest `FEAT-XXXX` number. Use Glob to list files, then Grep for `^id:` lines to extract IDs.
 5. **Read existing card conventions** — sample 2-3 recent cards from `backlog/` to match style.
 
+## Agent Specialization Rules (HARD RULE — zero tolerance)
+
+These two rules govern HOW you assign work to specialist agents. They are
+enforced by the validation phase of `/prd` (Step 6) and by the `/new`
+dispatcher — getting them wrong silently routes work to the wrong agent.
+
+### Rule A — Set `owner_agent` on every child card (enum, no default)
+
+Every child card you produce MUST set `owner_agent` to exactly one of:
+
+```
+coder | ui-expert | plan | visual-designer | motion-expert
+```
+
+`claude` is NOT a valid value (it is a legacy placeholder kept only for
+backward compatibility in the dispatcher's fallback). Missing, empty, or
+out-of-enum values fail validation.
+
+**How to choose:**
+
+- `coder` — backend, business logic, state management, data layer, API
+  handlers, scripts, CLI, hooks, anything that writes/reads persistence.
+- `ui-expert` — UI implementation from an existing mockup (`links.design`):
+  components, layout, styling, motion, accessibility, registry-first
+  discipline (reads `${paths.design_system}/INDEX.md` + tokens-reference
+  + per-component specs BEFORE coding, runs Post-Intervention Coherence
+  Check after).
+- `plan` — planning-only deliverables (no code edits): RFC, ADR draft,
+  research synopsis, sequencing doc.
+- `visual-designer` — static visual asset generation (illustrations, icons,
+  hero images) via the visual-designer agent.
+- `motion-expert` — motion specs (timing tables, easing curves,
+  micro-interaction storyboards) — NOT motion code implementation, which
+  is `ui-expert` work.
+
+**Epic cards** use `owner_agent: ""` (empty string) because they are
+trackers, not implementation. The dispatcher skips them.
+
+### Rule B — UI cards (`ui-expert`) have UI-ONLY scope
+
+When you assign `owner_agent: ui-expert` to a card, its scope MUST cover
+ONLY graphical concerns. The card MUST NOT bundle:
+
+- business logic, domain rules, calculation
+- API calls, data fetching, mutations
+- state management beyond local UI state (`useState` for open/closed,
+  hover, focus — fine; global app state, cache invalidation, sync — not)
+- validation LOGIC (rendering validation states is UI work; the rules and
+  side-effects are coder work)
+- backend changes (routes, handlers, DB schema, migrations, indexes)
+
+**If a step requires both UI and logic, you MUST split it into two cards**
+and wire them via `depends_on:` / `blocks:` — a `ui-expert` card that
+consumes a mocked or contract-stable interface, plus a `coder` card that
+owns the logic side. Canonical example: see § "Split example — Login
+feature" in `framework/.claude/skills/prd/references/backlog-phase.md`.
+
+If you cannot reasonably split (e.g. because the UI and logic share <3
+files and one file would be torn between two cards), prefer a single
+`coder` card with UI work as one of its acceptance criteria — do NOT
+assign `ui-expert` to a mixed card. The dispatcher's specialist routing
+breaks down when scope is mixed.
+
 ## Card Atomicity Rules
 
 Cards MUST be as atomic as possible to enable parallel execution:
@@ -127,7 +198,7 @@ applies even when N=1.
 4. **Reusing the FEAT-XXXX integer**. Each epic reserves the full integer space.
 5. **Epic with implementation fields**. The epic NEVER has `files_likely_touched`
    pointing to code (only docs), `validation_commands`, `existing_patterns`,
-   `data_fields`, `data_sources` beyond `[]`, or `firestore_indexes`.
+   `data_fields`, `data_sources` beyond `[]`, or `db_indexes` (legacy `firestore_indexes` alias also forbidden on epics).
 
 ### Why MANDATORY
 
@@ -188,31 +259,33 @@ Every card MUST include ALL fields from the template:
 - `data_sources` — MANDATORY for EVERY card (never omit, even if empty):
   - High-level inventory of every data source or destination the card touches.
   - One entry per distinct source. Supported types:
-    - `firestore`: collection name in `path`; field-level detail lives in `data_fields` (below).
+    - `db`: {entity} name in `path` (collection/table/index per `stack.database`); set `db_dialect` to the matching value. Field-level detail lives in `data_fields` (below).
     - `file`: repo-relative path, `operations` (READ|WRITE|APPEND|CREATE|DELETE), `format` (JSONL|YAML|JSON|markdown|binary).
     - `api`: URL or endpoint pattern; READ = GET, WRITE = POST/PUT/PATCH/DELETE.
     - `env`: env var name; `operations: [READ]`.
+    - **Legacy:** `firestore` is still accepted (treated as `db` with `db_dialect: firestore`).
   - For **pure docs/config/scaffolding cards** that read and write no data: set `data_sources: []` (explicit empty list — confirms the writer verified there are no sources; never silently omit the field).
-  - For **Firestore cards**: include `type: firestore` entries here AND populate `data_fields` below. The two fields serve different purposes: `data_sources` is the traceable overview; `data_fields` is the field-level grounding for mechanical validation.
-  - For **file-based tooling cards** (scripts, CLIs, hooks): list each file or directory the card reads from or writes to. This is the primary documentation for non-Firestore data flows.
-- `data_fields` — MANDATORY if card reads/writes any Firestore document:
-  - For each field the card touches (excluding `id`, `createdAt`, `updatedAt`):
-    - `collection`: exact collection name (must match key in `field-registry.json`)
-    - `field`: exact field name (verified via Grep per Field Grounding Rule above)
-    - `type`: TypeScript type string from the interface
+  - For **persistence-touching cards**: include `type: db` entries here AND populate `data_fields` below. The two fields serve different purposes: `data_sources` is the traceable overview; `data_fields` is the field-level grounding for mechanical validation.
+  - For **file-based tooling cards** (scripts, CLIs, hooks): list each file or directory the card reads from or writes to. This is the primary documentation for non-DB data flows.
+- `data_fields` — MANDATORY if card reads/writes the persistence layer:
+  - For each field the card touches (excluding universal identifiers — `id`/`uuid`/PK, `createdAt`/`created_at`, `updatedAt`/`updated_at`):
+    - `entity`: exact collection or table name (must match key in the schema registry resolved per Field Grounding Rule step 2)
+    - `field`: exact identifier (verified via Grep per Field Grounding Rule above)
+    - `type`: language-native type from the schema (TypeScript interface / Prisma model / SQL column / Mongo validator)
     - `status`: `existing` | `new` | `modified` | `deprecated_removed`
     - `ts_verified`: `true` (after Grep confirms field in registry) or `false` (new fields only)
-    - `source`: TypeScript file path where interface is defined (e.g. `src/types/booking.ts`)
+    - `source`: schema file path (e.g. `src/types/booking.ts`, `prisma/schema.prisma:42`, `migrations/2024_...sql`)
     - `schema_ref`: PRD section link — ONLY for `status: new` fields
   - Omit this block entirely for UI-only, docs-only, or config-only cards.
-- `firestore_indexes` — propagated from PRD Section 5 `### Firestore Composite Indexes` table:
-  - For each card that introduces or modifies a Firestore query with compound fields
-    (`where()` + `orderBy()` on different fields, or multiple `where()` on different fields),
+- `db_indexes` — propagated from PRD Section 5 `### Database Indexes & Query Optimization` table:
+  - For each card that introduces or modifies a query needing a multi-attribute index
+    (Firestore composite, SQL B-tree/covering, Mongo compound, DynamoDB GSI/LSI),
     include the matching `IDX-N` entries from the PRD index table.
-  - Each entry: `collection`, `fields` (with order ASC/DESC), `query_location`, `prd_ref`.
+  - Each entry: `entity`, `dialect` (matches `stack.database`), `fields`, `kind`, `query_location`, `prd_ref`.
   - If the PRD has no index table or this card has no compound queries: omit the field entirely.
-  - **CRITICAL**: missing indexes cause runtime FAILED_PRECONDITION (500 in production).
-    The coder MUST add these to `firestore.indexes.json` in the same commit as the query code.
+  - **CRITICAL**: missing indexes degrade performance or break production (Firestore: FAILED_PRECONDITION 500; SQL: sequential scan on hot path; DynamoDB: throttle on hot partition).
+    The coder MUST ship the index in the same commit as the query — per `stack.database` (firestore.indexes.json, migration file, createIndex call, table definition).
+  - Legacy field name `firestore_indexes` is still accepted for pre-3.15.0 cards.
 - `documentation_impact` — list of docs to update when card is DONE:
   - New `route.ts` -> `docs/references/api/<module>.md` + `api/index.md`
   - New collection -> `docs/references/data-model.md` + `collections/<domain>.md`

package/framework/.claude/agents/security-reviewer.md

@@ -43,7 +43,7 @@ Before reviewing:
 3. **Flag security anti-patterns**: unsafe libraries, insecure framework usage, dangerous data flows.
 4. **Review comprehensively**: authentication, authorization, session handling, secrets management, cryptography, input validation, output encoding, deserialization, file handling, logging, error handling.
 5. **Assess attack vectors**: SSRF, XSS, CSRF, SQL/NoSQL injection, command injection, path traversal, RCE, IDOR, broken access control, race conditions, insecure randomness, data leakage.
-6. **Evaluate cloud/infra risks**: IAM over-permissioning, public exposure, insecure storage, CI/CD secret leakage, supply chain risks, Firebase security rules.
+6. **Evaluate cloud/infra risks**: IAM over-permissioning, public exposure, insecure storage, CI/CD secret leakage, supply chain risks, persistence-layer access rules (variant per `stack.database`: Firebase security rules, Supabase RLS policies, MongoDB validators + role-based collection access, DynamoDB IAM policies, Postgres GRANT/REVOKE + RLS).
 7. **Assess privacy/data protection**: PII exposure, credential leakage, tokens in logs, internal ID exposure.
 8. **Evaluate dependencies**: third-party integration risks visible in code or manifests.
 9. **Propose remediations**: concrete, minimal, production-ready fixes.

package/framework/.claude/skills/bug/references/logging-patterns.md

@@ -1,8 +1,13 @@
 # Logging Patterns & Debug Environment Reference
 
-## Next.js 16 Built-In Logging (next.config.ts)
+> Pick the section matching `stack.framework` from `baldart.config.yml`. The
+> first section (Next.js) is the most common; sections for other frameworks
+> follow the same intent: maximize signal during a debug session, with a way
+> to turn it off cleanly when done.
 
-Add these to `next.config.ts` during debug sessions:
+## Next.js 16 Built-In Logging (`stack.framework: nextjs`)
+
+Add to `next.config.ts` during debug sessions:
 
 ```typescript
 logging: {
@@ -17,17 +22,49 @@ logging: {
 
 `browserToTerminal` (v16.2+) is the most powerful: it streams client-side `console.*` to the dev server terminal with file:line:col source location. No code changes needed.
 
+## Remix Built-In Logging (`stack.framework: remix`)
+
+- Enable `loader` / `action` timing via `DEBUG=remix:*` env.
+- For request logging, instrument `entry.server.ts` with a `handleRequest`
+  wrapper that logs method/path/duration.
+- Browser console forwarding: not built-in; use a small client-side logger
+  posting to `/__debug` route handler during the session.
+
+## SvelteKit (`stack.framework: sveltekit`)
+
+- Enable verbose `vite` logging via `vite --debug` for build-time issues.
+- `handle` hook in `hooks.server.ts` is the natural choke point: log
+  method/path/duration there during a session.
+
+## Astro / Nuxt / Other
+
+- Use the framework's request hook (Astro middleware, Nuxt `defineEventHandler`
+  wrapper) to log structured request/response data.
+- Stick to plain `console.log` with a unique prefix that's easy to grep and
+  remove (e.g. `[BUG-1234]`).
+
+## Generic fallback (any framework)
+
+When the framework has no built-in equivalent, add `pino` or `winston` to the
+project and emit JSON logs at every interesting choke point (request entry,
+DB call, external API call). Remove on session close.
+
 ## Environment Variables for Debug Sessions
 
 Set in `.env.local` during investigation, remove after:
 
 ```bash
-DEBUG_MODULES=reservations.patch,booking.schedule  # server-side module filter
-DEBUG_FIRESTORE=true                                # Firestore op tracing
-DEBUG_NETWORK=true                                  # request/response logging
-DEBUG_PROXY=true                                    # proxy/middleware logging
-NEXT_PUBLIC_DEBUG_COMPONENTS=booking.form,planner   # client component logs (rebuild required)
-NEXT_OTEL_VERBOSE=1                                 # verbose OpenTelemetry spans
+# Examples — pick the ones matching this project's stack:
+DEBUG_MODULES=<module>.<verb>            # server-side module filter (project-specific)
+DEBUG_DB=true                            # generic DB op tracing — name varies by stack:
+                                         #   firestore  → DEBUG_FIRESTORE=true
+                                         #   supabase   → SUPABASE_DEBUG=true
+                                         #   postgres   → DEBUG=knex:query  (or your ORM's flag)
+                                         #   mongo      → DEBUG=mongoose:* (if using mongoose)
+DEBUG_NETWORK=true                       # request/response logging
+DEBUG_PROXY=true                         # proxy/middleware logging
+NEXT_PUBLIC_DEBUG_COMPONENTS=<module>    # Next.js only — client component logs (rebuild required)
+NEXT_OTEL_VERBOSE=1                      # Next.js only — verbose OpenTelemetry spans
 NEXT_TURBOPACK_TRACING=1                            # Turbopack bundler trace → .next/dev/trace-turbopack
 ```