@live-change/frontend-template 0.9.201 → 0.9.204

package/.claude/rules/live-change-backend-actions-views-triggers.md

@@ -1,6 +1,6 @@
 ---
 description: Rules for implementing actions, views, and triggers in LiveChange services
-globs: **/services/**/*.js
+globs: **/services/**/*.js, **/server/**/*.js, server/**/*.js
 ---
 
 # LiveChange backend – actions, views, triggers (Claude Code)
@@ -52,6 +52,48 @@ definition.action({
 - Views should be simple query endpoints over models.
 - Prefer `indexObjectGet` / `indexRangeGet` instead of scanning whole tables.
 
+### Range view guardrails (for RangeViewer/rangeBuckets consumers)
+
+- For index-backed paginated lists, prefer `Model.sortedIndexRangePath(indexName, keyPrefix, App.extractRange(props))`.
+- Do not use `indexRangePath` semantics for views consumed by bucket-based range UI.
+- Keep `gt/gte/lt/lte` as cursor pagination fields, not domain filter fields.
+- If you need filtering by month/year/status, design index prefix for it first.
+- Use `App.utils.prefixRange` as backend fallback only when index redesign is not feasible.
+
+### Standalone index guardrail
+
+- If an index combines peer data streams (union of multiple tables), define it as service-level `definition.index(...)` (prefer separate `indexes.js`), not as `model.indexes` inside one arbitrary model.
+- Use model `indexes` only when one model is the clear owner of index semantics.
+
+### Index function serialization constraint
+
+Index functions (`definition.index({ function })` and model-level `indexes: { name: { function } }`) are **serialized via `toString()`** and executed on a remote server. They **cannot reference anything outside their own function body** — no outer variables, no imported functions, no module-scope helpers.
+
+```js
+// ❌ BROKEN — helper is outside the function, undefined at runtime
+function mapRow(obj) { return { id: obj.name + '_' + obj.id, to: obj.id } }
+
+definition.index({
+  name: 'myIndex',
+  function: async (input, output, { tableName }) => {
+    const table = await input.table(tableName)
+    await table.map(mapRow).to(output)       // mapRow is undefined!
+  },
+  parameters: { tableName: definition.name + '_MyModel' }
+})
+
+// ✅ CORRECT — helper is inside the function body
+definition.index({
+  name: 'myIndex',
+  function: async (input, output, { tableName }) => {
+    const mapRow = obj => ({ id: obj.name + '_' + obj.id, to: obj.id })
+    const table = await input.table(tableName)
+    await table.map(mapRow).to(output)
+  },
+  parameters: { tableName: definition.name + '_MyModel' }
+})
+```
+
 Example of a range view:
 
 ```js
@@ -159,6 +201,12 @@ definition.trigger({
 
 Check `data`/`oldData`: both present = update, only `data` = create, only `oldData` = delete.
 
+## Cron-service — schedules, intervals, and admin UI
+
+- For **cron-like** or **repeating-interval** execution of a **trigger**, use **`@live-change/cron-service`** (**Schedule** / **Interval**) plus **task-service** triggers — do not sketch “only a timer” without considering cron models and **`changeCron_Schedule`** / **`changeCron_Interval`** timer lifecycle.
+- Reference admin flow (see **task-frontend**): **`setSchedule`** / **`setInterval`** via **`ActionForm`**, lists via **`path.cron.schedules`** / **`path.cron.intervals`**, enrich rows with **`.with()`** for **`scheduleInfo`** / **`intervalInfo`**, **`runState`** (`jobType` **`cron_Schedule`** or **`cron_Interval`**), and **`task.tasksByCauseAndCreatedAt`**; delete with **`deleteSchedule`** / **`deleteInterval`**.
+- **Schedule** time fields (**minute**, **hour**, **day**, **dayOfWeek**, **month**): use **`NaN`** for “every” at that granularity; see **`15-cron-and-intervals.md`** (section **API used by task-frontend**).
+
 ## Granting access on object creation
 
 When a model uses `entity` with `writeAccessControl` / `readAccessControl`, the auto-generated CRUD checks roles but does **not** grant them automatically. The creator must be explicitly granted roles — typically `'owner'` — otherwise they cannot access their own object.

package/.claude/rules/live-change-backend-architecture.md

@@ -1,6 +1,6 @@
 ---
 description: Rules for LiveChange backend service architecture and directory structure
-globs: **/services/**/*.js
+globs: **/services/**/*.js, **/server/**/*.js, server/**/*.js
 ---
 
 # LiveChange backend – service architecture (Claude Code)
@@ -104,17 +104,17 @@ services: [
 
 ## Inspecting services with `describe`
 
-Use the `describe` CLI command to see what the framework generated from your definitions (models, views, actions, triggers, indexes, events):
+Use the `describe` CLI command to see what the framework generated from your definitions (models, views, actions, triggers, indexes, events). From the app root (directory with `.node-version` / `.nvmrc`), run Node via **fnm** so the toolchain matches the project — see rule `live-change-node-toolchain-fnm`.
 
 ```bash
 # All services overview
-node server/start.js describe
+fnm exec -- node server/start.js describe
 
 # One service in YAML (shows all generated code)
-node server/start.js describe --service myService --output yaml
+fnm exec -- node server/start.js describe --service myService --output yaml
 
 # Specific entity
-node server/start.js describe --service myService --model MyModel --output yaml
+fnm exec -- node server/start.js describe --service myService --model MyModel --output yaml
 ```
 
 This is especially useful after using relations (`userItem`, `itemOf`, `propertyOf`) — `describe` shows all the auto-generated views, actions, triggers, and indexes.

package/.claude/rules/live-change-backend-event-sourcing.md

@@ -1,6 +1,6 @@
 ---
 description: Event-sourcing data flow rules — emit events for DB writes, use triggerService for cross-service writes
-globs: **/services/**/*.js
+globs: **/services/**/*.js, **/server/**/*.js, server/**/*.js
 ---
 
 # LiveChange backend – event-sourcing data flow (Claude Code)
@@ -155,7 +155,7 @@ Without `waitForEvents: true`, the action returns immediately and events are pro
 When a model uses relations (`userItem`, `itemOf`, `propertyOf`, etc.), the relations plugin auto-generates CRUD triggers. Use `describe` to discover them:
 
 ```bash
-node server/start.js describe --service myService --output yaml
+fnm exec -- node server/start.js describe --service myService --output yaml
 ```
 
 Common auto-generated trigger patterns:

package/.claude/rules/live-change-backend-models-and-relations.md

@@ -1,6 +1,6 @@
 ---
 description: Rules for defining models, relations, indexes and access control in LiveChange
-globs: **/services/**/*.js
+globs: **/services/**/*.js, **/server/**/*.js, server/**/*.js
 ---
 
 # LiveChange backend – models and relations (Claude Code)
@@ -32,6 +32,25 @@ properties: {
 }
 ```
 
+## Relation arity (critical)
+
+Always separate:
+
+- **annotation arity** — can the annotation be a list of configs
+- **parent tuple arity** — can one config include multiple parents/dimensions
+
+| Relation | Annotation arity | Parent tuple arity |
+|---|---|---|
+| `propertyOf`, `itemOf`, `boundTo` | single config only | `what` can be one model or `[A, B, ...]` |
+| `relatedTo` | single config or config list | each config uses `what` with one model or `[A, B, ...]` |
+| `propertyOfAny`, `itemOfAny`, `boundToAny` | single config only | `to` can contain one or many names |
+| `relatedToAny` | single config or config list | each config uses `to` with one or many names |
+
+Guardrail:
+
+- valid: `propertyOf: { what: [A, B] }`
+- invalid: `propertyOf: [configA, configB]`
+
 ## `userItem` – belongs to the signed-in user
 
 Use when the model is owned by the currently signed-in user.
@@ -113,7 +132,7 @@ Effects:
 ## `propertyOf` with multiple parents (1:1 link to each)
 
 Sometimes a model is a dedicated 1:1 link between entities (for example: invoice ↔ contractor in a specific role).
-Most commonly this is 1–2 parents, but `propertyOf` can point to **any number** of parent models (including 3+), if that matches the domain semantics.
+Most commonly this is 1–2 parents, but `what` can point to **any number** of parent models (including 3+), if that matches the domain semantics.
 
 In that case:
 
@@ -132,10 +151,9 @@ definition.model({
   properties: {
     // optional extra fields
   },
-  propertyOf: [
-    { what: CostInvoice },
-    { what: Contractor }
-  ]
+  propertyOf: {
+    what: [CostInvoice, Contractor]
+  }
 })
 ```
 
@@ -180,7 +198,7 @@ Relations automatically add **identifier fields** and **indexes** to the model.
 | `propertyOfAny: { to: ['owner'] }` | `ownerType`, `owner` | `byOwner` (hash) |
 | `boundTo: { what: Device }` | `device` | `byDevice` (hash) |
 
-For multi-parent relations (e.g. `propertyOf: [{ what: A }, { what: B }]`), all index combinations are created (`byA`, `byB`, `byAAndB`).
+For multi-parent relations (e.g. `propertyOf: { what: [A, B] }`), all index combinations are created (`byA`, `byB`, `byAAndB`).
 
 ```js
 // ✅ Correct — only define YOUR fields
@@ -203,7 +221,7 @@ definition.model({
 })
 ```
 
-Use `node server/start.js describe --service myService --model MyModel --output yaml` to see all fields including auto-added ones.
+Use `fnm exec -- node server/start.js describe --service myService --model MyModel --output yaml` (from the app root, with fnm — see `live-change-node-toolchain-fnm`) to see all fields including auto-added ones.
 
 ## Indexes
 
@@ -223,6 +241,45 @@ indexes: {
 
 In other services, the same index may be visible with a prefixed name such as `myService_Model_byDeviceAndStatus`.
 
+### When index should be outside a model
+
+If an index is a union/projection over multiple peer tables (no single natural owner model), do not force it into `model.indexes`.
+
+- Use service-level `definition.index(...)` (prefer a dedicated `indexes.js` file).
+- Keep `model.indexes` for indexes semantically owned by one model.
+
+### Function index serialization constraint
+
+Function indexes (both `definition.index({ function })` and model `indexes: { name: { function } }`) are **serialized via `toString()`** and run on a remote server. All helpers, mappers, and variables used inside the function **must be defined inside the function body**. References to outer scope (module-level functions, imports, closures) will be `undefined` at runtime.
+
+```js
+// ❌ BROKEN — mapper defined outside, invisible after serialization
+const mapper = obj => ({
+  id: obj.name + '_' + obj.id, to: obj.id
+})
+indexes: {
+  byDerived: {
+    function: async (input, output, { tableName }) => {
+      const table = await input.table(tableName)
+      await table.map(mapper).to(output)  // mapper is undefined!
+    }
+  }
+}
+
+// ✅ CORRECT — mapper defined inside the function
+indexes: {
+  byDerived: {
+    function: async (input, output, { tableName }) => {
+      const mapper = obj => ({
+        id: obj.name + '_' + obj.id, to: obj.id
+      })
+      const table = await input.table(tableName)
+      await table.map(mapper).to(output)
+    }
+  }
+}
+```
+
 ## Access control on relations
 
 - Always set `readAccessControl` and `writeAccessControl` on relations (`userItem`, `itemOf`, `propertyOf`).

package/.claude/rules/live-change-frontend-e2e-lifecycle.md

@@ -0,0 +1,42 @@
+---
+description: Stable node:test E2E lifecycle with env, withBrowser and e2eSuite
+globs: **/e2e/**/*.{js,ts}
+---
+
+# Frontend E2E lifecycle
+
+Use this pattern in LiveChange E2E tests based on `node:test`.
+
+## Required files
+
+- `e2e/env.ts` with `getTestEnv()` and `disposeTestEnv()`
+- `e2e/withBrowser.ts` that closes context/browser in `finally`
+- `e2e/e2eSuite.ts` that wraps each test file in `describe(...)` + `after(...)`
+- `e2e/*.test.ts` wrapped in exactly one `e2eSuite(...)`
+
+## Teardown rule
+
+- Never register `after(...process.exit(...))` inside shared `e2e/env.ts`.
+- Register final `process.exit(0)` only in `e2eSuite.ts` after calling `disposeTestEnv()`.
+- Keep startup failure `process.exit(1)` in `getTestEnv()` catch block.
+
+## Minimal suite wrapper
+
+```ts
+import { after, describe } from 'node:test'
+import { disposeTestEnv } from './env.js'
+
+export function e2eSuite(name: string, define: () => void): void {
+  describe(name, () => {
+    after(async () => {
+      await disposeTestEnv()
+      process.exit(0)
+    })
+    define()
+  })
+}
+```
+
+## Running commands
+
+When running E2E commands, use `fnm exec -- ...` so Node matches `.node-version` / `.nvmrc`.

package/.claude/rules/live-change-frontend-i18n-locales.md

@@ -0,0 +1,25 @@
+---
+description: Keep all locale files under front/locales in sync when adding or changing i18n strings
+globs: **/front/locales/**/*.{json,js,ts}, **/front/src/**/*.{vue,js,ts}
+---
+
+# Frontend i18n – every file in `front/locales`
+
+When you add or change **user-visible strings** (labels, messages, buttons, errors, page titles, etc.) that go through **vue-i18n** or the project’s locale files, you must update **every** locale resource in that app’s **`front/locales/`** directory — not only one language.
+
+## Required workflow
+
+1. **Identify the app root** for the frontend you are editing (the folder whose tree contains `front/src` and `front/locales`).
+2. **List all locale files** in `front/locales/` for that app (`en.json`, `pl.json`, `en.js`, `pl.js`, `landing-en.json`, … — whatever exists).
+3. **Add or update the same keys** in **each** of those files. Structure and nesting must stay consistent across languages (same key paths).
+4. **Do not** add a new key to a single locale file and leave others missing — that breaks builds or shows raw keys at runtime.
+
+## Translations you are unsure about
+
+- Prefer a correct string in the primary locales (e.g. `en` + `pl`) when the product supports them.
+- For other files, use a sensible placeholder, copy from English, or add a clearly marked temporary string — but **still add the key** everywhere so nothing is omitted.
+
+## Scope
+
+- Applies to any work under `front/src` that introduces or changes translated text, and to direct edits in `front/locales`.
+- If a project uses multiple locale formats (`.json` and `.js`), update **all** files that participate in i18n for that app, not only one extension.

package/.claude/rules/live-change-frontend-vue-primevue.md

@@ -7,6 +7,10 @@ globs: **/front/src/**/*.{vue,js,ts}
 
 Use these rules when working on frontends that talk to LiveChange backends.
 
+## i18n and `front/locales`
+
+Whenever you introduce or change translated strings, follow **`live-change-frontend-i18n-locales`**: add the same keys to **all** files in that app’s **`front/locales/`** directory (every language / variant — not only one file).
+
 ## Stack
 
 - Vue 3 + TypeScript
@@ -48,6 +52,25 @@ In templates, use the `.value` of these refs:
 </template>
 ```
 
+## One-time fetches – `useFetch` (not `api.get` with Path)
+
+When you need a **one-time fetch** (not a live subscription), use `useFetch`:
+
+```js
+import { usePath, useFetch } from '@live-change/vue3-ssr'
+const path = usePath()
+
+const data = await useFetch(path.paperInvoice.invoiceFileInfo({ invoiceFile: fileId }))
+```
+
+**WARNING:** `path.service.view({ params })` returns a **Path object** (with `.what`, `.more`, `.to` properties), not a raw array. Do NOT pass it to `api.get()` — it will silently fail or produce wrong results.
+
+| Pattern | Correct? |
+|---|---|
+| `useFetch(path.svc.view({ ... }))` | **Yes** — handles Path objects |
+| `api.get(['svc', 'view', { ... }])` | **Yes** — raw array, low-level |
+| `api.get(path.svc.view({ ... }))` | **NO** — Path object, will break |
+
 ## Commands and forms – choosing the right pattern
 
 There are 4 ways to execute backend actions. Use the right one:
@@ -65,6 +88,51 @@ Decision flow:
 2. Is it editing a model record (create/update)? → **Yes**: use `editorData`. **No**: use `actionData`.
 3. Only use `<command-form>` for the simplest throwaway cases.
 
+## Autosave helpers – `synchronized` and `synchronizedList`
+
+Use these helpers when editing reactive data from `live(...)`:
+
+- Use `synchronized` for a single editable object.
+- Use `synchronizedList` for editable list rows.
+- Use shared context in `identifiers` and row-level keys in `objectIdentifiers`.
+- For draft payloads, use `updateDataProperty: 'data'`.
+
+Treat a screen as an editable list when:
+
+- The UI uses `v-for` and each row has editable fields.
+- Users edit many rows inline in one table/config/admin view.
+- Autosave should persist changes row-by-row.
+- Backend actions require shared list context plus row-specific keys.
+
+For these cases, create one `synchronizedList(...)` and edit row fields through `syncList.value`.
+Do not maintain a separate `id -> synchronized(...)` map for list rows.
+
+```js
+const sync = synchronized({
+  source: sourceRef,
+  update: actions.service.updateThing,
+  identifiers: { thing: thingId },
+  recursive: true,
+  autoSave: true,
+  debounce: 600
+})
+
+const syncList = synchronizedList({
+  source: rowsRef,
+  update: actions.service.updateRow,
+  delete: actions.service.deleteRow,
+  identifiers: { object, objectType },
+  objectIdentifiers: row => ({ row: row.to, object, objectType }),
+  recursive: true
+})
+```
+
+Typical list flows:
+
+- role/permission editors,
+- dictionary/configuration tables,
+- multi-row settings pages with inline edits.
+
 ## Form validation feedback
 
 Every field in a form using `editorData` or `actionData` **must** show validation errors. Never use bare `InputText`, `Dropdown`, or other PrimeVue inputs without error feedback.
@@ -234,6 +302,34 @@ path.blog.articles({})
 
 Access: `article.authorProfile?.firstName`. Works with both `live()` and `RangeViewer`.
 
+## Range lists with reactive filters
+
+If range list `pathFunction` depends on reactive filters (month/status/search/company), prefer `ReactiveRangeViewer`.
+
+Guidelines:
+
+- do not rely on mutating `pathFunction` in `RangeViewer`
+- avoid page-local workaround patterns with ad-hoc `:key`
+- use `sourceKey` as an explicit reload trigger
+- if layout stability matters, set `preserveHeightOnReload`
+
+```vue
+<ReactiveRangeViewer
+  :pathFunction="transactionsPathRange"
+  :sourceKey="JSON.stringify({ accountId, month: filterByMonth ? month : null })"
+  :preserveHeightOnReload="true"
+  :canLoadTop="false"
+  canDropBottom
+/>
+```
+
+## Range cursor guardrails (`RangeViewer` / `rangeBuckets`)
+
+- For index-backed list views, backend should expose `sortedIndexRangePath`-based range views.
+- Never override `range.gt/gte/lt/lte` inside frontend `pathFunction`.
+- Keep cursor fields from RangeViewer intact; pass domain filters (`month`, `year`, `status`) as separate params.
+- If filtering seems to require manual cursor rewriting, move logic to backend index design (or `prefixRange` fallback), not frontend hacks.
+
 ## WorkingZone for async actions
 
 `ViewRoot` wraps every page in `<WorkingZone>`. Use `inject('workingZone')` for non-form button actions:
@@ -306,12 +402,12 @@ export const sitemap = sitemapEntry(App, createRouter, routerSitemap, config)
 
 ## Discovering views and actions with `describe`
 
-Use the CLI `describe` command to find available views (for `live()`) and actions (for `api.command` / `editorData` / `actionData`):
+Use the CLI `describe` command to find available views (for `live()`) and actions (for `api.command` / `editorData` / `actionData`). From the app root, use **fnm exec** so Node matches `.node-version` / `.nvmrc` (see `live-change-node-toolchain-fnm`).
 
 ```bash
-node server/start.js describe --service blog
-node server/start.js describe --service blog --view articlesByCreatedAt --output yaml
-node server/start.js describe --service blog --action createMyUserArticle --output yaml
+fnm exec -- node server/start.js describe --service blog
+fnm exec -- node server/start.js describe --service blog --view articlesByCreatedAt --output yaml
+fnm exec -- node server/start.js describe --service blog --action createMyUserArticle --output yaml
 ```
 
 This is the fastest way to discover what paths and actions are available, including those auto-generated by relations.

package/.claude/rules/live-change-node-toolchain-fnm.md

@@ -0,0 +1,39 @@
+---
+description: Run Node, npm, npx, tsx with fnm exec using project .node-version or .nvmrc
+---
+
+# Node.js toolchain – use `fnm exec`
+
+Do **not** rely on whatever Node.js version the agent sandbox or shell happens to use. That often differs from the project and breaks the LiveChange stack, tests, and `describe`.
+
+Use **fnm** so the version from the project dotfiles (`.node-version` or `.nvmrc`) is selected.
+
+## Required pattern
+
+Work in the directory that contains the relevant `.node-version` or `.nvmrc` (app or package root). Prefix **every** `node`, `npm`, `npx`, `corepack`, or `tsx` invocation with:
+
+```bash
+fnm exec -- <command and arguments>
+```
+
+Examples:
+
+```bash
+fnm exec -- node server/start.js describe --service myService --output yaml
+fnm exec -- npm test
+fnm exec -- npm run build
+fnm exec -- npx eslint .
+fnm exec -- tsx scripts/example.ts
+```
+
+If the dotfile lives only under a subfolder (e.g. `auto-firma/app/`), `cd` there first, then run `fnm exec -- ...`.
+
+## When this applies
+
+- Tests, CI scripts, linters, builds
+- Framework CLI: `describe`, dev servers, migrations, anything touching `@live-change/*`
+- Any `npm` / `node` / `npx` / `tsx` for this monorepo or its subprojects
+
+## If `fnm` is unavailable
+
+Tell the user to install fnm or align the environment; do not proceed assuming an arbitrary `node` on `PATH` is correct.

package/.claude/rules/live-change-service-structure.md

@@ -1,13 +1,13 @@
 ---
 description: Rules for LiveChange service directory structure and file organization
-globs: **/services/**/*.js
+globs: **/services/**/*.js, **/server/**/*.js, server/**/*.js
 ---
 
 # LiveChange Service Structure
 
 Every LiveChange service **must** be a directory, not a single file.
 
-## Required structure
+## Required structureW
 
 ```
 server/services/<serviceName>/

package/.claude/settings.json

@@ -22,7 +22,9 @@
       "Bash(cp /home/m8/IdeaProjects/live-change/.claude/rules/live-change-backend-event-sourcing.md /home/m8/IdeaProjects/live-change/automation/.claude/rules/live-change-backend-event-sourcing.md)",
       "Bash(find /home/m8/IdeaProjects/live-change/live-change-stack/framework -type f \\\\\\(-name *.ts -o -name *.js \\\\\\))",
       "Bash(find /home/m8/IdeaProjects/live-change/live-change-stack/services -type f -name *.js)",
-      "Bash(grep -r \"userItem\\\\|userProperty\" /home/m8/IdeaProjects/live-change/live-change-stack/services/user-service --include=*.js)"
+      "Bash(grep -r \"userItem\\\\|userProperty\" /home/m8/IdeaProjects/live-change/live-change-stack/services/user-service --include=*.js)",
+      "Bash(find /home/m8/IdeaProjects/live-change/auto-firma/app -maxdepth 2 -type f \\\\\\(-name jest.config.* -o -name vitest.config.* -o -name *.test.js -o -name *.test.ts \\\\\\))",
+      "Bash(find /home/m8/IdeaProjects/live-change/auto-firma/app -maxdepth 3 -type d -not -path */node_modules* -not -path */dist* -not -path */backups* -not -path */dev_docker_home* -not -path */storage* -not -path */tmp.db*)"
     ],
     "additionalDirectories": [
       "/home/m8/IdeaProjects/live-change/.claude/skills/create-skills-and-rules",

package/.claude/skills/create-skills-and-rules/SKILL.md

@@ -137,6 +137,22 @@ globs: **/front/src/**/*.{vue,js,ts}
 | `description` | What this rule covers (used for matching) |
 | `globs` | File patterns that trigger this rule (e.g. `**/*.js`, `**/services/**/*.js`) |
 
+### Backend / LiveChange service rules — standard `globs`
+
+Rules for **server-side** LiveChange code (models, actions, triggers, service layout) should use a **comma-separated** `globs` line so they still match when a project stores services under different folder names (many teams copy `.cursor/rules` into other repos):
+
+```yaml
+globs: **/services/**/*.js, **/server/**/*.js, server/**/*.js
+```
+
+| Pattern | Covers |
+|---|---|
+| `**/services/**/*.js` | Trees such as `live-change-stack/services/<service>/` |
+| `**/server/**/*.js` | Any nested `server/` directory (e.g. `app/server/`, `packages/foo/server/`) |
+| `server/**/*.js` | Backend rooted at top-level `server/` |
+
+Frontend rules keep their own globs (e.g. `**/front/src/**/*.{vue,js,ts}`). Do not drop the `server` variants for backend-only rules — otherwise Cursor will miss files after a layout change.
+
 ### Body structure
 
 ```markdown
@@ -181,6 +197,7 @@ alwaysApply: false
 - Do NOT quote glob patterns in frontmatter
 - Keep rules short (target 25 lines, max 50 lines for best Cursor performance)
 - The `.mdc` extension is required for Cursor
+- For **backend** LiveChange rules, use the same **`globs`** standard as in Claude rules: `**/services/**/*.js, **/server/**/*.js, server/**/*.js`
 
 ## Step 5 – Register rules in OpenCode (`opencode.json`)
 
@@ -198,8 +215,12 @@ OpenCode reads `.claude/skills/<name>/SKILL.md` natively for skills (no extra st
 
 When you **create a new rule**, add its path to the `instructions` array in `opencode.json`.
 
+Project rule **`live-change-node-toolchain-fnm`** should stay **first** (or early) in `instructions` so agents always load the requirement to run `node`, `npm`, `npx`, and `tsx` via `fnm exec` using `.node-version` / `.nvmrc`.
+
 When you **create a new skill**, no `opencode.json` change is needed — OpenCode discovers skills from `.claude/skills/<name>/SKILL.md` automatically.
 
+When a skill or rule shows shell examples that invoke **`node`**, **`npm`**, **`npx`**, or **`tsx`**, use the **`fnm exec -- …`** form (see `.claude/rules/live-change-node-toolchain-fnm.md` and skill `live-change-node-toolchain-fnm`).
+
 **Important:** OpenCode ignores the `globs` frontmatter from Claude Code rules. All instructions listed in `opencode.json` are always loaded.
 
 ## Step 6 – Mirror Cursor skills (`.cursor/skills/<name>.md`)
@@ -239,10 +260,12 @@ done
 
 ## Checklist
 
+- [ ] Shell examples for Node/npm use `fnm exec --` per `live-change-node-toolchain-fnm`
 - [ ] Directory created: `.claude/skills/<name>/SKILL.md`
 - [ ] Frontmatter has both `name` (matching dir) and `description`
 - [ ] `.cursor/skills/<name>.md` mirrored (flat file, same content)
 - [ ] `.claude/rules/*.md` created (if rule)
 - [ ] `.cursor/rules/*.mdc` created with `globs` + `alwaysApply` (if rule)
+- [ ] Backend rules use standard `globs`: `**/services/**/*.js, **/server/**/*.js, server/**/*.js` (when the rule targets LiveChange server code)
 - [ ] `opencode.json` `instructions` array updated (if new rule)
 - [ ] Sub-projects updated (automation, auto-firma)

package/.claude/skills/live-change-backend-change-triggers/SKILL.md

@@ -112,6 +112,21 @@ definition.trigger({
 
 This means: when a user creates a Schedule via the UI or API, the timer is automatically set up. When they update it, the old timer is canceled and a new one created. When they delete it, the timer is canceled.
 
+## Cron-service — planning and admin UI guardrails
+
+When the domain needs **wall-clock schedules** or **fixed repeating intervals** that run a **trigger**, default to **`@live-change/cron-service`** (models **Schedule** / **Interval**, internal **timer** + **changeCron_*** lifecycle), not ad-hoc timers only.
+
+**Backend:** define the **target `definition.trigger`** in your service; put **Schedule** / **Interval** rows in **cron** with **`trigger: { name, service, properties, returnTask }`**. Rely on **`changeCron_Schedule`** / **`changeCron_Interval`** for timer repair (already implemented in cron-service).
+
+**Admin / task-frontend-style UI:** use the same integration as the reference pages:
+
+- **Create:** `ActionForm` with `service="cron"` and `action="setSchedule"` or `action="setInterval"` (relations-driven forms).
+- **List:** `RangeViewer` + `path.cron.schedules` / `path.cron.intervals` with **`reverseRange(range)`** as needed.
+- **Per row:** `.with()` → `scheduleInfo` / `intervalInfo`, `runState` (`jobType` **`cron_Schedule`** or **`cron_Interval`**, **`job`** = id), and `task.tasksByCauseAndCreatedAt` for recent runs.
+- **Delete:** `api.actions.cron.deleteSchedule` / `deleteInterval`.
+
+See **server doc** `15-cron-and-intervals.md` → section **“API used by task-frontend”** for path examples and **Schedule** field semantics (**`NaN`** = “every” for that field).
+
 ## Step 4 – Specific lifecycle triggers (alternative)
 
 If you only care about one lifecycle event, use the specific variant:

package/.claude/skills/live-change-dao-protocol/SKILL.md

@@ -0,0 +1,46 @@
+---
+description: Jak poprawnie wywoływać akcje i widoki frameworka LiveChange przez surowy protokół DAO.
+---
+
+# LiveChange DAO Protocol Arguments
+
+Kiedy komunikujesz się z frameworkiem LiveChange używając surowego protokołu `@live-change/dao` (np. z C++, Pythona, Rusta, Go lub dowolnego innego klienta nie-JS), MUSISZ ZAWSZE przekazywać argumenty jako **tablicę**.
+
+Framework traktuje argumenty żądań (request) i obserwabli (observable) DAO jak argumenty funkcji i używa operatora spread (`...args`), aby przekazać je do bazowych funkcji akcji lub widoków. Jeśli przekażesz obiekt zamiast tablicy, serwer rzuci błąd `TypeError: Spread syntax requires ...iterable[Symbol.iterator] to be a function`.
+
+Nawet jeśli akcja lub widok oczekuje pojedynczego obiektu jako parametru, ten obiekt MUSI być opakowany w jednoelementową tablicę.
+
+## Przykład w C++ (używając nlohmann/json)
+
+### Niepoprawnie ❌
+```cpp
+nlohmann::json args = {
+  {"pairingKey", "123"},
+  {"connectionType", "device"}
+};
+connection->request({"serviceName", "actionName"}, args, settings);
+```
+
+### Poprawnie ✅
+```cpp
+// Wrap the object in an array
+auto args = {
+  nlohmann::json::object({
+    {"pairingKey", "123"},
+    {"connectionType", "device"}
+  })
+};
+connection->request({"serviceName", "actionName"}, args, settings);
+```
+
+Lub jawnie:
+```cpp
+nlohmann::json args = nlohmann::json::array({
+  nlohmann::json::object({
+    {"pairingKey", "123"},
+    {"connectionType", "device"}
+  })
+});
+```
+
+Zawsze upewnij się, że Twój payload `args` jest tablicą przed wysłaniem go przez połączenie DAO.