baldart 4.0.1 → 4.0.3

package/CHANGELOG.md

@@ -5,6 +5,36 @@ 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).
 
+## [4.0.3] - 2026-06-02
+
+**Portability fix (round 3 — final): remove fidelity-app DOMAIN example-flavor from shipped framework files.** Closes the T13 portability sweep started in v4.0.1/4.0.2 by genericizing the consumer-domain vocabulary (`merchant`/`booking`/`reservation`/`merchant-theming`, `/merchant/dashboard` routes, `customer-facing vs merchant-facing`, `FEAT-0127-merchant-points-guard`, `area:customer|merchant|admin`) that survived as illustrative example flavor. No behaviour change → **PATCH**.
+
+> **Why.** Even in prose examples, a consumer-domain noun teaches the wrong vocabulary and trips the `contamination.js` `requires-decision` rules. The fix distinguishes genuine fidelity-domain flavor (generalized) from legitimate generic English (`customer` in marketing/security "multi-tenant … customers"), the scanner's own meta-references (`framework-edit-gate.js`, `contamination.js`), and `project-context.md`'s explanation that these opinionated tokens belong in the overlay — all of which are correct and untouched.
+
+### Changed — genericized domain example flavor
+
+- **Example queries/routes** → placeholders: `wiki-curator.md` / `doc-reviewer.md` search examples (`<feature-X>` / `<entity>`); `visual-fidelity-verifier.md`, `commands/design-review.md`, `e2e-review/SKILL.md` route envelopes (`/dashboard` instead of `/merchant/dashboard`); `impact-analysis.md` worked-CR endpoint.
+- **`prd.md`** — example card filename and `area:` labels reference `identity.audience_segments` instead of literal `merchant`/`customer`/`admin`.
+- **`prd-card-writer.md`** — "split by audience segment (per `identity.audience_segments`)" instead of "customer-facing vs merchant-facing"; generic subsystem example.
+- **`doc-writing-for-rag` reference files** (`before-after-examples.md`, `compact-templates.md`, `schemas-and-errors.md`) — added an "illustrative sample domain" disclaimer (the worked before/after corpus uses a sample API; only the *technique* is normative), rather than rewriting 290+ lines of self-contained illustration.
+
+> **Note — out of scope, surfaced for a future pass.** Running `contamination.js` over the whole `framework/` payload also flags ~200 hard-coded **path literals** (`backlog/`, `docs/design-system/`, `src/components/…`) that should be `${paths.*}` config keys. A meaningful fraction are legitimate (config-template defaults, `PROJECT-CONFIGURATION.md` docs, canonical protocol examples), but the rest are a genuine, larger portability cleanup deserving its own dedicated pass — not bundled here.
+
+## [4.0.2] - 2026-06-02
+
+**Portability fix (round 2): remove hard-coded auth/deployment project identifiers from shipped framework files.** Companion to v4.0.1 — extends the de-contamination from the database dimension to the auth and deployment dimensions, where fidelity-app-specific identifiers (`withAuth`, `withAuthNoParams`, `src/lib/auth/middleware.ts`, `src/app/api/v1/...`, `BookingTable`, `ADMIN + MERCHANT`, "Vercel Functions") leaked into self-verification examples, detection-signal lists, and template fills. No behaviour change → **PATCH**.
+
+> **Why.** A project-specific symbol baked into a shipped detection list or CoVe example is the same frozen-spot defect as a hard-coded datastore: the consumer's auth wrapper, role names, and deploy platform are `stack.*` / overlay facts. Genuinely platform-named integrations were left untouched because they are correct: the `vercel:deploy` skill documentation (that skill *is* Vercel-specific), the multi-platform deploy tables in `/new` ("firebase: … vercel: … aws: …"), the per-platform timeout/limit tables in `api-perf-gate.md`, and the config-driven `stack_signature` example in `research-phase.md` (which already shows both a Firestore and a Supabase example).
+
+### Changed — generalized auth/deployment identifiers to placeholders / config keys
+
+- **`code-reviewer.md`** + **`plan-auditor.md`** — the chain-of-verification example findings now use `<auth-wrapper>` / `<route-file>` / `<auth-module>` placeholders (resolved from `${paths.high_risk_modules}`) instead of `withAuth` + literal `src/app/api/v1/...` / `src/lib/auth/middleware.ts` paths.
+- **`audit-phase.md`** — the auth-change detection signal cites "the project's auth-guard wrapper / permission helper (e.g. a `withAuth*`-style wrapper)" rather than the literal `withAuth` / `checkPermission` symbols.
+- **`doc-writing-for-rag`** (SKILL + `compact-templates.md`) — endpoint template fills use `<authWrapper>` / `<ROLE_A>` / `<ROLE_B>` instead of `withAuthNoParams` / `ADMIN + MERCHANT`.
+- **`api-perf-gate.md`** — the upload red-flag cites "the platform's request-body limit (e.g. 4.5MB on Vercel Functions — per `stack.deployment`)".
+- **`validation-phase.md`** — the logic-marker grep list covers datastore-access patterns per `stack.database` (not only `prisma` / `firestore.collection`).
+- **`wiki-curator.md`**, **`doc-reviewer.md`** — illustrative example queries/paths use `<authWrapper>` / `<DomainType>` / `src/lib/<module>.ts#<symbol>` placeholders.
+
 ## [4.0.1] - 2026-06-02
 
 **Portability fix: remove hard-coded `Firestore` assumptions from shipped framework files (T13 follow-up).** The v4.0.0 portability pass guarded most stack-specific checks behind `stack.database`, but a residual set of agent checklists and methodology blocks still *assumed* Firestore as the datastore — contamination that is dead-false (or misleading) on any non-Firestore consumer. No behaviour change for correctly-configured projects → **PATCH**.

package/VERSION

@@ -1 +1 @@
-4.0.1
+4.0.3

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

@@ -266,10 +266,10 @@ Emit findings of type `simulation_failure` with the file:line of the breaking br
 
 After Challenge Pass + Diff Simulation, for EACH surviving HIGH/MEDIUM finding generate 2–3 verification questions and execute them via grep/read:
 
-Example finding: "withAuth missing on POST handler at `src/app/api/v1/foo/route.ts:45`":
-1. `Does the file exist?` → `test -f src/app/api/v1/foo/route.ts`
-2. `Is there really no withAuth import or wrapper?` → `grep -n "withAuth" src/app/api/v1/foo/route.ts`
-3. `Is the route actually public per docs?` → `grep -l "api/v1/foo" docs/references/api/`
+Example finding: "auth wrapper missing on POST handler at `<route-file>:45`" (here `<auth-wrapper>` is the project's auth guard — e.g. a `withAuth*`-style wrapper; resolve from `${paths.high_risk_modules}`):
+1. `Does the file exist?` → `test -f <route-file>`
+2. `Is there really no auth import or wrapper?` → `grep -n "<auth-wrapper>" <route-file>`
+3. `Is the route actually public per docs?` → `grep -l "<route-path>" ${paths.references_dir}/api/`
 
 Drop findings whose verification fails. Record dropped findings under "Hallucinated findings dropped (CoVe)".
 

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

@@ -119,7 +119,7 @@ the flags above.
   `docs/ops/graph-communities-scheduling.md`:
   - `search_synthesis(question, level="global")` — community-summary
     retrieval. Use for relational / cross-cutting questions ("how does
-    auth interact with booking?", "what touches reservations?").
+    auth interact with `<feature-X>`?", "what touches `<entity>`?").
   - `search_synthesis(question, level="local")` — entity-centric retrieval
     (specific identifier lookups; equivalent to `mode="local"`).
   - `search_docs(mode="drift")` — GraphRAG DRIFT (`global` → scoped `local`),
@@ -393,7 +393,7 @@ function whose **identity** matters to the doc's correctness — you SHOULD add
 a `code_refs:` entry to the doc's frontmatter that anchors the prose to a
 compiler-stable SCIP symbol ID.
 
-**Why**: prose paths like `src/lib/auth/middleware.ts#withAuth` rot silently
+**Why**: prose paths like `src/lib/<module>.ts#<symbol>` rot silently
 on rename. SCIP (Sourcegraph Code Intelligence Protocol) emits refactor-stable
 symbol IDs that survive moves and renames as long as the index is rebuilt.
 Research on LLM-driven doc-code traceability using SCIP-style anchors reports

package/framework/.claude/agents/plan-auditor.md

@@ -306,9 +306,9 @@ Emit findings of type `simulation_failure` with the failing step number and the
 
 After Challenge Pass and Simulation Pass, for EACH surviving HIGH/MEDIUM finding, generate 2–3 verification questions and execute them:
 
-For example, finding "Card lists `src/lib/auth/middleware.ts:45` but the function `withAuth` is at line 67":
-1. `Does the file exist?` → `test -f src/lib/auth/middleware.ts`
-2. `Is the function at line 45?` → `grep -n "function withAuth" src/lib/auth/middleware.ts`
+For example, finding "Card lists `<auth-module>:45` but the function `<auth-wrapper>` is at line 67" (where `<auth-module>` / `<auth-wrapper>` are the project's auth guard, resolved from `${paths.high_risk_modules}`):
+1. `Does the file exist?` → `test -f <auth-module>`
+2. `Is the function at line 45?` → `grep -n "function <auth-wrapper>" <auth-module>`
 3. `Does the proposed signature match?` → read 5 lines around the actual location
 
 Drop findings whose verification fails (i.e. the finding itself was wrong). Record them under "Hallucinated findings dropped (CoVe)".

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

@@ -211,14 +211,14 @@ Cards MUST be as atomic as possible to enable parallel execution:
 
 **Splitting heuristics:**
 - Split by concern: data model vs API vs UI vs docs
-- Split by user persona: customer-facing vs merchant-facing
+- Split by audience segment (per `identity.audience_segments`)
 - Split by module: each independent module = its own card
 - Keep tightly coupled work together (e.g., a type + its only consumer)
 
 **Anti-patterns to avoid:**
 - Monolithic "Phase 1-7" cards embedding an entire feature
 - XL cards with 15+ files — always split these
-- Cards that mix independent subsystems (e.g., booking API + promo UI)
+- Cards that mix independent subsystems (e.g., a service API + an unrelated feature's UI)
 
 ## Card Structure (MANDATORY — zero tolerance)
 

package/framework/.claude/agents/prd.md

@@ -502,7 +502,7 @@ Before creating cards, scan `backlog/*.yml` to determine the next available numb
 
 | Prefix | When to use | Example |
 |--------|-------------|---------|
-| `FEAT-NNNN-slug.yml` | Feature work | `FEAT-0127-merchant-points-guard.yml` |
+| `FEAT-NNNN-slug.yml` | Feature work | `FEAT-0127-user-rewards-guard.yml` |
 | `BUG-NNNN-slug.yml` | Bug fixes | `BUG-0071-issue-197-dashboard-bugs.yml` |
 | `UI-NNNN-slug.yml` | UI-only changes | `UI-0090-remove-install-pwa-cta.yml` |
 | `DOC-NNNN-slug.yml` | Documentation only | `DOC-0001-privacy-policy-draft.yml` |
@@ -647,7 +647,7 @@ priority: HIGH
 owner_agent: coder
 
 github_issue: NNN  # GitHub issue number
-labels: [bug, area:customer]  # area:customer | area:merchant | area:admin
+labels: [bug, area:<segment>]  # area:<segment> — values from identity.audience_segments
 
 clarity_analysis:  # MANDATORY per AGENTS.md for all bug cards
   expected_behavior: "[What should happen]"

package/framework/.claude/agents/visual-fidelity-verifier.md

@@ -52,7 +52,7 @@ The orchestrator (`/e2e-review`) invokes you with this JSON payload:
 ```json
 {
   "card_id": "FEAT-XXXX",
-  "route": "/merchant/dashboard",
+  "route": "/dashboard",
   "viewport": { "width": 1440, "height": 900 },
   "implementation_screenshot_path": "/abs/path/to/impl.png",
   "mockup_source": {
@@ -183,7 +183,7 @@ Inflating or suppressing severity to match the mode is a protocol violation.
 ```json
 {
   "status": "completed" | "skipped" | "error",
-  "route": "/merchant/dashboard",
+  "route": "/dashboard",
   "mockup_source_level": "figma" | "local" | "compliance-only" | "skip",
   "viewport": { "width": 1440, "height": 900 },
   "compliance_score": 0.87,

package/framework/.claude/agents/wiki-curator.md

@@ -102,12 +102,12 @@ exposed via dedicated MCP tools alongside `search_docs`:
 - `search_synthesis(question, level="global")` — community-summary retrieval.
   Use for **relational / cross-cutting** questions where the answer involves
   multiple modules at once. Examples:
-  - "How does auth interact with booking?"
-  - "What touches the reservations collection?"
-  - "Which areas share the merchant-theming pattern?"
+  - "How does auth interact with `<feature-X>`?"
+  - "What touches the `<entity>` collection/table?"
+  - "Which areas share the `<shared-pattern>` (e.g. a theming/layout) pattern?"
 - `search_synthesis(question, level="local")` — entity-centric retrieval
   (delegates to the existing `local` mode). Use for **specific lookups** —
-  "what is `withAuth`?", "show me the BookingTable type definition".
+  "what is `<authWrapper>`?", "show me the `<DomainType>` type definition".
 - `search_docs(query, mode="drift")` (or the dedicated `search_drift` tool) —
   the GraphRAG DRIFT pattern: first pick candidate communities via `global`,
   then run a scoped `local` retrieval for each. Use when a question is both

package/framework/.claude/commands/design-review.md

@@ -11,7 +11,7 @@ This command supports two output modes, detected from the input prompt:
 
 ### Mode A — Interactive (default)
 
-When the user invokes `/design-review` directly (input is a natural-language route reference, e.g. `/design-review /merchant/dashboard`), produce the **Markdown report** described in steps 1–5 below. Use the Blockers/High/Medium/Nitpicks template from `agents/design-review.md` § Report Template.
+When the user invokes `/design-review` directly (input is a natural-language route reference, e.g. `/design-review /dashboard`), produce the **Markdown report** described in steps 1–5 below. Use the Blockers/High/Medium/Nitpicks template from `agents/design-review.md` § Report Template.
 
 ### Mode B — Programmatic (invoked by `/e2e-review`)
 
@@ -23,7 +23,7 @@ When the input contains a JSON envelope with `"mode": "programmatic"` at any pos
 {
   "mode": "programmatic",
   "card_id": "FEAT-XXXX",
-  "route": "/merchant/dashboard",
+  "route": "/dashboard",
   "viewport": { "width": 1440, "height": 900 },
   "dev_server_port": 3000,
   "registry_paths": {
@@ -46,7 +46,7 @@ When the input contains a JSON envelope with `"mode": "programmatic"` at any pos
 {
   "status": "completed" | "skipped" | "error",
   "source": "design-review",
-  "route": "/merchant/dashboard",
+  "route": "/dashboard",
   "viewport": { "width": 1440, "height": 900 },
   "findings": [
     {
@@ -110,7 +110,7 @@ When the user invokes `/design-review`, do the following (in both modes — only
    - Read `${paths.design_system}/tokens-reference.md`.
    - Read `${paths.design_system}/components/<Name>.md` for every primitive expected on the route.
    When the flag is `false`, skip the registry reads. In Mode A flag the gap in the final report and recommend `/design-system-init`. In Mode B add the gap to the `gaps[]` array of the JSON output.
-1. Start with the route or component specified (e.g., `/merchant/dashboard`) and open it in the MCP browser. In Mode B, use the `dev_server_port` from the input envelope to construct `http://localhost:<port><route>`.
+1. Start with the route or component specified (e.g., `/dashboard`) and open it in the MCP browser. In Mode B, use the `dev_server_port` from the input envelope to construct `http://localhost:<port><route>`.
 2. Follow the Quick Visual Check in `agents/design-review.md` and run Phases 0‑7 (interaction, responsiveness, polish, accessibility, robustness, code health, content/console).
 3. Capture at least one full-page screenshot at the viewport from the input (default 1440px) and note console errors. In Mode B save the screenshot at `/tmp/design-review/<route-slug>.png` and cite it in `evidence.screenshot_path`.
 4. **Mode A**: report findings using the Markdown template in `agents/design-review.md` (Blockers/High/Medium/Nitpicks). **Mode B**: assemble the JSON output described above, normalizing severity per the table.

package/framework/.claude/skills/doc-writing-for-rag/SKILL.md

@@ -48,7 +48,7 @@ Do NOT load for:
    ```markdown
    ### POST /api/v1/domain/resource
 
-   **Auth**: withAuthNoParams  |  **Access**: ADMIN + MERCHANT
+   **Auth**: `<authWrapper>`  |  **Access**: `<ROLE_A>` + `<ROLE_B>`
 
    **Body**:
    | Field | Type | Required | Desc |

package/framework/.claude/skills/doc-writing-for-rag/references/before-after-examples.md

@@ -1,6 +1,12 @@
 # Before/After Examples — Wave 1+2+3 Compression
 
-Casi concreti validati sul corpus reale. Per ogni esempio: prima, dopo, tecnica applicata.
+> **Illustrative sample domain.** The endpoints, routes, and entity names below
+> (booking/rooms, menu/items, reservations planner, etc.) are a SAMPLE domain used
+> only to demonstrate the doc-compaction techniques — they are not part of any
+> consumer's API. Apply the *technique* (the before→after transformation), not the
+> example's vocabulary, to your own `${paths.references_dir}` docs.
+
+Concrete cases validated on a real corpus. For each example: before, after, technique applied.
 
 ## Example 1 — API Endpoint (booking.md)
 

package/framework/.claude/skills/doc-writing-for-rag/references/compact-templates.md

@@ -1,6 +1,11 @@
 # Compact Templates
 
-Template validati su 45 file in 3 wave di compressione. Ogni template include: before/after, line count, note critiche.
+> **Illustrative sample domain.** Endpoint paths, routes, roles, and entity names in
+> the filled examples below are a SAMPLE domain for demonstrating the template shapes —
+> substitute your project's own (auth wrapper, roles from `identity.audience_segments`,
+> routes, entities). Only the template *structure* is normative.
+
+Templates validated on 45 files across 3 compression waves. Each template includes: before/after, line count, critical notes.
 
 ## API Endpoint Template
 
@@ -9,7 +14,7 @@ Template validati su 45 file in 3 wave di compressione. Ogni template include: b
 ```markdown
 ### POST /api/v1/domain/resource
 
-**Auth**: withAuthNoParams  |  **Access**: ADMIN + MERCHANT
+**Auth**: `<authWrapper>`  |  **Access**: `<ROLE_A>` + `<ROLE_B>`
 
 **Body**:
 | Field | Type | Required | Desc |

package/framework/.claude/skills/doc-writing-for-rag/references/schemas-and-errors.md

@@ -1,6 +1,10 @@
 # Schemas & Errors — Central Reference Files
 
-Protocollo per usare e estendere `${paths.api_schemas}` e `${paths.api_errors}` (typically `docs/references/api/schemas.md` and `docs/references/errors.md`).
+> **Illustrative sample domain.** Error codes, routes, and entity names in the
+> examples below are a SAMPLE domain — substitute your own. Only the protocol
+> (central schema/error files, anchor cross-referencing) is normative.
+
+Protocol for using and extending `${paths.api_schemas}` and `${paths.api_errors}` (typically `docs/references/api/schemas.md` and `docs/references/errors.md`).
 
 > **Note**: the schema names and domain sections below come from a real project (a multi-merchant fidelity/loyalty platform) and are kept as a concrete example. Replace them with your own domain entities when applying this skill to a new project — the project-specific domain vocabulary lives in `.baldart/overlays/doc-writing-for-rag.md`.
 

package/framework/.claude/skills/e2e-review/SKILL.md

@@ -154,7 +154,7 @@ system constraints into a machine-readable verification plan.
    {
      "card_id": "FEAT-XXXX",
      "title": "...",
-     "routes": ["/merchant/dashboard", "/merchant/dashboard/edit"],
+     "routes": ["/dashboard", "/dashboard/edit"],
      "personas": [{"name": "merchant", "auth": "password", "creds": {...}}],
      "data_prerequisites": ["seed merchant 'demo'", "create one paid booking"],
      "scenarios": [
@@ -162,11 +162,11 @@ system constraints into a machine-readable verification plan.
          "id": "AC-1",
          "name": "Merchant can update store hours",
          "gherkin": "Feature: ...",
-         "routes_touched": ["/merchant/settings/hours"]
+         "routes_touched": ["/settings/hours"]
        }
      ],
      "non_functional_checks": ["loads in < 2s on slow 3G"],
-     "mockup_refs": [{"route": "/merchant/dashboard", "level": "local", "path": "mockups/dashboard.png"}]
+     "mockup_refs": [{"route": "/dashboard", "level": "local", "path": "mockups/dashboard.png"}]
    }
    ```
 
@@ -336,7 +336,7 @@ For each `route` in `plan.routes[]`:
      Input payload:
      {
        "card_id": "FEAT-XXXX",
-       "route": "/merchant/dashboard",
+       "route": "/dashboard",
        "viewport": { "width": 1440, "height": 900 },
        "implementation_screenshot_path": ".baldart/e2e-review/FEAT-XXXX/screenshots/merchant-dashboard.png",
        "mockup_source": { ... },

package/framework/.claude/skills/prd/references/api-perf-gate.md

@@ -70,7 +70,7 @@ Scan the PRD text for these keywords. Each match = a finding.
 | "global counter" / "total X" / "increment count" / "contatore" | Transaction hotspot (serializes writers) | HIGH |
 | "no limit" / "unlimited" / "senza limiti" / "illimitato" | Unbounded data growth | HIGH |
 | "save all in document" / "embed list" / "array nel documento" | Unbounded array in doc (max 1MB, degrades at 40K) | HIGH |
-| "upload file/image via API" / "carica file" | 4.5MB payload limit on Vercel Functions | HIGH |
+| "upload file/image via API" / "carica file" | the platform's request-body limit (e.g. 4.5MB on Vercel Functions — per `stack.deployment`) | HIGH |
 | "search by name" / "full-text search" / "cerca per nome" | Many DBs need a dedicated search index (Algolia/Typesense/Postgres FTS/Mongo Atlas Search) — DB-specific | HIGH |
 | "page N" / "skip" / "offset" / "pagina N" | Offset pagination is inefficient in most DBs (Firestore charges for skipped docs; SQL scans them) | MEDIUM |
 | "send email/SMS" in request path / "invia email/SMS" | Blocking I/O in request path (use waitUntil / background job) | MEDIUM |

package/framework/.claude/skills/prd/references/audit-phase.md

@@ -23,7 +23,7 @@ Scan each card for security signals to decide whether the `security-reviewer` ag
 | Signal | Where to look |
 |--------|---------------|
 | **New or modified API route** | `files_likely_touched` contains `route.ts`, `api/`, or requirements mention new endpoints |
-| **Authentication/authorization changes** | Requirements/files mention `withAuth`, `checkPermission`, `permissions`, login, session, token, JWT, OAuth |
+| **Authentication/authorization changes** | Requirements/files mention the project's auth-guard wrapper or permission helper (e.g. a `withAuth*`-style wrapper / `checkPermission`-style guard — resolve from `${paths.high_risk_modules}`), or generic markers: `permissions`, login, session, token, JWT, OAuth |
 | **Persistence-layer access rules** | `files_likely_touched` contains rule/policy files matching `stack.database` (e.g. `firestore.rules`, Supabase RLS migration, MongoDB validator) or requirements mention rule changes |
 | **External integrations** | Requirements mention webhooks, third-party APIs, payment, SMS, email providers, or external callbacks |
 | **File upload or media handling** | Requirements mention upload, image, file, media, or `files_likely_touched` contains upload/media paths |

package/framework/.claude/skills/prd/references/impact-analysis.md

@@ -248,7 +248,7 @@ touchpoints into the existing ISA table; assign new ISA-N IDs.
 
 ## Worked Example
 
-**CR: "Add POST /api/v1/merchant/reservations/bulk-confirm for batch confirmation"**
+**CR: "Add POST /api/v1/reservations/bulk-confirm for batch confirmation"**
 
 Change type: Addition (new endpoint)
 

package/framework/.claude/skills/prd/references/validation-phase.md

@@ -18,7 +18,7 @@ Mark task 5 as `in_progress`.
 
    b. **UI-only scope heuristic (WARN — soft gate, not blocking)** — for each card with `owner_agent: ui-expert`:
       - Concatenate `scope.summary`, `requirements[]`, and `acceptance_criteria[]` into one lowercase string.
-      - Grep for logic-marker substrings: `api call`, `endpoint`, `route handler`, `state machine`, `validation logic`, `business rule`, `database`, `migration`, `prisma`, `firestore.collection`, `auth flow`, `token storage`, `webhook`, `cron`.
+      - Grep for logic-marker substrings: `api call`, `endpoint`, `route handler`, `state machine`, `validation logic`, `business rule`, `database`, `migration`, and datastore-access patterns per `stack.database` (e.g. `prisma`, `.from(` / SQL client, `firestore.collection`, `db.collection`), `auth flow`, `token storage`, `webhook`, `cron`.
       - For each marker hit, log a WARN line in the audit output:
         `"[UI-SCOPE-WARN] Card <ID> (ui-expert) mentions '<marker>' — review whether logic belongs in a sibling coder card. See backlog-phase.md § Rule B."`
       - The check is intentionally a soft gate: substrings like "API contract per il mock" or "consumes the auth state from `useAuth()`" are legitimate UI references. The WARN exists to prompt human review, not to block.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "baldart",
-  "version": "4.0.1",
+  "version": "4.0.3",
   "description": "Claude Agent Framework - Reusable framework for coordinating AI agents and humans in software projects",
   "bin": {
     "baldart": "./bin/baldart.js"