@nurix/etna 0.17.1 → 0.18.1

package/data/harnesses/code/agents/performance-review.md

@@ -143,17 +143,20 @@ grep -rn "Icons\[" src/ --include="*.jsx" --include="*.tsx"
 Scan for React performance issues:
 
 ### Missing memoization
+
 - Components rendering large lists without `React.memo`
 - Expensive computations without `useMemo`
 - Callback props without `useCallback` causing child re-renders
 - Focus on components in tables, lists, grids, repeated rows
 
 ### Request waterfalls
+
 - Sequential `await` calls that could be `Promise.all`
 - `useEffect` chains where one fetch triggers another
 - Component trees where parent fetches block child renders
 
 ### Missing virtualization
+
 - Lists rendering >50 items without react-window or similar
 - Tables with unbounded row counts
 - Grids without lazy loading
@@ -183,6 +186,7 @@ grep -rn "TODO\|FIXME\|HACK\|XXX" src/ --include="*.jsx" --include="*.tsx" --inc
 ### Report format
 
 **Dependencies**
+
 - **Vulnerabilities**: critical/high CVEs, new since last audit
 - **Outdated**: top outdated packages by semver distance
 - **Licenses**: non-permissive license flags
@@ -191,6 +195,7 @@ grep -rn "TODO\|FIXME\|HACK\|XXX" src/ --include="*.jsx" --include="*.tsx" --inc
 - **Dependency size**: largest installed packages
 
 **Code**
+
 - **Bundle size**: total vendor size, top offenders, growth since last review
 - **Tree-shaking issues**: namespace imports, barrel-file problems (cross-referenced with the heavy/bloat packages from Part A)
 - **Performance**: missing memoization, request waterfalls, missing virtualization

package/data/harnesses/code/harness.json

@@ -8,5 +8,5 @@
     ".prettierignore",
     ".vscode/settings.json"
   ],
-  "digest": "da02e3f9ca11"
+  "digest": "3a6fb5194539"
 }

package/data/harnesses/code/rules/general.md

@@ -10,40 +10,40 @@
 
 No alternatives. Just use these.
 
-| Package                  | Version   | Use                    | Don't use               |
-| ------------------------ | --------- | ---------------------- | ----------------------- |
-| react                    | ^19.2.3   | UI components          | -                       |
-| vite                     | ^8.0.0    | Build tool, dev server | webpack, CRA            |
-| tailwindcss              | ^4.1.18   | Styling                | styled-components       |
-| @vitejs/plugin-react-swc | ^4.2.2    | JSX compilation        | @vitejs/plugin-react    |
-| react-router-dom         | ^7.11.0   | Routing                | -                       |
-| @reduxjs/toolkit         | ^2.11.2   | State management       | zustand, jotai          |
-| react-redux              | ^9.2.0    | Redux React bindings   | -                       |
-| axios                    | ^1.13.2   | HTTP requests          | fetch                   |
-| date-fns                 | ^4.1.0    | Date formatting        | moment, dayjs           |
-| @dnd-kit/core            | ^6.3.1    | Drag and drop          | react-beautiful-dnd     |
-| motion                   | ^12.23.26 | Animations             | react-spring            |
-| sonner                   | ^2.0.7    | Toast notifications    | react-toastify          |
-| react-window             | ^2.2.3    | List virtualization    | react-virtualized       |
-| nanoid                   | ^5.1.6    | ID generation          | uuid                    |
-| express                  | ^5.2.1    | HTTP server            | fastify, koa            |
-| drizzle-orm              | latest    | Database ORM           | prisma, sequelize, typeorm |
-| drizzle-kit              | latest    | Schema tooling         | -                       |
-| zod                      | ^4.2.1    | Schema validation      | yup, joi                |
-| jose                     | ^6.1.3    | JWT handling           | jsonwebtoken            |
-| microdiff                | ^1.5.0    | JSON object diffing    | deep-diff, just-diff    |
-| react18-json-view        | ^0.2.9    | JSON tree view         | react-json-view         |
-| @tiptap/react            | ^3.11.1   | Rich text editor       | slate, quill, draft-js  |
-| shiki                    | ^3.22.0   | Syntax highlighting    | prism, highlight.js     |
-| lucide-react             | ^0.562.0  | Icons                  | react-icons, heroicons  |
-| @pdfme/generator         | ^5.5.8    | PDF generation         | jspdf, pdfkit           |
-| cmdk                     | ^1.1.1    | Command palette        | kbar, ninja-keys        |
-| @monaco-editor/react     | ^4.7.0    | Code editor            | codemirror, ace         |
-| localforage              | ^1.10.0   | Client-side storage    | idb, dexie              |
-| react-markdown           | ^10.1.0   | Markdown rendering     | marked, markdown-it     |
-| fast-deep-equal          | ^3.1.3    | Deep equality checks   | lodash.isEqual          |
-| @ngneat/falso            | latest    | Fake data generation   | @faker-js/faker, chance |
-| pino                     | ^10.1.0   | Logging                | winston                 |
+| Package | Version | Use | Don't use |
+| --- | --- | --- | --- |
+| react | ^19.2.3 | UI components | - |
+| vite | ^8.0.0 | Build tool, dev server | webpack, CRA |
+| tailwindcss | ^4.1.18 | Styling | styled-components |
+| @vitejs/plugin-react-swc | ^4.2.2 | JSX compilation | @vitejs/plugin-react |
+| react-router-dom | ^7.11.0 | Routing | - |
+| @reduxjs/toolkit | ^2.11.2 | State management | zustand, jotai |
+| react-redux | ^9.2.0 | Redux React bindings | - |
+| axios | ^1.13.2 | HTTP requests | fetch |
+| date-fns | ^4.1.0 | Date formatting | moment, dayjs |
+| @dnd-kit/core | ^6.3.1 | Drag and drop | react-beautiful-dnd |
+| motion | ^12.23.26 | Animations | react-spring |
+| sonner | ^2.0.7 | Toast notifications | react-toastify |
+| react-window | ^2.2.3 | List virtualization | react-virtualized |
+| nanoid | ^5.1.6 | ID generation | uuid |
+| express | ^5.2.1 | HTTP server | fastify, koa |
+| drizzle-orm | latest | Database ORM | prisma, sequelize, typeorm |
+| drizzle-kit | latest | Schema tooling | - |
+| zod | ^4.2.1 | Schema validation | yup, joi |
+| jose | ^6.1.3 | JWT handling | jsonwebtoken |
+| microdiff | ^1.5.0 | JSON object diffing | deep-diff, just-diff |
+| react18-json-view | ^0.2.9 | JSON tree view | react-json-view |
+| @tiptap/react | ^3.11.1 | Rich text editor | slate, quill, draft-js |
+| shiki | ^3.22.0 | Syntax highlighting | prism, highlight.js |
+| lucide-react | ^0.562.0 | Icons | react-icons, heroicons |
+| @pdfme/generator | ^5.5.8 | PDF generation | jspdf, pdfkit |
+| cmdk | ^1.1.1 | Command palette | kbar, ninja-keys |
+| @monaco-editor/react | ^4.7.0 | Code editor | codemirror, ace |
+| localforage | ^1.10.0 | Client-side storage | idb, dexie |
+| react-markdown | ^10.1.0 | Markdown rendering | marked, markdown-it |
+| fast-deep-equal | ^3.1.3 | Deep equality checks | lodash.isEqual |
+| @ngneat/falso | latest | Fake data generation | @faker-js/faker, chance |
+| pino | ^10.1.0 | Logging | winston |
 
 ## Frontend
 
@@ -51,7 +51,7 @@ Tailwind v4 + shadcn-based UI; conventions below.
 
 - **@nurix/components** — the UI component library (linked, pre-built); import by subpath, e.g. `@nurix/components/button`.
 - No components.json / shadcn CLI scaffold (.tsx, not .jsx) — consume the prebuilt library; never `npx shadcn add`.
-- Vite: `@tailwindcss/vite` + `@vitejs/plugin-react-swc`. Pin react / react-dom / react/jsx-runtime / react/jsx-dev-runtime to the app's single copy via `resolve.alias` (linked @nurix/* ship nested react — keep one hook dispatcher).
+- Vite: `@tailwindcss/vite` + `@vitejs/plugin-react-swc`. Pin react / react-dom / react/jsx-runtime / react/jsx-dev-runtime to the app's single copy via `resolve.alias` (linked @nurix/\* ship nested react — keep one hook dispatcher).
 - Tailwind v4, CSS-only (no tailwind.config.js, no PostCSS): styling runs through the `@tailwindcss/vite` plugin.
 - CSS entry `globals.css`, imports in order — `@import "./personality.css"` (token source) → `@import "tailwindcss"` → the library's `styles.css` — then `@theme inline {…}` mapping vars to tokens.
 - Tokens: CSS vars in `:root, :root[data-theme="light"]` + the archetype selector `[data-style="…"]` (personality.css), consumed as semantic Tailwind tokens (bg-card, text-foreground). Honor the archetype's radius/theme decisions (e.g. re-assert `--radius-*` to 0 for a flat archetype; add `@custom-variant dark` only if the project supports dark mode). The library bundles class-variance-authority, clsx, tailwind-merge.
@@ -71,7 +71,11 @@ app.use(rateLimit({ windowMs: 15 * 60 * 1000, max: 100 }));
 ## API Response Format
 
 ```json
-{ "status": 1, "message": "Message sent successfully", "data": { "delivered": [{ "user@example.com": 2 }] } }
+{
+  "status": 1,
+  "message": "Message sent successfully",
+  "data": { "delivered": [{ "user@example.com": 2 }] }
+}
 ```
 
 Error: `{ "status": 0, "message": "Error description", "data": null }`

package/data/harnesses/code/skills/boundary/SKILL.md

@@ -7,45 +7,21 @@ description: Boundary diagnostic for implementation plans. Given a plan file, re
 
 You diagnose whether a plan's changes would break an application boundary.
 
-A boundary is a contract between two pieces of code (or code and infra) that
-share an assumption with **no compile-time link** between them: the column a raw
-SQL string names, the JSON envelope a client unwraps, the event string a
-dispatcher parses, the env var a deploy script writes. Changing one side ships
-green and breaks the other silently. Your job is to find those edges in the
-plan's path *before* execution.
-
-[`references/boundary-taxonomy.md`](references/boundary-taxonomy.md) is the
-catalog of boundary types (~170 across persistence, wire/API, frontend,
-auth/tenancy, async/messaging, config/build, runtime/infra), with per-type
-severities and safe-change checklists. Read it first — it tells you what to
-look for; the code tells you what exists.
+A boundary is a contract between two pieces of code (or code and infra) that share an assumption with **no compile-time link** between them: the column a raw SQL string names, the JSON envelope a client unwraps, the event string a dispatcher parses, the env var a deploy script writes. Changing one side ships green and breaks the other silently. Your job is to find those edges in the plan's path _before_ execution.
+
+[`references/boundary-taxonomy.md`](references/boundary-taxonomy.md) is the catalog of boundary types (~170 across persistence, wire/API, frontend, auth/tenancy, async/messaging, config/build, runtime/infra), with per-type severities and safe-change checklists. Read it first — it tells you what to look for; the code tells you what exists.
 
 ## Run
 
-**Input:** a plan path (given, or the newest in `docs/history/plans/`) — or a
-diff / named code area for non-plan work. Everything below is identical either
-way; a diff's hunks stand in for the plan's steps.
-
-1. **Build the touch list.** Parse the plan's Proposed Changes: files to be
-   created or modified, entities/state added or changed, API changes, anything
-   the author flags as a cross-module contract. Note missing subsections.
-
-2. **Identify the boundaries in the touched code.** Read each touched file (and
-   its immediate imports). Against the taxonomy, list the contracts this code
-   participates in — the schema it queries, the envelope it emits, the events
-   it publishes or parses, the auth checks it sits behind, the env it reads.
-
-3. **Trace the other side.** A boundary has two sides; the danger lives on the
-   one the plan *doesn't* mention. For each contract, grep the shared name or
-   shape across the repo — the column name in other SQL strings, the response
-   field in client unwrappers, the event kind in subscribers, the route in
-   fetch calls and scripts, the env key in deploy tooling. Record consumers as
-   `file:line`.
-
-4. **Judge each intersection.** Does the planned change alter a shape a traced
-   consumer depends on, break an invariant the code establishes (append-only
-   vocabularies, idempotency keys, fail-closed checks, ordering guarantees), or
-   add a new cross-module edge? Severity:
+**Input:** a plan path (given, or the newest in `docs/history/plans/`) — or a diff / named code area for non-plan work. Everything below is identical either way; a diff's hunks stand in for the plan's steps.
+
+1. **Build the touch list.** Parse the plan's Proposed Changes: files to be created or modified, entities/state added or changed, API changes, anything the author flags as a cross-module contract. Note missing subsections.
+
+2. **Identify the boundaries in the touched code.** Read each touched file (and its immediate imports). Against the taxonomy, list the contracts this code participates in — the schema it queries, the envelope it emits, the events it publishes or parses, the auth checks it sits behind, the env it reads.
+
+3. **Trace the other side.** A boundary has two sides; the danger lives on the one the plan _doesn't_ mention. For each contract, grep the shared name or shape across the repo — the column name in other SQL strings, the response field in client unwrappers, the event kind in subscribers, the route in fetch calls and scripts, the env key in deploy tooling. Record consumers as `file:line`.
+
+4. **Judge each intersection.** Does the planned change alter a shape a traced consumer depends on, break an invariant the code establishes (append-only vocabularies, idempotency keys, fail-closed checks, ordering guarantees), or add a new cross-module edge? Severity:
    - **CRITICAL** — can corrupt persisted data, or open an auth/money path.
    - **HIGH** — silent cross-module breakage that would ship green.
    - **MEDIUM** — drift-prone coupling (string-matched, duplicated constants).
@@ -67,10 +43,7 @@ way; a diff's hunks stand in for the plan's steps.
 
 ## Rules
 
-- **Read-only.** You never edit the plan, the code, or any doc. The user folds
-  your amendments into the plan.
-- **Verify in source.** Never flag from plan text alone — read both sides of
-  every boundary you report, and cite both as `file:line`.
-- **No consumer, no finding.** An intersection with no traced other side isn't
-  a violation; at most note it as a new edge the plan introduces.
+- **Read-only.** You never edit the plan, the code, or any doc. The user folds your amendments into the plan.
+- **Verify in source.** Never flag from plan text alone — read both sides of every boundary you report, and cite both as `file:line`.
+- **No consumer, no finding.** An intersection with no traced other side isn't a violation; at most note it as a new edge the plan introduces.
 - **A clean report is valid.** Zero violations means say so — don't pad.