@stechquick/studio-cli 4.1.0-6 → 4.1.1-0

package/dist/studio-cli/src/.ai-kit/AGENT_GUIDE.md

@@ -1,107 +0,0 @@
-# Agent Operating Guide — dispatcher
-
-You are an AI coding agent working on **Quick / Plateau Studio `.qjson` files** on a user's local filesystem. The user exported these files from Studio (the web IDE), wants you to create or edit pages, and will sync them back to Studio. This kit is your complete, source-of-truth knowledge of Quick. Follow this guide.
-
-## Building an app from a brief — do this first when the task is a product brief
-
-When the task is a **product brief** ("build an app"), not "edit this page," a Studio app is many files (pages, setting files, modules), not one page — see [knowledge/13-application.md](knowledge/13-application.md). Before authoring anything:
-
-1. **Decompose the brief into screens.** List each screen/flow (list, detail, form…); each distinct screen is its own page. A genuinely single-screen app is fine — but most briefs have more than one, and the app-level behaviors below apply either way.
-2. **Repeated UI → block components.** Any visual unit that appears on more than one screen (a list row that reappears on a detail, a card reused across screens) is authored **once** as its own page and embedded as a block component — see [knowledge/05-components.md](knowledge/05-components.md#block-component-embedding-another-qjson-page). Never copy the markup into each screen.
-3. **The behaviors the brief states are requirements, not decoration — and each is a setting file, not inline page code.** These are **not optional**: create each with `id: new` + `settingKey` and assign it in App Settings — see [knowledge/appSettings/appSettings.md](knowledge/appSettings/appSettings.md).
-
-   | If the brief implies… | You must create/use |
-   |---|---|
-   | a wait/loading indicator during any async or deliberate delay | **loading** setting file → `quick.loading.show()`/`hide()` |
-   | success, error, warning, or confirmation messages | **alert** setting file → `quick.Quick.alert({…})` |
-   | more than one language / a language switch | **global localization** setting file + page `LR` keys |
-   | data or logic that several screens or events share | **pipeline** (handlers with `EV: true`) |
-
-4. Only then author each page via the per-page workflow below (Step 0 onward), one page at a time.
-5. **Push cross-referenced pages together — never a page that links to one you haven't created yet.** A `<<qjson:…>>` link resolves to the target page's id only if that target already exists in Studio at push time. `studio push` sends the whole workspace in one atomic pass, so finish authoring **every** page that links to another **before** your first push. If you push a referrer while its target is still missing, the link silently stays an unresolved path in Studio (a warning is logged but the push still succeeds) and is **not** repaired when you create the target later — you would have to re-push the referrer with a body change to fix it. So: author all mutually-linked pages first, push once. If you add a linked page after an earlier push, create it, then re-push its referrer(s).
-
-If the brief implies one of the behaviors in step 3 and your delivered app lacks it — no loading during a stated wait, no alert for a stated warning, one language when it asked for two — the app is **unfinished**, even if it compiles and renders clean.
-
-## Step 0 — determine the style system, then follow your track guide
-
-Quick has **two style systems**, and they are not interchangeable on a page. Decide which one the target page is on **before** you style, lay out, or validate — then follow that track's guide and doc set for the rest of the task.
-
-**Read the target's root-level `opt.V`:**
-
-| Condition | Track | Guide to follow |
-|-----------|-------|-----------------|
-| **Creating a new page** | **`S` (new)** — new pages are always created at the current `V` | [AGENT_GUIDE-s.md](AGENT_GUIDE-s.md) |
-| **`opt.V >= 2.0`** | **`S` (new)** — the `S` object renders; author design in `S` | [AGENT_GUIDE-s.md](AGENT_GUIDE-s.md) |
-| **`opt.V` missing OR `< 2.0`** | **legacy (`cssClass`)** — `S` does NOT render; author `O.layout` + CSS classes | [AGENT_GUIDE-legacy.md](AGENT_GUIDE-legacy.md) |
-
-There is no in-between: a page is either fully `S` or fully legacy. **Do not mix mechanisms** (never introduce `S` on a legacy page — it silently won't render; never author `O.layout` on an `S` page). **The presence of an `S` object is the ground truth for which system a page is on**, and `opt.V` should agree with it (`>= 2.0` ⇔ uses `S`). If the two disagree — `opt.V >= 2.0` but the nodes carry `O.layout`, or `opt.V` missing/`< 2.0` but the nodes carry an `S` object — the page is mid-migration or mis-tagged: go by whether an `S` object is actually present, and flag the mismatch to the user.
-
-Your track guide lists the exact doc set to use (schema, structure, layout, styling, catalog, skeletons, validation, examples, specialist subagent) — **open only your track's docs plus the shared docs below.**
-
-## What a `.qjson` is (one paragraph)
-A JS module exporting `pjson = { ... }`. You author `pJson` (a tree of component nodes) and `lrids` (localization) — so an **AI-authored file carries only `{ pJson, lrids, opt }`**. The editor/compiler generates the compiled twins `cJson`/`clrids`; **omit them entirely from files you author** — never write them into a new file, and **strip them if present** when editing a downloaded file (Studio regenerates them on import). Each node is `{ T, P, E, C, O, _Editor }` plus styling fields — `S`/`SA`/`SC` on `S`-system pages, `O.layout` on legacy pages. Full schema: `S` → [reference/qjson-schema.md](reference/qjson-schema.md); legacy → [reference/qjson-schema-legacy.md](reference/qjson-schema-legacy.md).
-
-## Where to look — shared docs (both tracks)
-These carry no style-era content; use them regardless of track:
-- **Task-oriented how-to (shared topics)** → [knowledge/01-properties.md](knowledge/01-properties.md), [02-events-and-scripting.md](knowledge/02-events-and-scripting.md), [05-components.md](knowledge/05-components.md), [06-services.md](knowledge/06-services.md), [07-localization.md](knowledge/07-localization.md), [08-dynamic-components.md](knowledge/08-dynamic-components.md), [11-cli-bridge.md](knowledge/11-cli-bridge.md), [12-render-check.md](knowledge/12-render-check.md) (see your pushed page rendered + its console errors, via Playwright MCP).
-- **App-wide configuration — App Settings and the setting files it points at** → [knowledge/appSettings/appSettings.md](knowledge/appSettings/appSettings.md). Read it when a page's behavior comes from the app rather than the page: the **pipeline** wrapping every service call, the **alert** and **loading** screens your pages trigger, the **theme** and **style file** behind their look, **global localization** behind `LR` keys. It also explains why an unassigned setting **blocks Export and Publish** — a failure no amount of correct page authoring fixes.
-- **Exact API of `quick.*`** (store, alert, request, navigation, validation, dates…) → [reference/quick-api.md](reference/quick-api.md).
-- **Events deep dive** → [reference/events-system.md](reference/events-system.md); **events specialist** → `quick-events`.
-- **Which `T` exists + registry** → [reference/component-index.json](reference/component-index.json) (machine-readable; era-agnostic).
-- **Valid props/events for a component (so you don't invent them)** → [reference/component-contracts.json](reference/component-contracts.json) (per `T`: each prop's `pType` prop/class/text/attr, value `type`, allowed `options` (enum), `default`; and `events` as `{ name, params?: [{name,type}] }`).
-- **Valid Style-tab (`S`) params for a component** → [reference/component-styles.json](reference/component-styles.json) (per `T`: supported style param → value `type` + editor `default`).
-
-> **Do NOT read these two big files whole.** `component-contracts.json` (~82k tokens) and `component-styles.json` (~37k tokens) are keyed per `T`, one component block each. Reading either whole wastes context and the file tools cap at 2000 lines — so a whole-file read silently truncates and you'd miss most components without knowing. Instead, **for each component you place, grep its block and read only that slice**: `grep -n '"VIcon":' reference/component-contracts.json` → a line number → `Read` that offset for ~30–60 lines. Batch the lookups a section needs before writing it.
-
-> **Why read these first (the core principle):** these dictionaries are *generation inputs*. Pick the prop/event/param/style from the contract **before** you write — then you never invent something the editor rejects. The compiler is the backstop for the rare miss; it is **not** the way to discover the valid set (a raw error says *what's wrong*, not *what's right*). Look it up up front.
-
-- **Component-specific deep detail / anything the distilled docs don't cover** → the full official documentation in [docs/](docs/) (index: [docs/README.md](docs/README.md)).
-- **Building a page *from a Figma design*** → the `figma-to-qjson` skill ([skills/figma-to-qjson/SKILL.md](skills/figma-to-qjson/SKILL.md)).
-
-**Everything else — the schema, structure, layout, styling how-to, component catalog, page skeletons, validation checklist, examples folder, and the styling/layout specialist subagent — is era-specific and listed in your track guide** ([AGENT_GUIDE-s.md](AGENT_GUIDE-s.md) / [AGENT_GUIDE-legacy.md](AGENT_GUIDE-legacy.md)).
-
-> **Subagents only become real, invokable subagents if also present in `.claude/agents/`** (Claude Code auto-discovers project subagents from that folder, not from `.ai-kit/agents/`). Check `.claude/agents/` first; if the persona is there, call it via the Agent tool (`subagent_type: "quick-styling"`, etc.). If missing, copy it there from `.ai-kit/agents/` (the source of truth; keep both in sync) before relying on delegation.
-
-## Workflow for every task
-1. **Read the target + neighbors.** Open the `.qjson` you'll edit and 1–2 sibling pages in the same folder. The kit gives you the *rules*; sibling pages give you *project conventions* (ID style, service URLs, `QJsonPath` of any service component, navigation `<<qjson:id>>` references). Mirror them.
-2. **Classify the work** — static layout / service / table / dialog-form / chart / navigation / localization / dynamic component. Read the matching shared `knowledge/` file(s).
-3. **Determine the style system (Step 0) and open your track guide.** Everything about *how* you build the tree's design, style, lay out, and validate lives there — follow it.
-4. **Compile** before finishing: `studio buildQjson <file>` (bundled Quick compiler; see tools/README.md). Fix all errors. (Full pre-sync checklist is in your track's `10-validation…` doc.)
-5. **Push, then render-check.** If `.studio/server.json` exists (the CLI bridge is running), run `studio push` yourself once the compile is clean — that places the page in the user's open Studio session (as unsaved work; nothing is saved or published). Then, when the `playwright` MCP server is available, open the page in the authenticated test browser and fix what the render and console show — see [knowledge/12-render-check.md](knowledge/12-render-check.md). Compiling clean does not prove the page runs clean.
-6. **Report**: changed file(s), what changed (including styling), compile result, render-check result (or that the bridge/browser wasn't available — never skip it silently), any project assumption you made.
-
-## Non-negotiable rules — shared (both tracks)
-These apply on every page regardless of era. (Style/layout-mechanism rules are in your track guide.)
-1. **Omit `cJson`/`clrids` entirely from AI-authored files.** Author `pJson`/`lrids` only; never write the compiled twins into a new file, and **strip them if present** when editing a downloaded one. Studio regenerates them on import.
-2. Every node: valid `T` (check the index), unique `P.ID.H`, unique `_Editor.eID`. (eID need not equal ID.) Don't invent props **or events** — use the props/events listed for that `T` in [reference/component-contracts.json](reference/component-contracts.json), with the PType it specifies and the event `params` it gives.
-3. Strings in prop `H` are single-quoted (`"'primary'"`); booleans/numbers/expressions are bare; QScript object literals use `=` (`{text='A', value=1}`).
-4. `QLabel.text` → PType `"prop"`. `VIcon` icon name → `text` with PType `"text"` — `H` is still a QScript string, so single-quote it: `"H": "'mdi-home'"` (never bare `"mdi-home"`).
-5. Events: never native `return` (use `quick.return`); close object literals with `};`; no browser globals (`window`/`document`/`console`/`setTimeout`) — use `quick.*`. **Event handlers are always TypeScript — set `"HL":"TS"` on every handler.** (Property/binding expressions are the ones that default to `QS`.)
-6. Props use bare `LR('key')`; events use `quick.LR('key')`.
-7. **Containment** (editor-enforced, era-agnostic): `VCol` only inside `VRow` (never at root); `VRow` holds only `VCol`; `VFooter` holds only `VContainer`; canonical wrapper `VContainer > VRow > VCol > content`.
-8. Charts: only `Bar`/`Line`/`Doughnut` (no `Pie`); no `visible` prop on charts.
-9. `quick.Quick.alert({...})` always includes `actionButtons`.
-10. `VBtn` label is a child `QLabel`/`VIcon`/`VImg`, not a text prop.
-
-## Things the previous-generation community docs got wrong (now corrected here)
-- **Props *can* contain `if/else` conditionals** (QScript returns the last value). They are not forbidden.
-- **`VIcon` icon uses PType `"text"`**, not `"prop"` — and `H` is still a single-quoted QScript string: `"H": "'mdi-home'"`, never `"H": "mdi-home"`.
-- **`_Editor.eID` need not equal `P.ID.H`** (equal when auto-generated; differs after a rename).
-- **Property/binding default language is `QS`** (not TS) — but **event handlers are always authored as `TS`** (`"HL":"TS"` on every handler). The old docs' mistake was calling TS the default for *properties*; it is not. Handlers, however, are TS-only.
-- **`quick.store` prefixes** are Page/Bag(`#`)/Global(`$`)/Shared(`&`) — for cross-session persistence use `quick.permanentStore`.
-- **`quick.Quick.validation`** has `required/minLength/maxLength/email/iban/regex/tckn/vkn` (no `phone` rule — use input `format` + `regex`).
-- **Styling is the Style tab, not just CSS utility classes.** How per-component design serializes depends on the page's era — see your track guide. The previous community docs treated styling as CSS-utility-classes only; that was incomplete.
-
-## Studio sync-back
-The user round-trips files Studio → local → Studio. So:
-- **Never rename** downloaded files or change embedded page ids — Studio matches them back by name/id.
-
-- **If you do rename/move/delete a page that others reference**, update every referrer's `<<qjson:path>>` in the same change (local links are path-based, so they go stale) — see [knowledge/10-validation-and-sync.md](knowledge/10-validation-and-sync.md#renaming--moving--deleting-a-referenced-page--update-the-referrers-yourself).
-- Omit `cJson`/`clrids` so Studio recompiles cleanly on import (it regenerates the twins whether they're absent or empty); never paste compiled (`╬…╩╩`) content. Strip them from any downloaded file you edit.
-
-- Validate the whole folder before syncing if you touched multiple files.
-- A file pulled from Studio may be **readonly** (`0444`) if it is locked/checked-out by someone else in Studio. To edit it locally, run `studio startWorking <file>` — do not `chmod` it manually.
-- **If you added a page into another page as a block component**, the embedded page must be converted in Studio: run `studio convertToBlock <embedded-file>` unless its frontmatter already has `blockComponent: true`. For a newly created page, run it **after** `studio push`. Details: [knowledge/05-components.md](knowledge/05-components.md#block-component-embedding-another-qjson-page).
-
-## When unsure
-Don't invent props/events/slots/values. Check [reference/component-index.json](reference/component-index.json) and your track's component catalog; for Vuetify components Vuetify 2 semantics apply; otherwise find a real example in a sibling page or ask the user. If a `T` isn't in the index, it's probably wrong (or the index needs updating from a newer runtime).

package/dist/studio-cli/src/.ai-kit/CLAUDE.md

@@ -1,14 +0,0 @@
-# CLAUDE.md — Quick QJSON workspace
-
-> Template: copy to the **root of the downloaded qjson folder** (next to `.ai-kit/`). Claude Code auto-reads `CLAUDE.md`. (Same content as `AGENTS.md`; keep whichever your agent reads, or both.)
-
-This workspace contains **Quick / Plateau Studio `.qjson`** UI pages. To create or edit them, **first read [`.ai-kit/AGENT_GUIDE.md`](.ai-kit/AGENT_GUIDE.md)** — the operating procedure for authoring qjson correctly.
-
-- Author `pJson`/`lrids` only. **AI-authored files omit `cJson`/`clrids` entirely** — never write these compiled twins into a new file, and **strip them if present** when editing a downloaded file (Studio regenerates them on import). Authored envelope = `{ pJson, lrids, opt }`.
-- How-to: [`.ai-kit/knowledge/`](.ai-kit/knowledge/) · Exact API/schema/components: [`.ai-kit/reference/`](.ai-kit/reference/).
-- **App-wide configuration** (the pipeline, alert, loading, theme, localization and other files an app is wired to) → [`.ai-kit/knowledge/appSettings/appSettings.md`](.ai-kit/knowledge/appSettings/appSettings.md). Read it when behavior comes from the app rather than the page; an unassigned setting there blocks Export and Publish.
-- **Building an app from a brief** (not "edit this page"): decompose into screens (one page each), extract repeated UI as block components, and — **not optional** — turn every behavior the brief states into a setting file, never inline page code: a stated wait → **loading**, stated messages/warnings → **alert**, more than one language → **global localization**, data/logic shared across screens → **pipeline**. Create each with `id: new` + `settingKey`. See the "Building an app from a brief" section in [`.ai-kit/AGENT_GUIDE.md`](.ai-kit/AGENT_GUIDE.md).
-- Always compile before finishing: `studio buildQjson <file-or-folder>` (compiles with the bundled Quick compiler, reports any errors, and reports `S`/`SC` gaps as errors; it never edits the file — apply every fix yourself from `.ai-kit/reference/component-styles.json` and re-run until clean; see tools/README.md).
-- **Compiling is not the finish line — push and render-check.** If `.studio/server.json` exists (the CLI bridge is running), run `studio push` yourself after a clean compile; the pushed page lands in the user's open Studio session as unsaved work. Then, if the `playwright` MCP server is available, verify the page actually *runs*: open `http://127.0.0.1:<port>/render` (port from `.studio/server.json`) and check the rendered page + browser console — full loop in [`.ai-kit/knowledge/12-render-check.md`](.ai-kit/knowledge/12-render-check.md). When you're done, close the browser with `browser_close` — the Playwright MCP leaves it running otherwise. Report the render-check result; if the bridge or browser isn't available, say so instead of skipping silently.
-- **Two style systems:** `AGENT_GUIDE.md` (Step 0) reads the page's root-level `opt.V` and routes you to the **`S`** track (new page / `opt.V >= 2.0`) or the **legacy** track (`opt.V` missing / `< 2.0`) — each with its own guide (`AGENT_GUIDE-s.md` / `AGENT_GUIDE-legacy.md`) and doc set. Follow one track; don't mix.
-- A `quick-qjson-author` router subagent (+ per-track `quick-qjson-author-s` / `quick-qjson-author-legacy`) is available in [`.ai-kit/agents/`](.ai-kit/agents/) if you want to delegate page authoring.

package/dist/studio-cli/src/.ai-kit/README.md

@@ -1,81 +0,0 @@
-# Quick AI Kit
-
-Everything an AI coding agent needs to **create, edit, and validate Quick / Plateau Studio `.qjson` UI pages** on a local filesystem — then sync them back to Studio.
-
-This kit ships alongside the `.qjson` files a user downloads from Studio. Any agent (Claude Code, Copilot, Cursor, …) that reads these files can author correct qjson without prior Quick knowledge. It is **grounded in the actual Quick runtime source** (scripting API, qjson schema, component registry, official compiler), not reverse-engineered guesses.
-
-## Quick start (for the AI agent)
-1. Read **[AGENT_GUIDE.md](AGENT_GUIDE.md)** — your operating procedure.
-2. Use **[knowledge/](knowledge/)** to author, **[reference/](reference/)** for exact API/schema/components.
-3. Compile before finishing: `studio buildQjson <file-or-folder>` (compiles with the bundled Quick compiler and reports any errors; see tools/README.md).
-
-## Setup per agent (drop-in)
-The kit is agent-agnostic. Copy the matching entry file(s) to the **root of the downloaded qjson folder** (next to `.ai-kit/`):
-
-- **opencode** → copy [`opencode.jsonc`](opencode.jsonc) to the root as `opencode.json` (it auto-loads `AGENT_GUIDE.md` and registers the `quick-*` subagents from the kit) **and** keep [`AGENTS.md`](AGENTS.md) at the root (opencode reads it natively). Then run opencode in that folder; ask the main agent or `@quick-qjson-author` to build/edit a page.
-- **Claude Code** → keep [`CLAUDE.md`](CLAUDE.md) at the root; the `agents/*.md` work as Claude subagents.
-- **Cursor / Copilot / others** → keep [`AGENTS.md`](AGENTS.md) at the root (the emerging cross-agent standard). The knowledge/reference/tools are plain files any agent can read and run.
-
-**Activate the skill (opencode + Claude Code).** Both auto-discover [Agent Skills](https://opencode.ai/docs/skills/) only from `.claude/skills/`, `.opencode/skills/`, or `.agents/skills/` at the workspace root — there's no config path for it. Place the kit's skill at the shared `.claude/skills/` location (read by both):
-```
-cp -r .ai-kit/skills/quick-qjson .claude/skills/
-```
-The agent then sees a `quick-qjson` skill in its `skill` tool and loads the kit on demand. (Without this the kit still works via `AGENT_GUIDE.md`/`AGENTS.md` + the subagents — the skill is the native, invokable entry point.)
-
-**Optional — Figma import.** To build qjson pages *from a Figma design*, also install the add-on skill:
-```
-cp -r .ai-kit/skills/figma-to-qjson .claude/skills/
-```
-It runs the `studio figmaPull` command (part of the studio CLI) to pull a Figma selection (URL + token) into a local `.figma/` folder, then maps that design to qjson — delegating page authoring back to `quick-qjson`.
-
-Compile and validate with **`studio buildQjson <file-or-folder>`** — no build or install step; it runs the bundled compiler plus the structural and S-style checks. See [`tools/README.md`](tools/README.md).
-
-## Layout
-```
-.ai-kit/
-  README.md                  ← you are here
-  AGENT_GUIDE.md             ← dispatcher: Step-0 opt.V routing + shared workflow/rules
-  AGENT_GUIDE-s.md           ← S-track guide (new / opt.V≥2.0)
-  AGENT_GUIDE-legacy.md      ← legacy-track guide (opt.V missing / <2.0)
-  knowledge/                 ← task-oriented how-to (read what you need)
-    SHARED (both tracks):  01-properties.md  02-events-and-scripting.md  05-components.md
-                           06-services.md  07-localization.md  08-dynamic-components.md  11-cli-bridge.md
-    STYLE-SPLIT (S = base name, legacy = -legacy sibling):
-      00-qjson-structure(.md / -legacy.md)    03-layout-and-slots(.md / -legacy.md)
-      09-page-skeletons(.md / -legacy.md)     10-validation-and-sync(.md / -legacy.md)
-      04-styling.md (S)  ·  04-styling-legacy.md (legacy)
-  reference/                 ← authoritative, source-extracted ground truth
-    SHARED:  quick-api.md  events-system.md  component-index.json  component-contracts.json  component-styles.json
-    STYLE-SPLIT:
-      qjson-schema(.md / -legacy.md)          component-catalog(.md / -legacy.md)
-      styling-system.md (S)  ·  layout-system.md (legacy)
-    mapping-S-vuetify-class.md ← legacy→S migration bridge (references both eras)
-  tools/                     ← compile + validate via `studio buildQjson`
-    README.md                ← the fix-loop + reference-data notes for `studio buildQjson`
-  examples/                  ← curated example pages, split by style system (see examples/README.md)
-    style/                   ← S-system pages — reference for new / V≥2 pages
-    cssClass/                ← legacy pages — reference for V<2 edits only
-  agents/                    ← subagent definitions (Claude-style; usable as personas elsewhere)
-    quick-qjson-author.md    ← router (reads opt.V, routes to the track author)
-    quick-qjson-author-s.md  quick-qjson-author-legacy.md   ← per-track authors
-    quick-styling.md  quick-styling-legacy.md  quick-events.md   ← S styling+layout / legacy O.layout+CSS / events (shared)
-    qjson-legacy-migrator.md ← opt-in legacy→S migration (one file at a time)
-  skills/                    ← Agent Skill entry points (opencode + Claude Code)
-    quick-qjson/SKILL.md     ← invokable skill; install to .claude/skills/ (see Setup)
-    figma-to-qjson/SKILL.md  ← (add-on) build a qjson page from a Figma design; install to .claude/skills/
-  docs/                      ← the full official Quick UI documentation (deep fallback)
-    README.md                ← topic → official-doc index
-    UI-Screens/  UI-Module/  ← components, layout-design, logic, ui-settings
-```
-
-**Two style systems:** most style/layout docs exist as an `S` variant (base name) and a `-legacy` sibling. `AGENT_GUIDE.md` Step 0 reads the page's `opt.V` and routes you to one track; open only that track's docs plus the shared ones. Don't mix eras on a page.
-
-**Two-layer knowledge:** `knowledge/` + `reference/` are the distilled primary path; `docs/` is the full official documentation for deep, component-specific detail (see [docs/README.md](docs/README.md)).
-
-## Why this is the authoritative version
-Built directly from the Quick monorepo source, it corrects several long-standing mistakes in earlier community/agent docs — e.g. `VIcon` uses PType `text` (not `prop`); props *can* use `if/else`; `_Editor.eID` need not equal `P.ID.H`; the default scripting language is QScript; `quick.store` prefixes are Page/Bag/Global/Shared; only `Bar`/`Line`/`Doughnut` charts exist. See [AGENT_GUIDE.md](AGENT_GUIDE.md#things-the-previous-generation-community-docs-got-wrong-now-corrected-here).
-
-## For maintainers (the Quick team)
-- `reference/component-index.json` is the component registry the agent authors against. When the runtime adds/removes components, regenerate it from `packages/websdk/src/components/providers/*` so authoring stays current.
-- Compilation uses the official `apps/cli` compiler, bundled into studio-cli and exposed as `studio buildQjson` (deep TS/QScript diagnostics, in sync with the editor) — see [tools/README.md](tools/README.md).
-- Place a copy of `AGENTS.md` and/or `CLAUDE.md` at the root of the downloaded qjson folder (pointing at this kit) so agents auto-discover it. Templates are in this folder.

package/dist/studio-cli/src/.ai-kit/agents/qjson-legacy-migrator.md

@@ -1,308 +0,0 @@
----
-name: qjson-legacy-migrator
-description: Migrates a single Quick .qjson file from legacy O.layout/dOpt/Vuetify-props to the S-first style system. One file at a time, controlled migration with per-node decision log.
-tools: Read, Edit, Write, Bash, Grep, Glob
----
-
-You are a migration specialist for Quick / Plateau Studio `.qjson` files. Your job is to convert a single `.qjson` file from the legacy style system (`O.layout` / `dOpt` tokens / Vuetify responsive props) to the new **S-first style system**.
-
-You receive one file path. You migrate it completely, compile to verify, and report every decision you made.
-
----
-
-## Read These First (before touching the file)
-
-1. **`.ai-kit/reference/layout-system.md`** — the complete dOpt prefix grammar (`d`, `fd`, `a`, `j`, `w`, `c`, `sp`, `tt`, `tc`, `te`, `fi`) and the compiled `class` string rules. You need this to decode dOpt tokens.
-2. **`.ai-kit/reference/mapping-S-vuetify-class.md`** — the authoritative S ↔ Vuetify class token table. Use it for both dOpt-derived classes and existing `class` prop values.
-3. **`.ai-kit/knowledge/04-styling.md`** — the S-first priority flow and token-by-token class justification rule.
-
-For `component-styles.json` **do NOT read the whole file** (~37k tokens). Instead, for each component type (`T`) you encounter, run:
-```bash
-grep -n '"<T>":' .ai-kit/reference/component-styles.json
-```
-Then read only that component's block (~30–60 lines). Batch these lookups at the start.
-
----
-
-## The Three Violation Types You Must Fix
-
-### Violation A — `O.layout` / `dOpt`
-
-Legacy layout data embedded in the `O` field. Must be removed; its intent migrated to `S`.
-
-```json
-"O": {
-  "cType": "slot",
-  "layout": {
-    "dOpt": { "xs": ["d:d-flex", "fd:flex-column", "c:col-12", "a:align-center"] },
-    "class": "d-flex flex-column col-12 align-center"
-  }
-}
-```
-After migration: `"O": { "cType": "slot" }` (only `cType` remains).
-
-### Violation B — VCol responsive col props
-
-```json
-"cols": {"H": "'12'", "T": "prop"},
-"sm":   {"H": "'10'", "T": "prop"},
-"md":   {"H": "'8'",  "T": "prop"},
-"lg":   {"H": "'6'",  "T": "prop"}
-```
-These Vuetify props bypass the Style System. Remove from `P`; migrate to `S` resolution ranges.
-
-### Violation C — `class` prop with S-expressible tokens
-
-```json
-"class": {"H": "'d-flex flex-column'", "T": "class"}
-"class": {"H": "'text-center elevation-2 text-h5'", "T": "class"}
-```
-Each token must be evaluated individually. Tokens with S equivalents → move to `S`. Non-S tokens stay.
-
----
-
-## Migration Rules
-
-### Spacing Formula
-
-Vuetify spacing `N` → `N × 4px`
-`sp:pa-0` = 0px, `sp:pa-1` = 4px, `sp:pa-2` = 8px, `sp:pa-3` = 12px, `sp:pa-4` = 16px, `sp:pa-5` = 20px …
-
-### dOpt Token → S Param Table
-
-| dOpt token | S param | Component restriction |
-| --- | --- | --- |
-| `d:d-flex` | **DROP** on VCol (flexDirection implies flex). Keep as class on VRow/VCard/VContainer. | VCol only: drop |
-| `fd:flex-column` | `flexDirection: "column"` | **VCol only** |
-| `fd:flex-row` | `flexDirection: "row"` | **VCol only** |
-| `fd:flex-row-reverse` | `flexDirection: "row-reverse"` | **VCol only** |
-| `fd:flex-column-reverse` | `flexDirection: "column-reverse"` | **VCol only** |
-| `a:align-center` | `alignItems: "center"` | **VCol only** |
-| `a:align-start` | `alignItems: "flex-start"` | **VCol only** |
-| `a:align-end` | `alignItems: "flex-end"` | **VCol only** |
-| `a:align-stretch` | `alignItems: "stretch"` | **VCol only** |
-| `a:align-baseline` | `alignItems: "baseline"` | **VCol only** |
-| `j:justify-center` | `justifyContent: "center"` | **VCol only** |
-| `j:justify-start` | `justifyContent: "flex-start"` | **VCol only** |
-| `j:justify-end` | `justifyContent: "flex-end"` | **VCol only** |
-| `j:justify-space-between` | `justifyContent: "space-between"` | **VCol only** |
-| `j:justify-space-around` | `justifyContent: "space-around"` | **VCol only** |
-| `c:col-N` (N=1–12) | `col: "N"` | **VCol only** |
-| `c:col-auto` | `col: "auto"` | **VCol only** |
-| `c:d-none` | `col: "0"` | **VCol only** |
-| `sp:pa-N` | `paddingTop/Right/Bottom/Left: "N×4px"` | All components with padding S params |
-| `sp:px-N` | `paddingLeft: "N×4px"`, `paddingRight: "N×4px"` | — |
-| `sp:py-N` | `paddingTop: "N×4px"`, `paddingBottom: "N×4px"` | — |
-| `sp:pt-N` | `paddingTop: "N×4px"` | — |
-| `sp:pb-N` | `paddingBottom: "N×4px"` | — |
-| `sp:pl-N` | `paddingLeft: "N×4px"` | — |
-| `sp:pr-N` | `paddingRight: "N×4px"` | — |
-| `sp:ma-N` | `marginTop/Right/Bottom/Left: "N×4px"` | All components with margin S params |
-| `sp:mx-N` | `marginLeft: "N×4px"`, `marginRight: "N×4px"` | — |
-| `sp:my-N` | `marginTop: "N×4px"`, `marginBottom: "N×4px"` | — |
-| `sp:mt-N` | `marginTop: "N×4px"` | — |
-| `sp:mb-N` | `marginBottom: "N×4px"` | — |
-| `sp:ml-N` | `marginLeft: "N×4px"` | — |
-| `sp:mr-N` | `marginRight: "N×4px"` | — |
-| `sp:mt-nN` (negative) | `marginTop: "-N×4px"` | — |
-| `sp:mb-nN` (negative) | `marginBottom: "-N×4px"` | — |
-| `te:font-weight-bold` | `fontWeight: "700"` | — |
-| `te:font-weight-medium` | `fontWeight: "500"` | — |
-| `te:font-weight-regular` | `fontWeight: "400"` | — |
-| `te:font-weight-light` | `fontWeight: "300"` | — |
-| `te:font-italic` | `fontStyle: "italic"` | — |
-| `tc:primary--text` | `fontColor: "<primary hex>"` (use theme value or keep as class) | — |
-| `tc:white--text` | `fontColor: "#FFFFFF"` | — |
-| `tt:text-h1`…`text-h6`, `text-body-1/2`, etc. | `fontSize` + `fontWeight` + `lineHeight` per Vuetify typography scale — see mapping table | — |
-
-For `VRow`, `VCard`, `VContainer`: flex tokens (`d`, `fd`, `a`, `j`) have **no S equivalent** on those components. Convert these to the component's `P.class` prop as Web-only last resort (or remove `d:d-flex` if no flex intent is needed on those components — VRow is already a flex row by default). Spacing tokens (`sp:`) can go to `S` if the component supports margin/padding params (check component-styles.json).
-
-For **unknown/third-party components** (DxDataGrid, DxTreeList, etc.): do not convert O.layout tokens to S — leave any class content in `P.class` as Web-only and note in the decision log.
-
-### dOpt Breakpoint → S Resolution Range
-
-dOpt uses single breakpoints (`xs`, `sm`, `md`, `lg`, `xl`). S uses ranges.
-
-Rule: each dOpt breakpoint `{bp}` becomes S key `"{bp}-xl"`. Multiple breakpoints stack:
-
-```json
-// dOpt:
-{ "xs": ["fd:flex-column", "c:col-12"], "md": ["c:col-6"] }
-
-// → S:
-{ "xs-xl": { "flexDirection": "column", "col": "12" },
-  "md-xl": { "col": "6" } }
-```
-
-The `"md-xl"` range overrides only the `col` param for medium and above — `flexDirection` stays from the base `"xs-xl"`.
-
-If dOpt has only `xs` tokens and no other breakpoints → single `"xs-xl"` S key.
-
-### VCol cols/sm/md/lg/xl Props → S Ranges
-
-```json
-// Before (P props):
-"cols": {"H": "'12'", "T": "prop"},
-"sm":   {"H": "'10'", "T": "prop"},
-"md":   {"H": "'8'",  "T": "prop"}
-
-// After (S):
-"xs-xl": { "col": "12" },
-"sm-xl": { "col": "10" },
-"md-xl": { "col": "8" }
-```
-
-Remove `cols`, `sm`, `md`, `lg`, `xl` from `P` after converting. If both O.layout `c:col-N` and `cols` prop exist on the same VCol, prefer the O.layout value (more explicit) and drop the prop.
-
-### class Prop Token Migration
-
-For each token in a `class` prop string:
-1. Check `.ai-kit/reference/mapping-S-vuetify-class.md` for an S equivalent.
-2. Check component-styles.json to confirm the component supports that S param.
-3. **Both conditions true** → write S param, remove token from class string.
-4. **S equivalent exists but component doesn't support it** → keep token in class (Web-only last resort).
-5. **No S equivalent** → keep token in class.
-6. If the class string becomes empty after removing tokens → delete the `class` prop entirely.
-
-### Version Stamp (`opt.V`)
-
-A migrated file must declare the S-first style-system version. At the **top level** of the object (sibling of `pJson`/`lrids`/`opt`), set:
-
-```json
-"opt": { "V": 2.5 }
-```
-
-- If `opt` is absent, add it.
-- If `opt.V` is present but lower than `2.5` (e.g. legacy `2.1`/`2.2`), bump it to `2.5`.
-- Never lower an existing higher value.
-
-This is what tells Studio the page uses the new style system — a migrated file left at a stale `opt.V` is treated as legacy and the `S` params won't render.
-
----
-
-## Hard Rules (Non-Negotiable)
-
-1. **Remove `cJson` and `clrids` entirely** — strip them from the source file and never re-emit them; only edit `pJson` and `lrids`. The migrated file must come out without the compiled twins (Studio/the compiler regenerates them on import).
-2. **Never touch `O.cType`** — only remove `O.layout` from O. Keep `cType`, `dynProps`, and other O fields.
-3. **Deduplicate spacing tokens** — if dOpt has `sp:pt-12` twice, use `"48px"` once.
-4. **If both O.layout and S exist on the same node** — merge: existing S values take priority; dOpt-derived values fill in only where S doesn't already have that param.
-5. **Delete `O.compDomClasses`** if present — it's an editor-managed field that will be regenerated; it's safe to remove.
-6. **`d:d-flex` on VCol with no `fd:` token** — the component is a flex container by default (VCol is always flex). Drop the `d:d-flex` token and note in log: "d:d-flex dropped on VCol — VCol is always flex."
-7. **`d:d-flex` on non-VCol components** — convert to `class: 'd-flex'` (Web-only) unless VRow (VRow is already `display:flex` by browser default + Vuetify — drop it).
-8. **Don't invent S params** — only write S params that exist in component-styles.json for that component. If you're unsure, grep the component block first.
-9. **Compile loop** — always run `studio buildQjson <file>` after writing. If errors: read the error, fix pJson, recompile. Deliver only when compile is clean.
-10. **Style-validate loop** — the raw compiler silently ignores bad styling (a wrong `S` param or a Vuetify styling prop compiles "clean" but renders nothing). `studio buildQjson` now runs a deterministic S-first style check automatically as part of its output — it activates once the page is on the S track (`opt.V >= 2.0` or an `S` object is present), so your **post-migration** `buildQjson` run reports every style violation; drive it to **0 error/warn**. Apply the suggested fixes in order: contract prop → `S` equivalent → Vuetify class only as last resort. When a fix needs a value (e.g. a theme color → hex), ask/confirm the value rather than inventing it.
-
----
-
-## Workflow
-
-**Step 1 — Read reference files**
-
-Read layout-system.md, mapping-S-vuetify-class.md, and knowledge/04-styling.md.
-
-**Step 2 — Read the target file**
-
-Read the `.qjson` file. Identify all unique component types (`T` values) in pJson.
-
-**Step 3 — Batch component-styles.json lookups**
-
-For each unique `T`, grep component-styles.json and read its block. Build a map:
-```
-VCol → supports: flexDirection, alignItems, justifyContent, col, padding*, margin*
-VRow → supports: padding*, margin* (no flex S params)
-VCard → supports: padding*, margin*, backgroundColor, border*, boxShadow, ...
-...
-```
-
-**Step 4 — Scan pJson for violations**
-
-Walk every node in pJson. Note which nodes have:
-- Violation A: `O.layout` present
-- Violation B: VCol with `cols`/`sm`/`md`/`lg`/`xl` in P
-- Violation C: `class` prop with S-expressible tokens
-
-**Step 5 — Apply migrations node by node**
-
-For each flagged node:
-- Apply A → B → C in order (A first because it may add S params that B/C then merge into)
-- Build the updated node JSON
-- Keep a decision log entry per node
-
-**Step 6 — Write the updated file**
-
-Write pJson with all migrations applied. **Omit `cJson`/`clrids` entirely** (strip them if the source file has them — don't leave them empty either). Set the top-level `opt.V` to `2.5` (add `"opt": { "V": 2.5 }` if absent; bump it if lower).
-
-**Step 7 — Compile**
-
-```bash
-studio buildQjson <file.qjson>
-```
-
-**Step 8 — Fix errors, recompile**
-
-Read compiler output. Fix any issues in pJson. Recompile until clean (0 errors).
-
-**Step 9 — Report**
-
-Output a summary:
-```
-File: <filename>
-Nodes processed: N
-  - O.layout removed: N nodes
-  - VCol col props converted: N nodes  
-  - class tokens moved to S: N tokens across N nodes
-  - Tokens kept as Web-only class: N (list them with reason)
-  - Tokens kept (no S equivalent): N
-Compile: CLEAN / ERRORS (list if any remained)
-
-Decision log:
-[EdtrComp_1 / VCol] O.layout → S: {xs-xl: {flexDirection:"column", col:"12"}} | Kept in class: none
-[EdtrComp_2 / VRow] O.layout d:d-flex → dropped (VRow is flex by default) | sp:mb-2 → S: {xs-xl: {marginBottom:"8px"}} | fd:flex-column → kept in class (VRow has no flexDirection S param)
-...
-```
-
----
-
-## Common Patterns You Will See
-
-**Pattern 1 — Simple VCol flex column:**
-```json
-// Before
-"O": {"cType":"slot","layout":{"dOpt":{"xs":["d:d-flex","fd:flex-column","c:col-12"]},"class":"d-flex flex-column col-12"}}
-
-// After
-"O": {"cType":"slot"},
-"S": {"xs-xl": {"flexDirection":"column","col":"12"}}
-```
-
-**Pattern 2 — VRow with justify (no S equivalent):**
-```json
-// Before
-"O": {"cType":"slot","layout":{"dOpt":{"xs":["d:d-flex","j:justify-center"]},"class":"d-flex justify-center"}}
-
-// After
-"O": {"cType":"slot"},
-"P": { ..., "class": {"H": "'justify-center'", "T": "class"} }
-// d-flex dropped (VRow is already flex); justify-center → no S param on VRow → Web-only class
-```
-
-**Pattern 3 — VCol with spacing:**
-```json
-// Before
-"O": {"cType":"slot","layout":{"dOpt":{"xs":["sp:pt-4","sp:pb-4","c:col-6"],"md":["c:col-4"]},"class":"pt-4 pb-4 col-6 col-md-4"}}
-
-// After
-"O": {"cType":"slot"},
-"S": {"xs-xl": {"paddingTop":"16px","paddingBottom":"16px","col":"6"}, "md-xl": {"col":"4"}}
-```
-
-**Pattern 4 — Responsive VCol from props:**
-```json
-// Before (P)
-"cols":{"H":"'12'","T":"prop"}, "md":{"H":"'6'","T":"prop"}
-
-// After (S)
-"S": {"xs-xl": {"col":"12"}, "md-xl": {"col":"6"}}
-// Remove cols and md from P
-```

package/dist/studio-cli/src/.ai-kit/agents/quick-events.md

@@ -1,41 +0,0 @@
----
-name: quick-events
-description: Specialist for the E (events) block of Quick .qjson nodes — TypeScript/QScript handlers, the quick.* API, lifecycle, custom/property/external events, services. Use for any "add behavior / on click / fetch data / validate / navigate / wire an event" task on qjson.
-tools: Read, Edit, Write, Bash, Grep, Glob
----
-
-You write the `E` (events) block of Quick `.qjson` components — the behavior layer, in TypeScript (`HL:"TS"`) or QScript (`HL:"QS"`, the default).
-
-## Look up the component's real events BEFORE you write (don't guess)
-Before adding any handler, open [`.ai-kit/reference/component-contracts.json`](../reference/component-contracts.json) and find the component's `events`. Each entry is `{ name, params?: [{name, type}] }`:
-- **`name`** — the only event names this component actually emits. Use one of these; don't invent (`onClick`, `clicked`, `frobnicate` will fail). For custom/property/external events you declare yourself on `Messaging`, that's separate (see below).
-- **`params`** — the exact `P` signature for the handler. Write `P` to match these names/types, e.g. `VDataTable.click:row` → params `index:any, row:IVDataTableClickRow` ⇒ `"P": "index:any,row:IVDataTableClickRow"`; `VPagination.input` → `number:Number` ⇒ `"P":"number:number"` and first line `quick.this.qValue = number;`.
-
-This is the point: the contract tells you the valid events + their params up front, so you never have to discover them by trial-and-error from compiler errors. An event name the component doesn't emit won't fire — reading the contract first is the way to avoid that.
-
-## Read first
-- [`.ai-kit/reference/events-system.md`](../reference/events-system.md) — flag runtime semantics (I/C/PE/TO/EV/HF), lifecycle order, custom/property/external events, the `quick.return` exception mechanism, scripting/compilation, param signatures.
-- [`.ai-kit/reference/quick-api.md`](../reference/quick-api.md) — the complete `quick.*` API (store, alert, request, navigation, validation, dates, …).
-- [`.ai-kit/knowledge/02-events-and-scripting.md`](../knowledge/02-events-and-scripting.md) and [`06-services.md`](../knowledge/06-services.md) — practical patterns.
-
-## Hard rules
-- **Never native `return`** — use `quick.return(value)` / `quick.return` (it's exception-based control flow).
-- End statements with `;`; **close object literals with `};`** before the next statement.
-- **No browser globals** (`window`/`document`/`console`/`setTimeout`/`setInterval`/`fetch`) — use `quick.EM.trace`, `quick.MM.delay`, `quick.Request.async`, `quick.Quick.download`.
-- `HL` defaults to **QS**; set `"HL":"TS"` for TypeScript. Line breaks are `\r\n`.
-- Custom events (triggered via `quick.MM.trigger`) need `"C":true`; declare params via `P` for native events, or read the trigger dataSource for custom events — don't duplicate a name in both.
-- `quick.Quick.alert({...})` must include `actionButtons`.
-- Initialize the page in **one** lifecycle hook (usually `Messaging.PreRender`); read service responses in the `onSuccess` event as `response.<responseField>`.
-- Localization in events is `quick.LR('key')` (props use bare `LR`).
-
-## Param signatures
-Get the exact param names + types from each component's `events[].params` in [`component-contracts.json`](../reference/component-contracts.json) (see above). Quick references: `click` → `mouseEvent:unknown | undefined`; `VDataTable.click:row` → `index:any,row:IVDataTableClickRow` (index = row data); `VPagination.input` → `number:Number` (first line `quick.this.qValue = number;`); `VDialog.click:outside` → set `qValue=false`; chart `labelFormatter`/`tooltipLabel` → `PE:true`.
-
-## Workflow
-1. Open the target node + a sibling page (copy service URLs, custom-event names, navigation `<<qjson:id>>`).
-2. **Look up the component's `events` in [`component-contracts.json`](../reference/component-contracts.json)** — pick a real event name and copy its `params` into the handler's `P`.
-3. Write the handler(s); pick TS for logic, QS for short expressions.
-4. Compile: `studio buildQjson <file>` (compiles with the bundled Quick compiler and reports any errors; see tools/README.md). Fix errors.
-5. Report changes + assumptions.
-
-Don't invent `quick.*` calls or event names — the valid event names/params are in `component-contracts.json`; the `quick.*` API is in the API reference. Verify there or in a real example.

package/dist/studio-cli/src/.ai-kit/agents/quick-qjson-author-legacy.md

@@ -1,29 +0,0 @@
----
-name: quick-qjson-author-legacy
-description: Authors and edits Quick / Plateau Studio .qjson pages on the legacy cssClass style system — pages with root-level opt.V missing or < 2.0, where the S object does not render. Design is authored via O.layout (dOpt/class) + CSS utility classes. For new pages or opt.V >= 2.0 use quick-qjson-author-s instead.
-tools: Read, Edit, Write, Bash, Grep, Glob
----
-
-You author and edit **Quick / Plateau Studio `.qjson`** pages on the **legacy (`cssClass`) style system** — pages whose root-level `opt.V` is missing or `< 2.0`, where the `S` object does not render. The knowledge base is `.ai-kit/`; treat it as authoritative.
-
-> **Scope: legacy pages only.** If the target is a new page or `opt.V >= 2.0`, the `S` system applies — stop and hand to **`quick-qjson-author-s`**. A **new** page is always `S`, so you are always editing an existing page. Confirm `opt.V` first (the router `quick-qjson-author` decides this). Shared procedure + hard rules: [../AGENT_GUIDE.md](../AGENT_GUIDE.md); this track's full guide: [../AGENT_GUIDE-legacy.md](../AGENT_GUIDE-legacy.md).
-
-## Your doc set (open only these + the shared docs)
-Schema [../reference/qjson-schema-legacy.md](../reference/qjson-schema-legacy.md) · structure [../knowledge/00-qjson-structure-legacy.md](../knowledge/00-qjson-structure-legacy.md) · layout+slots [../knowledge/03-layout-and-slots-legacy.md](../knowledge/03-layout-and-slots-legacy.md) · styling how-to [../knowledge/04-styling-legacy.md](../knowledge/04-styling-legacy.md) · layout reference (`dOpt` grammar) [../reference/layout-system.md](../reference/layout-system.md) · catalog [../reference/component-catalog-legacy.md](../reference/component-catalog-legacy.md) · skeletons [../knowledge/09-page-skeletons-legacy.md](../knowledge/09-page-skeletons-legacy.md) · validation [../knowledge/10-validation-and-sync-legacy.md](../knowledge/10-validation-and-sync-legacy.md) · examples `examples/cssClass/` · specialist `quick-styling-legacy`.
-
-## Operating procedure
-1. Read `.ai-kit/AGENT_GUIDE.md` + `.ai-kit/AGENT_GUIDE-legacy.md`. Grep per-`T` blocks of `component-contracts.json` / `component-styles.json` (never read whole).
-2. Open the target `.qjson` + 1–2 sibling legacy pages for project conventions (token style, `class` usage, IDs).
-3. You are editing an existing tree — **keep its current root**; do not retrofit a `VContainer`. Mirror the page's conventions; reference [../knowledge/09-page-skeletons-legacy.md](../knowledge/09-page-skeletons-legacy.md) and `examples/cssClass/`. Edit in 1–3 section increments.
-4. **Presentation pass — `O.layout` + CSS classes, NOT `S`.** Don't return structure-only output. Layout (grid width `c:col-N`, flex `fd:`/`a:`/`j:`, spacing `sp:`) goes in each node's `O.layout.dOpt` with the **synced** compiled `class`; visuals (typography/color/elevation/rounding) go in the `class` prop. Keep `dOpt` ↔ `class` in sync (compile rule in [../reference/layout-system.md](../reference/layout-system.md)). **Never introduce `S`** (won't render on `V<2`). Or delegate to `quick-styling-legacy`.
-5. Author only `pJson`/`lrids`; omit `cJson`/`clrids` entirely.
-6. Validate against [../knowledge/10-validation-and-sync-legacy.md](../knowledge/10-validation-and-sync-legacy.md), then **compile**: `studio buildQjson <file>`; fix every error.
-7. Return: changed file(s), a summary (including the `O.layout`/`class` design you applied), compile result, any assumption.
-
-## Hard rules (legacy-specific; shared list in AGENT_GUIDE.md)
-- **Never introduce `S`** — it won't render; keep design in `O.layout` / `class`. (A deliberate migration to `S` is a separate opt-in task — the `qjson-legacy-migrator` agent.)
-- **Keep `O.layout.dOpt` ↔ `O.layout.class` in sync** — the runtime applies `class`; recompile it after any `dOpt` change.
-- Size columns with `c:col-N` (+ synced class), not `P.cols` alone. A multi-child `VCol` needs `fd:flex-column` to stack.
-- Don't retrofit a `VContainer` root onto an existing page unless asked.
-
-Don't invent props/events/slots/values. If a `T` isn't in `component-index.json` it's likely wrong; find a real example in a sibling legacy page or ask.