@live-change/frontend-template 0.9.199 → 0.9.200

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

@@ -132,6 +132,68 @@ definition.trigger({
 })
 ```
 
+## Change triggers – reacting to model changes
+
+Models with relations (`propertyOf`, `itemOf`, `userItem`, etc.) automatically fire change triggers on every create/update/delete. The naming convention is `{changeType}{ServiceName}_{ModelName}`:
+
+- `changeSvc_Model` — fires on any change (recommended, covers all cases)
+- `createSvc_Model` / `updateSvc_Model` / `deleteSvc_Model` — specific lifecycle
+
+Parameters: `{ objectType, object, identifiers, data, oldData, changeType }`.
+
+```js
+// React to any change in Schedule model from cron service
+definition.trigger({
+  name: 'changeCron_Schedule',
+  properties: {
+    object: { type: Schedule, validation: ['nonEmpty'] },
+    data: { type: Object },
+    oldData: { type: Object }
+  },
+  async execute({ object, data, oldData }, { triggerService }) {
+    if(oldData) { /* cleanup old state */ }
+    if(data) { /* setup new state */ }
+  }
+})
+```
+
+Check `data`/`oldData`: both present = update, only `data` = create, only `oldData` = delete.
+
+## 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.
+
+Use a change trigger that fires on creation (`data` exists, `oldData` does not):
+
+```js
+definition.trigger({
+  name: 'changeMyService_MyModel',
+  properties: {
+    object: { type: MyModel, validation: ['nonEmpty'] },
+    data: { type: Object },
+    oldData: { type: Object }
+  },
+  async execute({ object, data, oldData }, { client, triggerService }) {
+    if (!data || oldData) return   // only on create
+    if (!client?.user) return
+
+    await triggerService({ service: 'accessControl', type: 'accessControl_setAccess' }, {
+      objectType: 'myService_MyModel',
+      object,
+      roles: ['owner'],
+      sessionOrUserType: 'user_User',
+      sessionOrUser: client.user,
+      lastUpdate: new Date()
+    })
+  }
+})
+```
+
+Key details:
+- `objectType` format: `serviceName_ModelName` (e.g. `company_Company`)
+- For public access (readable by everyone), use `accessControl_setPublicAccess` with `userRoles` / `sessionRoles`
+- For anonymous users, use `sessionOrUserType: 'session_Session'` and `sessionOrUser: client.session`
+
 ## Pending + resolve pattern (async result)
 
 Use this pattern when an action must wait for a result from an external process (device, worker, etc.).

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

@@ -0,0 +1,186 @@
+---
+description: Event-sourcing data flow rules — emit events for DB writes, use triggerService for cross-service writes
+globs: **/services/**/*.js
+---
+
+# LiveChange backend – event-sourcing data flow (Claude Code)
+
+Use these rules when implementing actions, triggers, and events in LiveChange services.
+
+## How data flows in LiveChange
+
+LiveChange uses an event-sourcing pattern:
+
+1. **Actions and triggers** validate input and publish events via `emit()`.
+2. **Events** (`definition.event()`) execute and perform actual database writes (`Model.create`, `Model.update`, `Model.delete`).
+3. For models with **relations** (`userItem`, `itemOf`, `propertyOf`, etc.), the relations plugin auto-generates CRUD events and triggers — use those via `triggerService()`.
+4. For **cross-service writes**, always use `triggerService()` — `foreignModel` is read-only.
+
+```
+Action/Trigger  ──emit()──▶  Event handler  ──▶  Model.create/update/delete
+       │
+       └──triggerService()──▶  Other service's trigger  ──emit()──▶  ...
+```
+
+## Rule 1: No direct Model.create/update/delete in actions or triggers
+
+Actions and triggers must **not** call `Model.create()`, `Model.update()`, or `Model.delete()` directly. Instead:
+
+- **If the model has relations** (auto-generated CRUD) → use `triggerService()` to call the relation-declared trigger (e.g. `serviceName_createModelName`, `serviceName_updateModelName`, `serviceName_setModelName`).
+- **If no relation trigger exists** → use `emit()` to publish an event, then define a `definition.event()` handler that performs the DB write.
+
+### Correct: emit an event from an action
+
+```js
+definition.action({
+  name: 'createImage',
+  properties: { /* ... */ },
+  waitForEvents: true,
+  async execute({ image, name, width, height }, { client, service }, emit) {
+    const id = image || app.generateUid()
+    // validation, business logic...
+    emit({
+      type: 'ImageCreated',
+      image: id,
+      data: { name, width, height }
+    })
+    return id
+  }
+})
+
+definition.event({
+  name: 'ImageCreated',
+  async execute({ image, data }) {
+    await Image.create({ ...data, id: image })
+  }
+})
+```
+
+### Correct: use triggerService for relation-declared triggers
+
+```js
+definition.action({
+  name: 'giveCard',
+  properties: { /* ... */ },
+  async execute({ receiverType, receiver }, { client, triggerService }, emit) {
+    // Use the auto-generated trigger from the relations plugin
+    await triggerService({
+      service: definition.name,
+      type: 'businessCard_setReceivedCard',
+    }, {
+      sessionOrUserType: receiverType,
+      sessionOrUser: receiver,
+      // ...
+    })
+  }
+})
+```
+
+### Wrong: direct DB write in an action
+
+```js
+// ❌ DON'T DO THIS
+definition.action({
+  name: 'createSomething',
+  async execute({ name }, { client }, emit) {
+    const id = app.generateUid()
+    await Something.create({ id, name })  // ❌ direct write in action
+    return id
+  }
+})
+```
+
+## Rule 2: Events can only modify same-service models
+
+Event handlers (`definition.event()`) must only write to models defined in the **same service**. Never attempt to write to a `foreignModel` — it is read-only (supports `.get()`, `.indexObjectGet()`, `.indexRangeGet()` but not `.create()`, `.update()`, `.delete()`).
+
+For cross-service writes, use `triggerService()` from the action or trigger (before emitting):
+
+```js
+// ✅ Correct: cross-service write via triggerService
+definition.trigger({
+  name: 'chargeCollected_billing_TopUp',
+  async execute(props, { triggerService }, emit) {
+    // Write to another service via its declared trigger
+    await triggerService({
+      service: 'balance',
+      type: 'balance_setOrUpdateBalance',
+    }, { ownerType: 'billing_Billing', owner: props.cause })
+
+    // Write to own service via triggerService (relation-declared trigger)
+    await triggerService({
+      service: definition.name,
+      type: 'billing_updateTopUp'
+    }, { topUp: props.cause, state: 'paid' })
+  }
+})
+```
+
+```js
+// ❌ DON'T DO THIS — foreignModel is read-only
+const ExternalModel = definition.foreignModel('otherService', 'SomeModel')
+
+definition.event({
+  name: 'SomethingHappened',
+  async execute({ id }) {
+    await ExternalModel.update(id, { status: 'done' })  // ❌ will fail
+  }
+})
+```
+
+## `waitForEvents: true`
+
+When an action or trigger emits events and needs them processed before returning a result, set `waitForEvents: true`:
+
+```js
+definition.action({
+  name: 'createNotification',
+  waitForEvents: true,
+  async execute({ message }, { client }, emit) {
+    const id = app.generateUid()
+    emit({
+      type: 'created',
+      notification: id,
+      data: { message, sessionOrUserType: 'user_User', sessionOrUser: client.user }
+    })
+    return id  // event is processed before this returns
+  }
+})
+```
+
+Without `waitForEvents: true`, the action returns immediately and events are processed asynchronously.
+
+## Relation-declared triggers
+
+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
+```
+
+Common auto-generated trigger patterns:
+- `serviceName_createModelName` — create a new record
+- `serviceName_updateModelName` — update an existing record
+- `serviceName_deleteModelName` — delete a record
+- `serviceName_setModelName` — create or update (upsert)
+- `serviceName_setOrUpdateModelName` — set if not exists, update if exists
+
+Invoke them via `triggerService()`:
+
+```js
+await triggerService({
+  service: 'myService',
+  type: 'myService_createMyModel'
+}, {
+  // properties matching the model's writeable fields
+})
+```
+
+## Summary
+
+| Where | Can call Model.create/update/delete? | How to change data |
+|---|---|---|
+| `definition.event()` | ✅ Yes (same-service models only) | Direct DB writes |
+| `definition.action()` | ❌ No | `emit()` or `triggerService()` |
+| `definition.trigger()` | ❌ No | `emit()` or `triggerService()` |
+| Cross-service | ❌ Never via foreignModel | `triggerService()` to target service |

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

@@ -163,6 +163,48 @@ Notes:
 - First argument is the service name.
 - Second is the model name in that service.
 
+## Auto-added fields from relations
+
+Relations automatically add **identifier fields** and **indexes** to the model. Do **not** re-declare these in `properties`.
+
+**Naming convention:** field name = parent model name with first letter lowercased (`Device` → `device`, `CostInvoice` → `costInvoice`).
+
+| Relation | Field(s) auto-added | Index(es) auto-added |
+|---|---|---|
+| `itemOf: { what: Device }` | `device` | `byDevice` |
+| `propertyOf: { what: Device }` | `device` | `byDevice` |
+| `userItem` | `user` | `byUser` |
+| `userProperty` | `user` | `byUser` |
+| `sessionOrUserProperty` | `sessionOrUserType`, `sessionOrUser` | `bySessionOrUser` (hash) |
+| `sessionOrUserProperty: { extendedWith: ['object'] }` | + `objectType`, `object` | composite indexes |
+| `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`).
+
+```js
+// ✅ Correct — only define YOUR fields
+definition.model({
+  name: 'Connection',
+  properties: {
+    status: { type: String }  // 'device' is NOT here — auto-added by itemOf
+  },
+  itemOf: { what: Device }   // adds 'device' field + 'byDevice' index
+})
+
+// ❌ Wrong — redundant field
+definition.model({
+  name: 'Connection',
+  properties: {
+    device: { type: String },  // ❌ already added by itemOf
+    status: { type: String }
+  },
+  itemOf: { what: Device }
+})
+```
+
+Use `node server/start.js describe --service myService --model MyModel --output yaml` to see all fields including auto-added ones.
+
 ## Indexes
 
 - Declare indexes explicitly when you frequently query by a field or field combination.
@@ -186,3 +228,33 @@ In other services, the same index may be visible with a prefixed name such as `m
 - Always set `readAccessControl` and `writeAccessControl` on relations (`userItem`, `itemOf`, `propertyOf`).
 - Treat access control as part of the model definition, not an afterthought.
 
+## `entity` models – granting access on creation
+
+Models with `entity` and `writeAccessControl` / `readAccessControl` check roles on every CRUD operation, but do **not** auto-grant roles to the creator. You must add a change trigger to grant the creator `'owner'` (or other roles) after creation:
+
+```js
+definition.trigger({
+  name: 'changeMyService_MyModel',
+  properties: {
+    object: { type: MyModel, validation: ['nonEmpty'] },
+    data: { type: Object },
+    oldData: { type: Object }
+  },
+  async execute({ object, data, oldData }, { client, triggerService }) {
+    if (!data || oldData) return   // only on create
+    if (!client?.user) return
+
+    await triggerService({ service: 'accessControl', type: 'accessControl_setAccess' }, {
+      objectType: 'myService_MyModel',
+      object,
+      roles: ['owner'],
+      sessionOrUserType: 'user_User',
+      sessionOrUser: client.user,
+      lastUpdate: new Date()
+    })
+  }
+})
+```
+
+Without this trigger, the creator cannot read or modify their own object. The `objectType` format is `serviceName_ModelName`.
+

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

@@ -65,6 +65,32 @@ 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.
 
+## 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.
+
+Three approaches (pick whichever fits the layout):
+
+1. **AutoField without slot** — auto-picks input and shows errors. Simplest, use by default.
+2. **AutoField with slot** — wrap a custom input inside `<AutoField>`. Still renders label + error automatically.
+3. **Manual `Message`** — add `<Message v-if="editor.propertiesErrors?.field" severity="error" variant="simple" size="small">` below the input. Use when AutoField wrapper doesn't fit.
+
+Always pass `:error="editor.propertiesErrors?.fieldName"` (or `formData.propertiesErrors?.fieldName` for `actionData`).
+
+## Form element requirement
+
+Forms using `editorData` or `actionData` with `EditorButtons` or `ActionButtons` **must** be wrapped in a `<form>` element with submit/reset handlers:
+
+```vue
+<!-- editorData -->
+<form @submit.prevent="editor.save()" @reset.prevent="editor.reset()">
+
+<!-- actionData -->
+<form @submit.prevent="formData.submit()" @reset.prevent="formData.reset()">
+```
+
+`EditorButtons` and `ActionButtons` use `type="submit"` / `type="reset"` on their internal buttons. Without a `<form>` parent, these buttons do nothing.
+
 ### `api.command`
 
 ```js

package/.claude/settings.json

@@ -0,0 +1,32 @@
+{
+  "permissions": {
+    "allow": [
+      "Bash(ls -d /home/m8/IdeaProjects/live-change/*/.claude/skills/)",
+      "Bash(ls -d /home/m8/IdeaProjects/live-change/*/.cursor/skills/)",
+      "Bash(node -e \"const p = require.resolve\\(''''@live-change/vue3-components''''\\); console.log\\(p\\)\")",
+      "Bash(find /home/m8/IdeaProjects/live-change/live-change-stack -path *vue3-components* -name *.js)",
+      "Read(//home/m8/IdeaProjects/**)",
+      "Bash(find /home/m8/IdeaProjects/live-change -name \"*.vue\" -type f ! -path \"*/node_modules/*\" ! -path \"*/.history/*\" -exec grep -l \"AutoField\" {})",
+      "Bash(cp /home/m8/IdeaProjects/live-change/.claude/skills/live-change-frontend-editor-form/SKILL.md /home/m8/IdeaProjects/live-change/.cursor/skills/live-change-frontend-editor-form.md)",
+      "Bash(cp /home/m8/IdeaProjects/live-change/.claude/skills/live-change-frontend-action-form/SKILL.md /home/m8/IdeaProjects/live-change/.cursor/skills/live-change-frontend-action-form.md)",
+      "Bash(cp /home/m8/IdeaProjects/live-change/.claude/rules/live-change-frontend-vue-primevue.md /home/m8/IdeaProjects/live-change/auto-firma/.claude/rules/live-change-frontend-vue-primevue.md)",
+      "Bash(cp /home/m8/IdeaProjects/live-change/.claude/rules/live-change-frontend-vue-primevue.md /home/m8/IdeaProjects/live-change/automation/.claude/rules/live-change-frontend-vue-primevue.md)",
+      "Bash(cp /home/m8/IdeaProjects/live-change/.claude/rules/live-change-frontend-vue-primevue.md /home/m8/IdeaProjects/live-change/live-change-stack/frontend/frontend-template/.claude/rules/live-change-frontend-vue-primevue.md)",
+      "Bash(cp /home/m8/IdeaProjects/live-change/.claude/skills/live-change-design-models-relations/SKILL.md /home/m8/IdeaProjects/live-change/.cursor/skills/live-change-design-models-relations.md)",
+      "Bash(cp /home/m8/IdeaProjects/live-change/.claude/skills/live-change-design-actions-views-triggers/SKILL.md /home/m8/IdeaProjects/live-change/.cursor/skills/live-change-design-actions-views-triggers.md)",
+      "Bash(cp /home/m8/IdeaProjects/live-change/.claude/rules/live-change-backend-actions-views-triggers.md /home/m8/IdeaProjects/live-change/auto-firma/.claude/rules/live-change-backend-actions-views-triggers.md)",
+      "Bash(cp /home/m8/IdeaProjects/live-change/.claude/rules/live-change-backend-models-and-relations.md /home/m8/IdeaProjects/live-change/auto-firma/.claude/rules/live-change-backend-models-and-relations.md)",
+      "Bash(cp /home/m8/IdeaProjects/live-change/.claude/rules/live-change-backend-actions-views-triggers.md /home/m8/IdeaProjects/live-change/automation/.claude/rules/live-change-backend-actions-views-triggers.md)",
+      "Bash(cp /home/m8/IdeaProjects/live-change/.claude/rules/live-change-backend-models-and-relations.md /home/m8/IdeaProjects/live-change/automation/.claude/rules/live-change-backend-models-and-relations.md)",
+      "Bash(cp /home/m8/IdeaProjects/live-change/.claude/rules/live-change-backend-event-sourcing.md /home/m8/IdeaProjects/live-change/auto-firma/.claude/rules/live-change-backend-event-sourcing.md)",
+      "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)"
+    ],
+    "additionalDirectories": [
+      "/home/m8/IdeaProjects/live-change/.claude/skills/create-skills-and-rules",
+      "/home/m8/IdeaProjects/live-change/.claude/rules"
+    ]
+  }
+}

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

@@ -0,0 +1,248 @@
+---
+name: create-skills-and-rules
+description: Create or update Claude Code skills and Cursor rules/skills with proper format and frontmatter, and configure OpenCode
+---
+
+# Skill: create-skills-and-rules
+
+Use this skill when you need to **create or update skills and rules** for Claude Code (`.claude/`), Cursor (`.cursor/`), and OpenCode (`opencode.json`).
+
+## Directory structure
+
+```
+.claude/
+  rules/     *.md              – always-loaded project instructions
+  skills/    <name>/SKILL.md   – step-by-step guides, invocable or auto-matched by description
+.cursor/
+  rules/     *.mdc             – Cursor rules with description/globs/alwaysApply frontmatter
+  skills/    *.md              – flat files, same content as .claude/skills/ (Cursor reads them as reference)
+opencode.json                  – OpenCode config: instructions array points to .claude/rules/*.md
+```
+
+**Cross-tool compatibility:**
+- **Claude Code** reads both flat files and directory-based skills from `.claude/skills/`
+- **OpenCode** reads **only** directory-based skills (`.claude/skills/<name>/SKILL.md`) — flat files are ignored
+- **Cursor** reads flat files from `.cursor/skills/*.md` as reference documents
+- Rules are loaded by OpenCode via `opencode.json` `instructions` array
+
+**Standard format:** Always use directory-based skills (`<name>/SKILL.md`) for compatibility with all tools.
+
+## Step 1 – Decide: rule or skill
+
+| Type | Purpose | When loaded |
+|---|---|---|
+| **Rule** | Constraints, conventions, best practices | Automatically, based on `globs` or `alwaysApply` |
+| **Skill** | Step-by-step implementation guide | When description matches task, or invoked via `/skill-name` |
+
+Rules say **what to do / not do**. Skills say **how to do it step by step**.
+
+## Step 2 – Create a skill (`.claude/skills/<name>/SKILL.md`)
+
+### Create the directory and file
+
+```bash
+mkdir -p .claude/skills/my-skill-name
+# then create .claude/skills/my-skill-name/SKILL.md
+```
+
+### Required frontmatter
+
+```yaml
+---
+name: my-skill-name
+description: Short description of what this skill does and when to use it
+---
+```
+
+| Field | Required by | Description |
+|---|---|---|
+| `name` | OpenCode, Claude Code | Must match directory name exactly. Lowercase, hyphens only, regex `^[a-z0-9]+(-[a-z0-9]+)*$`, max 64 chars |
+| `description` | All tools | When to use — Claude/OpenCode match this to decide auto-invocation |
+
+### Optional frontmatter fields (Claude Code only)
+
+```yaml
+---
+name: my-skill
+description: What this skill does
+user-invocable: true
+disable-model-invocation: false
+allowed-tools: Read, Grep, Bash
+context: fork
+agent: Explore
+argument-hint: [filename]
+model: sonnet
+---
+```
+
+| Field | Default | Description |
+|---|---|---|
+| `user-invocable` | `true` | Show in `/` menu |
+| `disable-model-invocation` | `false` | Prevent auto-loading by Claude |
+| `allowed-tools` | – | Tools allowed without asking (e.g. `Read, Grep, Bash`) |
+| `context` | – | Set to `fork` to run in isolated subagent |
+| `agent` | – | Subagent type when `context: fork` (`Explore`, `Plan`, etc.) |
+| `argument-hint` | – | Hint for autocomplete (e.g. `[issue-number]`) |
+| `model` | inherited | Model override (`sonnet`, `opus`, `haiku`) |
+
+OpenCode ignores unknown frontmatter fields, so these are safe to include.
+
+### Dynamic substitutions in skill content
+
+- `$ARGUMENTS` – all arguments passed when invoking
+- `$ARGUMENTS[0]`, `$1` – specific argument by index
+- `${CLAUDE_SESSION_ID}` – current session ID
+- `${CLAUDE_SKILL_DIR}` – directory containing SKILL.md
+
+### Body structure
+
+```markdown
+---
+name: my-skill-name
+description: Build X with Y and Z
+---
+
+# Skill: my-skill-name
+
+Use this skill when you build **X** using Y and Z.
+
+## When to use
+
+- Bullet list of scenarios
+
+## Step 1 – First step
+
+Explanation + code example.
+
+## Step 2 – Second step
+
+Explanation + code example.
+```
+
+Keep skills under 500 lines. Use clear step numbering. Include real code examples.
+
+## Step 3 – Create a Claude Code rule (`.claude/rules/<name>.md`)
+
+### Frontmatter
+
+```yaml
+---
+description: Short description of this rule's purpose
+globs: **/front/src/**/*.{vue,js,ts}
+---
+```
+
+| Field | Description |
+|---|---|
+| `description` | What this rule covers (used for matching) |
+| `globs` | File patterns that trigger this rule (e.g. `**/*.js`, `**/services/**/*.js`) |
+
+### Body structure
+
+```markdown
+---
+description: Rules for X development
+globs: **/*.js
+---
+
+# Title
+
+## Section 1
+
+- Rule bullet points
+- Code examples
+
+## Section 2
+
+- More rules
+```
+
+Rules are concise. Lead with the constraint, then show a code example.
+
+## Step 4 – Create Cursor rule (`.cursor/rules/<name>.mdc`)
+
+Same content as the Claude rule, but with Cursor-specific frontmatter:
+
+```yaml
+---
+description: Short description of this rule's purpose
+globs: **/front/src/**/*.{vue,js,ts}
+alwaysApply: false
+---
+```
+
+| Field | Default | Description |
+|---|---|---|
+| `description` | – | What the rule does; Cursor uses this to decide when to apply |
+| `globs` | – | Comma-separated file patterns (e.g. `**/*.tsx, src/**/*.js`) |
+| `alwaysApply` | `false` | If `true`, applies to every session regardless of context |
+
+**Notes:**
+- 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
+
+## Step 5 – Register rules in OpenCode (`opencode.json`)
+
+OpenCode reads `.claude/skills/<name>/SKILL.md` natively for skills (no extra step needed). But rules must be registered in `opencode.json`:
+
+```json
+{
+  "$schema": "https://opencode.ai/config.json",
+  "instructions": [
+    ".claude/rules/live-change-backend-architecture.md",
+    ".claude/rules/live-change-frontend-vue-primevue.md"
+  ]
+}
+```
+
+When you **create a new rule**, add its path to the `instructions` array in `opencode.json`.
+
+When you **create a new skill**, no `opencode.json` change is needed — OpenCode discovers skills from `.claude/skills/<name>/SKILL.md` automatically.
+
+**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`)
+
+Copy the skill content to `.cursor/skills/` as a **flat file** (Cursor reads flat `.md` files as reference):
+
+```bash
+cp .claude/skills/my-skill-name/SKILL.md .cursor/skills/my-skill-name.md
+```
+
+The content is the same (including `name` in frontmatter). Cursor ignores unknown frontmatter fields.
+
+## Step 7 – Mirror to sub-projects
+
+If the project has sub-projects with their own `.claude/` and `.cursor/` directories, copy the files there too:
+
+```bash
+for dir in automation auto-firma; do
+  # Skills: directory format for .claude, flat for .cursor
+  mkdir -p "$dir/.claude/skills/my-skill-name"
+  cp .claude/skills/my-skill-name/SKILL.md "$dir/.claude/skills/my-skill-name/SKILL.md"
+  cp .claude/skills/my-skill-name/SKILL.md "$dir/.cursor/skills/my-skill-name.md"
+
+  # Rules
+  cp .claude/rules/my-rule.md "$dir/.claude/rules/"
+  cp .cursor/rules/my-rule.mdc "$dir/.cursor/rules/"
+done
+```
+
+## Naming conventions
+
+- Use lowercase with hyphens: `live-change-frontend-editor-form`
+- Must match regex `^[a-z0-9]+(-[a-z0-9]+)*$` (OpenCode requirement)
+- Prefix with domain: `live-change-frontend-*`, `live-change-backend-*`
+- Skills describe actions: `*-editor-form`, `*-range-list`, `*-action-buttons`
+- Rules describe scope: `*-vue-primevue`, `*-models-and-relations`
+
+## Checklist
+
+- [ ] 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)
+- [ ] `opencode.json` `instructions` array updated (if new rule)
+- [ ] Sub-projects updated (automation, auto-firma)