@xgent-ai/skills 0.6.0 → 0.7.0

package/vendor/phoenix-ui/bundle/blobs/cdfab22b61243715df8c1809f0d9576de9c325fdbd154a1355a95c91a07537eb

@@ -0,0 +1,101 @@
+> **Additional context needed**: only the target element, when the request does not name one that resolves uniquely on the page.
+
+Generate is the fast lane into live mode: the user names an element, a direction, and a count in one sentence, and within a minute they are cycling through variants in their browser. One command boots the helper, hands the element to the overlay in the page your harness already shows (it scrolls to it, selects it, and fires the same Go a click fires) and returns the generate event; one edit writes the variants; one call replies and waits for the user's choice, which the helper bakes into source itself. This file owns the lane's plumbing; from the event onward the design work is [live.md](live.md)'s, unchanged, so read it in full now if you have not this session.
+
+**Web only.** Live mode's browser overlay has no native equivalent; on `ios` / `android` / `adaptive` projects, decline this command and offer `bolder` or `quieter` on the source instead.
+
+The plumbing is where the lane saves time: one command starts the session around the page your harness already shows, one call replies and waits, and nothing here is a browser you have to babysit. The design work is not where it saves time. Setup runs as for any command (`phoenix-ui context`, this reference, craft-floor.md before the edit), and the variants are planned, written, and accepted exactly the way a live session plans, writes, and accepts them.
+
+Three prohibitions cover the known ways this command goes wrong:
+
+- **Never run init or document, and never ask for PRODUCT.md or DESIGN.md.** When they exist, the start command prints them under `boot` and you use them. When they do not, it says so (`contextMissing`, `contextNote`) and you extract the identity from the event (Step 3). A missing file is never a reason to interview the user inside this command; offer `init` in one line after the session ends.
+- **Never hand-write a variants wrapper or invent a session id.** Only the browser mints session ids (8 hex characters, at Go). A missing event is fixed by rerunning Step 2, never with a direct source edit.
+- **Do not act on hook findings while live markers are in the file**, and do not restyle variants to appease them; the accept verifies the file once the variant is permanent.
+
+## Step 1: Parse the request
+
+Three parts, all from the user's sentence:
+
+- **A number in the request**: that is the count. **No number**: 3. The protocol caps count at 8.
+- **The direction wording** maps onto the live action vocabulary; never invent a new action value:
+  - **bold, bolder, stronger, punchier**: `bolder`
+  - **quiet, calmer, softer, toned down**: `quieter`
+  - **simpler, minimal, stripped**: `distill`
+  - **refined, tightened, polished**: `polish`
+  - **font and type words**: `typeset`
+  - **color words**: `colorize`
+  - **arrangement and spacing words**: `layout`
+  - **device and breakpoint words**: `adapt`
+  - **motion words**: `animate`
+  - **playful words**: `delight`
+  - **rule-breaking words**: `overdrive`
+  - **Wording that carries intent but no vocabulary word** ("make it feel like a bank", "warmer", "more premium"): `phoenix-ui`, with the user's wording passed as the prompt.
+  - **An action fits AND extra intent rides along** ("bolder, but keep it monochrome"): that action, with the rest as the prompt.
+  - **The wording names no direction at all** ("better", "improve", "nicer", "different", "fresh", "new", "redesign", "fix", "some options", "ideas", "alternatives", or just "variants" with nothing else): STOP and call the AskUserQuestion tool to clarify. Ask one question, offering the vocabulary: *"Which direction should the variants take? bolder, quieter, simpler (distill), polished, typography (typeset), color (colorize), layout, motion (animate), playful (delight), or rule-breaking (overdrive)."* Map the answer with this list; an answer that is still open ("surprise me", "you pick") is `phoenix-ui` with the user's original wording as the prompt, and Step 2 starts on that answer.
+- **The element description** ("the pricing cards", "the hero heading"): Step 2 resolves it to a selector.
+
+Done when you hold an action from the vocabulary (asked for, when the request named no direction), a count from 1 to 8, and the element description.
+
+## Step 2: Reuse the page, then start
+
+**Reuse** the dev server already running and the tab your harness already shows it in; a second server or a second browser window is the failure this step prevents.
+
+1. **Find the dev server**, cheapest source first, and stop at the first hit: the user's message, a browser tab already on the app (Claude Code: an origin in `tabs_context`), a server your harness started (Claude Code: `preview_list`), a terminal that printed its URL. Its origin is your `--dev-url`. **No hit**: leave `--dev-url` off and run the start command with no wait; the boot probes for a running server and its verdict names the move. `browser_needed` carries the `devUrl` it found: open it as in 2, then rerun with `--dev-url <devUrl> --wait-for-browser 60000`. `no_dev_server` means nothing serves the app: start the dev script the way the verdict says (Claude Code: `preview_start`; Cursor: a background terminal; Codex: an exec you yield from), wait for its URL, then rerun with `--dev-url <url>`.
+2. **Open the page that renders the element in your browser, then start.** The route the request names, else the one `--target` serves; `--dev-url` takes only the origin.
+   - **Cursor** (`browser_navigate`) and **Claude Code** (`navigate`, which opens the Browser pane when it is closed and takes the `tabId` from `tabs_context` when a tab is already on that origin): open the URL, then run the start command with `--dev-url <url> --wait-for-browser 60000`. The boot injects the overlay and the page reloads into it while the command waits. Your browser tool is the only opener on these harnesses; the engine ignores `--open` there.
+   - **No browser tool** (Codex, others): run the start command with `--open --wait-for-browser 120000`; it opens the system browser, and the longer wait covers the user finding the tab. **`browser_open_failed` back**: tell the user the `url` in one line and rerun with `--wait-for-browser 120000`.
+
+```bash
+.claude/skills/phoenix-ui/scripts/phoenix-ui live-generate --target src/App.jsx --dev-url http://127.0.0.1:5173/ --selector ".pricing-grid" --action bolder --count 3 --boot --wait-for-browser 60000
+```
+
+Run it in the foreground in Cursor and Claude Code (it returns within the wait); on Codex, in an exec you yield from, the way Step 3 runs the poll.
+
+- `--target`: the file that renders the element when the request or the project makes it obvious; skip it otherwise.
+- `--dev-url`: the origin from 1; omit it and the boot probes.
+- `--selector`: a unique class first, then a landmark tag plus class, an id last (every variant mounts a copy of the element, so an id repeats in the DOM). **The request names a repeated component in plural** ("the pricing cards"): target the container that holds the set, so one scoped stylesheet restyles every instance. One read of the source file that renders the element is allowed when the selector is not obvious; `--dry-run` resolves and reports without starting anything when it is not certain.
+- `--boot`: runs the lane's boot (PRODUCT.md and DESIGN.md loaded again for the helper, missing files tolerated, dev URL found, bottom bar hidden for the helper's lifetime) and reuses a helper that is already running. Its result rides along as `boot`.
+- Also available: `--prompt`, `--text` (keep only matches whose visible text contains a snippet), `--index` (1-based pick among matches).
+
+Read the output in this order: `boot` (or `boot.contextMissing` with `boot.contextNote`: the page is the source of truth, per the note), then `event`, the generate event for `sessionId`, with the same `_instructions` a user's Go gets. Every verdict carries `_instructions`, and they win over your recollection of this file; the ones whose move is a decision of yours:
+
+- **`ambiguous`**: the candidates are listed; target their common container, or rerun with `--text "<visible text>"` or `--index <n>`.
+- **`dev_server_gone`**: the dev server stopped answering while the command waited for the page (on Cursor, a server another chat started dies with that chat). Start it the way the verdict says, then rerun with `--dev-url <url>`.
+- **`no_match`**: the tab is on a route that does not render the element (navigate to the right route, rerun), or the selector is wrong (derive a better one from the source, or add `--text`).
+- **`config_missing` / `config_invalid`** under `bootError`: follow [live-setup.md](live-setup.md) first, then rerun.
+- **`event: null`** with `ok: true`: the event was slower than the wait; run `.claude/skills/phoenix-ui/scripts/phoenix-ui live-poll` once to collect it, then continue.
+
+Done when the output shows `ok: true`, a `sessionId`, and an `event`, reached with at most one server started and one tab opened by you.
+
+## Step 3: Generate
+
+The event is a standard `generate` event: the picked element's context, a preflighted scaffold, and `_instructions` naming the action's reference, the planning section, and the exact splice. Handle it exactly per live.md's **Handle generate**, which owns everything from the identity lock to the done reply: read the action's reference and craft-floor.md as it says, plan per section 4 (identity first, then mode, then three different primary axes, then the squint test), declare knobs per section 7, and deliver per section 6 (a complete replacement of the element per variant, the preview CSS plus every variant in one edit at the scaffold's splice). The lane changes nothing about what a variant may be: the moves a live session would make on this element (a promoted tier, a restructured set, a reordered card, a different surface) are open here too. Never screenshot the page; the overlay preview is the review channel until accept.
+
+**Reply and wait in one call**, with the file you wrote:
+
+```bash
+.claude/skills/phoenix-ui/scripts/phoenix-ui live-poll --reply EVENT_ID done --file src/App.jsx --then-poll
+```
+
+This replies done (the browser mounts the variants) and then blocks until the user's choice arrives, so run it the way your harness runs a long wait: **Claude Code** in the foreground with your tool's longest timeout (600000 ms), so you are paused until the choice arrives; **Codex** in a yielded foreground exec; **Cursor** in a background terminal with notify on `"type":"(accept|discard|variant_mount_failed|exit)"`. Never pass a short `--timeout=`. While it runs there is nothing else to do: never sleep and never poll its output on a timer; a harness that backgrounds it wakes you when it returns. `{"type":"timeout"}` means the user has not chosen yet: run `live-poll` again and keep waiting. If the edit fails after the browser flipped to GENERATING, `--reply EVENT_ID error "Short reason"` (without `--then-poll`) so the bar resets.
+
+Then tell the user, in one line, where their variants are: *"Three [bolder] variants are live on [the pricing cards]: cycle with the floating bar's arrows, adjust the Tune knobs, and Accept the keeper."*
+
+Outside the replace path, read the matching live.md section before acting: `scaffold.previewMode: "svelte-component"` (Svelte previews are edited as components, and their accept is mechanical), `mode: "insert"`, `variant_mount_failed`, `steer`, `manual_edit_apply`, and any `fallback: "agent-driven"` wrap error.
+
+## Step 4: Accept and close
+
+The call from Step 3 returns the user's choice. **`discard`**: nothing to do. **`accept`**: `_acceptResult.carbonize: true` is the normal case, and the cleanup is live.md's **Required after accept**, unchanged: move the accepted variant's rules into the stylesheet that already owns the element with real selectors, bake the chosen knob values in, unwrap the element and drop every `data-impeccable-*` attribute, delete the inline `<style>` block and both `phoenix-ui-carbonize` markers, then `.claude/skills/phoenix-ui/scripts/phoenix-ui live-complete --id SESSION_ID` and confirm `phase: "completed"`. (`baked: true` appears only when the accept was run with `--bake`; then the helper already made the variant permanent and no `live-complete` is owed.)
+
+Close without being asked, the moment the choice is handled:
+
+```bash
+.claude/skills/phoenix-ui/scripts/phoenix-ui live-server stop
+```
+
+Stopping removes the injected script and reloads the page once: the user sees the accepted design with no overlay chrome, still served by their dev server. **Never kill or restart the dev server**, including one you started in Step 2.
+
+- **The user asks for more variants before you closed**: skip the close, run Step 2 again for the next element (the helper is reused), and close after the last choice.
+- **Interrupted or unsure of the state**: `.claude/skills/phoenix-ui/scripts/phoenix-ui live-status`, then `live-resume`; the journal under `.phoenix-ui/live/sessions/` is canonical.
+
+Done when the helper is stopped and the dev site still answers with the accepted design.

package/vendor/phoenix-ui/bundle/blobs/ce19855b842a453973bff4eab9614bcfe502092dc9b2f4238dce27038e2d15d1

@@ -0,0 +1,256 @@
+{
+  "schemaVersion": 2,
+  "catalogVersion": "phoenix-2026-01",
+  "authoringStatus": "draft",
+  "qualityBar": {
+    "principle": "A composition specifies relationships among information, attention, controls, and adaptation while leaving visual identity to project direction. Its structure must fit a concrete task with actual state, accessible actions, and honest implementation boundaries."
+  },
+  "families": [
+    {
+      "id": "phoenix-composition-persuade",
+      "label": "Informed decisions",
+      "description": "Original arrangements connecting an offer, its evidence or fit, complete conditions, and the next decision."
+    },
+    {
+      "id": "phoenix-composition-operate",
+      "label": "Scoped work",
+      "description": "Original arrangements preserving object scope, review context, explicit commitment, and concrete results."
+    },
+    {
+      "id": "phoenix-composition-read",
+      "label": "Located understanding",
+      "description": "Original arrangements connecting question maps or corresponding sections to readable explanation and evidence."
+    },
+    {
+      "id": "phoenix-composition-experience",
+      "label": "Revisable participation",
+      "description": "Original arrangements supporting optional exploration or accessible co-authoring with visible context and return."
+    }
+  ],
+  "compositions": [
+    {
+      "id": "phoenix-persuade-claim-proof-decision",
+      "familyId": "phoenix-composition-persuade",
+      "surface": "persuade",
+      "form": "A claim-to-decision view, the primary promise leads into comparable evidence and then one complete decision region.",
+      "lineage": "Original composition connecting a purchase claim to its support and a fully informed next step.",
+      "tags": [
+        "claim-support",
+        "comparable-evidence",
+        "decision-region"
+      ],
+      "grammar": [
+        "Staging/hierarchy: Give one primary claim highest rank; use readable headings for supporting evidence and decision detail.",
+        "Sequence/attention: Move from claim to support to conditions and decision; keep qualifications beside the claims they limit.",
+        "Controls/state: Put the primary next step after the complete offer; show unavailable or uncertain states explicitly.",
+        "Adaptation: Stack evidence by criterion on small screens; retain order without sticky controls hiding required content."
+      ],
+      "spark": "Let readers connect the offer, the reason to trust it, and the consequence of choosing it in one clear pass through the page, with qualifications still readable.",
+      "webLeverage": "Use semantic sections, comparable tables or lists, and an explicit decision form without imposing palette or typeface.",
+      "applicability": "适用于具备真实证据和明确条件的产品介绍、订阅选择或服务报价单页。",
+      "thesis": "让主张、依据与决定形成连续空间关系，并保持条件可读。",
+      "provenance": "Original Phoenix catalog authoring text proposal for this local catalog; no external model, fixture copying, project acceptance, or implemented interface is asserted.",
+      "source": {
+        "kind": "original",
+        "title": "Phoenix original composition: Claim, proof, decision",
+        "license": "Apache-2.0"
+      }
+    },
+    {
+      "id": "phoenix-persuade-fit-cost-next-step",
+      "familyId": "phoenix-composition-persuade",
+      "surface": "persuade",
+      "form": "A fit-to-next-step flow, requirements remain visible beside the resulting option, complete cost, and an editable final summary.",
+      "lineage": "Original composition retaining needs, price assumptions, and the final decision across guided offer selection.",
+      "tags": [
+        "visible-requirements",
+        "cost-assumptions",
+        "editable-summary"
+      ],
+      "grammar": [
+        "Staging/hierarchy: Give the current question primary position; maintain a compact requirements summary beside the result.",
+        "Sequence/attention: Move from needs to option and cost to the next step; expose the assumptions explaining recommendations.",
+        "Controls/state: Provide back and edit actions; distinguish an estimate from a committed order and disclose incomplete fit.",
+        "Adaptation: Use one narrow-screen column; retain answers and restore focus after editing earlier requirements."
+      ],
+      "spark": "Hold the reason for a recommendation together with its cost, so returning to a requirement changes a visible decision rather than restarting a hidden sales funnel.",
+      "webLeverage": "Use grouped forms, named step regions, and an accessible editable summary whose updates do not steal focus.",
+      "applicability": "适用于明确需求推荐套餐的选择流程，系统能解释推荐并完整计算成本。",
+      "thesis": "让需求、依据和成本连续可见，支持修改与检查结果。",
+      "provenance": "Original Phoenix catalog authoring text proposal for this local catalog; no external model, fixture copying, project acceptance, or implemented interface is asserted.",
+      "source": {
+        "kind": "original",
+        "title": "Phoenix original composition: Fit, cost, next step",
+        "license": "Apache-2.0"
+      }
+    },
+    {
+      "id": "phoenix-operate-record-detail-action",
+      "familyId": "phoenix-composition-operate",
+      "surface": "operate",
+      "form": "A record-to-action workspace, a stable collection opens contextual detail and a scoped action while the active record remains identifiable.",
+      "lineage": "Original composition giving operational selection, inspection, and action one explicit object scope.",
+      "tags": [
+        "stable-collection",
+        "contextual-detail",
+        "scoped-action"
+      ],
+      "grammar": [
+        "Staging/hierarchy: Rank collection location, record identity, and action scope clearly; subordinate detail to the current task.",
+        "Sequence/attention: Select a record, inspect detail, then act; preserve collection filters and return location throughout.",
+        "Controls/state: Separate loading, stale, edited, committed, and failed states; name actions and keep cancellation explicit.",
+        "Adaptation: Replace adjacent regions with labeled detail on small screens; return focus to the originating record."
+      ],
+      "spark": "Keep one object unmistakable through inspection and action, then return the operator to the same filtered collection with the result of their work clearly stated.",
+      "webLeverage": "Use semantic collection and detail regions, stable identifiers, scoped forms, and an explicit focus return target.",
+      "applicability": "适用于记录管理 Portal、库存或工单后台，可保持列表筛选并提供清晰对象详情。",
+      "thesis": "持续联系列表位置、活动对象和操作范围，降低错误对象操作。",
+      "provenance": "Original Phoenix catalog authoring text proposal for this local catalog; no external model, fixture copying, project acceptance, or implemented interface is asserted.",
+      "source": {
+        "kind": "original",
+        "title": "Phoenix original composition: Record, detail, action",
+        "license": "Apache-2.0"
+      }
+    },
+    {
+      "id": "phoenix-operate-before-after-commit",
+      "familyId": "phoenix-composition-operate",
+      "surface": "operate",
+      "form": "A before-and-after commitment flow, proposed differences and affected scope are reviewed before a separate explicit commit and result.",
+      "lineage": "Original composition separating review of consequential configuration or bulk change from commitment.",
+      "tags": [
+        "proposal-difference",
+        "affected-scope",
+        "separate-commit"
+      ],
+      "grammar": [
+        "Staging/hierarchy: Prioritize proposed differences and scope; put commitment after review rather than above its evidence.",
+        "Sequence/attention: Inspect old and proposed values, examine consequences, then commit; keep unchanged context available.",
+        "Controls/state: Invalidate stale previews and distinguish partial failure; name consequences and promise only supported undo.",
+        "Adaptation: Stack labeled before/after values on small screens; place consequence summary beside the commit control."
+      ],
+      "spark": "Make commitment deliberate through a specific reviewed difference and scope; the subsequent result identifies what succeeded and what still needs attention rather than implying universal success.",
+      "webLeverage": "Use labeled comparisons, scoped confirmation forms, and accessible result lists with specific failure or retry detail.",
+      "applicability": "适用于配置审批、权限调整或批量修改，可生成真实预览并返回具体提交结果。",
+      "thesis": "真实差异与影响审查之后单独提交，并诚实展示失败和恢复边界。",
+      "provenance": "Original Phoenix catalog authoring text proposal for this local catalog; no external model, fixture copying, project acceptance, or implemented interface is asserted.",
+      "source": {
+        "kind": "original",
+        "title": "Phoenix original composition: Before, after, commit",
+        "license": "Apache-2.0"
+      }
+    },
+    {
+      "id": "phoenix-read-overview-body-evidence",
+      "familyId": "phoenix-composition-read",
+      "surface": "read",
+      "form": "An overview-to-evidence reading view, a descriptive section map leads into a stable text column with support connected to each argument.",
+      "lineage": "Original composition joining a reader question map to detailed explanation and inspectable support.",
+      "tags": [
+        "section-map",
+        "stable-text",
+        "connected-evidence"
+      ],
+      "grammar": [
+        "Staging/hierarchy: Give title, section promises, body, and references distinct readable roles; keep the reading column stable.",
+        "Sequence/attention: Read overview before detail; connect support to its passage and return to the same reading location.",
+        "Controls/state: Provide contents and note-return links; keep required content readable without optional disclosures.",
+        "Adaptation: Move side material into small-screen flow; preserve heading order and usability at enlarged text sizes."
+      ],
+      "spark": "Serve both quick question lookup and sustained reading: locate a useful section, inspect its detail, and verify supporting evidence without being displaced from the argument.",
+      "webLeverage": "Use semantic headings, contents navigation, stable fragments, and accessible reference backlinks without imposing visual identity.",
+      "applicability": "适用于技术指南、政策说明和有真实引用的长篇知识文章。",
+      "thesis": "连接问题地图、正文与局部证据，使定位与持续阅读共存。",
+      "provenance": "Original Phoenix catalog authoring text proposal for this local catalog; no external model, fixture copying, project acceptance, or implemented interface is asserted.",
+      "source": {
+        "kind": "original",
+        "title": "Phoenix original composition: Overview, body, evidence",
+        "license": "Apache-2.0"
+      }
+    },
+    {
+      "id": "phoenix-read-parallel-explanation",
+      "familyId": "phoenix-composition-read",
+      "surface": "read",
+      "form": "A parallel explanation region, corresponding source and interpretation remain aligned with explicit labels and an optional combined reading view.",
+      "lineage": "Original composition retaining corresponding statements and consequences in migration or specialist explanations.",
+      "tags": [
+        "corresponding-sections",
+        "explicit-labels",
+        "combined-view"
+      ],
+      "grammar": [
+        "Staging/hierarchy: Give paired sections equal readable roles; distinguish commentary from source through explicit labels.",
+        "Sequence/attention: Inspect one corresponding pair at a time; connect its difference to practical meaning before advancing.",
+        "Controls/state: Switch paired and combined views explicitly; preserve active section, focus, and selection context.",
+        "Adaptation: Stack corresponding labeled sections on small screens; retain anchors without forced synchronized scrolling."
+      ],
+      "spark": "Explain a relationship rather than merely placing text side by side: each corresponding pair identifies the interpreted content and why its difference matters to the reader.",
+      "webLeverage": "Use named sections, stable anchors, and accessible view controls preserving focus and source/interpretation labels.",
+      "applicability": "适用于 API 迁移解释、规范解读或版本对照，原文与解释能按章节准确对应。",
+      "thesis": "用明确对应关系帮助理解，避免并排布局制造位置或来源混淆。",
+      "provenance": "Original Phoenix catalog authoring text proposal for this local catalog; no external model, fixture copying, project acceptance, or implemented interface is asserted.",
+      "source": {
+        "kind": "original",
+        "title": "Phoenix original composition: Parallel explanation",
+        "license": "Apache-2.0"
+      }
+    },
+    {
+      "id": "phoenix-experience-choose-explore-return",
+      "familyId": "phoenix-composition-experience",
+      "surface": "experience",
+      "form": "A choose-and-return exploration flow, a compact overview opens bounded branches and restores the visitor to the same identifiable choice.",
+      "lineage": "Original composition arranging an optional choice point, bounded detail branch, and reliable return.",
+      "tags": [
+        "choice-overview",
+        "bounded-branch",
+        "reliable-return"
+      ],
+      "grammar": [
+        "Staging/hierarchy: Give current choice or branch a clear primary heading; preserve its relationship to the compact overview.",
+        "Sequence/attention: Choose a topic, inspect bounded detail, then return or choose another; never advance automatically.",
+        "Controls/state: Provide named back and restart; distinguish visited from completed and retain the originating choice.",
+        "Adaptation: Use an ordered small-screen overview; restore focus and context after branches without requiring motion."
+      ],
+      "spark": "Support curiosity without lost orientation: every branch has a clear extent, an identifiable starting choice, and a return path restoring the overview the visitor left.",
+      "webLeverage": "Use semantic navigation, stable routes or fragments, named detail headings, and accessible focus restoration on return.",
+      "applicability": "适用于互动展览、产品细节探索或可选分支教学，内容有明确起点和有限分支。",
+      "thesis": "让探索由用户选择推动，以可见起点和可靠返回支持自由路线。",
+      "provenance": "Original Phoenix catalog authoring text proposal for this local catalog; no external model, fixture copying, project acceptance, or implemented interface is asserted.",
+      "source": {
+        "kind": "original",
+        "title": "Phoenix original composition: Choose, explore, return",
+        "license": "Apache-2.0"
+      }
+    },
+    {
+      "id": "phoenix-experience-arrange-preview-revise",
+      "familyId": "phoenix-composition-experience",
+      "surface": "experience",
+      "form": "An arrange-and-preview workspace, ordered contributions stay connected to the current result while participants inspect and revise their sequence.",
+      "lineage": "Original composition linking each editable contribution to its place in a visible ordered result.",
+      "tags": [
+        "ordered-editor",
+        "current-preview",
+        "inspectable-revision"
+      ],
+      "grammar": [
+        "Staging/hierarchy: Separate editable order and current preview clearly; label position and the affected contribution.",
+        "Sequence/attention: Inspect, revise, then inspect the changed preview; preserve the selected contribution through the sequence.",
+        "Controls/state: Provide move and remove controls and only supported undo; expose rather than hide concurrent conflicts.",
+        "Adaptation: Stack editor and preview on small screens; retain focus after moves and support revision without dragging."
+      ],
+      "spark": "Make a developing result understandable through its pieces: participants see where a contribution sits, change it with accessible controls, and inspect the consequence in the preview.",
+      "webLeverage": "Use ordered lists, named revision controls, position announcements, and a preview that does not replace editor focus.",
+      "applicability": "适用于共创提纲、故事排序或步骤编排，结果能由当前有序内容真实生成。",
+      "thesis": "同时展示贡献、顺序和结果，支持可理解且可访问的修改。",
+      "provenance": "Original Phoenix catalog authoring text proposal for this local catalog; no external model, fixture copying, project acceptance, or implemented interface is asserted.",
+      "source": {
+        "kind": "original",
+        "title": "Phoenix original composition: Arrange, preview, revise",
+        "license": "Apache-2.0"
+      }
+    }
+  ]
+}

package/vendor/phoenix-ui/bundle/blobs/ce504e51c031e6e20d737155e4747aa512a694fc87f879c7ceeb76121162b781

@@ -0,0 +1,26 @@
+# Region map
+
+A region map names what is actually visible in the approved comp before asset production. It is not a page build or an asset approval.
+
+1. Run `.dsh/skills/phoenix-ui/scripts/phoenix-ui comp-spec --comp <comp.png> --grid` and open the original and gridded images.
+2. Run `.dsh/skills/phoenix-ui/scripts/phoenix-ui comp-spec --schema` for the JSON fields. Write `regions.json` with a `regions` array. Each region needs a stable `id`, `kind`, `note`, and exactly one of `pixelBox`, normalized `box`, or `grid`. Use the original comp’s dimensions.
+3. Run `.dsh/skills/phoenix-ui/scripts/phoenix-ui comp-spec --comp <comp.png> --regions regions.json --inspect-map`. The output points to a report, overlay, exact crops and `COMPARE` sheets of masked references. The default prints findings; `--json` prints the entire report, with sheet paths in `comparisonSheets`.
+4. Open the comparison sheets first to inspect affected crops together, then open individual crops where more detail is needed. Compare their bounds with the original. Inspect excluded foreground pixels as well as geometry errors. Every overlapping non-container code box is masked in full, including empty space inside it. Bound separate text elements separately so artwork in the gaps stays visible; a container describes their layout extent and never replaces its children. Correct the map and inspect again; use a new output directory each time. Zero errors does not certify crop accuracy. Coverage warnings are hints, not proof of completeness.
+
+If the request ends at mapping, stop with the map, inspection report and unresolved findings. To continue a build, measure the inspected map with `comp-spec --comp <comp.png> --regions regions.json` and follow [new-work.md](new-work.md).
+
+`--auto` produces horizontal band scaffolding, not element identification. It is optional and does not replace authoring a map.
+
+## Containment
+
+`parentId` identifies an enclosing `container: true` region. Parent and children keep separate IDs and crops. Containment never transfers approval.
+
+## What varies independently
+
+Split regions by what varies independently: content the site swaps (room photos, products, people), moving parts (anything a hover or the signature interaction moves), and structure (frames, surrounds, ornament). A window with open shutters onto a room is three kinds of region: the surround as a plate with a transparent opening, the room as an image region beneath it, and each shutter as its own plate. Overlapping regions are composited in the page. `comp-spec` flags a raster region whose note names a frame and the view it opens onto (`baked-composite`), and the plan and asset review shows it to the user first.
+
+## Painted material
+
+When measuring, `comp-spec` flags a `text`, `control` or `chrome` region, containers included, whose crop looks painted (`painted-pixels`: many colours, soft gradients) and lists it in its summary. The plan and asset review shows flagged regions, and those marked `codeDrawn` (painted material you chose to draw in code), to the user first. Do not leave the catch to them: if a region is painted material (a figure, a photograph, a metal or paper surface), classify it `plate`, `image` or `texture` now.
+
+Comp crops are reference evidence only, never production assets. The map inspector marks its PNGs as comp-derived.

package/vendor/phoenix-ui/bundle/blobs/ce73e93d7836ca153511f15f2cf174f0849c6d6f728fe43fb864392b1dd610a2

@@ -0,0 +1,5 @@
+#!/bin/sh
+# Generated provider copies use the local Node launcher; ordinary runs do not install.
+set -eu
+dir=$(CDPATH= cd -- "$(dirname -- "$0")" && pwd)
+exec node "$dir/phoenix-launcher.cjs" "$@"

package/vendor/phoenix-ui/bundle/blobs/cefb245ee3b44caaac43da6e5d6877b5d469960f53f7c6c8b58c380d2f9045ae

@@ -0,0 +1,104 @@
+One-time live-mode project setup. Loaded from [live.md](live.md) only when `phoenix-ui live` reports `config_missing` / `config_invalid`, when `configDrift` needs handling, or when the config lacks `cspChecked`. Not part of the per-session hot path.
+
+## Write the config
+
+Create the file at the `path` the boot reported (default `.phoenix-ui/live/config.json`):
+
+```json
+{
+  "files": ["<path-or-glob>", "<path-or-glob>", ...],
+  "exclude": ["<optional-glob>", ...],
+  "insertBefore": "</body>",
+  "commentSyntax": "html",
+  "cspChecked": true
+}
+```
+
+`files` is the inject target: **the HTML files the browser actually loads**, not necessarily source (tracked vs generated does not matter here; wrap has its own generated-file guard). Entries are literal paths or globs. `exclude` (optional) skips files a `files` glob would otherwise include (email templates, demo fixtures). `cspChecked` records that the CSP step below has run; absent on first setup.
+
+**Hard-excluded paths (cannot be overridden):** `**/node_modules/**` and `**/.git/**`; injecting there would instrument third-party code.
+
+**Glob syntax:** `**` matches any number of segments (including zero), `*` matches within a segment, `?` matches one character. Paths are project-root-relative with forward slashes.
+
+| Framework | `files` | `insertBefore` | `commentSyntax` |
+|-----------|---------|----------------|-----------------|
+| SPA with single shell (Vite / React / Plain HTML) | `["index.html"]` | `</body>` | `html` |
+| Next.js (App Router) | `["app/layout.tsx"]` | `</body>` | `jsx` |
+| Next.js (Pages) | `["pages/_document.tsx"]` | `</body>` | `jsx` |
+| Nuxt | `["app.vue"]` | `</body>` | `html` |
+| Svelte / SvelteKit | `["src/app.html"]` | `</body>` | `html` |
+| TanStack Router (SPA, Vite) | `["index.html"]` | `</body>` | `html` |
+| TanStack Start (SSR) | `["src/routes/__root.tsx"]` | `<Scripts` | `jsx` |
+| Astro | `[" <root layout .astro>"]` | `</body>` | `html` |
+| Multi-page (separate HTML per route) | `["public/**/*.html"]` glob over the served dir | `</body>` | `html` |
+
+Pick an anchor that exists in every file (`</body>` almost always works); `insertAfter` matches after a line instead. For multi-page sites prefer a glob so new pages are picked up automatically. For sites whose pages are rebuilt by a generator, the inject survives only until the next regeneration: re-run `phoenix-ui live` after each build (accept is unaffected; it writes true source via the fallback flow).
+
+**Framework adapters (auto-detected at inject time).** Every inject records what it wrote in `.phoenix-ui/live/inject-journal.json`; the next inject or remove heals artifacts a crash or wrong-directory stop left behind. SvelteKit, Nuxt, and TanStack Start server-render their document shell, so a raw `<script>` in the entry template will not execute reliably; `phoenix-ui live-inject` detects them and routes to a dedicated adapter (SvelteKit: dev-only root component from `+layout.svelte`; Nuxt: dev-only `.client.ts` plugin; TanStack Start: a generated dev-only `Phoenix UILiveRoot` component in `__root`). The `files` value stays a valid detection/CSP hint but is not the literal insertion site. A plain TanStack Router SPA takes the baseline Vite path.
+
+## Config drift
+
+On every boot the project is scanned for HTML files under common page roots (`public/`, `src/`, `app/`, `pages/`) that the resolved `files` list does not cover; they surface as `configDrift.orphans` with a hint. Tell the user once per session which files are uncovered and offer to add them or switch `files` to a glob. Never auto-update the config; the user decides. `configDrift` is `null` when there is no drift.
+
+## CSP detection (first-time only)
+
+Keep all allowances below development-only, including manual middleware and meta-tag edits. Do not change a deployed production site's CSP to load the localhost helper; see [live.md](live.md) for production inspection alternatives.
+
+If `config.cspChecked === true`, skip this whole section; the user was already asked once.
+
+```bash
+.cursor/skills/phoenix-ui/scripts/phoenix-ui detect-csp
+```
+
+Output `{ shape, signals }`; the shape names the *patch mechanism*, so one template covers many frameworks:
+
+- **`null`**: no CSP; write the config with `cspChecked: true` and stop here.
+- **`append-arrays`**: CSP as structured directive arrays; auto-patchable (monorepo helpers with `additionalScriptSrc`/`additionalConnectSrc`, SvelteKit `kit.csp.directives`, Nuxt `nuxt-security`).
+- **`append-string`**: CSP as a literal value string; auto-patchable (inline `next.config.*` `headers()`, Nuxt `routeRules`).
+- **`middleware`** / **`meta-tag`**: detected but not auto-patched. Show the user the detected files, ask them to add `http://localhost:8400` to `script-src` and `connect-src` manually, then mark `cspChecked: true` and proceed.
+
+### Consent prompt (use this phrasing)
+
+> **CSP patch needed.** I detected a Content Security Policy in your project that blocks `http://localhost:8400`: the live picker won't load without an allowance. Here's the change I'd make:
+>
+> ```diff
+> [file: <patchTarget>]
+> [exact diff, 2-5 lines]
+> ```
+>
+> It's guarded by `NODE_ENV === "development"` so the extra entry only appears in dev and never reaches production. You can remove it any time by reverting this file. Apply? [y/n]
+
+On "no": skip the patch, note that live will not work until the allowance is added manually, and still write `cspChecked: true` (the question has been asked). On "yes": apply the shape's patch below, then write `cspChecked: true`.
+
+### append-arrays
+
+Declare near the top of the file that holds the CSP arrays, then append `...__phoenixUiLiveDev` to the script-src and connect-src arrays:
+
+```ts
+// Dev-only allowance so phoenix-ui live mode can load. Guarded by NODE_ENV.
+const __phoenixUiLiveDev =
+  process.env.NODE_ENV === "development" ? ["http://localhost:8400"] : [];
+```
+
+Per-framework: Next.js + monorepo helper: edit the *app's* `next.config.*` (not the shared helper), appending to `additionalScriptSrc` / `additionalConnectSrc`. SvelteKit: `svelte.config.js`, `kit.csp.directives['script-src']` and `['connect-src']`. Nuxt + nuxt-security: `nuxt.config.*`, `security.headers.contentSecurityPolicy['script-src']` and `['connect-src']`. Reference outputs: [nextjs-turborepo/expected-after-patch.ts](https://github.com/pbakaus/impeccable/blob/8dac6ae7e020c43ab10ce9b41939f6fd42627b96/tests/framework-fixtures/nextjs-turborepo/expected-after-patch.ts), [sveltekit-csp/expected-after-patch.js](https://github.com/pbakaus/impeccable/blob/8dac6ae7e020c43ab10ce9b41939f6fd42627b96/tests/framework-fixtures/sveltekit-csp/expected-after-patch.js). Idempotency: if `__phoenixUiLiveDev` already exists in the file, the patch is applied; just mark `cspChecked: true`.
+
+### append-string
+
+Two-point patch: declare a dev-only string, interpolate it into the CSP value at both directives (leading space so it concatenates cleanly; convert literals to template strings as part of the edit):
+
+```ts
+// Dev-only allowance so phoenix-ui live mode can load.
+const __phoenixUiLiveDev =
+  process.env.NODE_ENV === "development" ? " http://localhost:8400" : "";
+```
+
+- `script-src 'self' 'unsafe-inline'` becomes `` `script-src 'self' 'unsafe-inline'${__phoenixUiLiveDev}` ``
+- `connect-src 'self'` becomes `` `connect-src 'self'${__phoenixUiLiveDev}` ``
+
+Per-framework: Next.js inline `headers()` in `next.config.*`; Nuxt `routeRules['/**'].headers['Content-Security-Policy']` in `nuxt.config.*`. Reference outputs: [nextjs-inline-csp/expected-after-patch.js](https://github.com/pbakaus/impeccable/blob/8dac6ae7e020c43ab10ce9b41939f6fd42627b96/tests/framework-fixtures/nextjs-inline-csp/expected-after-patch.js), [nuxt-csp/expected-after-patch.ts](https://github.com/pbakaus/impeccable/blob/8dac6ae7e020c43ab10ce9b41939f6fd42627b96/tests/framework-fixtures/nuxt-csp/expected-after-patch.ts).
+
+## Troubleshooting
+
+If the user said "no" to the CSP patch and later reports live not working: their dev CSP blocks `http://localhost:8400`. Delete `cspChecked` from `.phoenix-ui/live/config.json` and re-run `phoenix-ui live`; setup asks again.
+
+After setup, re-run `phoenix-ui live`.

package/vendor/phoenix-ui/bundle/blobs/cfac9eaf96481a8874391e5cecc6149abea1f1f19622f77f1ebb9e1876720e91

@@ -0,0 +1,90 @@
+---
+name: phoenix-ui
+description: 用于前端设计、重设计、局部优化与 live 交互；不用于后端任务、仅维护设计规范或独立 UI 验收。结合项目上下文提供设计命令和本地检测，npm 安装后使用。
+version: 0.1.0
+---
+
+Phoenix UI provides local design tools for frontend work. Follow the project's product truth, accepted direction, and design rules; use the command references to create complete, accessible interfaces with a clear visual direction.
+
+Install this runtime through `@xgent-ai/skills` on npm. Source copies from skills.sh do not include an engine installation. The engine does not update or download during context, detection, or hooks. Explicit `engine install` restores the version pinned by the installed package.
+
+Core principles:
+- Go all out. No hedging, no shortcuts. The deliverable must be complete (except assets the user must provide).
+- Dream big and bold. Distinct, beautiful, outstanding and highly inspiring work.
+- Keep Phoenix design self-QA to one batched inspection and at most one confirmation after fixing the findings. This ceiling applies to the design pass. Independent review-ui/apply-ui-review cycles and work the user has authorized follow their own completion conditions. Finish-reviewer and component-review evidence do not close an independent UI acceptance cycle.
+
+## Setup
+
+1. Run `<skill-base-dir>/scripts/phoenix-ui context` once per session, where `<skill-base-dir>` contains this SKILL.md; keep cwd at the user's project. It resolves every `.gemini/skills/phoenix-ui/scripts/phoenix-ui <verb>` command in this skill and its references. This release supports macOS and Linux. The thin launcher requires Node >=18 and validates the fixed manifest, binary digest and Phoenix engine version before running. Users do not need Rust. Pass a named source file or route as `--target <path>`. It loads PRODUCT.md, DESIGN.md, the matching surface brief, and native-platform guidance; follow its directives.
+   For design facts, also read `.gemini/skills/phoenix-ui/scripts/phoenix-ui context --target <primary-target> --json`: product, design, surfaceBrief, provenance, parseCoverage and conflicts retain their original sources. Read the original when coverage is partial. An explicitly enabled profile provides advice; product truth, accepted directions and frozen targets retain authority. Missing context or a disabled profile supplies no template defaults. If JSON mode is unavailable, read the originals directly and disclose that the profile and brief mapping were not loaded; do not install or upgrade as a side effect.
+2. Load the request's playbook: its Commands-table reference for an explicit/implied sub-command, or [reference/new-work.md](reference/new-work.md) for a new surface or replacement visual world. Inspect target and incumbent visual truth before editing. When the app cannot run, start with committed visual-regression goldens or screenshot fixtures; verify target and freshness against current tokens, CSS, components, or assets, resolve conflicts, and compare theme/variant captures.
+3. After resolving analysis and direction, read [reference/craft-floor.md](reference/craft-floor.md) immediately before any UI edit, including small refinements. It carries the quality floor, the absolute bans, and the reflexes no detector catches. Do not load it for planning-only work.
+
+**Launcher unavailable:** On refusal or failure, send a separate message **before the next tool call**: “Context loading did not run; I’ll read the existing project context directly.” Then read existing PRODUCT.md and DESIGN.md without inventing missing context, follow applicable steps 2–3, and continue through permitted tools. This applies to planning and editing; launcher failure alone does not block either.
+
+## How to design
+
+- **The brief wins.** Honor pinned aesthetics, eras, materials, fonts, and palettes even when they conflict with a saturated-pattern warning. Redirecting a clear brief toward your taste is failure.
+- **Refinement preserves; redesign replaces.** Refinement keeps the incumbent identity, behavior, copy, and everything outside scope. Ask before replacing factual copy or adding claims. Redesign keeps product truth, content, function, native affordances, and constraints; choose a replacement world within the authorized scope. Changes to an existing DESIGN.md follow design-md's writing authority and the user's accepted decisions. Record approval for changes to frozen targets before replacing them.
+- **Visual authority is evidence, not a filename.** Missing DESIGN.md alone does not make a project greenfield; new-work decides whether to preserve, expand, or replace the incumbent world.
+
+## Modes
+
+The mode names what the visitor's success looks like on this surface.
+
+- **Persuade:** the visitor decides and acts; design is the product. Landing pages, marketing, campaigns, pricing. Earn attention and action. Ship real imagery when the brief needs it; follow the committed world, not category habit.
+- **Operate:** the visitor completes a task. App UI, dashboards, editors, admin, settings, tools. Scanability, consistency, native expectations, and the real usage scene outrank expression. Brand lives in precise details.
+- **Read:** the visitor understands something. Docs, articles, guides, help, changelogs. Structure for comprehension, then make the reading experience worth staying in.
+- **Experience:** the visitor is inside the work itself. Portfolios, galleries, showcases. Let the artifact lead from the first viewport; the interface recedes.
+
+Choose the mode from the requested surface, not the product, and persist it only in that surface brief. A tool's landing page is still Persuade; a fashion house's documentation is still Read; a docs index is Read, not Persuade. See [new-work.md](reference/new-work.md) for new surfaces and [operate.md](reference/operate.md) for deeper Operate/Read guidance.
+
+## Commands
+
+| Command | Category | Description | Reference |
+|---|---|---|---|
+| `craft [feature]` | Build | Deprecated alias for an ordinary new-work request | [reference/craft.md](reference/craft.md) |
+| `shape [feature]` | Build | Plan UX/UI before writing code | [reference/shape.md](reference/shape.md) |
+| `init` | Build | Capture durable product context in PRODUCT.md | [reference/init.md](reference/init.md) |
+| `document` | Build | Generate DESIGN.md from existing project code | [reference/document.md](reference/document.md) |
+| `extract [target]` | Build | Pull reusable tokens and components into design system | [reference/extract.md](reference/extract.md) |
+| `critique [target]` | Evaluate | UX design review with heuristic scoring | [reference/critique.md](reference/critique.md) |
+| `audit [target]` | Evaluate | Technical quality checks (a11y, perf, responsive) | [reference/audit.md](reference/audit.md) · native: [reference/audit.native.md](reference/audit.native.md) |
+| `polish [target]` | Refine | Final quality pass before shipping | [reference/polish.md](reference/polish.md) |
+| `bolder [target]` | Refine | Amplify safe or bland designs | [reference/bolder.md](reference/bolder.md) |
+| `quieter [target]` | Refine | Tone down aggressive or overstimulating designs | [reference/quieter.md](reference/quieter.md) |
+| `distill [target]` | Refine | Strip to essence, remove complexity | [reference/distill.md](reference/distill.md) |
+| `harden [target]` | Refine | Production-ready: errors, i18n, edge cases | [reference/harden.md](reference/harden.md) |
+| `onboard [target]` | Refine | Design first-run flows, empty states, activation | [reference/onboard.md](reference/onboard.md) |
+| `animate [target]` | Enhance | Add purposeful animations and motion | [reference/animate.md](reference/animate.md) |
+| `colorize [target]` | Enhance | Add strategic color to monochromatic UIs | [reference/colorize.md](reference/colorize.md) |
+| `typeset [target]` | Enhance | Improve typography hierarchy and fonts | [reference/typeset.md](reference/typeset.md) |
+| `layout [target]` | Enhance | Fix spacing, rhythm, and visual hierarchy | [reference/layout.md](reference/layout.md) |
+| `delight [target]` | Enhance | Add personality and memorable touches | [reference/delight.md](reference/delight.md) |
+| `overdrive [target]` | Enhance | Push past conventional limits | [reference/overdrive.md](reference/overdrive.md) |
+| `clarify [target]` | Fix | Improve UX copy, labels, and error messages | [reference/clarify.md](reference/clarify.md) |
+| `adapt [target]` | Fix | Adapt for different devices and screen sizes | [reference/adapt.md](reference/adapt.md) · native: [reference/adapt.native.md](reference/adapt.native.md) |
+| `optimize [target]` | Fix | Diagnose and fix UI performance | [reference/optimize.md](reference/optimize.md) |
+| `live` | Iterate | Visual variant mode: pick elements in the browser, iterate on alternatives | [reference/live.md](reference/live.md) |
+| `generate [n] [action] [element]` | Iterate | Variants, versions, or alternatives of a named element to choose from in the live browser; no manual picking | [reference/generate.md](reference/generate.md) |
+
+Routing:
+
+- **Continue an accepted direction for this target:** reuse the original brief returned by context. A matching accepted hash restores the direction across sessions without another interview or concept roll. A stale, missing or ambiguous mapping requires resolving the original source and acceptance decision; do not select by mtime or silently accept changed bytes. If the user requests a different direction, record that change scope and use design-reference for the new choice.
+- **Visual references/direction:** use design-reference. **Interaction-pattern choice:** use ui-pattern-research. **Create/update DESIGN.md:** use design-md's source and writing rules. Phoenix shape consumes the accepted interaction choice and develops the remaining surface decisions.
+- **Independent UI acceptance:** route to review-ui; an existing UI report routes repairs to apply-ui-review. If the required skill is unavailable, report that prerequisite rather than claim Phoenix's design review completed that acceptance.
+- **No argument:** read [routing.md](reference/routing.md) and present its context-aware menu; never auto-run a command.
+- **Explicit or clearly implied request to run a command:** load its reference (native variant on native platforms) and follow it. Ask once if two commands fit.
+- **Workflow or command-selection question:** read [Workflow questions](reference/routing.md#workflow-questions).
+- **Otherwise:** treat the request as general design work. Missing PRODUCT.md routes a new surface or replacement world through init, then new-work; a narrow refinement of existing code proceeds on the incumbent implementation as `phoenix-ui context` directs, offering init afterward rather than blocking on it.
+- `teach` aliases `init`. `craft` is a deprecated alias for ordinary new-work and adds nothing. `shape` owns task discovery, then enters new-work only for visual-world and surface-concept decisions.
+
+After an authorized context or brief write, refresh `context --target <primary-target> --json` before using the changed facts. Init loads the native platform reference itself when the platform it recorded is `ios`, `android`, or `adaptive`.
+
+**Pin / Unpin:** `.gemini/skills/phoenix-ui/scripts/phoenix-ui pin <pin|unpin> <command>` creates or removes a standalone `/<command>` shortcut. Report the script's result concisely; relay stderr verbatim on error.
+
+**Hooks:** `/phoenix-ui hooks <on|off|status|ignore-rule|ignore-file|ignore-value|reset>` manages the design detector hook for this project (auto-runs the detector after UI file edits and surfaces findings). Load [reference/hooks.md](reference/hooks.md) when the user invokes it with any argument.
+
+**Doctor:** `/phoenix-ui doctor` reports and repairs drift between this project's Phoenix UI artifacts (PRODUCT.md, DESIGN.md and its sidecar, config, surface briefs, the hook) and what this version reads. Load [reference/doctor.md](reference/doctor.md) when the user invokes it, or when they ask what is out of date, stale, or needs refreshing. A `CONTEXT_STALE` directive in Setup's output is the cheap subset of the same report; act on it there per its own instructions rather than running doctor unasked.
+
+**Never repair drift as a side effect of a design task.** A `CONTEXT_STALE` finding is reported, not acted on, unless the user asks. The one exception is a finding marked `auto`, which the next write to that file performs anyway.