enigma-cli 1.30.5 → 1.30.7

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -43,6 +43,7 @@ Non-negotiable, language-agnostic defaults - apply them by default without being
43
43
 
44
44
  ### Task Execution (Always-On)
45
45
 
46
+ - 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.
46
47
  - 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.
47
48
  - 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.
48
49
  - 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.
@@ -43,6 +43,7 @@ Non-negotiable, language-agnostic defaults - apply them by default without being
43
43
 
44
44
  ### Task Execution (Always-On)
45
45
 
46
+ - 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.
46
47
  - 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.
47
48
  - 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.
48
49
  - 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.
@@ -7,6 +7,6 @@
7
7
  "minimalCode"
8
8
  ],
9
9
  "updated": "2026-07-17T00:17:02+02:00",
10
- "cliVersion": "1.30.5",
10
+ "cliVersion": "1.30.7",
11
11
  "sha": "3f0dcc28341bb0407860534f7ce9314cfc91b5e673f8f3d13b89d61851ed75f6"
12
12
  }
@@ -4,6 +4,6 @@
4
4
  "provider": "FJRG2007/enigma",
5
5
  "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.",
6
6
  "updated": "2026-06-16T11:24:30+02:00",
7
- "cliVersion": "1.30.5",
7
+ "cliVersion": "1.30.7",
8
8
  "sha": "f742a2be3f328b9ea1ff9a35a449177c2cbec35ad16e46f7054b7a873a2ab017"
9
9
  }
@@ -4,6 +4,6 @@
4
4
  "provider": "FJRG2007/enigma",
5
5
  "description": "Backend/API architecture: controller-service-repository layering, API and request optimization, server-side caching (Redis), and Zod boundary validation.",
6
6
  "updated": "2026-06-16T12:06:06+02:00",
7
- "cliVersion": "1.30.5",
7
+ "cliVersion": "1.30.7",
8
8
  "sha": "a46c3cd00aa5f47adb1e7907f1d2bc6f5562f7a272890dee9b1121976ac04ae1"
9
9
  }
@@ -4,6 +4,6 @@
4
4
  "provider": "FJRG2007/enigma",
5
5
  "description": "Ciphera code style conventions (formatting, naming, imports, comments, code-level anti-patterns; TypeScript-first, language-agnostic).",
6
6
  "updated": "2026-06-26T13:40:52+02:00",
7
- "cliVersion": "1.30.5",
7
+ "cliVersion": "1.30.7",
8
8
  "sha": "dc9ceb784004b05a0117c464e4bed05946835a04acea282586c0b735ee7c2284"
9
9
  }
@@ -4,6 +4,6 @@
4
4
  "provider": "FJRG2007/enigma",
5
5
  "description": "Pre-delivery self-review gate, prioritized review dimensions, and change-quality criteria.",
6
6
  "updated": "2026-06-01T00:45:28+02:00",
7
- "cliVersion": "1.30.5",
7
+ "cliVersion": "1.30.7",
8
8
  "sha": "3d3bbe0602d5bbb4afe37648fe3c2fa39376b1bcbac5d8c441f01fad1e866ed0"
9
9
  }
@@ -4,6 +4,6 @@
4
4
  "provider": "FJRG2007/enigma",
5
5
  "description": "Core engineering execution policy and harness orchestration (highest-authority rules).",
6
6
  "updated": "2026-07-16T22:43:53+02:00",
7
- "cliVersion": "1.30.5",
7
+ "cliVersion": "1.30.7",
8
8
  "sha": "d132f20db08806054d95e58d3d56c2aa7ebc8e6dd24d902b0a0ed9ddfae216c5"
9
9
  }
@@ -4,6 +4,6 @@
4
4
  "provider": "FJRG2007/enigma",
5
5
  "description": "Senior database architecture policy: query optimization, anti-duplication/normalization, scalability, and RGPD/GDPR encryption.",
6
6
  "updated": "2026-06-03T14:19:50+02:00",
7
- "cliVersion": "1.30.5",
7
+ "cliVersion": "1.30.7",
8
8
  "sha": "2883bcecb3202683ae6f81b073c3d6a9cec9c55029e011bdd06ba7ac3537297e"
9
9
  }
@@ -4,6 +4,6 @@
4
4
  "provider": "FJRG2007/enigma",
5
5
  "description": "Reproduce-isolate-fix debugging methodology with root-cause discipline and regression verification.",
6
6
  "updated": "2026-06-01T00:45:28+02:00",
7
- "cliVersion": "1.30.5",
7
+ "cliVersion": "1.30.7",
8
8
  "sha": "14b0064c8b33a0dc85e51464b05005cf5801c756b1101789a6924b9548420f6b"
9
9
  }
@@ -4,6 +4,6 @@
4
4
  "provider": "FJRG2007/enigma",
5
5
  "description": "Dependency and supply-chain security: lockfiles and reproducible installs, version pinning, vulnerability auditing, vetting/minimizing packages, vendoring, and SBOM/provenance.",
6
6
  "updated": "2026-06-01T00:45:28+02:00",
7
- "cliVersion": "1.30.5",
7
+ "cliVersion": "1.30.7",
8
8
  "sha": "6375d835c2aef2c9bd31ce116444dc3d796f510f9970a213aa3ac4696d7e21b9"
9
9
  }
@@ -4,6 +4,6 @@
4
4
  "provider": "FJRG2007/enigma",
5
5
  "description": "Guidance for distinctive, intentional visual design when building new UI or reshaping an existing one.",
6
6
  "updated": "2026-06-25T15:51:43-04:00",
7
- "cliVersion": "1.30.5",
7
+ "cliVersion": "1.30.7",
8
8
  "sha": "fb78be3233bf9caa67d1f522c19831542b23f47e440b02211b5a950c898318b9"
9
9
  }
@@ -64,6 +64,16 @@ description: Frontend architecture - reusable components, abstraction thresholds
64
64
 
65
65
  ---
66
66
 
67
+ ## Visual Hierarchy & Layout Restraint
68
+
69
+ Keep surfaces flat and let spacing, not chrome, do the grouping.
70
+
71
+ - 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.
72
+ - 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.
73
+ - 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.
74
+
75
+ ---
76
+
67
77
  ## State Management
68
78
 
69
79
  - Keep state as local as possible; lift it only when genuinely shared.
@@ -97,6 +107,16 @@ Decide per case which mode fits; when in doubt for simple single-user forms and
97
107
 
98
108
  ---
99
109
 
110
+ ## Real-Time Uniqueness Against Loaded Data
111
+
112
+ When the user edits a value that must be unique within a set the client already holds in memory (the list of names, slugs, tags, emails it just rendered), validate uniqueness against that loaded data on every change instead of waiting for a server round-trip to report "already taken". The set is already loaded - reuse it (per Client-Side Caching): the user gets instant inline feedback as they type, and a redundant request (and its downstream DB query) is skipped. This is a default to apply without being asked, not a feature to wait for the user to request.
113
+
114
+ - Apply whenever duplicates are disallowed (unique names, slugs, one-per-parent constraints, "already in use", reserved values). Skip it when repeats are legitimate - never gate a value the model has no basis to treat as unique.
115
+ - Check on every change/blur and block submission while a conflict stands; surface the conflict inline, not only on submit.
116
+ - The cross-record rule itself - mirror the server's exact check (trim, case-fold, scope, reserved values), exclude the edited record's own value, and keep the server as the authority since client data can be stale - is owned by validation-policy. This client check is a UX and request-saving accelerator, never the sole validation layer.
117
+
118
+ ---
119
+
100
120
  ## Client-Side Caching (Reduce Server Load)
101
121
 
102
122
  Cache on the client to avoid redundant server round-trips and to keep the app usable under rate limits. The goal is to reach the backend (and therefore Redis/DB) as rarely as correctness allows.
@@ -168,11 +188,31 @@ Never render an unbounded or large dataset in one shot (no fetch-everything then
168
188
 
169
189
  ---
170
190
 
191
+ ## Dates & Timestamps
192
+
193
+ Render dates and timestamps as localized, auto-updating values. Do not hand-roll formatting (`new Date().toLocaleString`, ad-hoc "X ago" math) scattered across components, and do not pull in a heavy date library just to display a time.
194
+
195
+ - On the web, use the `<relative-time>` element (`@github/relative-time-element`, MIT, dependency-light): `<relative-time datetime="<ISO-8601>">fallback text</relative-time>`. It renders relative phrasing that updates itself ("3 minutes ago" -> "4 minutes ago"), localizes to the user's timezone and locale via `Intl`, is accessible, and works server-rendered with a graceful no-JS fallback (the slotted text is what the server caches). Switch relative vs. absolute with `format`, `tense`, `precision`, and `threshold`, and style it through `::part(root)`.
196
+ - Keep the raw ISO-8601 / UTC value in data and state; localize only at the render boundary. Never store or compare pre-formatted date strings.
197
+ - Where a custom element is not available (React Native, non-web surfaces), centralize formatting in one shared helper built on the platform `Intl` APIs rather than repeating format calls, and keep the same "store UTC, localize at render" rule.
198
+
199
+ ---
200
+
201
+ ## Search & Filtering
202
+
203
+ 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.
204
+
205
+ - 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.
206
+ - 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.
207
+
208
+ ---
209
+
171
210
  ## Accessibility & Resilience
172
211
 
173
212
  - Use semantic markup and accessible interactive elements by default.
174
213
  - Handle loading, empty, and error states explicitly for every async view.
175
214
  - Validate user input in real time per validation-policy; never rely on the UI as the only validation layer.
215
+ - 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.
176
216
 
177
217
  ---
178
218
 
@@ -1,9 +1,9 @@
1
1
  {
2
2
  "name": "frontend-policy",
3
- "version": "1.4.0",
3
+ "version": "1.9.0",
4
4
  "provider": "FJRG2007/enigma",
5
5
  "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.",
6
- "updated": "2026-06-26T13:57:02+02:00",
7
- "cliVersion": "1.30.5",
8
- "sha": "41cb938c9022efcdadc3056417cc7d442511adee40b09a141f11bb5fd9d56514"
6
+ "updated": "2026-07-22T01:41:06+02:00",
7
+ "cliVersion": "1.30.7",
8
+ "sha": "c5e0b4ac972e6448331bc56f7fc0069f3f57c3515ea719d0be46addfc8dbb064"
9
9
  }
@@ -4,6 +4,6 @@
4
4
  "provider": "FJRG2007/enigma",
5
5
  "description": "Git & contribution policy (senior engineering standards).",
6
6
  "updated": "2026-07-16T22:44:02+02:00",
7
- "cliVersion": "1.30.5",
7
+ "cliVersion": "1.30.7",
8
8
  "sha": "e6dfbc33884000d9d25841bd9c5a84d6558ffd374882cb7b34451eb2cebc2161"
9
9
  }
@@ -7,6 +7,6 @@
7
7
  "logoColorPolicy"
8
8
  ],
9
9
  "updated": "2026-07-17T00:17:02+02:00",
10
- "cliVersion": "1.30.5",
10
+ "cliVersion": "1.30.7",
11
11
  "sha": "09cdbefd98625b02a7d03685e5deed128238ff8454a83fe22279610fe3ef8ddf"
12
12
  }
@@ -4,6 +4,6 @@
4
4
  "provider": "FJRG2007/enigma",
5
5
  "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.",
6
6
  "updated": "2026-06-01T00:45:28+02:00",
7
- "cliVersion": "1.30.5",
7
+ "cliVersion": "1.30.7",
8
8
  "sha": "9971e9d9127397d0152e89d24aad3191e2935e55a8483db7fd15f5d4d7a60e7a"
9
9
  }
@@ -4,6 +4,6 @@
4
4
  "provider": "FJRG2007/enigma",
5
5
  "description": "Create new skills, modify and improve existing skills, and measure skill performance with evals and benchmarks.",
6
6
  "updated": "2026-06-16T16:39:13+02:00",
7
- "cliVersion": "1.30.5",
7
+ "cliVersion": "1.30.7",
8
8
  "sha": "699586cce82ec0a5458288b598ee7e5ebdddb3dfcf19db354d8bc5e85e47c1c7"
9
9
  }
@@ -3,7 +3,7 @@
3
3
  "version": "1.2.0",
4
4
  "provider": "FJRG2007/enigma",
5
5
  "description": "Exhaustive completion discipline for long/multi-item tasks - inventory, coverage ledger, verified done.",
6
- "updated": "2026-06-10T22:11:09+02:00",
7
- "cliVersion": "1.30.5",
6
+ "updated": "2026-07-21T20:25:56+02:00",
7
+ "cliVersion": "1.30.7",
8
8
  "sha": "feaf44a9b3ab9676c8ebd3c2a799f156d28419998f5a5355250fe95a28cd5a01"
9
9
  }
@@ -62,6 +62,14 @@ microcopy - the reader shouldn't have to study it.
62
62
  - READMEs: assume a competent reader. Explain what is non-obvious or load-bearing (how to
63
63
  run it, the one surprising constraint, why a choice was made) and skip what the audience
64
64
  already knows or can infer from the code. Lead with the point; cut the throat-clearing.
65
+ - Do NOT volunteer a "Project Structure" section with an ASCII/box-drawing file tree and a
66
+ folder-by-folder explanation ("src/ contains the files of the application", "public/:
67
+ contains static files") on your own initiative. It is the hallmark of an AI-written README:
68
+ it rots the instant a file moves, is usually misaligned, and restates what the reader sees in
69
+ the file browser - real project READMEs rarely ship one. If the user explicitly asks for a
70
+ project-structure tree, generate it (well-formed and accurate); just never add one unprompted.
71
+ Otherwise document a directory only when its purpose is non-obvious and load-bearing, in one
72
+ line of prose, never a whole tree.
65
73
 
66
74
  ## Reviewing existing copy
67
75
 
@@ -1,9 +1,9 @@
1
1
  {
2
2
  "name": "technical-writing-policy",
3
- "version": "1.1.0",
3
+ "version": "1.2.0",
4
4
  "provider": "FJRG2007/enigma",
5
5
  "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.",
6
- "updated": "2026-06-26T14:09:06+02:00",
7
- "cliVersion": "1.30.5",
8
- "sha": "e750988b8de51d8a69be621673dceca5413ebad7e1a48e40acd18aad526d9928"
6
+ "updated": "2026-07-22T01:41:06+02:00",
7
+ "cliVersion": "1.30.7",
8
+ "sha": "a8c008fac91782de0d4ef1a4ae6ee77d69e3c0a506ea06b649aa86a6c988bc4f"
9
9
  }
@@ -4,6 +4,6 @@
4
4
  "provider": "FJRG2007/enigma",
5
5
  "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).",
6
6
  "updated": "2026-06-16T17:11:49+02:00",
7
- "cliVersion": "1.30.5",
7
+ "cliVersion": "1.30.7",
8
8
  "sha": "3bdf591057b760f674fb2b1425f63acb426cda2c4f042e1a74c5a5d3807df664"
9
9
  }
@@ -33,7 +33,7 @@ description: Strict frontend + backend schema validation (Zod or equivalent), sc
33
33
  - Use schema-driven validation (e.g. Zod or equivalent).
34
34
  - Validation must prevent invalid state before submission.
35
35
  - UI must reflect validation state immediately and clearly.
36
- - Validate cross-record constraints (uniqueness, availability, "already in use") in real time too, not just per-field type/format. When the client already holds the relevant set (the list of accounts, profiles, names, slugs it just rendered), check the input against that loaded data on every change and block submission on a conflict - do not defer the duplicate check to the server round-trip. The server still re-validates as the authority (client checks can be stale), but the user must see the conflict as they type. Mirror the server's exact rule (same pattern, case-folding, reserved values, and scope - e.g. unique per parent vs. globally) so the two never disagree; exclude the record's own current value when editing so renaming to the same name is not flagged.
36
+ - Validate cross-record constraints (uniqueness, availability, "already in use") in real time too, not just per-field type/format. When the client already holds the relevant set (the list of accounts, profiles, names, slugs it just rendered), check the input against that loaded data on every change and block submission on a conflict - do not defer the duplicate check to the server round-trip (this gives instant feedback and spares a redundant request and its DB query). The server still re-validates as the authority (client checks can be stale), but the user must see the conflict as they type. Mirror the server's exact rule (same pattern, case-folding, reserved values, and scope - e.g. unique per parent vs. globally) so the two never disagree; exclude the record's own current value when editing so renaming to the same name is not flagged.
37
37
 
38
38
  ### Backend / API Validation (Mandatory)
39
39
 
@@ -73,6 +73,7 @@ description: Strict frontend + backend schema validation (Zod or equivalent), sc
73
73
  - Internal paths
74
74
  - Service names
75
75
  - Log detailed errors internally only, with enough context to debug.
76
+ - 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.
76
77
  - Use consistent, structured error responses (stable codes, safe messages).
77
78
  - Distinguish validation errors (4xx, actionable) from internal failures (5xx, opaque to the client).
78
79
  - Never leak the existence or absence of sensitive resources through error differences.
@@ -1,9 +1,9 @@
1
1
  {
2
2
  "name": "validation-policy",
3
- "version": "1.1.0",
3
+ "version": "1.3.0",
4
4
  "provider": "FJRG2007/enigma",
5
5
  "description": "Strict frontend + backend schema validation, schema consistency, and safe client-facing error handling.",
6
- "updated": "2026-06-25T18:21:50-04:00",
7
- "cliVersion": "1.30.5",
8
- "sha": "50349f5b3c55cc337f828dd510c163550614832acb28714871210a7c115a1501"
6
+ "updated": "2026-07-22T01:41:06+02:00",
7
+ "cliVersion": "1.30.7",
8
+ "sha": "d937df0052d1ec151728a28f6567744d9e7ca0a65d84b4d5c9a697f1e40d704f"
9
9
  }
@@ -1,6 +1,6 @@
1
1
  {
2
- "enigma-darwin-arm64": "f9d771e9f5230cef78d37f428db4f9fd0d5eba50157665153656d5ea15753a0c",
3
- "enigma-linux-arm64": "b823ffa1f2059dda5ff80559228268ecde03c69ff64240282cb4421caf635509",
4
- "enigma-linux-x64": "08a0fdb81242947331fb98a2d7f361bdfdd19616fcc6233b830092dbd4444557",
5
- "enigma-win32-x64.exe": "f59e9668e991f82eb1aeb00237c607a7a81df75fd8f57a3cf7d97c48e7ee70b0"
2
+ "enigma-darwin-arm64": "ec0e3648824798d272df7bfcd36a3de7cdbc02e5684f6fecbaa8108f32fdea9a",
3
+ "enigma-linux-arm64": "1e2fd06ad4ce9c23d134d647c177d8ee86463ab544441e61db477b632f78400f",
4
+ "enigma-linux-x64": "6a31ba93f9b379d81cd32a081ce5a4e3761870b0aefbd7a404e26b5365b0607a",
5
+ "enigma-win32-x64.exe": "d906126cd9a28c20bd80e973e00f6715596e2b887806b5681c8207065fe0f02b"
6
6
  }
@@ -102,6 +102,70 @@ var BUILTIN_RULES = [
102
102
  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).",
103
103
  severity: "warn",
104
104
  skill: "frontend-policy"
105
+ },
106
+ {
107
+ id: "fe-date-moment",
108
+ label: "Modern date handling (no moment.js)",
109
+ files: ["*.tsx", "*.jsx", "*.vue", "*.svelte", "*.astro"],
110
+ excludeFiles: ["*.test.*", "*.spec.*", "**/tests/**", "**/__tests__/**"],
111
+ scope: "file",
112
+ // Importing moment / moment-timezone. The `from "..."` / `require("...")` specifier is
113
+ // unambiguous (near-zero FP): a quote must sit right before `moment`, so "react-moment"
114
+ // and a prose "...from moment" string do not match, and comment lines are skipped anyway.
115
+ // This is the only regex-gateable slice of the date-display convention - "use
116
+ // <relative-time>" itself is a positive semantic recommendation the engine cannot assert.
117
+ pattern: `from\\s+["']moment(?:-timezone)?["']|require\\(\\s*["']moment(?:-timezone)?["']\\s*\\)`,
118
+ 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).",
119
+ severity: "warn",
120
+ skill: "frontend-policy"
121
+ },
122
+ {
123
+ id: "fe-search-fuzzy",
124
+ label: "Fuzzy search for finders (fuse.js)",
125
+ files: ["*.tsx", "*.jsx", "*.vue", "*.svelte", "*.astro"],
126
+ excludeFiles: ["*.test.*", "*.spec.*", "**/tests/**", "**/__tests__/**"],
127
+ scope: "file",
128
+ // A hand-rolled case-insensitive substring finder: a .filter(...) whose body does
129
+ // `.toLowerCase().includes(....toLowerCase())`. The SYMMETRIC double-toLowerCase inside a
130
+ // filter is a near-certain search box (precision over recall - a one-sided or non-filter
131
+ // .includes is intentionally not matched). Skipped when fuse is already present in the file.
132
+ pattern: "\\.filter\\([^;]*\\.toLowerCase\\(\\)\\.includes\\([^;]*\\.toLowerCase\\(\\)",
133
+ absent: "fuse",
134
+ 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).",
135
+ severity: "warn",
136
+ skill: "frontend-policy"
137
+ },
138
+ {
139
+ id: "doc-no-file-tree",
140
+ label: "No ASCII file-tree in the README",
141
+ // README only, at any depth. Scoped deliberately: a file tree in a deliberate
142
+ // authoring guide or tutorial (e.g. a skill-creation doc) is legitimate; the
143
+ // auto-generated "Project Structure" tree in a README is the AI tell this targets.
144
+ files: ["README.md", "README.mdx", "readme.md", "readme.mdx"],
145
+ scope: "file",
146
+ // Box-drawing branch connectors (U+251C '├' and U+2514 '└' followed by U+2500 '─') are
147
+ // the signature of an auto-generated project-structure tree; they appear almost nowhere
148
+ // else in prose, markdown tables, or mermaid.
149
+ pattern: "[\\u251C\\u2514]\\u2500",
150
+ 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).",
151
+ severity: "warn",
152
+ skill: "technical-writing-policy"
153
+ },
154
+ {
155
+ id: "be-no-leak-internal-error",
156
+ label: "Do not leak internal errors to the client",
157
+ files: ["*.ts", "*.js", "*.mts", "*.cts"],
158
+ excludeFiles: ["*.test.*", "*.spec.*", "**/tests/**", "**/__tests__/**"],
159
+ scope: "file",
160
+ // Two high-signal one-line leaks: (a) a 5xx response whose body includes a caught error's
161
+ // .message/.stack (the Prisma/DB-error leak), or (b) a stack trace passed into any response
162
+ // body. A 4xx validation reply carrying a constructed .message is deliberately NOT matched
163
+ // (those can be safe). `console.error(err.message)` / `logger.error(err.stack)` are not
164
+ // responses, so logging the real error is never flagged - only sending it out is.
165
+ 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",
166
+ 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).",
167
+ severity: "warn",
168
+ skill: "validation-policy"
105
169
  }
106
170
  ];
107
171
  var PROJECT_CHECKS = {
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "enigma-cli",
3
- "version": "1.30.5",
3
+ "version": "1.30.7",
4
4
  "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.",
5
5
  "type": "module",
6
6
  "bin": {