enigma-cli 1.30.6 → 1.30.7

package/assets/memory/AGENTS.md

@@ -37,14 +37,13 @@ Non-negotiable, language-agnostic defaults - apply them by default without being
 
 - Validate EVERY external input (request body, query, params, event payload, form field, CLI arg, webhook/message) against an explicit schema before use - Zod (TS/JS), Pydantic (Python), the language's equivalent elsewhere. Never consume an unvalidated shape or leave it open-ended. When the input is a tagged/event union, validate the discriminant AND that specific variant's body, with the expected fields typed.
 - Frontend forms: validate in real time against the same schema, and use optimistic UI with rollback on failure for user-facing mutations.
-- When a value must be unique within a set the client already holds (a list of names, slugs, emails, tags the user just rendered or is editing), check uniqueness/availability in real time against that loaded data on every change and block the conflicting submit BEFORE any server call - instant feedback for the user, no wasted round-trip or DB query. Apply this whenever duplicates are disallowed (unique names, one-per-parent, "already in use"); mirror the server's exact rule (trim, case-fold, scope, reserved values) and exclude the record's own current value when editing so renaming to the same value is not flagged. The backend still re-validates as the authority (client data can be stale).
 - Cache reads on the client (localStorage/sessionStorage, or the data layer's cache) with a short TTL (~30s or more) to avoid redundant queries and survive rate limits; invalidate on write.
 - Build reusable, composable components instead of duplicating UI - e.g. a single Input that renders a show/hide toggle when the type is password. Reuse before writing new.
 - Never use the browser's native `alert`/`confirm`/`prompt` - use a dialog/modal component that matches the page design.
-- Display dates/timestamps as localized, auto-updating values - never hand-rolled `toLocaleString`/"X ago" math scattered across components, nor a heavy date library just to format one. On the web use `<relative-time>` (`@github/relative-time-element`): `<relative-time datetime="<ISO-8601>">fallback</relative-time>` renders relative phrasing that updates itself, localizes to the user's timezone/locale via `Intl`, is accessible, and SSR-caches with a graceful no-JS fallback (the slotted text); switch relative vs. absolute with `format`/`tense`/`precision`/`threshold`. Keep raw ISO-8601/UTC in your data; localize only at render. Off the web, centralize formatting in one shared `Intl`-based helper with the same "store UTC, localize at render" rule.
 
 ### Task Execution (Always-On)
 
+- Treat correctness as mission-critical: do the work excellently, as if lives depend on it being right. Finish every part of what was asked with nothing left pending, and before claiming it is done VERIFY it actually works - exercise the exact behavior requested (run it, test it, reproduce the scenario), not merely that it compiles or typechecks. If you have not verified it, do not say it is done; state precisely what remains or is unverified.
 - A message that bundles several asks, questions, or items is a MULTI-PART task - even if it is just two, three, or four things. Before doing anything, extract EVERY distinct ask into an explicit list (the runtime's todo system when it has one, else a written checklist) and treat the request as unfinished until every item on that list is addressed. Never answer the first ask and drop, summarize away, or postpone the rest. When you present a plan, execute the whole plan - do not stop after listing it.
 - For long or complex tasks - or any task you judge to warrant it - break the work into smaller, well-scoped subtasks and complete them incrementally, validating each subtask before moving to the next. Map the dependencies between subtasks first, and do only the decomposition the task genuinely needs - never over-decompose simple work.
 - For multi-item work (ports, migrations, batch changes), enumerate the FULL inventory of work units with deterministic commands before implementing, persist it as a checklist (file or todo system), and mark a unit done only after verifying it - never because a similar unit worked. This is the task-completion-policy skill; load it for any task that spans many files/items or bundles several asks.

package/assets/memory/CLAUDE.md

@@ -37,14 +37,13 @@ Non-negotiable, language-agnostic defaults - apply them by default without being
 
 - Validate EVERY external input (request body, query, params, event payload, form field, CLI arg, webhook/message) against an explicit schema before use - Zod (TS/JS), Pydantic (Python), the language's equivalent elsewhere. Never consume an unvalidated shape or leave it open-ended. When the input is a tagged/event union, validate the discriminant AND that specific variant's body, with the expected fields typed.
 - Frontend forms: validate in real time against the same schema, and use optimistic UI with rollback on failure for user-facing mutations.
-- When a value must be unique within a set the client already holds (a list of names, slugs, emails, tags the user just rendered or is editing), check uniqueness/availability in real time against that loaded data on every change and block the conflicting submit BEFORE any server call - instant feedback for the user, no wasted round-trip or DB query. Apply this whenever duplicates are disallowed (unique names, one-per-parent, "already in use"); mirror the server's exact rule (trim, case-fold, scope, reserved values) and exclude the record's own current value when editing so renaming to the same value is not flagged. The backend still re-validates as the authority (client data can be stale).
 - Cache reads on the client (localStorage/sessionStorage, or the data layer's cache) with a short TTL (~30s or more) to avoid redundant queries and survive rate limits; invalidate on write.
 - Build reusable, composable components instead of duplicating UI - e.g. a single Input that renders a show/hide toggle when the type is password. Reuse before writing new.
 - Never use the browser's native `alert`/`confirm`/`prompt` - use a dialog/modal component that matches the page design.
-- Display dates/timestamps as localized, auto-updating values - never hand-rolled `toLocaleString`/"X ago" math scattered across components, nor a heavy date library just to format one. On the web use `<relative-time>` (`@github/relative-time-element`): `<relative-time datetime="<ISO-8601>">fallback</relative-time>` renders relative phrasing that updates itself, localizes to the user's timezone/locale via `Intl`, is accessible, and SSR-caches with a graceful no-JS fallback (the slotted text); switch relative vs. absolute with `format`/`tense`/`precision`/`threshold`. Keep raw ISO-8601/UTC in your data; localize only at render. Off the web, centralize formatting in one shared `Intl`-based helper with the same "store UTC, localize at render" rule.
 
 ### Task Execution (Always-On)
 
+- Treat correctness as mission-critical: do the work excellently, as if lives depend on it being right. Finish every part of what was asked with nothing left pending, and before claiming it is done VERIFY it actually works - exercise the exact behavior requested (run it, test it, reproduce the scenario), not merely that it compiles or typechecks. If you have not verified it, do not say it is done; state precisely what remains or is unverified.
 - A message that bundles several asks, questions, or items is a MULTI-PART task - even if it is just two, three, or four things. Before doing anything, extract EVERY distinct ask into an explicit list (the runtime's todo system when it has one, else a written checklist) and treat the request as unfinished until every item on that list is addressed. Never answer the first ask and drop, summarize away, or postpone the rest. When you present a plan, execute the whole plan - do not stop after listing it.
 - For long or complex tasks - or any task you judge to warrant it - break the work into smaller, well-scoped subtasks and complete them incrementally, validating each subtask before moving to the next. Map the dependencies between subtasks first, and do only the decomposition the task genuinely needs - never over-decompose simple work.
 - For multi-item work (ports, migrations, batch changes), enumerate the FULL inventory of work units with deterministic commands before implementing, persist it as a checklist (file or todo system), and mark a unit done only after verifying it - never because a similar unit worked. This is the task-completion-policy skill; load it for any task that spans many files/items or bundles several asks.

package/assets/skills/anti-overengineering-policy/skill.json

@@ -7,6 +7,6 @@
     "minimalCode"
   ],
   "updated": "2026-07-17T00:17:02+02:00",
-  "cliVersion": "1.30.6",
+  "cliVersion": "1.30.7",
   "sha": "3f0dcc28341bb0407860534f7ce9314cfc91b5e673f8f3d13b89d61851ed75f6"
 }

package/assets/skills/anti-overengineering-review/skill.json

@@ -4,6 +4,6 @@
   "provider": "FJRG2007/enigma",
   "description": "On-demand over-engineering review - diff review, whole-repo audit, and enigma: debt-marker ledger (tags delete/stdlib/native/yagni/shrink, line/dep scoring); lists cuts, applies nothing.",
   "updated": "2026-06-16T11:24:30+02:00",
-  "cliVersion": "1.30.6",
+  "cliVersion": "1.30.7",
   "sha": "f742a2be3f328b9ea1ff9a35a449177c2cbec35ad16e46f7054b7a873a2ab017"
 }

package/assets/skills/backend-policy/skill.json

@@ -4,6 +4,6 @@
   "provider": "FJRG2007/enigma",
   "description": "Backend/API architecture: controller-service-repository layering, API and request optimization, server-side caching (Redis), and Zod boundary validation.",
   "updated": "2026-06-16T12:06:06+02:00",
-  "cliVersion": "1.30.6",
+  "cliVersion": "1.30.7",
   "sha": "a46c3cd00aa5f47adb1e7907f1d2bc6f5562f7a272890dee9b1121976ac04ae1"
 }

package/assets/skills/ciphera-style-policy/skill.json

@@ -4,6 +4,6 @@
   "provider": "FJRG2007/enigma",
   "description": "Ciphera code style conventions (formatting, naming, imports, comments, code-level anti-patterns; TypeScript-first, language-agnostic).",
   "updated": "2026-06-26T13:40:52+02:00",
-  "cliVersion": "1.30.6",
+  "cliVersion": "1.30.7",
   "sha": "dc9ceb784004b05a0117c464e4bed05946835a04acea282586c0b735ee7c2284"
 }

package/assets/skills/code-review-policy/skill.json

@@ -4,6 +4,6 @@
   "provider": "FJRG2007/enigma",
   "description": "Pre-delivery self-review gate, prioritized review dimensions, and change-quality criteria.",
   "updated": "2026-06-01T00:45:28+02:00",
-  "cliVersion": "1.30.6",
+  "cliVersion": "1.30.7",
   "sha": "3d3bbe0602d5bbb4afe37648fe3c2fa39376b1bcbac5d8c441f01fad1e866ed0"
 }

package/assets/skills/core-engineering-policy/skill.json

@@ -4,6 +4,6 @@
   "provider": "FJRG2007/enigma",
   "description": "Core engineering execution policy and harness orchestration (highest-authority rules).",
   "updated": "2026-07-16T22:43:53+02:00",
-  "cliVersion": "1.30.6",
+  "cliVersion": "1.30.7",
   "sha": "d132f20db08806054d95e58d3d56c2aa7ebc8e6dd24d902b0a0ed9ddfae216c5"
 }

package/assets/skills/database-expert/skill.json

@@ -4,6 +4,6 @@
   "provider": "FJRG2007/enigma",
   "description": "Senior database architecture policy: query optimization, anti-duplication/normalization, scalability, and RGPD/GDPR encryption.",
   "updated": "2026-06-03T14:19:50+02:00",
-  "cliVersion": "1.30.6",
+  "cliVersion": "1.30.7",
   "sha": "2883bcecb3202683ae6f81b073c3d6a9cec9c55029e011bdd06ba7ac3537297e"
 }

package/assets/skills/debugging-policy/skill.json

@@ -4,6 +4,6 @@
   "provider": "FJRG2007/enigma",
   "description": "Reproduce-isolate-fix debugging methodology with root-cause discipline and regression verification.",
   "updated": "2026-06-01T00:45:28+02:00",
-  "cliVersion": "1.30.6",
+  "cliVersion": "1.30.7",
   "sha": "14b0064c8b33a0dc85e51464b05005cf5801c756b1101789a6924b9548420f6b"
 }

package/assets/skills/dependency-policy/skill.json

@@ -4,6 +4,6 @@
   "provider": "FJRG2007/enigma",
   "description": "Dependency and supply-chain security: lockfiles and reproducible installs, version pinning, vulnerability auditing, vetting/minimizing packages, vendoring, and SBOM/provenance.",
   "updated": "2026-06-01T00:45:28+02:00",
-  "cliVersion": "1.30.6",
+  "cliVersion": "1.30.7",
   "sha": "6375d835c2aef2c9bd31ce116444dc3d796f510f9970a213aa3ac4696d7e21b9"
 }

package/assets/skills/frontend-design/skill.json

@@ -4,6 +4,6 @@
   "provider": "FJRG2007/enigma",
   "description": "Guidance for distinctive, intentional visual design when building new UI or reshaping an existing one.",
   "updated": "2026-06-25T15:51:43-04:00",
-  "cliVersion": "1.30.6",
+  "cliVersion": "1.30.7",
   "sha": "fb78be3233bf9caa67d1f522c19831542b23f47e440b02211b5a950c898318b9"
 }

package/assets/skills/frontend-policy/SKILL.md

@@ -64,6 +64,16 @@ description: Frontend architecture - reusable components, abstraction thresholds
 
 ---
 
+## Visual Hierarchy & Layout Restraint
+
+Keep surfaces flat and let spacing, not chrome, do the grouping.
+
+- Do not nest a card inside another card. A card already establishes a surface; wrapping cards in cards stacks backgrounds, paddings, and shadows into visual noise. Group related content inside one card with spacing, a heading, or a light divider - not a second bordered container.
+- Do not add borders, boxes, or dividers that carry no information. A border is justified only when it marks a real boundary the user needs (a distinct interactive region, a table edge); otherwise prefer whitespace, type weight, and grouping over outlines, and reach for a divider only when spacing alone cannot convey the separation.
+- Avoid redundant containers in general: one elevation/background per surface, minimal wrapping, and consistent padding read cleaner and are easier to maintain than deeply nested boxed layouts.
+
+---
+
 ## State Management
 
 - Keep state as local as possible; lift it only when genuinely shared.
@@ -188,11 +198,21 @@ Render dates and timestamps as localized, auto-updating values. Do not hand-roll
 
 ---
 
+## Search & Filtering
+
+For a user-facing search box or finder over a list, use fuse.js (fuzzy search) rather than a hand-rolled `.toLowerCase().includes()` filter. Fuzzy matching tolerates typos and partial or transposed input and ranks results by relevance - which is what users expect from a search field; a raw substring filter misses "usnig" for "using" and cannot rank. Apply it by default without being asked whenever the input is a free-text search.
+
+- Reach for fuse.js whenever the input is a search/filter box the user types free text into. Keep a plain equality/predicate filter only for exact, structured filtering (a status dropdown, a tag toggle) where fuzziness would be wrong.
+- Configure the searched `keys` and a sensible `threshold`, and run the search over the already-loaded client list where possible (reuse the data, per Client-Side Caching) before falling back to a server query.
+
+---
+
 ## Accessibility & Resilience
 
 - Use semantic markup and accessible interactive elements by default.
 - Handle loading, empty, and error states explicitly for every async view.
 - Validate user input in real time per validation-policy; never rely on the UI as the only validation layer.
+- When a select/dropdown/radio group (or any single-choice control) resolves to exactly one option, preselect it by default so the user is not forced to open a menu to pick the only possibility; disable the control when that single option is fixed. This applies whenever the set narrows to one, including after filtering or an async load.
 
 ---
 

package/assets/skills/frontend-policy/skill.json

@@ -1,9 +1,9 @@
 {
   "name": "frontend-policy",
-  "version": "1.6.0",
+  "version": "1.9.0",
   "provider": "FJRG2007/enigma",
   "description": "Frontend architecture: reusable components, abstraction thresholds, state management, no-op save detection, large-list rendering (infinite scroll/pagination, virtualization, skeletons, progressive loading), and optimistic UI with rollback.",
-  "updated": "2026-07-22T00:21:54+02:00",
-  "cliVersion": "1.30.6",
-  "sha": "aac4a6fa8ef875ce968ef35613361c78d1935972bf224770ca286998f8f053e5"
+  "updated": "2026-07-22T01:41:06+02:00",
+  "cliVersion": "1.30.7",
+  "sha": "c5e0b4ac972e6448331bc56f7fc0069f3f57c3515ea719d0be46addfc8dbb064"
 }

package/assets/skills/git-policy/skill.json

@@ -4,6 +4,6 @@
   "provider": "FJRG2007/enigma",
   "description": "Git & contribution policy (senior engineering standards).",
   "updated": "2026-07-16T22:44:02+02:00",
-  "cliVersion": "1.30.6",
+  "cliVersion": "1.30.7",
   "sha": "e6dfbc33884000d9d25841bd9c5a84d6558ffd374882cb7b34451eb2cebc2161"
 }

package/assets/skills/logo-sourcing-policy/skill.json

@@ -7,6 +7,6 @@
     "logoColorPolicy"
   ],
   "updated": "2026-07-17T00:17:02+02:00",
-  "cliVersion": "1.30.6",
+  "cliVersion": "1.30.7",
   "sha": "09cdbefd98625b02a7d03685e5deed128238ff8454a83fe22279610fe3ef8ddf"
 }

package/assets/skills/security-policy/skill.json

@@ -4,6 +4,6 @@
   "provider": "FJRG2007/enigma",
   "description": "Application and AI-agent security: secrets, authn/authz (least privilege), OWASP Top 10, transport/crypto baseline, secure logging, and agent/MCP/tool-use safety.",
   "updated": "2026-06-01T00:45:28+02:00",
-  "cliVersion": "1.30.6",
+  "cliVersion": "1.30.7",
   "sha": "9971e9d9127397d0152e89d24aad3191e2935e55a8483db7fd15f5d4d7a60e7a"
 }

package/assets/skills/skill-creator/skill.json

@@ -4,6 +4,6 @@
   "provider": "FJRG2007/enigma",
   "description": "Create new skills, modify and improve existing skills, and measure skill performance with evals and benchmarks.",
   "updated": "2026-06-16T16:39:13+02:00",
-  "cliVersion": "1.30.6",
+  "cliVersion": "1.30.7",
   "sha": "699586cce82ec0a5458288b598ee7e5ebdddb3dfcf19db354d8bc5e85e47c1c7"
 }

package/assets/skills/task-completion-policy/skill.json

@@ -4,6 +4,6 @@
   "provider": "FJRG2007/enigma",
   "description": "Exhaustive completion discipline for long/multi-item tasks - inventory, coverage ledger, verified done.",
   "updated": "2026-07-21T20:25:56+02:00",
-  "cliVersion": "1.30.6",
+  "cliVersion": "1.30.7",
   "sha": "feaf44a9b3ab9676c8ebd3c2a799f156d28419998f5a5355250fe95a28cd5a01"
 }

package/assets/skills/technical-writing-policy/SKILL.md

@@ -62,6 +62,14 @@ microcopy - the reader shouldn't have to study it.
 - READMEs: assume a competent reader. Explain what is non-obvious or load-bearing (how to
   run it, the one surprising constraint, why a choice was made) and skip what the audience
   already knows or can infer from the code. Lead with the point; cut the throat-clearing.
+- Do NOT volunteer a "Project Structure" section with an ASCII/box-drawing file tree and a
+  folder-by-folder explanation ("src/ contains the files of the application", "public/:
+  contains static files") on your own initiative. It is the hallmark of an AI-written README:
+  it rots the instant a file moves, is usually misaligned, and restates what the reader sees in
+  the file browser - real project READMEs rarely ship one. If the user explicitly asks for a
+  project-structure tree, generate it (well-formed and accurate); just never add one unprompted.
+  Otherwise document a directory only when its purpose is non-obvious and load-bearing, in one
+  line of prose, never a whole tree.
 
 ## Reviewing existing copy
 

package/assets/skills/technical-writing-policy/skill.json

@@ -1,9 +1,9 @@
 {
   "name": "technical-writing-policy",
-  "version": "1.1.0",
+  "version": "1.2.0",
   "provider": "FJRG2007/enigma",
   "description": "Concise, realistic technical copy - UI microcopy, descriptions, hints, empty/error states, and README/doc prose that informs without over-explaining or restating the obvious.",
-  "updated": "2026-06-26T14:09:06+02:00",
-  "cliVersion": "1.30.6",
-  "sha": "e750988b8de51d8a69be621673dceca5413ebad7e1a48e40acd18aad526d9928"
+  "updated": "2026-07-22T01:41:06+02:00",
+  "cliVersion": "1.30.7",
+  "sha": "a8c008fac91782de0d4ef1a4ae6ee77d69e3c0a506ea06b649aa86a6c988bc4f"
 }

package/assets/skills/testing-policy/skill.json

@@ -4,6 +4,6 @@
   "provider": "FJRG2007/enigma",
   "description": "Test strategy, coverage gates, deterministic tests, mocking discipline, regression-first bug fixing, and test-suite organization (layout by type/domain, mirrored paths, file naming, fixture/helper placement).",
   "updated": "2026-06-16T17:11:49+02:00",
-  "cliVersion": "1.30.6",
+  "cliVersion": "1.30.7",
   "sha": "3bdf591057b760f674fb2b1425f63acb426cda2c4f042e1a74c5a5d3807df664"
 }

package/assets/skills/validation-policy/SKILL.md

@@ -73,6 +73,7 @@ description: Strict frontend + backend schema validation (Zod or equivalent), sc
   - Internal paths
   - Service names
 - Log detailed errors internally only, with enough context to debug.
+- Concretely: in a catch block never return the caught error's `message`/`stack` or the raw error object to the client. A leaked ORM/DB error like `Invalid prisma.driveItemMeta.findMany() invocation: Inconsistent column data: Error creating UUID...` exposes your ORM, table/column names, and internals to an attacker. Log the real error server-side (`console.error` or your logger) and respond with a generic message plus a stable code. This is about 5xx internal failures; a 4xx validation reply may carry a safe, caller-actionable message you constructed, never a raw framework/ORM error.
 - Use consistent, structured error responses (stable codes, safe messages).
 - Distinguish validation errors (4xx, actionable) from internal failures (5xx, opaque to the client).
 - Never leak the existence or absence of sensitive resources through error differences.

package/assets/skills/validation-policy/skill.json

@@ -1,9 +1,9 @@
 {
   "name": "validation-policy",
-  "version": "1.2.0",
+  "version": "1.3.0",
   "provider": "FJRG2007/enigma",
   "description": "Strict frontend + backend schema validation, schema consistency, and safe client-facing error handling.",
-  "updated": "2026-07-22T00:21:54+02:00",
-  "cliVersion": "1.30.6",
-  "sha": "24cda38efc700bed1fcdaca006834b8df6daf75ac5a8b75b00f68728471a26e1"
+  "updated": "2026-07-22T01:41:06+02:00",
+  "cliVersion": "1.30.7",
+  "sha": "d937df0052d1ec151728a28f6567744d9e7ca0a65d84b4d5c9a697f1e40d704f"
 }

package/bin/checksums.json

@@ -1,6 +1,6 @@
 {
-  "enigma-darwin-arm64": "f9d771e9f5230cef78d37f428db4f9fd0d5eba50157665153656d5ea15753a0c",
-  "enigma-linux-arm64": "b823ffa1f2059dda5ff80559228268ecde03c69ff64240282cb4421caf635509",
-  "enigma-linux-x64": "08a0fdb81242947331fb98a2d7f361bdfdd19616fcc6233b830092dbd4444557",
-  "enigma-win32-x64.exe": "f59e9668e991f82eb1aeb00237c607a7a81df75fd8f57a3cf7d97c48e7ee70b0"
+  "enigma-darwin-arm64": "ec0e3648824798d272df7bfcd36a3de7cdbc02e5684f6fecbaa8108f32fdea9a",
+  "enigma-linux-arm64": "1e2fd06ad4ce9c23d134d647c177d8ee86463ab544441e61db477b632f78400f",
+  "enigma-linux-x64": "6a31ba93f9b379d81cd32a081ce5a4e3761870b0aefbd7a404e26b5365b0607a",
+  "enigma-win32-x64.exe": "d906126cd9a28c20bd80e973e00f6715596e2b887806b5681c8207065fe0f02b"
 }

package/dist/guardrails.js

@@ -102,6 +102,70 @@ var BUILTIN_RULES = [
     message: "Native browser dialog (alert/confirm/prompt) - use a dialog/modal component that matches the page design instead of the browser's built-in (frontend-policy).",
     severity: "warn",
     skill: "frontend-policy"
+  },
+  {
+    id: "fe-date-moment",
+    label: "Modern date handling (no moment.js)",
+    files: ["*.tsx", "*.jsx", "*.vue", "*.svelte", "*.astro"],
+    excludeFiles: ["*.test.*", "*.spec.*", "**/tests/**", "**/__tests__/**"],
+    scope: "file",
+    // Importing moment / moment-timezone. The `from "..."` / `require("...")` specifier is
+    // unambiguous (near-zero FP): a quote must sit right before `moment`, so "react-moment"
+    // and a prose "...from moment" string do not match, and comment lines are skipped anyway.
+    // This is the only regex-gateable slice of the date-display convention - "use
+    // <relative-time>" itself is a positive semantic recommendation the engine cannot assert.
+    pattern: `from\\s+["']moment(?:-timezone)?["']|require\\(\\s*["']moment(?:-timezone)?["']\\s*\\)`,
+    message: "moment.js is heavy and in maintenance mode. For displaying dates use <relative-time> (@github/relative-time-element) or the native Intl APIs; for date math prefer a lightweight option (date-fns, dayjs, or Temporal) (frontend-policy).",
+    severity: "warn",
+    skill: "frontend-policy"
+  },
+  {
+    id: "fe-search-fuzzy",
+    label: "Fuzzy search for finders (fuse.js)",
+    files: ["*.tsx", "*.jsx", "*.vue", "*.svelte", "*.astro"],
+    excludeFiles: ["*.test.*", "*.spec.*", "**/tests/**", "**/__tests__/**"],
+    scope: "file",
+    // A hand-rolled case-insensitive substring finder: a .filter(...) whose body does
+    // `.toLowerCase().includes(....toLowerCase())`. The SYMMETRIC double-toLowerCase inside a
+    // filter is a near-certain search box (precision over recall - a one-sided or non-filter
+    // .includes is intentionally not matched). Skipped when fuse is already present in the file.
+    pattern: "\\.filter\\([^;]*\\.toLowerCase\\(\\)\\.includes\\([^;]*\\.toLowerCase\\(\\)",
+    absent: "fuse",
+    message: "Hand-rolled substring search. For a free-text search box use fuse.js (fuzzy search): it tolerates typos and ranks matches, which is more robust and professional than a case-insensitive .includes() filter (frontend-policy).",
+    severity: "warn",
+    skill: "frontend-policy"
+  },
+  {
+    id: "doc-no-file-tree",
+    label: "No ASCII file-tree in the README",
+    // README only, at any depth. Scoped deliberately: a file tree in a deliberate
+    // authoring guide or tutorial (e.g. a skill-creation doc) is legitimate; the
+    // auto-generated "Project Structure" tree in a README is the AI tell this targets.
+    files: ["README.md", "README.mdx", "readme.md", "readme.mdx"],
+    scope: "file",
+    // Box-drawing branch connectors (U+251C '├' and U+2514 '└' followed by U+2500 '─') are
+    // the signature of an auto-generated project-structure tree; they appear almost nowhere
+    // else in prose, markdown tables, or mermaid.
+    pattern: "[\\u251C\\u2514]\\u2500",
+    message: "ASCII/box-drawing project-structure tree in the README. Only keep one if the user explicitly asked for it - never volunteer it. If unprompted, drop the tree and the folder-by-folder explanation: it rots when files move, is usually misaligned, and restates what the file browser shows (technical-writing-policy).",
+    severity: "warn",
+    skill: "technical-writing-policy"
+  },
+  {
+    id: "be-no-leak-internal-error",
+    label: "Do not leak internal errors to the client",
+    files: ["*.ts", "*.js", "*.mts", "*.cts"],
+    excludeFiles: ["*.test.*", "*.spec.*", "**/tests/**", "**/__tests__/**"],
+    scope: "file",
+    // Two high-signal one-line leaks: (a) a 5xx response whose body includes a caught error's
+    // .message/.stack (the Prisma/DB-error leak), or (b) a stack trace passed into any response
+    // body. A 4xx validation reply carrying a constructed .message is deliberately NOT matched
+    // (those can be safe). `console.error(err.message)` / `logger.error(err.stack)` are not
+    // responses, so logging the real error is never flagged - only sending it out is.
+    pattern: "\\.status\\(\\s*5\\d\\d\\s*\\)[^;]*\\b(err|error|e|ex|exception)\\.(message|stack)\\b|(res|reply|response)\\.(json|send|end)\\([^;]*\\b(err|error|e|ex|exception)\\.stack\\b",
+    message: "Leaking an internal error to the client. Never send a caught exception's .message/.stack (or a raw ORM/DB error) in a 5xx response - it exposes your schema, ORM, and internals. Log it server-side (console.error / your logger) and return a generic message with a stable code (validation-policy, security-policy).",
+    severity: "warn",
+    skill: "validation-policy"
   }
 ];
 var PROJECT_CHECKS = {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "enigma-cli",
-  "version": "1.30.6",
+  "version": "1.30.7",
   "description": "Everything you need to work with a coding agent: install shared policy skills for Claude Code, OpenAI Codex and opencode, and set up portable git security hooks.",
   "type": "module",
   "bin": {