@ccoalm/ccl-skills 0.7.0 → 0.9.0

package/dist/assets/marketplace/plugins/ccl-skills/skills/product-ui-ux-design/references/layout-recipes-and-screenshot-acceptance.md

@@ -4,25 +4,28 @@ Use this reference when a design task risks becoming "rule-compliant but plain".
 
 This file is distilled from current Figma rules and frontend implementation evidence. Source product terms are provenance only; do not copy them into new-product UI.
 
-## Non-Negotiable Adaptation Defaults
+## Adaptation Test Setup
 
 Do this before drawing or coding any nontrivial page:
 
-1. Pick the screen family: desktop workbench, consumer web, mobile app/H5, dense table/list, structured editor, scan/upload/review, analytics/tracking, or resource/library.
-2. Pick the primary viewport and two stress viewports:
-   - Desktop workbench: 1440x810 first, then wider desktop and a narrow desktop/tablet width.
+1. Pick the rendered family and task shape: React or other Web, mobile app/H5, mini-app host/page, ordinary CLI or full-screen terminal/TUI, Electron/desktop/TV shell, dense table/list, structured editor, scan/upload/review, analytics/tracking, or resource/library. For an unlisted client, name its installed owner or fail-closed project convention before choosing adaptation evidence.
+2. Derive the primary viewport and stress viewports from the product's supported-device matrix, analytics, host constraints, or existing repository configuration. If no stronger source exists, use these only as provisional test seeds and record that evidence gap:
+   - Desktop workbench: one representative desktop frame, then a wider frame and a narrow desktop/tablet width; 1440x810 is a useful seed, not a universal target.
    - Consumer web: content column and optional rail at desktop, then one tablet/narrow width and one mobile width.
-   - Mobile app/H5: 393x852 first, then 375x812 and 428x926; if the task supports landscape or review, also check about 874x402.
+   - Mobile app/H5: one representative shipped device, a narrower/shorter stress device, and a larger device; 393x852, 375x812, and 428x926 are useful seeds. If the task supports landscape or review, add a representative landscape frame such as 874x402.
+   - Mini-app: use the shipped host/tool and at least one real supported device class; include host chrome, safe area, permission/capability, package/platform, and any embedded web-view constraints.
+   - Ordinary CLI or terminal/TUI: cover TTY and non-TTY/plain modes as applicable, representative narrow/default/wide dimensions, color/capability fallback, long/localized output, keyboard/focus/resize/scrollback only where the contract uses them, and the actual command/help/exit/recovery path.
+   - Electron/desktop/TV shell or other Web renderer: use the actual content owner plus shell owner/project convention; exercise supported window/display sizes, scaling, focus/input, host bridge, and content-shell integration rather than borrowing the generic browser matrix.
 3. Assign fixed or bounded regions before spacing polish: shell/header, context/filter row, primary region, secondary panel, feedback region, and action area.
 4. Decide the collapse rule: secondary panel, side rail, preview, filters, and metadata collapse before the primary content becomes unreadable. Do not just shrink everything.
 5. Decide the density mode and spacing scale. Productive compact and consumer relaxed use different page padding, control height, row height, and card breathing room.
 6. Map long text, no data, partial data, permission blocked, loading, error, and keyboard/safe-area states into the same geometry as the happy path.
 
-If a design or implementation skips these decisions, it is not ready for UI review even if the component choices are correct.
+If a design or implementation skips these decisions, it is not ready for UI review even if the component choices are correct. Numeric ranges in the recipes below are source-derived starting heuristics; they become acceptance criteria only when the current product source or a recorded decision adopts them and rendered evidence exercises the relevant stress case.
 
-## Four-Layer Quality Pass
+## Quality Lenses For Layout Proof
 
-Use the canonical four-layer order from `design-execution-checklist.md` after choosing a recipe and before coding, screenshot review, or acceptance. In this reference, translate that order into layout proof:
+After choosing the delivery profile in `design-execution-checklist.md`, apply the relevant structure, interaction, behavior, and aesthetic lenses before coding, screenshot review, or acceptance. Translate them into layout proof:
 
 - Aesthetic proof: visible layer model, rhythm, density, alignment, color weight, and one primary focus.
 - Interaction proof: visible entry point, current task, next action, progressive disclosure, and return path.
@@ -31,9 +34,9 @@ Use the canonical four-layer order from `design-execution-checklist.md` after ch
 
 If one layer is missing, the screen is incomplete even when it passes component and token checks.
 
-## Universal Layout Recipe
+## Shared Composition Pass
 
-Every nontrivial screen needs a visible composition before component styling:
+Before component styling, name the applicable composition roles for a nontrivial screen; mark a role non-applicable with the surface/task reason instead of forcing every product into one shell:
 
 1. Shell: global nav, account/context, route title, and persistent feedback providers.
 2. Context row: current scope, mode, filters, selected object, permission or trust state.
@@ -43,7 +46,7 @@ Every nontrivial screen needs a visible composition before component styling:
 6. Return loop: back/close, save draft, retry, undo, next item, or route-preserved selection.
 7. Annotation and flow support: for complex tasks, expose the user's current step, decision point, hot zone, affected object, and measurement/status cue through concise labels, markers, progress steps, or tooltips rather than forcing users to infer the workflow from raw layout.
 
-If a screen cannot be described by this recipe, it is probably a marketing page, a raw component dump, or an unfinished placeholder. Data-driven empty workbenches are valid when they still expose module structure and next action.
+When these roles do not fit, choose a surface-specific structure and record why it supports the representative task. A marketing page can legitimately use a different composition; a raw component dump or unfinished placeholder cannot pass merely by resembling this list. Data-driven empty workbenches are valid when they still expose module structure and next action.
 
 ## Productive Web Workbench
 
@@ -56,7 +59,7 @@ Use for creator tools, moderation, analytics, AI review, asset management, and o
 - Header: compact title/context/action row, usually 48-64px high. Avoid a second oversized title inside the page.
 - Control bar: filters, segmented mode, search, upload/generate action, and selected scope in one compact band. Prefer 32-40px controls.
 - Status strip: small facts such as scope, source, permission, job state, model/cost, data freshness, or selected count. Keep it one line when possible.
-- Desktop baseline: many source workspaces use 1440x810 frames with 64px navigation/header bars. Use this as a practical first screenshot target, then check wider desktop and narrow responsive behavior.
+- Desktop seed: many source workspaces use 1440x810 frames with 64px navigation/header bars. Use this only when it represents the current product or as a provisional first screenshot, then check wider desktop and narrow responsive behavior.
 - Workbench body: use one of these structures:
   - Library/resource workspace: left tree/source rail around 240px, top filter/search band, sticky filter state, content cards/table in the main region, preview/download/share/edit actions near the object.
   - Split review: left list/source/input 280-360px, center preview/result flexible, right settings/metadata 320-420px.
@@ -71,7 +74,7 @@ Use for creator tools, moderation, analytics, AI review, asset management, and o
 - Data-driven workbenches are valid: modules may appear, disappear, reorder, or change status based on permissions, jobs, saved drafts, metrics, or configured workflows. The requirement is that the empty/loading/no-permission shape still exposes the intended module grid, next action, and future data slots instead of collapsing into an unstructured placeholder.
 - Table, modal, empty, alert, progress, metric, and chart components must be selected by task role. A table needs stable row/header/action behavior; a modal needs decision and return context; an empty state needs next action; a chart needs drill-down or explanation; an alert needs scope and consequence.
 
-Good workbench screens make the next operator action obvious within five seconds.
+In representative tasks, operators should be able to identify the current object, current state, and next relevant action without guessing or opening unrelated regions. Verify that outcome with task-based review, not an arbitrary time threshold.
 
 ## Consumer Web Recipe
 
@@ -88,7 +91,7 @@ Use for feed, detail, profile, community/topic, notification, and creator-facing
 
 Use for app/H5 consumer surfaces and focused mobile task flows.
 
-- Mobile baseline: check 393x852 portrait as a primary app/H5 target. For media/review tasks that support landscape, also check a landscape frame around 874x402.
+- Mobile seed: when no stronger device matrix exists, start with a 393x852 portrait frame and a narrower/shorter stress frame. For media/review tasks that support landscape, also check a representative landscape frame such as 874x402.
 - Aesthetic logic: mobile screens should have one clear focus per viewport. Use compact rhythm for repeated tasks and warmer spacing for discovery or creation, but keep tap targets reliable.
 - Interaction logic: design around thumb reach, back/close clarity, bottom-sheet focus, keyboard appearance, and foreground/background recovery. Landscape modes need a new toolbar and preview arrangement, not a rotated portrait layout.
 - Behavioral psychology: mobile users are interruption-prone. Preserve draft/input/progress when the app backgrounds, explain disabled actions, and keep the active input/action visible when the keyboard or safe area changes the viewport.
@@ -108,7 +111,7 @@ Use for app/H5 consumer surfaces and focused mobile task flows.
 Use for analytics, moderation queues, asset libraries, admin settings, and review backlogs.
 
 - Top row: search/filter/segmented mode left, primary action right, selected count/status visible.
-- Management baseline: use a 1440x810 working frame with a 64px-class page header when designing table/list management pages; long configuration pages may extend vertically to 1254px-wide content sections.
+- Management seed: when it matches the current product, use a 1440x810 working frame with a compact page header for table/list management pages; derive long-page content width from the product grid and content rather than treating a source frame as a standard.
 - Filter stack: cascade selector, tabs, keyword search, status/date/source filters, and bulk action entry should be grouped before the table/list. Avoid scattering filters across unrelated cards.
 - Table/list: zebra or subtle row separation is acceptable; hover should preserve row identity and may highlight the hovered column for comparison-heavy data.
 - Table header/cell system: define header label, sortable/selected state, row lead action, row secondary actions, cell truncation, status badges, and responsive hidden/wrapped columns before implementation.
@@ -161,7 +164,7 @@ Use for media ingestion, file parsing, AI extraction, moderation/review queues,
 - Adaptation: support one item vs multiple items, single focus vs side-by-side comparison, and portrait/landscape review where relevant.
 - Unsupported input: explain what is unsupported and what the user can still upload, retry, replace, or skip.
 - High-throughput evaluation screenshot set: capture at least single-item, multi-item, long-content, empty/delayed artifact, completed item, unsupported automation, and active automation-config states.
-- Evaluation header acceptance: queue/progress, display-count controls, view/reference tools, and session actions should read as grouped regions in the 64px-class header. The progress count must stay visible at 1440x810 and the narrow desktop stress width.
+- Evaluation header acceptance: queue/progress, display-count controls, view/reference tools, and session actions should read as grouped regions in the product's compact header. The progress count must stay visible at the recorded primary desktop width and its narrow stress width.
 - Evaluation canvas acceptance: selected item or sub-unit boundary, current metadata strip, retry/loading shell, and bottom/session tool state must remain visible when switching between one-item, multi-item, and long-artifact layouts.
 - Automation-config acceptance: left item list keeps item hierarchy and enable switch state; middle panel shows either an enablement prerequisite or strategy/config controls; right panel keeps required context/reference/rationale fields stable; result-use mode remains visible near final save.
 - Long reference/output acceptance: short content still has a readable minimum block, long content caps at a declared height and scrolls inside the panel, and the dialog or workbench does not grow beyond the viewport.
@@ -238,7 +241,7 @@ When implementing from a design or creating a new screen in code, verify these a
 Before calling a UI done, inspect desktop and mobile/narrow screenshots where relevant:
 
 - First viewport: primary workflow is visible; the screen is not mostly banner, blank illustration, or unrelated dashboard content.
-- Hierarchy: the eye lands on the right object/action within five seconds.
+- Hierarchy: the intended object/action leads for the representative task; verify it through task-based review rather than an arbitrary time threshold.
 - Geometry: shell, control bar, primary region, secondary panel, and feedback state align to a clear grid.
 - Density: no large dead zones; no nested-card clutter; no card-in-card framing unless the inner card is a repeated item or modal content.
 - States: happy, empty, loading, error, disabled/permission, long-content, and narrow-width states keep the same layout logic.

package/dist/assets/marketplace/plugins/ccl-skills/skills/product-ui-ux-design/references/multi-project-token-consistency.md

@@ -23,7 +23,7 @@ For cross-stack design coordination, route to `multi-stack-strategy.md` first.
 
 ## Rules
 
-- **UI-kit stack uniqueness per end-platform**: within one product, all desktop subprojects use the same desktop UI-kit family; all mobile-H5 subprojects use the same mobile UI-kit family. A subproject choosing a different UI-kit family inside the same stack is treated as an outlier and must have an explicit retirement or isolation plan. The specific UI-kit family is a per-team decision recorded in the project's design-system file or architecture doc — it is not a recommendation from this skill. **Strong detection signal worth investigating**: a single subproject's `package.json` simultaneously depending on a desktop UI-kit (`antd` / `@mui/material` / `@mantine/core` / `@chakra-ui/react`) **and** a mobile UI-kit (`antd-mobile` / `@ionic/react` / `react-onsenui` / `vant`) is presumptively an off-stack outlier. The presumption can be cleared (without ignoring the rule) by a documented reason — a migration in progress with a known retirement plan, a deliberate adaptive UI-kit choice serving desktop+H5 from one package, a storybook / demo / lint / test dep that does not ship to runtime, or an unused dep awaiting removal. Without such a documented reason, the mixed dependency is the outlier and is owned by the subproject for fix or isolation. Per `multi-stack-strategy.md`, code-grep alone cannot distinguish accidental drift from a design-driven exception — the dependency signal triggers an audit, not an automatic verdict.
+- **UI-kit stack uniqueness per end-platform**: within one product, every same-stack subproject uses the same canonical UI-kit/component family for that rendered stack—React or other web, H5, native mobile, mini-app, terminal/TUI, Electron/desktop, TV, or another client. A subproject choosing a different family inside the same stack is an outlier and needs an explicit retirement or isolation plan. The concrete family is a per-team decision recorded in the project's design-system or architecture record, not a recommendation from this skill. Dependency manifests, platform configs, import graphs, and runtime composition are detection evidence; a Web `package.json` mixing desktop and mobile kits is one illustrative signal, not the universal detector. A documented migration, adaptive family, non-runtime dependency, or pending removal may clear the presumption. Per `multi-stack-strategy.md`, source search alone cannot distinguish accidental drift from a design-driven exception—the signal triggers an audit, not an automatic verdict.
 - **Theme must be shared, not copied**: all same-stack subprojects share one theme source — a published internal npm package, a monorepo workspace module, or an explicitly imported shared module. Each subproject copying its own `theme.ts` is anti-pattern; tokens will drift the moment one subproject ships a brand tweak.
 - **Theme must be explicitly injected**: every subproject that depends on the brand theme injects it explicitly at the entry layer — `ConfigProvider theme={brandTheme}` at the root component or a framework-level config (`antd: { theme }` in UmiJS, `ThemeProvider` in styled-components, etc.). A subproject that ships with no theme injection silently inherits the UI-kit default and drifts away from the brand on day one.
 - **Theme injection partial-customisation is leak**: a `ConfigProvider` that overrides only one component (e.g. `Tree.titleHeight: 32`) while leaving `colorPrimary` at default is worse than no injection — it signals "we have a theme" while shipping the default color. Either inject the full brand theme or remove the partial injection.
@@ -61,7 +61,7 @@ known_loss: <which of the data-loss modes above apply to this export shape>
 
 ## Design-Source Health Check (Pre-Consumption Gate)
 
-Before any downstream stack (web desktop, web H5, native app, mini-program) is told to **align with** a design-system token source, run this health check on the source itself. The cross-source validation procedure that follows assumes each source is internally consistent; if a source is internally broken, alignment work copies the brokenness into every downstream stack and the cross-source drift gets harder to detect, not easier.
+Before any downstream stack (React or other web, web H5, native app, mini-program, terminal/TUI, Electron/desktop, TV, or another rendered client) is told to **align with** a design-system token source, run this health check on the source itself. The cross-source validation procedure that follows assumes each source is internally consistent; if a source is internally broken, alignment work copies the brokenness into every downstream stack and the cross-source drift gets harder to detect, not easier.
 
 The gate runs against the source artifact (Figma file, token JSON export, theme package, or whichever shape the team's source-of-truth ships). It is a precondition, not a one-off; re-run when the source has a material change.
 
@@ -143,7 +143,7 @@ A code search for raw token values (the color-literal detection above, or any "i
 - **inline style objects** — `style={{ backgroundColor: … }}` / `:style` bindings / equivalent;
 - **imperative config / option objects** — dialog / toast / sheet option fields (e.g. a confirm-dialog's color field), chart option palettes, and other JS-config color strings.
 
-Before reporting a token migration complete or a surface drift-free, enumerate the stack's component-layer color sites and grep them **alongside** the stylesheets. The owning stack skill (`web-react-dev` / `app-cross-platform-dev` / `miniapp-product-dev`) owns the concrete prop / option names for its component set; this rule owns the two-layer requirement. Color literals are the most common case, but the two-layer requirement generalizes to any token class with a component-layer site (typography / spacing / radius props, theme-option objects); the stack skill names those sites per class. The same caveat applies in reverse to the slot-name false-positive trap above — a slot that exists is not a slot that carries the brand, and a value that is absent from the stylesheet is not a value that is absent from the surface.
+Before reporting a token migration complete or a surface drift-free, enumerate the stack's component-layer color sites and grep them **alongside** the stylesheets. The complete affected client-owner set in `delivery-contract.md` owns the concrete prop / option names for each component set: React web → `web-react-dev`; other web → its installed owner or project convention; native mobile → `app-cross-platform-dev`; mini-app → `miniapp-product-dev`; terminal/TUI → `terminal-cli-dev`; Electron/desktop/TV → its installed owner or fail-closed project convention. This rule owns the two-layer requirement. Color literals are the most common case, but the two-layer requirement generalizes to any token class with a component-layer site (typography / spacing / radius props, theme-option objects); the owning client skill names those sites per class. The same caveat applies in reverse to the slot-name false-positive trap above — a slot that exists is not a slot that carries the brand, and a value that is absent from the stylesheet is not a value that is absent from the surface.
 
 ## Token Cross-Source Validation Procedure
 
@@ -210,10 +210,10 @@ Audits routinely produce confidently-wrong verdicts when the auditor reasons fro
 
 When auditing or starting multi-project token work:
 
-1. List every subproject and its UI-kit (read `package.json` deps). Confirm they fit the stack-uniqueness rule. Outliers = the off-stack-outlier anti-pattern; route to multi-stack strategy.
-2. For each same-stack subproject, find the theme injection point (`ConfigProvider`, framework config, `ThemeProvider`). Classify as: **full custom** / **partial custom (single prop)** / **none (default)**.
+1. List every subproject, rendered stack, and UI-kit/component family using the stack's manifest, platform config, import graph, and runtime entry—not only Web `package.json`. Confirm they fit the stack-uniqueness rule. Outliers route to multi-stack strategy.
+2. For each same-stack subproject, find the actual theme injection or token-consumption point: Web provider/framework config, native theme object/asset catalog, mini-app host config, terminal palette/style registry, or Electron/desktop/TV owner convention. Classify it as **full custom** / **partial custom** / **none (default)**.
 3. If any subproject is in **partial** or **none**: that subproject is silently off-brand. File a fix or document a deliberate exception.
-4. Find the theme source file (or pkg) and confirm it is imported, not copied. If multiple subprojects have their own `theme.ts` with different values, the brand has already drifted; pick the canonical source and migrate.
+4. Find the theme source artifact or package and confirm it is consumed, not copied. If multiple same-stack subprojects carry divergent local theme artifacts, the brand has already drifted; pick the canonical source and migrate through the affected client owners.
 5. Cross-check token naming alignment: the design-source names (e.g. semantic-tokens in the design-system Figma file) should map to the code-token names by an explicit dictionary. If the dictionary does not exist, build it before refactoring.
 
 ## Anti-Patterns
@@ -231,7 +231,5 @@ When auditing or starting multi-project token work:
 
 ## Routing
 
-- Implementation tooling (shared theme package, automated check that every subproject imports the shared theme) → `web-react-dev`.
-- Mobile / native equivalent (`MaterialApp.theme`, `UIAppearance`) → `app-cross-platform-dev`.
-- Mini-app equivalent (mini-app `app.json` theme and host-platform theme constraints) → `miniapp-product-dev`.
+- Implementation tooling and theme enforcement follow the complete affected client-owner set in `delivery-contract.md`: React web → `web-react-dev`; Vue/Svelte/other web → its installed owner or project convention; Flutter/RN/native mobile (`MaterialApp.theme`, `UIAppearance`) → `app-cross-platform-dev`; mini-app (`app.json` and host constraints) → `miniapp-product-dev`; terminal/TUI theme/color behavior → `terminal-cli-dev`; Electron shell and other desktop/TV runtimes → their installed owner or the fail-closed project-convention lookup. A shared theme package never becomes React-owned merely because one consumer uses React.
 - Test acceptance (screenshot diff on canonical components per subproject; runtime assert that primary color matches brand) → `testing-strategy`.

package/dist/assets/marketplace/plugins/ccl-skills/skills/product-ui-ux-design/references/multi-stack-strategy.md

@@ -12,10 +12,10 @@ Load this reference when a product spans **more than one client stack** — for
 
 ## Rules
 
-- **Map the product's stack landscape before drawing rules**: list every subproject and tag it `web-desktop` / `web-h5` / `mobile-rn` / `mobile-native-android` / `mobile-native-ios` / `mini-app` / `legacy`. A product is "multi-stack" the moment two of these coexist on the same brand.
+- **Map the product's stack landscape before drawing rules**: list every subproject and tag it `web-desktop` / `web-h5` / `other-web` / `mobile-rn` / `mobile-native-android` / `mobile-native-ios` / `mini-app` / `terminal-tui` / `desktop-tv-shell` / `legacy`. A product is "multi-stack" the moment two of these coexist on the same brand.
 - **One stack = one UI-kit family**: within each stack, pick one UI-kit family (see multi-project-token-consistency). Mixing two UI-kit families inside the same end without a stated migration plan is anti-pattern. The specific families a team uses are a project-level decision and live in the project's design-system file or architecture doc, not here.
 - **Feature-domain capability-library isolation may be acceptable when the design source requires capabilities beyond the stack's canonical UI-kit/design-system**: the one-UI-kit-family rule is the unification baseline, not an absolute. This exception applies **only** to feature-local capability add-ons — specialized notification / toast / alert / modal / overlay / editor / chart / scanner-bridge / canvas / annotation / media-player libraries layered alongside the canonical UI-kit. It never authorizes a second UI-kit family for canonical surface area: tokens, theme, layout primitives, forms, tables, navigation, and page shell remain under the unify-stack audit. Within that scope, isolation is design-driven only when **all** of the following hold: (a) the **active team-authored A1** design-system source (classified per `design-system-source-of-truth.md` — a file labeled "design system" may be a third-party mirror; mirrors don't count) contains zero components of the relevant capability class; (b) the feature-area design file contains explicit extended forms (multi-size variants, in-domain teaching/help patterns, multi-step modal flows, hardware-aware states, or other concrete capability extensions visible as separate frames) that the canonical library **cannot express without one-off local reimplementation or unacceptable UX loss** — verify against the canonical runtime UI-kit's component docs, not Figma alone; (c) the exception is recorded with all required fields below. Missing any of (a)/(b)/(c) → treat as accidental drift and apply the unify-stack rule. **Required exception-record fields** (in the project alias map or private provenance archive, optionally mirrored to the subproject README — pick the location appropriate for project confidentiality, but recording is mandatory, not optional). The field set is shaped by which branch fired: **A1-present branch** — capability class; exact package and feature-path boundary that is exempt (everything outside the boundary stays under unify-stack audit); owner + exception date; design-source node id and revision/version marker for both the A1 file and the feature file; recheck trigger (re-evaluate when the canonical design system adds the capability class, or when either source frame's revision/version stamp changes). **Green-field/provisional branch** (when no A1 Figma design system exists yet per `design-system-source-of-truth.md` provisional path) — capability class; exact package and feature-path boundary; owner + exception date; `A1 source: absent (provisional)`; canonical runtime UI-kit version + docs link verified to lack the capability; shared primitives audited (list what was checked); feature design file node id and revision; provisional status flag; recheck trigger fires when A1 lands or when the feature file's revision changes. In either branch, missing any required field for that branch's field set → the exception does not exist and the unify-stack rule applies.
-- **Design system should split by stack, not by product feature**: a single Figma "design system" covering desktop + H5 + native usually under-serves at least one stack. Split desktop and mobile design-system files; for mini-app or native-platform-specific tokens, split further only if there is real divergence (HIG/Material guidance, system fonts, touch targets).
+- **Design system should split by rendered stack, not by product feature**: a single design-system source covering every end usually under-serves at least one. Inventory React and other web, H5, native mobile, mini-app, terminal/TUI, Electron/desktop, and TV consumers; assign each to the applicable canonical source or record an explicit shared-source decision with stack-specific variants and evidence. Split only where real divergence exists, but never omit a stack because the examples emphasize desktop/mobile.
 - **Outlier stacks need a documented retire/isolate/coexist plan**: if exactly one subproject runs an off-stack family inside an otherwise unified organization (a single Vue island in a React organization is one illustrative shape), decide explicitly: retire (set a date), isolate (declare it permanently independent and exclude from brand drift checks), or coexist (write down the shared layer). A silent outlier silently leaks brand inconsistency.
 - **No-dominant-stack early phase**: if the portfolio has no dominant stack yet (every subproject picked its own framework + UI-kit, no consolidation pressure has been applied), the retire/isolate/coexist framing does not apply — there is nothing to be an outlier *of*. The prior decision is "which stack(s) does the organization commit to long-term?", which is a product/business call, not a design call. Route to `product-rd-workflow` for the stack-commitment decision. If the consuming organization has external strategy or ideation support installed, `product-rd-workflow` may use it through local skill discovery; otherwise escalate the stack-commitment question to the human owner or record it as `unresolved` in the active audit's notes, and do not apply the retire/isolate/coexist framing in this file until that prior decision is landed.
 - **Native + WebView + H5 hybrid is a contract, not a coincidence**: when a product ships as a native shell wrapping an H5 module, the shell owns chrome/storage/safe-area/orientation/upload-bridge/back-gesture; the H5 owns content/state/business logic. Crossing the line — H5 controlling status bar, shell rendering business UI — is the cause of most "the iPhone version looks weird" bugs. Document the contract; do not rely on each engineer's intuition.
@@ -27,10 +27,12 @@ A frontend monorepo with multiple packages is its own mini-source-set. Classify
 
 | Class | Definition | Routing |
 |---|---|---|
-| **web** | Browser-targeted application (consumer web, admin console, ops dashboard, marketing site, H5) | `web-react-dev` (or the language-specific web skill) |
-| **native** | Mobile / desktop / TV client (Flutter, native iOS, native Android, RN, Electron) | `app-cross-platform-dev` |
+| **web** | Browser-targeted application (consumer web, admin console, ops dashboard, marketing site, H5) | React → `web-react-dev`; Vue/Svelte/static/vendor/other web → its installed web-content owner or the fail-closed project-convention lookup |
+| **native-mobile** | Flutter, React Native, native iOS, or native Android app | `app-cross-platform-dev` |
+| **desktop/TV shell** | Electron, native desktop, or TV client | Electron renderer → actual web-content owner; Electron shell → installed desktop-shell owner or project client convention. Other desktop/TV runtimes → their installed owner or the same fail-closed project-convention lookup; do not route them to `app-cross-platform-dev` merely because they are non-browser clients. |
 | **mini-app** | Host-platform mini-program client (WeChat, Alipay, Douyin, Baidu, Taro/uni-app mini-program target) | `miniapp-product-dev` |
-| **pkg-shared** | Reusable library / SDK consumed by app packages (shared components, hooks, types, design tokens, business primitives) | Routes per platform: web-facing rules → `web-react-dev`, app-facing rules → `app-cross-platform-dev`, design-system rules → `product-ui-ux-design` |
+| **terminal-tui** | Command tree, help/output contract, terminal workflow, ANSI renderer, or full-screen TUI | `terminal-cli-dev` for user-facing terminal behavior; language owner may implement parser/library mechanics |
+| **pkg-shared** | Reusable library / SDK consumed by app packages (shared components, hooks, types, design tokens, business primitives) | Route every affected consumer: React web → `web-react-dev`; other web → its installed owner or project convention; native mobile → `app-cross-platform-dev`; mini-app → `miniapp-product-dev`; terminal/TUI → `terminal-cli-dev`; desktop/TV shell → its installed owner or fail-closed project convention; design judgment → `product-ui-ux-design` |
 | **infra** | Build / tooling / dev infrastructure (CI scripts, codegen, lint config, monorepo manager, deploy/release pipelines, server-side renderers, edge config) | Mostly routing-internal; concrete rules live in the relevant implementation skill's "release/build" section |
 | **legacy** | Archived or deprecated package, kept for reference (pre-migration, retired surface, abandoned experiment) | Excluded as a positive baseline; provenance only |
 
@@ -42,9 +44,9 @@ When starting a multi-stack task:
 
 1. List every subproject and tag its stack family. Identify which are `current` and which are `legacy` / `outlier`.
 2. For each stack, confirm the canonical UI-kit family is set. Outliers raise an explicit retire/isolate/coexist decision (record in private archive).
-3. For each end-platform stack (desktop, mobile H5, mobile native, mini-app), confirm one design-system file owns its tokens (see design-system-source-of-truth).
+3. For each rendered stack in the inventory—React or other web, H5, native mobile, mini-app, terminal/TUI, Electron/desktop, TV, or another client—confirm which canonical design-system source owns its tokens and stack-specific variants (see design-system-source-of-truth).
 4. For native-shell + H5 / RN + H5 / mini-app + H5 hybrids: locate the chrome/business-logic contract. If it is not written down, write it down before adding new features.
-5. For any feature spanning multiple stacks: decide per-surface ownership (desktop = X, H5 = Y, native = Z, mini-app = W). Do not assume one design satisfies all surfaces.
+5. For any feature spanning multiple stacks, write the complete per-surface owner matrix using the actual affected inventory: React web, other web, H5, native, mini-app, terminal/TUI, Electron/desktop/TV shell, and any additional client. Use the installed owner or fail-closed project-convention lookup for a layer without a named skill. Do not assume one design or one owner satisfies all surfaces.
 6. If one feature area inside an otherwise unified stack uses a non-canonical UI-library family: branch on whether an active team-authored A1 Figma design-system exists for that stack (classify per `design-system-source-of-truth.md`). **A1 exists** → open the A1 file AND the feature-area design file; both criteria met (zero canonical abstraction class in A1 + extended forms in feature file the canonical runtime UI-kit cannot express without one-off reimplementation or unacceptable UX loss) AND the A1-present exception-record field set from rule 2 (capability class, package/feature-path boundary, owner+date, A1+feature node ids and revisions, recheck trigger) is recorded → design-driven exception. Any criterion fails → raise the unify decision per rule 2. **No A1 yet (green-field/provisional)** → use the Green-field fallback: evaluate against the canonical runtime UI-kit's component docs + existing shared primitives + provisional token taxonomy, and record the exception with the **green-field/provisional field set from rule 2** (capability class, package/feature-path boundary, owner+date, `A1 source: absent (provisional)`, runtime UI-kit version + docs link, shared-primitives audit list, feature design node id and revision, provisional status flag, recheck trigger fires when A1 lands or feature file revision changes). Never authorize a second UI-kit family for canonical surface area regardless of branch.
 
 ## Anti-Patterns
@@ -58,8 +60,10 @@ When starting a multi-stack task:
 
 ## Routing
 
-- Web-react-dev: enforces the canonical web UI-kit and tests the desktop / H5 surfaces.
-- App-cross-platform-dev: enforces the native / RN design-system mapping and owns the native-H5 contract document.
-- Miniapp-product-dev: enforces mini-app platform mapping, host-platform capability boundaries, and mini-app release evidence.
+- Actual web-content owner: enforces the web renderer's UI-kit and content-layer evidence; React routes to `web-react-dev`, while Vue/Svelte/static/vendor content uses its installed owner or project convention.
+- `app-cross-platform-dev`: enforces Flutter/RN/native iOS/Android design-system mapping and owns the native-H5 container/bridge contract member.
+- `miniapp-product-dev`: enforces mini-app platform mapping, host-platform capability boundaries, and mini-app release evidence.
+- `terminal-cli-dev`: enforces terminal/TUI cell-grid, color-fallback, input, resize, and streaming/progress behavior.
+- Installed desktop-shell owner or project client convention: owns Electron shell and other desktop/TV layers; incomplete lookup is `owner-lookup-unavailable`, never an invented mobile-app owner.
 - Testing-strategy: verifies per-platform smoke for shared features (one platform passing ≠ all platforms passing).
 - Product-rd-workflow: if a new feature appears that should span multiple stacks, raise the decision early instead of building web-only first and "porting" later. Optional external strategy or ideation support may supplement this through local skill discovery, but the portable ccl-owned route is `product-rd-workflow`.

package/dist/assets/marketplace/plugins/ccl-skills/skills/product-ui-ux-design/references/operational-processing-workflows.md

@@ -14,6 +14,8 @@ Treat operational processing flows as recoverable production work, not as simple
 - Generated or processed output is not final by default. Mark unreviewed, reviewed, edited, failed, and returned states distinctly.
 - Long sessions need stable controls, persistent progress, keyboard-friendly repeated actions, and recovery after interruption.
 
+For operational, admin, moderation, and AI-review workspaces, do not use a marketing-style hero banner, decorative gradient as the design, oversized empty illustration, heavy visual drama, or a large unused first-screen area that pushes the real task below unrelated dashboard content. The default is a focused work surface. If the representative task is actually presentation or marketing, classify it as that different surface instead of weakening this operational rule.
+
 ## Focused Review Workspace
 
 Use for moderation review, AI output validation, creator task approval, content QA, dispute handling, incident processing, or trust/safety operations:

package/dist/assets/marketplace/plugins/ccl-skills/skills/product-ui-ux-design/references/platform-mobile-patterns.md

@@ -195,7 +195,7 @@ Implementation rules:
 - AI extraction flows should be staged visibly: capture/import, crop/preview, upload, analyze, review generated content, classify/tag, save/publish, and retake/retry. Disable final commit until required generated content and metadata are valid.
 - Rich generated content needs its own rendering and fallback states. Long formulas, markup, tables, or extracted structured text must scroll or wrap safely and should not block the whole screen if one renderer fails.
 - The preview must build trust. If the app shows an enhanced or processed image, the saved/uploaded artifact should match that visual intent; otherwise label the preview honestly and give the user a chance to retake or reprocess.
-- Capture controls should be large, icon-led, and spatially stable. Keep primary capture centered, secondary import on one side, device tool on the other. Separate icon glyph size from hit area, and meet platform touch targets of at least 44pt on iOS and 48dp on Android.
+- Capture controls should be large, icon-led, and spatially stable. Keep primary capture centered, secondary import on one side, device tool on the other. Separate icon glyph size from hit area, and apply the current first-party platform rule to the actual hit region: Apple HIG's general rule is at least 44×44pt for buttons (60×60pt on visionOS), while Android guidance recommends at least 48×48dp for touch/focusable targets. Keep both platform-scoped; do not average them into a universal number.
 - Upload/analyze waits should preserve context: keep the last image visible, overlay progress near the task, disable only unsafe controls, and provide retry/retake when the failure is recoverable.
 - Crop/review screens should expose direct manipulation affordances: a dimmed outside region, visible crop boundary, corner or edge handles, optional grid, retake, rotate, and confirm. While the user is dragging, prefer raw image feedback; after release, show processed preview only when it can represent the committed artifact.
 - Handoff from native capture back to hosted content should avoid route flash. Keep a calm transition cover until the destination route is mounted and ready, then remove it deterministically with a timeout fallback.
@@ -311,7 +311,7 @@ Implementation rules:
 Motion must have a product purpose — comprehension, orientation, feedback, or deliberate brand/emotional expression. Operational, finance, moderation, dense-data, and destructive flows default to calmer motion (this complements, not contradicts, the expressive-defaults note in the next section). Apply across iOS and Android:
 
 - **Budget attention-grabbing motion.** Avoid more than roughly two *attention-grabbing or decorative* animations competing at once in one view; essential status indicators (a progress spinner, a skeleton shimmer) and a single choreographed timeline are exempt. Layered competing motion reads as jank, not polish.
-- **Let platform and design-system motion tokens own duration and curve; only tune micro-feedback.** Micro-feedback (tap, toggle, small in-place state change) defaults to a short band (about 150–350ms), but system navigation, sheet presentation, predictive-back/gesture, hero choreography, and design-system motion tokens (e.g. M3 Expressive) carry their own longer, tuned durations — do not clamp them to the micro band. Reserve custom playful bounce/overshoot for light surfaces; on serious, destructive, financial, or trust-sensitive flows do not add custom overshoot that makes finality feel reversible or celebratory (standard platform component motion, including system spring settling, is fine).
+- **Let platform and design-system motion tokens own duration and curve; only tune micro-feedback.** Micro-feedback (tap, toggle, small in-place state change) defaults to a short band (about 150–350ms — a team heuristic, not a platform mandate: it sits inside Material 3's official duration tokens, which span 50–400ms across the short/medium steps, while Apple HIG gives no numeric duration guidance), but system navigation, sheet presentation, predictive-back/gesture, hero choreography, and design-system motion tokens (e.g. M3 Expressive) carry their own longer, tuned durations — do not clamp them to the micro band. Reserve custom playful bounce/overshoot for light surfaces; on serious, destructive, financial, or trust-sensitive flows do not add custom overshoot that makes finality feel reversible or celebratory (standard platform component motion, including system spring settling, is fine).
 - **Respect the OS reduce-motion setting natively, not only via web `prefers-reduced-motion`.** iOS exposes it directly: `UIAccessibility.isReduceMotionEnabled` / SwiftUI `\.accessibilityReduceMotion`. Android has no single reduce-motion boolean — gate custom animation on `ValueAnimator.areAnimatorsEnabled()` (or the framework duration scale), treating the animation scale as a capability signal rather than a reduce-motion *intent* flag, and fall back to `Settings.Global.*_ANIMATION_SCALE` only when needed. Classify each motion as decorative / spatial-orientation / essential: reduced motion drops decorative movement and shortens or simplifies spatial/essential movement, but must still show required feedback and state changes (progress, a status flip, a gesture preview).
 - **Motion must not shift layout or delay the task.** Confirm active state without reflowing surrounding content (per the bottom-tab rule above), and never hold loading/disabled/error feedback behind an entrance animation.
 
@@ -320,5 +320,5 @@ Motion must have a product purpose — comprehension, orientation, feedback, or
 When the target product ships on iOS 26+ / Android 16+ / Material 3 Expressive defaults, the design baseline shifts. Treat these as platform-default changes that affect token tuning, motion budget, and gesture geometry — not as visual style copies.
 
 - **iOS 26 Liquid Glass (Apple, WWDC 2025; iOS 26 / iPadOS 26 / macOS Tahoe 26 / watchOS 26 / tvOS 26)** introduces a translucent system material that reflects and refracts surrounding content and dynamically transforms across controls, navigation, app icons, and widgets. Apps built with standard SwiftUI / UIKit / AppKit components inherit the new design automatically when rebuilt against the Xcode 26 / iOS 26 SDK; custom-drawn UI (custom CALayers, manual gradients, hand-rolled tab bars) does NOT inherit it and must adopt explicitly. Apple ships a temporary opt-out in Xcode 26 so teams can ramp on their schedule rather than be forced to ship Liquid Glass the day they upgrade SDK. Design impact: (1) custom translucent / blur / glass material tokens MUST be tuned separately for Light, Dark, AND Increased Contrast appearances — Apple's own system colors were re-tuned across all three; (2) typography baseline became bolder and left-aligned, so if the product design uses centered or thinner type to "feel premium" on iOS, re-validate hierarchy on iOS 26; (3) chrome-on-content (tab bars, sidebars) now refract content beneath, so check that overlay surface tokens still keep on-surface text readable when chrome sits over high-contrast or saturated media. Do not adopt Apple's Liquid Glass as a cross-platform default token — it is a system material with system-tuned color/blur/refraction, and cloning it on web / Android as "default brand glass" produces a hard-to-maintain knock-off. Web / Android may use a deliberate glassmorphism treatment when the product needs it, but it must declare its own contrast budget, performance fallback (opaque mode when GPU / battery / low-end device requires), and an opaque-mode trigger that does NOT rely solely on `prefers-reduced-transparency` (the CSS media feature is real but not Baseline — Chrome desktop / Firefox stable lag — so back it up with an in-app "Reduce transparency" setting, platform-equivalent OS preference where available, or a default-opaque variant for non-supporting browsers); cite the explicit rationale in the design spec rather than treating glass as a free aesthetic upgrade.
-- **Material 3 Expressive (Google, 2025)** is an opt-in expansion of Material Design 3 with research-backed motion theming tokens, more expressive shape / color / typography, and an explicit emotional-design dimension (research showed expressive variants outperformed baseline on "energetic / emotive / positive / playful / friendly" perception). When the project uses M3 Expressive defaults (Jetpack Compose with M3 expressive themes, libraries pulling expressive motion tokens — note AndroidX `MotionScheme.expressive()` is alpha at the time of writing, not a stable everywhere-default), expect default animation durations and easings to be more energetic than baseline M3. Review whether *operational* / *finance* / *moderation* / *dense-data* surfaces should override motion tokens to a calmer set (`MotionScheme.standard()`) rather than inheriting expressive defaults, because dense workbench surfaces work against the expressive tone and feel jittery under it.
+- **Material 3 Expressive (Google, 2025)** is an opt-in expansion of Material Design 3 with research-backed motion theming tokens, more expressive shape / color / typography, and an explicit emotional-design dimension (Google's design.google research article reports 46 studies with 18,000+ participants; expressive variants outperformed baseline on "energetic / emotive / positive / playful / friendly" perception). When the project uses M3 Expressive defaults (Jetpack Compose with M3 expressive themes, libraries pulling expressive motion tokens — note AndroidX `MotionScheme.expressive()` is alpha at the time of writing, not a stable everywhere-default), expect default animation durations and easings to be more energetic than baseline M3. Review whether *operational* / *finance* / *moderation* / *dense-data* surfaces should override motion tokens to a calmer set (`MotionScheme.standard()`) rather than inheriting expressive defaults, because dense workbench surfaces work against the expressive tone and feel jittery under it.
 - **Android Predictive Back is default-enforced for apps targeting API 36 (Android 16, 2025)**. Design implication: the back gesture is no longer a single instant action but a *preview-then-commit* gesture — during the swipe the inner area scales down and the destination peeks behind; on commit-threshold crossing the contents fade-through to the destination (Android recommends `STANDARD_DECELERATE` or `PathInterpolator(0f, 0f, 0f, 1f)` for the progress easing). The system handles the previous-destination snapshot automatically for stock navigation; the design only needs to define preview behavior for custom-managed states: modals, bottom sheets, full-screen overlays, in-screen multi-step wizards, and any flow that owns its own back stack. Avoid placing draggable controls or custom horizontal-edge gestures inside the system gesture inset; they fight the OS back gesture and feel broken. For multi-step in-screen flows (form wizards, multi-pane), the design owns the *semantic back contract* (back pops inner step, not the whole screen) — *implementation* should integrate through the owning navigation stack's predictive-back support (Jetpack Navigation predictive-back APIs, `react-native-screens` predictive-back, Flutter `PopScope` / `NavigatorPopHandler`, native Fragment back-stack handlers) rather than wiring an ad-hoc `OnBackPressedCallback` at the screen level. Compose's lower-level `PredictiveBackHandler` is appropriate when the Compose screen owns its own back stack (no navigation library on top); when a navigation library is present, prefer the library's predictive-back hook so the system snapshot and inner-step pop stay in sync. Ad-hoc handlers on top of a navigation library double-pop, desync the system snapshot animation, or bypass the library's intended back stack and the regression is hard to reproduce because the OS-level animation still looks right.

package/dist/assets/marketplace/plugins/ccl-skills/skills/product-ui-ux-design/references/product-lifecycle-acceptance-and-iteration.md

@@ -24,7 +24,9 @@ Code evidence:
 
 ## Lifecycle Workflow
 
-Use this lifecycle for design, frontend implementation, and release readiness:
+For every runtime-visible slice, the canonical prerequisite and acceptance path is `delivery-contract.md`: Design brief → Test Phase 0 → producer/client execution → Test Phase 1/sufficiency → design verdict. The lifecycle below annotates that contract with launch and post-launch work; it is not a parallel readiness path. Every runtime-ready or launch-ready claim cites the complete immutable design/test/producer/client binding set and an allowed verdict. A pending, blocked, rejected, stale, or incomplete contract cannot become ready by passing a later checklist.
+
+Use this lifecycle for design, client implementation, release readiness, and iteration:
 
 1. **Intent lock**: state the target product loop, user segment, surface, and success behavior.
 2. **Design coverage**: map the screen to component primitives, responsive variants, and required states.
@@ -40,7 +42,7 @@ When a shipped feature, review, or user correction changes the design rule, upda
 
 ## Design Acceptance
 
-Before coding or handoff, verify:
+Record the following as criteria in the applicable full or lightweight Design record before coding or handoff, then let Test Phase 0 choose their oracles:
 
 - The primary loop is visible: discover, inspect, act, confirm, return.
 - Every visible action has success, failed, disabled, loading, and cancel/undo behavior where relevant.
@@ -53,7 +55,7 @@ Before coding or handoff, verify:
 
 ## Frontend Readiness
 
-Before implementation is considered ready:
+Record these client implementation-readiness criteria inside the canonical Design/Test records; the list is not a completion decision:
 
 - There is a clear component boundary for shell, navigation, content, action area, feedback, overlay, and terminal result.
 - Existing primitives are used before custom UI: async wrapper, error block, toast/message provider, modal/dialog, upload/progress, result, skeleton, empty state, responsive container, route-driven navigation.
@@ -69,7 +71,7 @@ Before implementation is considered ready:
 
 ## Product Launch Acceptance
 
-For product launch review, check these gates:
+Start these launch gates only after the exact candidate is `accepted + complete` under `delivery-contract.md`, with every required design/test/producer/client record, exercised-version link, and binding member present. These gates can block launch or add release evidence; they cannot replace Phase 1, repair a stale binding, or issue the design verdict.
 
 - **Build gate**: project build or type/lint/format commands pass where available; generated API code is up to date.
 - **Cold-start gate**: new communities have seed content, onboarding prompts, recommended topics/users, creator prompts, or first-action defaults; do not launch an empty loop.
@@ -77,7 +79,7 @@ For product launch review, check these gates:
 - **State gate**: manually exercise the canonical state taxonomy plus retry, disabled, cancel/undo, permission, long-content, and responsive states.
 - **Interaction gate**: verify hover/focus/active/selected on web; safe-area, keyboard, scroll, swipe/back, and bottom-sheet behavior on mobile.
 - **Feedback gate**: feedback strength follows the ladder in `interaction-design-patterns.md`.
-- **Performance gate**: infinite lists, media, AI generation, uploads, and long tasks do not block the main action or hide progress.
+- **Performance gate**: for affected infinite-list, media, streaming, AI-generation, upload, PDF/document-rendering, long-table, chart, and other long-task paths, user input should remain responsive, background work must not block the main action, and progress remains visible in runtime evidence.
 - **Localization gate**: long strings, mixed languages, numeric/date formats, and translated action labels fit without breaking hierarchy or controls.
 - **Trust gate**: moderation, report/block/mute, public publishing, AI source/citation, privacy/consent, and destructive flows are explicit.
 - **Fallback gate**: version/update notices, service migration notices, unavailable features, permissions, stale data, and partial results have understandable UI.
@@ -103,7 +105,8 @@ Use product evidence to decide what to change:
 When reviewing a shipped or almost-shipped feature, report:
 
 - What evidence was checked: Figma frame/page, code path, screenshot, metrics, or QA scenario.
-- Launch readiness: pass, conditional pass, or block.
+- Canonical `delivery-contract.md` verdict/next state plus the complete design/test/producer/client binding-set IDs; do not invent a second design-readiness status.
+- Separate release/iteration disposition: proceed, conditional, or blocked, with the release-specific reason. This disposition can add a launch block but cannot override the canonical design verdict.
 - Top risks by severity and user impact.
 - State coverage gaps.
 - Component/token drift.

package/dist/assets/marketplace/plugins/ccl-skills/skills/product-ui-ux-design/references/product-surface-patterns.md

@@ -43,6 +43,9 @@ Use this default loop unless the product has a stronger one:
 - Finance/data/trust-sensitive: use `trust-sensitive-ai-and-data-patterns.md`, `analytics-visualization-interactions.md`, and `operational-processing-workflows.md` for evidence, provenance, dense analysis, permission, and review-before-action patterns.
 - Mobile/app: use `platform-mobile-patterns.md` and app implementation skills for safe area, keyboard, orientation, native shell, and device acceptance.
 - Web/workbench: use `platform-web-desktop-patterns.md` and `layout-recipes-and-screenshot-acceptance.md` for shell, density, responsiveness, and screenshot acceptance.
+- Mini-app: keep design criteria here and route host/page, permission/capability, package/platform, device, and web-view bridge evidence to `miniapp-product-dev`.
+- Ordinary CLI or terminal/TUI: keep product hierarchy, command semantics, states, and acceptance here; route command/help/default/exit/recovery, terminal geometry, fallback, input, and real-terminal evidence to `terminal-cli-dev`.
+- Other Web and Electron/desktop/TV: React content routes to `web-react-dev`; Vue/Svelte/static/vendor/other content and shell layers route to their installed owner or the fail-closed project-convention lookup in `delivery-contract.md`. Composite hosts keep separate content and shell members.
 
 ## Workflow Surface Extensions
 

package/dist/assets/marketplace/plugins/ccl-skills/skills/product-ui-ux-design/references/source-map.md

@@ -18,9 +18,32 @@ When two sources disagree or overlap, decide explicitly:
 - **Merge** compatible variants into a generalized rule.
 - **Discard** stale, duplicated, lower-quality, or overly domain-specific details.
 - Never let one source file define the product domain. Source identity is provenance, not the product model.
+- Do not infer any product domain from source identity.
 
 Apply the same rule to code, external benchmarks, and review feedback: use them for reusable UI/UX behavior, implementation quality, launch gates, and iteration signals only; never to infer the product's business domain.
 
+For a conflict-heavy task, the decision artifact is a row-per-property-and-state
+matrix, not a blank record schema or a prose precedence list. Include the exact
+artifact revision and observed value for every source, its status and owned
+scope, the governing source or replacement decision, the conflict class, the
+chosen result, and an explicit unknown plus verifier where evidence is missing.
+Cover every applicable interaction and visual state; do not hide disagreement
+inside a combined `loading/error` row or a generic `other states` entry.
+
+Resolve the matrix in execution order:
+
+1. Freeze the relevant source revisions or content digests and
+   inventory the complete state/property rows before choosing a winner.
+2. Classify authority and scope per row; a source may govern one state and be
+   partial or silent for another.
+3. Keep current specified decisions, merge only compatible freedom, and create
+   an explicitly reviewable replacement decision for an intentional change.
+4. List the exact design, component/API, token, example/story, and test updates
+   in dependency order. Stories and tests expose intent or drift; existence and
+   unexecuted assertions do not settle authority or runtime behavior.
+5. Bind and run the resulting static, component, rendered, interaction, and
+   accessibility checks. A passing test closes only its declared row/oracle.
+
 Backend service code evidence is out of scope for this skill except where it affects product-visible lifecycle: generated API freshness, async task status, artifact readiness, permission/empty/error states, and launch observability. Detailed backend service rules belong in the relevant backend skill.
 
 ## Source Class Capability Map
@@ -31,7 +54,7 @@ For each design source available to the maintainer, classify before extraction a
 | --- | --- | --- |
 | `label` | sanitized capability label (e.g. `<design-system-web>`, `<review-module>`, `<scan-module>`) | Reusable identifier in skill text; never use a real file name |
 | `class` | `A1` rules-as-source (design system / UI kit / icon / annotation spec) / `A2` business-module / `B` reference-or-deprecated | Determines extraction weight: A1 anchors tokens/components, A2 anchors flows/states, B is provenance-only |
-| `stack` | `desktop-web` / `mobile-h5` / `mobile-native` / `mini-app` / `mixed-host` | Determines which implementation skill cross-checks the source |
+| `stack` | `react-web` / `other-web` / `mobile-h5` / `mobile-native` / `mini-app` / `terminal-tui` / `desktop-tv-shell` / `mixed-host` / `other-client` | Determines which installed implementation owner or fail-closed project convention cross-checks the source; a composite host records every layer |
 | `surface` | `shell` / `auth-and-account` / `workbench` / `creation-and-import` / `review-and-evaluation` / `analytics-and-report` / `asset-management` / `roster-and-entity-management` / `device-and-capture` / `notification-and-recovery` | Determines which pattern reference owns the rules |
 | `freshness` | `current` / `candidate-needs-inspection` / `deprecated` / `archived` | Determines whether the source can drive hard rules |
 | `coverage` | `published-system` / `targeted-workflow` / `representative-cross-check` / `metadata-only` / `screenshot-fallback` / `unavailable` | Determines how strong the evidence is |
@@ -50,9 +73,11 @@ Collection strategy default: **local-plus-external**.
 - If a Figma file's name carries a team-specific deprecation prefix or suffix (the team's known deprecation markers are kept in the private archive; common categories include a brand-bracketed prefix used to flag legacy snapshots, an automatic `(Copy)` suffix from Figma duplication, or an explicit "deprecated" page name in the team's working language), classify the file `freshness: deprecated` before any read. Such files cannot drive hard rules.
 - If a Figma frame carries inline version or date stamps (e.g. a version suffix `_verN`, a "current/latest" marker in the team's language, an `MMDDnew` date stamp, or a designer-added disambiguation parenthetical), treat the source as in-flight and prefer the latest stamp. Older sibling frames remain as discardable provenance.
 
+For a formal source re-extraction or full portfolio audit, first enumerate every formal design file in the portfolio, apply the exclusion rules, and fully extract every non-excluded file. A targeted frame pass cannot substitute for that all-file obligation. Ordinary product design may inspect only the sources relevant to its decision, but must not describe that targeted pass as full extraction.
+
 Coverage discipline:
 
-- "Full coverage" means every relevant source class has been used, routed, discarded, or marked unavailable with a reason — not "everything inspected".
+- "Full coverage" means every non-excluded formal source has been inspected/extracted and every relevant source class has been used, routed, discarded, or marked unavailable with a reason. It is stronger than a targeted pass, not a synonym for "some representative files inspected".
 - "Targeted" passes are explicit about which surfaces and which frames were read. Do not promote a targeted pass to a full audit in language alone.
 - For large Figma files, use page-level inventory first, then targeted frame/node reads, then screenshot fallback. Failed reads are recorded with the smaller read attempted; "unavailable" requires a remediation attempt first.
 
@@ -62,7 +87,8 @@ A product UI/UX skill must be product-agnostic. If the skill name or default sco
 
 Routing boundary:
 
-- Implementation rules belong to `web-react-dev`, `app-cross-platform-dev`, and `miniapp-product-dev` for mini-program implementation.
+- Runtime delivery follows `delivery-contract.md`; it is the single shared contract for design, testing, producer execution, client execution, evidence, and verdict. Each owner writes its own record; the design verdict cites the complete bound set rather than copying evidence.
+- Implementation rules follow the complete affected client-owner set in `delivery-contract.md`: React web → `web-react-dev`; Vue/Svelte/static/vendor/other web → its installed web-content owner or fail-closed project-convention lookup; native mobile/host → `app-cross-platform-dev`; mini-app → `miniapp-product-dev`; terminal/CLI/TUI → `terminal-cli-dev`; Electron/desktop/TV shell → its installed owner or the same lookup. Composite hosts keep separate content and shell members; a missing owner is never silently treated as Web or React.
 - Test-layer rules belong to `testing-strategy`.
 - This skill owns UI/UX judgment, state completeness, visual acceptance, design readiness, and scenario-specific design lenses.
 
@@ -90,15 +116,16 @@ Each row must be fillable as "inspected / not inspected / not applicable" with o
 
 ## External Quality Sources
 
-Use these as named quality benchmarks only, not as visual or product-domain sources:
+Use named external sources at their actual evidence strength, never as visual or product-domain donors:
 
-- Nielsen Norman Group usability heuristics: heuristic review layer for status visibility, user control, consistency, error prevention, and recovery.
-- W3C WCAG 2.2: accessibility baseline for labels, keyboard, focus, contrast, target size, error identification, and consistent behavior.
-- web.dev Core Web Vitals: launch/performance benchmark for LCP, CLS, INP, and field/lab measurement.
-- Google HEART framework: iteration metric lens for happiness, engagement, adoption, retention, and task success.
-- Material Design / Atlassian Design System guidance: platform/design-system support for touch targets, progressive disclosure, empty states, errors, and feedback clarity.
+- ISO 9241-210 and ISO 9241-11: human-centred lifecycle and context-dependent usability framing; neither supplies a page recipe or proves a particular design.
+- W3C WCAG 2.2 and ARIA Authoring Practices: normative accessibility criteria plus informative implementation patterns. APG examples are not a complete design system or production-ready code.
+- Primary empirical papers: contextual evidence for a bounded mechanism. Record participants/task/materials and contradictory or limiting findings before turning a result into a rule.
+- Current platform guidance: host convention for the named platform and input mode, not a cross-platform constant.
+- Design Tokens Community Group format: interchange vocabulary, not proof of visual quality, token governance, rendered themes, or standards status.
+- Expert heuristics: risk-discovery prompts only. Heuristic review is not acceptance proof.
 
-Extracted patterns live in `external-ui-ux-quality-benchmarks.md`.
+The claim ledger, primary links, and boundaries live in `external-ui-ux-quality-benchmarks.md`.
 
 ## Candidate Formal Sources Policy
 

package/dist/assets/marketplace/plugins/ccl-skills/skills/product-ui-ux-design/references/tokens-and-components.md

@@ -10,17 +10,22 @@ The team's current desktop design system is a `class: A1` published source. It m
 
 The team's current mobile design system is a `class: A1` published source for the mobile end. It may be team-authored, abstracted out of a mobile product framework file, or aligned to a third-party mobile component library. Read `platform-mobile-patterns.md` for mobile tokens, component groups, theming, and mobile state coverage. Use `design-system-source-of-truth.md` to identify the actual source when multiple candidates exist.
 
+## Complete Consumer Set
+
+Desktop and mobile catalogs below are illustrative component vocabularies, not a closed platform list. Before applying a shared token/component decision, enumerate every affected rendered consumer under `delivery-contract.md`: React web → `web-react-dev`; other web → its installed owner or fail-closed project convention; native mobile → `app-cross-platform-dev`; mini-app → `miniapp-product-dev`; terminal/CLI/TUI → `terminal-cli-dev`; Electron/desktop/TV → its installed owner or the same lookup. Each owner maps the semantic token and state contract to its own component, host, input, accessibility, and evidence model; absence from the desktop/mobile examples is never `not-applicable` proof.
+
 ## Usage Rules
 
 - Use published design-system files for tokens, component names, variants, and theme behavior.
 - Use product UI files for page composition, state coverage, and interaction-pattern evidence; do not inherit their old domain requirements.
 - Use third-party UI kits and icon libraries only as reference-only coverage checks for component categories, state variants, icon discipline, and documentation quality. Do not copy their brand, marketing IA, or visual identity into the product skill.
 - Do not hardcode colors, spacing, radii, or typography when a design-system token exists.
+- Existing non-compliant code is not permission: an old component's hard-coded color or ad-hoc style is recorded debt, never a precedent to copy into new work. When the requested result cannot be achieved within the design system's current rules, stop and route the gap to the design-system owner instead of silently inventing a new visual rule.
 - **Color tokens 优先 HSL 而非 Hex / RGB**（hand-tuning same-hue 变体）：HSL 让"同色不同亮度"（hover、disabled、bg tint、border-on-bg shade）通过只改 L 直接派生；Hex / RGB 改 1 个亮度需要算 3 通道易调不准。toolchain 支持时**优先 OKLCH / LCH** 做感知一致的 color ramp（HSL 在跨 hue 时亮度不感知统一）。Token 源用 HSL/OKLCH 表达 intent；输出层（CSS / iOS / Android）按需 convert；设计工具如 Figma 可能存 RGB，token spec 保留 HSL/OKLCH 语义即可。
 
 ## Token Sync Pipeline (Figma → Front End)
 
-Design tokens have a **design-tool source of truth**, typically a Figma file with a curated token set (color, spacing, radii, typography, shadow, motion). Tokens reach the front end through a project-specific sync mechanism, not through manual front-end authoring.
+Design tokens have a **design-tool source of truth**, typically a Figma file with a curated token set (color, spacing, radii, typography, shadow, motion). Tokens reach every affected rendered client through its project-specific sync or mapping mechanism, not through manual client-local authoring.
 
 - The Figma token set is the canonical source. Front-end token files (CSS variables, framework theme entry, `tokens.ts`, generated SCSS / LESS variables, etc.) are downstream artifacts of the sync.
 - The sync mechanism varies by project: Style Dictionary build pipeline, Tokens Studio plugin export, a Figma-API-driven script, the component suite's theme entry that mirrors the Figma token set, or a Feishu/Lark-hosted spec doc that a script consumes. Architecture records which mechanism this project uses and where the sync script / config lives so future agents do not invent a parallel path.
@@ -36,6 +41,8 @@ Design tokens have a **design-tool source of truth**, typically a Figma file wit
 
 ## Cross-Platform Component Capability Map
 
+The desktop/mobile names in this map are examples. For other web, native, mini-app, terminal/TUI, Electron/desktop/TV, or another client, use the affected owner to map the same semantic roles and full state/interaction contract; do not force these example component names onto another stack or omit that stack from evidence.
+
 - Shell and navigation: desktop `Layout`, `Menu`, `Breadcrumb`, `Dropdown`, `Pagination`, `Steps`, `Splitter`; mobile `NavBar`, `TabBar`, `Tabs`, `CapsuleTabs`, `SideBar`, `IndexBar`. Use them to preserve route context, selected state, overflow, long labels, and return paths.
 - Input and creation: desktop `Form`, `Input`, `Select`, `Upload`, `DatePicker`, `Transfer`, `TreeSelect`; mobile `Form`, `Input`, `TextArea`, `Picker`, `Selector`, `ImageUploader`, `NumberKeyboard`, `PasscodeInput`. Cover focus, validation, disabled reason, keyboard/safe-area, upload progress, and preview-before-commit.
 - Content display: desktop `Card`, `List`, `Avatar`, `Image`, `Tag`, `Badge`, `Tooltip`, `Popover`, `Statistic`, `Tree`; mobile `Card`, `List`, `Avatar`, `Image`, `ImageViewer`, `Tag`, `Ellipsis`, `FloatingPanel`, `InfiniteScroll`. Cover long content, media failure, skeleton, empty, selected/hover/pressed, and secondary actions.