@live-change/frontend-template 0.9.201 → 0.9.204

package/.claude/skills/live-change-design-actions-views-triggers/SKILL.md

@@ -7,6 +7,12 @@ description: Design actions, views, triggers with indexes and batch processing p
 
 Use this skill to design **actions, views, and triggers** in LiveChange services while making good use of indexes and avoiding full-table scans.
 
+## Reads vs writes (CQRS-like)
+
+**Frontend (Vue):** load data with `usePath` + `live` / `useFetch` on **views**. Do **not** use `api.command` or `useActions()` only to fetch, preview, or compute display-only values — add a `definition.view` on the server and read it on the client.
+
+**Backend (services):** **`definition.view`** is the read surface (including computed or preview data). From triggers/actions use **`app.viewGet`** / **`app.serviceViewGet`** when you need the same view layer as the client, or direct model/index reads where appropriate. **Actions and triggers** change state via **`emit`** / **`trigger`** / **`triggerService`**, not via fake “read-only actions.”
+
 ## When to use
 
 - You add or change actions on existing models.
@@ -73,6 +79,116 @@ definition.action({
    - use model paths (`Model.path`, `Model.rangePath`, `Model.sortedIndexRangePath`, `Model.indexObjectPath`)
    - use `...App.rangeProperties` + `App.extractRange(props)` for range views
 
+### Step 2a – Prefix-aware range filtering
+
+When you query an index with `Model.sortedIndexRangePath(indexName, keyPrefix, range)`, remember:
+
+- `keyPrefix` is matched first (for example `[bankAccount]` or `[bankAccount, month]`).
+- `range.gt/gte/lt/lte` is applied to full serialized index keys, not to a single field.
+- If you need optional narrowing, pass a dedicated filter parameter (`month`, `state`, etc.) and keep range for cursor pagination.
+
+```js
+definition.view({
+  name: 'bankTransactionsByBankAccountAndDate',
+  properties: {
+    bankAccount: { type: String },
+    month: { type: String },
+    ...App.rangeProperties
+  },
+  returns: { type: Array, of: { type: Object } },
+  async daoPath({ bankAccount, month, ...props }) {
+    const range = App.extractRange(props)
+    if(month) {
+      const prefix = [bankAccount, month].map(v => JSON.stringify(v)).join(':')
+      return BankTransaction.rangePath(App.utils.prefixRange(range, prefix, prefix + ':'))
+    }
+    return BankTransaction.sortedIndexRangePath('byBankAccountAndDate', [bankAccount], range)
+  }
+})
+```
+
+If filtering by month is a frequent query, prefer a dedicated index like `byBankAccountAndMonthAndDate` and query it with:
+
+```js
+BankTransaction.sortedIndexRangePath('byBankAccountAndMonthAndDate', [bankAccount, month], range)
+```
+
+For that index, prefer this function-index style:
+
+```js
+function: async (input, output, { tableName }) => {
+  const table = await input.table(tableName)
+  const mapper = obj => ({
+    id: [obj.bankAccount, obj.date?.slice(0, 7), obj.date]
+      .map(v => JSON.stringify(v)).join(':') + '_' + obj.id,
+    to: obj.id
+  })
+  await table.map(mapper).to(output)
+}
+```
+
+`map()` automatically filters out `null`, so you can keep mapper logic concise.
+
+### Step 2b – RangeViewer/rangeBuckets compatibility
+
+When a view is consumed by `RangeViewer` or `rangeBuckets`:
+
+- prefer `Model.sortedIndexRangePath(...)` for index-backed list views,
+- keep `App.extractRange(props)` as pagination cursor input,
+- do not reinterpret `gt/gte/lt/lte` as domain filters.
+
+Anti-patterns:
+
+- using `indexRangePath` for frontend bucket pagination flow,
+- injecting custom month/year bounds into cursor fields in frontend,
+- rewriting cursor values in backend with unrelated filter semantics.
+
+Preferred filtering strategy:
+
+1. design index prefix for frequent filters,
+2. use `App.utils.prefixRange` only as backend fallback,
+3. keep string min/max hacks as last resort.
+
+### Step 2c – Standalone indexes for union/equal sources
+
+When index rows are built from multiple equal tables (union-like flow), do not force the index into one model definition.
+
+Use `definition.index(...)` at service level (typically `indexes.js`) when:
+
+- index combines rows from two or more source tables,
+- source tables are peer entities (no natural single owner model),
+- index is a projection layer for cross-table reads.
+
+> **IMPORTANT — serialization constraint:** Index functions are serialized via `toString()` and executed remotely. All helpers, mappers, and variables **must be defined inside the function body**. References to outer scope (module-level functions, imports) will be `undefined` at runtime.
+
+Example:
+
+```js
+definition.index({
+  name: 'Urls',
+  function: async (input, output) => {
+    const mapRedirect = obj => obj && ({
+      id: /* composed key */, to: obj.target
+    })
+    const mapCanonical = obj => obj && ({
+      id: /* composed key */, to: obj.target
+    })
+
+    await input.table('url_Redirect').onChange((obj, oldObj) =>
+      output.change(mapRedirect(obj), mapRedirect(oldObj))
+    )
+    await input.table('url_Canonical').onChange((obj, oldObj) =>
+      output.change(mapCanonical(obj), mapCanonical(oldObj))
+    )
+  }
+})
+```
+
+Decision rule:
+
+- model-local index -> `definition.model({ indexes: ... })`,
+- union/peer-source index -> standalone `definition.index(...)` in `indexes.js`.
+
 ### Example: `daoPath` (preferred, DAO-backed)
 
 ```js

package/.claude/skills/live-change-design-models-relations/SKILL.md

@@ -62,6 +62,25 @@ properties: {
 }
 ```
 
+## Step 2b – Relation arity rules (critical)
+
+Treat arity on two levels:
+
+- **Annotation arity**: can the annotation itself be a list of configs?
+- **Parent tuple arity**: can one config point to 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]`
+
 ## Step 3 – Configure the relation
 
 ### `userItem`
@@ -110,7 +129,7 @@ so the relations/CRUD generator can treat it as a relation rather than a plain `
 
 Notes:
 
-- Usually you’ll have 1–2 parents, but the `propertyOf` list may contain **any number** of parent models (including 3+).
+- Usually you’ll have 1–2 parents, but `what` may contain **any number** of parent models (including 3+).
 - If the entity is a relation, avoid adding manual `...Id` fields in `properties` just to represent the link — CRUD generators won’t treat it as a relation.
 
 Example:
@@ -124,10 +143,9 @@ definition.model({
   properties: {
     // optional extra fields
   },
-  propertyOf: [
-    { what: CostInvoice },
-    { what: Contractor }
-  ]
+  propertyOf: {
+    what: [CostInvoice, Contractor]
+  }
 })
 ```
 
@@ -168,6 +186,46 @@ indexes: {
 
 3. Use these indexes in views/actions, via `indexObjectGet` / `indexRangeGet`.
 
+### Step 5b – Use `function` indexes for derived keys
+
+Use a `function` index when key parts are not stored directly as properties (for example `yearMonth` derived from `date`).
+
+Key rules:
+
+- Keep index entries stable and deterministic.
+- Build composite keys as serialized parts joined with `:` and append `_' + id`.
+- Emit `{ id, to }` objects so `to` points to the source model id.
+- Prefer `table.map(mapper).to(output)` over manual `onChange(...output.change...)`.
+- `map()` drops `null` results automatically, so mapper can stay clean.
+
+Example:
+
+```js
+indexes: {
+  byBankAccountAndMonthAndDate: {
+    function: async (input, output, { tableName }) => {
+      const table = await input.table(tableName)
+      const mapper = obj => ({
+        id: [
+          obj.bankAccount,
+          obj.date?.slice(0, 7),   // YYYY-MM month bucket
+          obj.date
+        ].map(v => JSON.stringify(v)).join(':') + '_' + obj.id,
+        to: obj.id
+      })
+      await table.map(mapper).to(output)
+    },
+    parameters: {
+      tableName: definition.name + '_BankTransaction'
+    }
+  }
+}
+```
+
+This format matches how property indexes are serialized internally and works well with range-prefix filtering in views.
+
+> **IMPORTANT — serialization constraint:** Function indexes are serialized via `toString()` and executed remotely. The mapper and all helpers **must be defined inside the function body** — not in module scope. References to outer variables or imports will be `undefined` at runtime.
+
 ## Step 6 – Set access control on relations
 
 1. For `userItem`, `itemOf`, and `propertyOf`, always define:

package/.claude/skills/live-change-frontend-command-forms/SKILL.md

@@ -19,15 +19,16 @@ Before using this skill, pick the right approach:
 |---|---|
 | `editorData` | **Editing model records** (create/update). Drafts, validation, `AutoField`. See `live-change-frontend-editor-form` skill. |
 | `actionData` | **One-shot action forms** (not CRUD). Submit once → done. See `live-change-frontend-action-form` skill. |
-| `api.command` | **Single button or programmatic calls** (no form fields). This skill, Step 1. |
+| `api.command` | **Mutations only** — single button or programmatic calls that **change persisted state** (no form fields). This skill, Step 1. Not for loading or previewing data (use views + `live` / `useFetch`; see `live-change-frontend-data-views`). |
 | `<command-form>` | **Avoid.** Legacy. Only for trivial prototypes without drafts or `AutoField`. This skill, Step 2. |
 
 **Decision flow:**
 
-1. Does the user fill in form fields? → **No**: use `api.command` (this skill).
-2. Is it editing a model record? → **Yes**: use `editorData`.
-3. Is it a one-shot action? → **Yes**: use `actionData`.
-4. Only use `<command-form>` for the simplest throwaway cases.
+1. Do you only need to **read** data (including previews)? → **Use views** (`live` / `useFetch`), not this skill.
+2. Does the user fill in form fields? → **No**: use `api.command` (this skill) **only if** the operation **mutates** state.
+3. Is it editing a model record? → **Yes**: use `editorData`.
+4. Is it a one-shot action? → **Yes**: use `actionData`.
+5. Only use `<command-form>` for the simplest throwaway cases.
 
 ## Step 1 – Use `api.command` directly
 

package/.claude/skills/live-change-frontend-data-views/SKILL.md

@@ -14,6 +14,8 @@ Use this skill when you build **reactive data views** using `usePath`, `live`, `
 - You need to load related objects alongside the main data.
 - You need to restrict data loading for unauthenticated users.
 
+**Do not use `api.command` / `useActions()` to load data.** Commands are for **mutations**. For every read (lists, details, previews, “next number”), use **views** with `live` or `useFetch` as in this skill.
+
 ## Step 1 – Basic data loading with computed paths
 
 When paths depend on reactive values (route params, props), wrap them in `computed()`:
@@ -36,6 +38,21 @@ const [article, comments] = await Promise.all([
 ])
 ```
 
+- Call `usePath()` **once** at the top of `setup` (synchronously). Inside `computed`, use only the returned `path` object to build paths — **never** call `usePath()` or the legacy `path()` inside the getter (there is often no active component instance, which breaks `getCurrentInstance()` / `appContext`).
+
+Wrong:
+
+```javascript
+computed(() => usePath().blog.article({ article: id }))
+```
+
+Right:
+
+```javascript
+const path = usePath()
+const articlePath = computed(() => path.blog.article({ article: id }))
+```
+
 In templates access `.value`:
 
 ```vue
@@ -45,7 +62,26 @@ In templates access `.value`:
 </div>
 ```
 
-## Step 2 – Load related objects with `.with()`
+## Step 2 – One-time fetches with `useFetch`
+
+When you need data once (e.g. after an upload, in an event handler), use `useFetch` instead of `live`:
+
+```javascript
+import { usePath, useFetch } from '@live-change/vue3-ssr'
+
+const path = usePath()
+const data = await useFetch(path.paperInvoice.invoiceFileInfo({ invoiceFile: fileId }))
+```
+
+**Do NOT use `api.get()` with Path objects.** `path.service.view()` returns a Path object (with `.what`, `.more`, `.to` properties), not a raw array. `api.get()` only accepts raw arrays like `['service', 'view', { params }]`.
+
+| Method | Input | Returns | Use when |
+|---|---|---|---|
+| `live(path)` | Path or array | Reactive Ref | Live-updating data |
+| `useFetch(path)` | Path or array | Promise | One-time fetch |
+| `api.get([...])` | Raw array only | Promise | Low-level, avoid in app code |
+
+## Step 3 – Load related objects with `.with()`
 
 Chain `.with()` to attach related data to each item:
 
@@ -62,6 +98,40 @@ const articlesPath = computed(() =>
 const [articles] = await Promise.all([live(articlesPath)])
 ```
 
+### `.with()` callback guardrails
+
+Treat `.with(item => ...)` as a declarative Path DSL builder:
+
+- the callback receives a proxy, not a hydrated runtime record
+- do not place side effects or command calls inside `.with(...)`
+- do not use imperative branching like `if(item.type === '...')` in the callback
+
+Use `$switch` for conditional path branching:
+
+```javascript
+const settlementsPath = computed(() =>
+  path.accounting.settlementsByTransaction({
+    transactionType: 'bankAccount_BankTransaction',
+    transaction: transactionId,
+    range: { limit: 256 }
+  }).with(settlement => settlement.subjectType.$switch({
+    invoice_CostInvoice: path.invoice.costInvoice({ costInvoice: settlement.subject }),
+    invoice_IncomeInvoice: path.invoice.incomeInvoice({ incomeInvoice: settlement.subject }),
+    hr_CivilContract: path.hr.civilContract({ civilContract: settlement.subject })
+  }).$bind('subjectDoc'))
+)
+```
+
+Production-style pattern reference:
+
+```javascript
+p.url.urlsByTargetAndPath({ targetType, domain, path: urlPath })
+  .with(url => url.type.$switch({
+    canonical: null,
+    redirect: p.url.canonical({ targetType, target: url.target })
+  }).$bind('canonical'))
+```
+
 Access in template:
 
 ```vue
@@ -86,7 +156,7 @@ const eventPath = computed(() =>
 )
 ```
 
-## Step 3 – Conditional loading with `useClient`
+## Step 4 – Conditional loading with `useClient`
 
 Use `useClient()` to check authentication state and conditionally build paths:
 
@@ -132,7 +202,7 @@ When the path is `null` / `false` / `undefined`, `live()` returns a ref with `nu
 </template>
 ```
 
-## Step 4 – Dependent paths
+## Step 5 – Dependent paths
 
 When one path depends on data from another, load them sequentially:
 
@@ -152,7 +222,7 @@ const [author] = await Promise.all([live(authorPath)])
 
 Or use `.with()` to combine them in a single query (preferred when possible).
 
-## Step 5 – Props-based paths in components
+## Step 6 – Props-based paths in components
 
 When building reusable components that receive IDs as props:
 
@@ -177,6 +247,7 @@ When building reusable components that receive IDs as props:
 | Pattern | When to use |
 |---|---|
 | `computed(() => path.xxx(...))` | Path depends on reactive values |
+| `useFetch(path.xxx(...))` | One-time data fetch (not reactive) |
 | `.with(item => path.yyy(...).bind('field'))` | Attach related objects |
 | `client.value.user && path.xxx(...)` | Load only when authenticated |
 | `client.value.roles.includes('admin')` | Load/show only for specific roles |

package/.claude/skills/live-change-frontend-e2e-lifecycle/SKILL.md

@@ -0,0 +1,82 @@
+---
+name: live-change-frontend-e2e-lifecycle
+description: Set up stable node:test E2E lifecycle with env, withBrowser and e2eSuite
+---
+
+# Skill: live-change-frontend-e2e-lifecycle
+
+Use this skill when creating or refactoring LiveChange frontend E2E tests.
+
+## Goal
+
+Avoid flaky teardown where only the first test file runs because shared env teardown calls `process.exit`.
+
+## Step 1 - Build shared env helper
+
+Create `e2e/env.ts` with:
+
+- `getTestEnv()` that starts `TestServer` once and memoizes with `envPromise`
+- `disposeTestEnv()` that resets memoized state and disposes server
+- fallback cleanup:
+
+```ts
+process.on('beforeExit', () => {
+  void disposeTestEnv()
+})
+```
+
+Keep startup failure `process.exit(1)` inside `getTestEnv()` catch.
+
+Do not add `after(...process.exit(...))` to this file.
+
+## Step 2 - Isolate browser per test
+
+Create `e2e/withBrowser.ts` with Playwright setup/teardown in `try/finally`:
+
+- call `getTestEnv()` once per test execution
+- open browser/context/page
+- close context and browser in `finally`
+
+## Step 3 - Add suite-level teardown
+
+Create `e2e/e2eSuite.ts`:
+
+```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()
+  })
+}
+```
+
+## Step 4 - Wrap tests
+
+Each `e2e/*.test.ts` file should use one wrapper:
+
+```ts
+import test from 'node:test'
+import { e2eSuite } from './e2eSuite.js'
+
+e2eSuite('example-suite', () => {
+  test('renders page', async () => {
+    // test body
+  })
+})
+```
+
+## Step 5 - Verify
+
+Run from project root with `fnm exec`:
+
+```bash
+fnm exec -- npm run e2e
+```
+
+Confirm multiple test files execute and process exits only after full suite teardown.

package/.claude/skills/live-change-frontend-range-list/SKILL.md

@@ -27,6 +27,19 @@ function articlesPathRange(range) {
 }
 ```
 
+## Step 1a – Hard rules for index-backed ranges
+
+For lists loaded with `RangeViewer` / `rangeBuckets`:
+
+- backend views should use `sortedIndexRangePath`, not `indexRangePath`,
+- keep `range.gt/gte/lt/lte` for pagination cursor only,
+- never override `gt/lt` in frontend `pathFunction` with ad-hoc filters.
+
+Why:
+
+- RangeViewer computes next buckets from previous cursor boundaries,
+- replacing cursor fields causes repeated slices and broken infinite loading.
+
 ## Step 2 – Attach related objects with `.with()`
 
 Chain `.with()` calls to load related data for each item:
@@ -47,6 +60,22 @@ Each `.with()` call:
 - builds a path to the related data,
 - calls `.bind('fieldName')` to attach the result under that field name.
 
+Important:
+- this proxy is Path DSL input, not a hydrated runtime item
+- do not branch with imperative `if/else` on proxy fields inside `.with(...)`
+- for type-based conditional branches, use `$switch(...).$bind(...)`
+
+```javascript
+function settlementsPathRange(range) {
+  return path.accounting.settlementsByTransaction({ ...range })
+    .with(settlement => settlement.subjectType.$switch({
+      invoice_CostInvoice: path.invoice.costInvoice({ costInvoice: settlement.subject }),
+      invoice_IncomeInvoice: path.invoice.incomeInvoice({ incomeInvoice: settlement.subject }),
+      hr_CivilContract: path.hr.civilContract({ civilContract: settlement.subject })
+    }).$bind('subjectDoc'))
+}
+```
+
 Nested `.with()` is also supported:
 
 ```javascript
@@ -127,3 +156,64 @@ Iterate in the template:
   </div>
 </template>
 ```
+
+## Step 5 – Optional filters without breaking range cursor
+
+When your list supports optional filtering (for example `month`), do not push raw field values into `gt/gte/lt/lte` from the frontend.
+
+Why:
+
+- Range boundaries are compared against full index keys, not a single field.
+- `RangeViewer` controls `gt/lt` for pagination; overriding them breaks infinite scroll behavior.
+
+Correct pattern:
+
+1. Keep RangeViewer cursor in `range` (`...reverseRange(range)`).
+2. Send optional filters as separate params (`month`, `state`, etc.).
+3. Let backend view apply prefix logic (`sortedIndexRangePath` with longer key prefix or `App.utils.prefixRange`).
+
+```js
+function transactionsPathRange(range) {
+  return path.bankAccount.bankTransactionsByBankAccountAndDate({
+    bankAccount: accountId,
+    month: month.value || undefined,
+    ...reverseRange(range)
+  })
+}
+```
+
+## Step 6 – Reactive filter changes (no hidden bucket bugs)
+
+If `pathFunction` depends on reactive filters (for example month/company/status), prefer `ReactiveRangeViewer` over mutating `RangeViewer` input directly.
+
+Why:
+
+- changing filters can recreate bucket state in subtle ways
+- forcing rerender with ad-hoc `:key` works, but spreads fragile logic across pages
+- `ReactiveRangeViewer` centralizes safe reload behavior
+
+```vue
+<ReactiveRangeViewer
+  :pathFunction="transactionsPathRange"
+  :sourceKey="JSON.stringify({ month: filterByMonth ? month : null, accountId })"
+  :preserveHeightOnReload="true"
+  :canLoadTop="false"
+  canDropBottom
+  loadBottomSensorSize="3000px"
+  dropBottomSensorSize="8000px"
+>
+  <template #default="{ item }">
+    <BankTransactionListItem :transaction="item" />
+  </template>
+</ReactiveRangeViewer>
+```
+
+Use `sourceKey` as the explicit reload trigger when filter inputs change.
+
+## Checklist – range pagination safety
+
+- [ ] backend index view is based on `sortedIndexRangePath`
+- [ ] frontend `pathFunction` forwards `range` unchanged (`...range` or `...reverseRange(range)`)
+- [ ] domain filters (`month`, `year`, `status`) are separate view params
+- [ ] no manual cursor overrides (`gt/gte/lt/lte`) in frontend code
+- [ ] if narrowing is needed, backend uses index prefix design first, `prefixRange` only as fallback

package/.claude/skills/live-change-frontend-synchronized/SKILL.md

@@ -0,0 +1,101 @@
+---
+name: live-change-frontend-synchronized
+description: Use synchronized and synchronizedList for autosave editing in LiveChange Vue frontends, including object vs list decision flow, identifiers mapping, and save/delete patterns
+---
+
+# Skill: live-change-frontend-synchronized (Claude Code)
+
+Use this skill when implementing or refactoring frontend editing flows that should keep local form state synchronized with backend data.
+
+## When to use
+
+- Editing one object loaded from `live(...)` with autosave or manual save.
+- Editing list items inline (for example access roles) with per-row identifiers.
+- Replacing custom `watch + api.command` autosave logic with a standard helper.
+- Choosing between `synchronized`, `synchronizedList`, and `editorData`.
+
+## Decision flow
+
+1. **One editable object** (`profile`, `note`, `settings`) -> use `synchronized`.
+2. **Editable list rows** (`accesses`, `invitations`, `requests`) -> use `synchronizedList`.
+3. **Definition-driven CRUD form with validation UI** -> use `editorData` from auto-form stack.
+
+## What counts as "editable list rows"
+
+Treat the feature as a list flow (`synchronizedList`) when most of these are true:
+
+- The UI renders rows with `v-for` and each row has editable fields.
+- Users can edit many rows inline in one screen (table/config/admin list).
+- Autosave should happen per row while the list stays reactive.
+- Each row needs its own action payload keys in addition to shared list context.
+
+In this case, wire one `synchronizedList(...)` and edit fields directly on `syncList.value`.
+Do not build a parallel `id -> synchronized(...)` map for rows.
+
+## `synchronized` pattern (object)
+
+```javascript
+import { synchronized } from '@live-change/vue3-components'
+
+const sync = synchronized({
+  source: sourceRef,
+  update: actions.service.updateThing,
+  identifiers: computed(() => ({ thing: thingId.value })),
+  recursive: true,
+  autoSave: true,
+  debounce: 600
+})
+
+const { value: editable, changed, saving, save } = sync
+```
+
+### Rules
+
+- `source` should come from `live(...)` or a computed source.
+- Keep identifiers stable and pass them through `identifiers` (plain object or `computed`).
+- Use `updateDataProperty: 'data'` for draft-like payloads where backend expects nested data.
+- Use `autoSave: false` when save must happen only after explicit confirmation.
+
+## `synchronizedList` pattern (list)
+
+```javascript
+import { synchronizedList } from '@live-change/vue3-components'
+
+const syncList = synchronizedList({
+  source: accesses,
+  update: actions.accessControl.updateSessionOrUserAndObjectOwnedAccess,
+  delete: actions.accessControl.resetSessionOrUserAndObjectOwnedAccess,
+  identifiers: { object, objectType },
+  objectIdentifiers: ({ to, sessionOrUser, sessionOrUserType }) => ({
+    access: to, sessionOrUser, sessionOrUserType, object, objectType
+  }),
+  recursive: true
+})
+
+const editableRows = syncList.value
+await syncList.delete(editableRows.value[0])
+```
+
+### Rules
+
+- `source` should be a list from `live(...)`.
+- Every item should have stable `id`.
+- Put shared context in `identifiers`, and row-specific keys in `objectIdentifiers`.
+- Edit rows through `syncList.value`; call `syncList.delete(...)` / `syncList.insert(...)` on the helper object.
+- Prefer this pattern for configuration lists, permission tables, dictionaries, and other multi-row settings editors.
+
+## Project examples to follow
+
+- `speed-dating/front/src/components/notes/NoteEditor.vue` (`synchronized` with autosave)
+- `speed-dating/front/src/components/profile/ProfileSettings.vue` (`synchronized` + `updateDataProperty: 'data'`)
+- `family-tree/front/src/components/AgreementDialog.vue` (`synchronized` with manual save)
+- `rcstreamer/front/src/configuration/AccessRequests.vue` (`synchronizedList`)
+- `rcstreamer/front/src/configuration/AccessInvitations.vue` (`synchronizedList`)
+- `rcstreamer/front/src/configuration/AccessList.vue` (`synchronizedList`)
+
+## Common mistakes
+
+- Using `synchronized` for a list of rows instead of `synchronizedList`.
+- Forgetting `objectIdentifiers` when backend update/delete actions need per-row keys.
+- Mutating raw `live(...)` list data instead of `synchronizedList(...).value`.
+- Mixing autosave helper patterns with unrelated one-shot action form patterns.