@ccoalm/ccl-skills 0.6.2 → 0.8.0

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

@@ -1,214 +1,88 @@
-# Design Execution Checklist
-
-Use this checklist when applying the skill to a concrete product screen, feature, implementation, or review.
-
-## 0. Resolve Target Context
-
-Before loading detailed references, translate the active task into the target product frame:
-
-- Classify the target as community/social, education, finance/data, AI workspace, operational tool, consumer content, mobile app, web workbench, settings/account, or shared system.
-- Translate source-domain terms into target-product interaction patterns; do not output source-domain UI copy or source-domain information architecture.
-- Exclude source-domain terminology, role models, and workflow structure from product-facing output.
-- If the task context is mixed, state which product assumption is being used before design or implementation.
-
-## 1. Classify The Task
-
-Identify the target surface:
-
-- Mobile consumer surface: feed/detail, creation, profile, onboarding, notifications, AI assistant, settings, or finance/data mobile task flow.
-- Web consumer surface: content/detail/community, creator center, AI workspace, finance/data research surface, settings, notifications.
-- Web operational surface: moderation, trust/safety, analytics, data/research workbench, creator tools, admin-like settings.
-- Shared system work: tokens, components, theming, interaction states, visual QA.
-
-Then load only the relevant references:
-
-Core layer:
-
-- Always: `product-surface-patterns.md`.
-- Broad design, implementation, or review work: `design-intake-and-acceptance.md`.
-- Interaction logic, attention, motivation, perceived effort, trust psychology, habit loops, or aesthetic judgment: `behavioral-aesthetic-logic.md`.
-- UI/UX audit, implementation review, code/design comparison, usability risk, accessibility, or responsive QA: `ui-ux-audit.md`.
-- UI/UX design and frontend implementation: `ui-ux-design-development.md`.
-- Product launch acceptance, lifecycle review, and iteration planning: `product-lifecycle-acceptance-and-iteration.md`.
-- Frontend visual polish, brand feel, or anti-slop review: `visual-craft.md`.
-- Layout recipes, component density, empty/loading/error templates, workbench structure, or screenshot acceptance: `layout-recipes-and-screenshot-acceptance.md`.
-- Interaction flow, feedback strength, gestures, AI generated states, or serious/trust-sensitive states: `interaction-design-patterns.md`.
-- Shared token/component capability map: `tokens-and-components.md`.
-
-Platform lenses:
-
-- Mobile/App/H5/WebView: `platform-mobile-patterns.md`.
-- Web/Desktop/workbench/auth/admin: `platform-web-desktop-patterns.md`.
-
-Scenario lenses:
-
-- Community/social/feed/creator/moderation: `scenario-community-patterns.md`.
-- External usability, accessibility, performance, or metrics benchmark: `external-ui-ux-quality-benchmarks.md`.
-- Trust-sensitive AI/data, citation, upload, permission, instrumentation, or dense operational patterns: `trust-sensitive-ai-and-data-patterns.md`.
-- Local frontend implementation evidence, codebase source classification, reusable primitives, or build/launch scripts: `frontend-code-evidence-map.md`.
-- Complex creation, upload/import, AI draft extraction, structured editing, matching, manual correction, or publish/export flows: `complex-creation-interactions.md`.
-- Analytics, visualization, charts, comparisons, drill-down reports, creator/topic health, retention, or AI quality metrics: `analytics-visualization-interactions.md`.
-- Operational processing workspaces for capture/upload, focused review, moderation queues, quality/progress monitoring, assignment, or ownership workflows: `operational-processing-workflows.md`.
-- Resource libraries, AI cloud-drive style storage, media/template centers, saved prompts, knowledge sources, content packs, sharing, or resource governance: `resource-management-interactions.md`.
-
-Provenance and multi-project lenses:
-
-- Identifying which Figma file is the real design-system source, detecting third-party-mirror design systems, deciding which file owns brand tokens, or auditing theme/code comments pointing at the wrong figma file: `design-system-source-of-truth.md`.
-- **Same-stack multi-subproject** theme consistency (e.g. multiple desktop apps, or multiple H5 apps, sharing one brand), detecting silent default-theme drift across same-stack subprojects, or deciding how to share one theme module: `multi-project-token-consistency.md`. Use this when the subprojects are on the same end (all web-desktop, or all web-h5, etc.).
-- Resolving Figma↔code naming drift, deciding which of `Foo` / `FooV2` is active, planning retirement of in-flight version stamps, or maintaining a design-code terminology glossary: `design-impl-naming-and-versioning.md`.
-- **Cross-stack** strategy when a product spans multiple client stacks (web + H5 + native + mini-app + RN), handling stack outliers (a Vue island in a React organization, a single mini-app surface, etc.), splitting design system by stack, or writing the native-shell ↔ H5 contract: `multi-stack-strategy.md`. Use this when stacks differ across subprojects, not when the subprojects share a stack.
-- **Same-framework cross-end** (e.g. React desktop + React H5 + React Native, sharing one brand and one TS toolchain but different UI-kit per end): a common middle case. Load **both** `multi-project-token-consistency.md` (for the shared theme module across same-framework subprojects) and `multi-stack-strategy.md` (for the per-end UI-kit and surface differences). Do not pick one — apply both.
-
-## 2. Translate Source Patterns
-
-Before designing or coding, state the translation explicitly:
-
-- What source pattern is being reused?
-- What target-product behavior does it become?
-- What source-domain details must be discarded?
-- Which source-domain details must remain provenance-only and excluded from product-facing output?
-
-Examples:
-
-- Source dashboard card -> community feed module, creator task card, or AI suggestion.
-- Source task/progress state -> publish, review, moderation, AI-generation, upload, or sync state.
-- Source answer/analysis region -> post body, comment, AI response, annotation, or explanation panel.
-- Source settings/report view -> creator analytics, moderation tools, trust settings, or account preferences.
-- Source complex creation/import flow -> media creation, AI draft extraction, structured content setup, event/campaign setup, or imported data cleanup.
-- Source chart/report interaction -> creator analytics, topic health, retention, trust/safety monitoring, or AI quality analytics.
-- Source operational-processing workspace -> media ingestion, moderation queue, AI output validation, evidence review, creator approval, or incident processing.
-- Source resource/cloud-drive management -> creator asset library, AI knowledge source management, saved prompt library, topic template library, media pack, or content-pack governance.
-
-## 3. Choose Product Density
-
-Pick one density mode:
-
-- Consumer relaxed: feed, detail, profile, onboarding, creation. Use readable spacing, clear hierarchy, visible reactions, and approachable empty states.
-- Productive compact: creator tools, analytics, moderation, settings, AI workspace. Use denser cards, filters, side panels, tables/lists, and compact controls.
-- Hybrid: discovery page with a secondary creator/AI panel. Keep primary content readable and collapse secondary panels first.
-
-Do not make consumer discovery pages look like internal operations software.
-
-## 3.5 Required Design Checkpoint
-
-Before implementing or approving any visible UI change, write a compact checkpoint that can be tested against the final screen:
-
-- Surface type: mobile consumer, web consumer, web operational, or shared system.
-- Density mode: consumer relaxed, productive compact, or hybrid.
-- Implementation-owner checkpoint (rule text is canonical in `SKILL.md`'s implementation-owner checkpoint section; this checklist lists only the slots to fill — a checkpoint record must cite `checkpoint rules read: product-ui-ux-design/SKILL.md#implementation-owner checkpoint`, and a record without that citation is not valid):
-  - Record before the first implementation edit for a runtime visible UI/UX slice (slice definition and rendered-vs-backend-only routing: see `SKILL.md`): persistent artifact (plan/checklist, MR notes, or evidence file) for branch/MR-bound work; the visible progress update only for a single-turn local edit reverted or discarded before the final response (chat-only exception conditions per `SKILL.md`), and any change that remains at final response, push, or MR time repeats the full checkpoint fields in a persistent artifact.
-  - Include design owner (`product-ui-ux-design`), stack implementation owner, test owner (`testing-strategy`, loaded, with its assertion layer and rendered-evidence choice recorded, not only its name), entry-rule evidence, and rendered/device evidence status.
-  - Stack owner mapping: `app-cross-platform-dev` for Flutter/RN/native mobile, `web-react-dev` for React web, `miniapp-product-dev` for mini-programs, `terminal-cli-dev` for terminal/TUI, the recorded project client-code convention, or `no-installed-owner` with the surface type named — `no-installed-owner` only when no project convention exists and the lookup completed — name the runtime/framework and where conventions were looked for; an incompletable lookup is recorded `unavailable`, never `no-installed-owner`; container-wins, project-convention lookup minimum, shared-token consuming-stack inventory, and `unknown-consumers`/`out-of-scope` handling all per `SKILL.md`'s stack-owner entry rules; an entry list limited to stacks the author happened to name is not an inventory.
-  - Entry-rule evidence: a short quote, or the exact section/rule identifier plus the decision it produced — never only a file path, runtime name, or a vague anchor; runtime copy-only edits record `not-triggered (copy-only, existing component/viewport unchanged)` plus classification evidence that is measured — new text no longer than the old in every shipped locale, by rendered extent rather than byte/character count for width-constrained components (or a named length/viewport check; an unmeasured no-overflow assertion does not qualify; acceptable anchors and copy-only conditions: per `SKILL.md`); project-convention owners quote the convention line/rule applied; `no-installed-owner` records `no owner rule available`; trust/safety/risk-bearing copy never takes the copy-only path — full checkpoint plus risk grading routed to `feature-risk-router` (per `SKILL.md`).
-  - Evidence status: `captured/verified` with an inspected artifact pointer, `planned` with a capture command, or `unavailable-with-owner`/`unavailable-no-owner` with attempt records — status semantics, fabrication bars, persistence/review-resolution rules, completion-claim consequences, and evidence-artifact sanitization (sanitized/test accounts; tokens, PII, credentials, private paths redacted) per `SKILL.md`; a bare `captured/verified` without a pointer is treated as `planned`; any status other than `captured/verified` blocks completion claims — report `pre-runtime-test ready`, `blocked`, or an explicit evidence gap with owner and next command/unblock action.
-  - Remediation: naming an owner without loading its entry rules does not satisfy the checkpoint (the copy-only `not-triggered` path exempts only the stack-owner entry-rule quote, with every other checkpoint field still required); a missed checkpoint discovered by anyone is redone with an audit of the already-made diff per `SKILL.md`'s remediation rule.
-- Primary workflow: the shortest successful path and the main return loop.
-- Human logic: user intent in the next 10 seconds, likely anxiety/friction, attention order, motivation to continue, and trust concern.
-- Aesthetic logic: intended mood, visual focus, density rhythm, contrast role, material treatment, and which details should feel restrained versus expressive.
-- Visual direction: typography source, primary color source, neutral/background scale, radius/shadow role, token source versus new page-specific values, and whether two or three compact visual options were compared or deliberately skipped.
-- Interaction logic: Discover -> Inspect -> Act -> Confirm -> Return, including what is progressively disclosed, what stays persistent, and where the user returns after modal/drawer/upload/generation/detail work.
-- Behavioral logic: duplicate action protection, waiting feedback, disabled reasons, undo/retry/cancel, interruption recovery, and risk-matched confirmation.
-- Psychology: users should know what is happening, what changed, what is safe to wait for or retry, what mistake risk exists, and how to recover without losing context or control.
-- Layout structure: navigation/context, input/control region, content/result region, and secondary metadata.
-- Required states: empty, loading/generating, success, failure/retry, disabled/permission, long-content, and narrow-width behavior where relevant.
-- Trust boundary: generated content, publish/save limits, source/context/cost/model metadata, and any action that must not be implied.
-- Visual acceptance: hierarchy, spacing, component fit, copy tone, no nested-card clutter, no generic dump of fields, and no text overflow.
-- Behavioral/aesthetic acceptance: primary action feels obvious, feedback matches consequence, friction matches risk, mood fits the surface, and the result does not feel like a generic component demo.
-- Recipe: choose one concrete recipe from `layout-recipes-and-screenshot-acceptance.md` before drawing or coding.
-- Adaptation matrix: name the primary viewport, the stress viewport(s), the collapse rule, the spacing/density mode, and the screenshot/device checks that will prove the layout. For mobile, include safe-area and keyboard behavior; for desktop workbenches, include secondary-panel collapse before primary content becomes unreadable.
-
-Run the checkpoint in this order so it changes the result, not just the wording:
-
-1. Aesthetic logic: decide layers, white space, density, alignment, rhythm, color weight, radius/shadow restraint, and visual focus around the primary task.
-2. Visual direction: if the screen is new or substantially reshaped and no strong design reference exists, compare two or three compact directions before coding or final acceptance; if reusing existing product language, state the exact theme/token source and what stays unchanged.
-3. Interaction logic: decide entry point, current task, next step, progressive disclosure, confirmation, return path, and how complex work is split across pages, drawers, sheets, toolbars, or stages.
-4. Behavioral logic: decide what users may repeat, misclick, wait for, abandon, undo, retry, cancel, or recover after interruption, and place visible state/control for each risk.
-5. Psychology: reduce cognitive load and uncertainty, explain disabled or risky actions, keep users feeling in control, and make high-impact actions feel deliberate before execution.
-
-For admin, operations, moderation, analytics, creator-tool, and AI-review workspaces, a component library is only the implementation vocabulary. Do not describe the design as "Ant Design style" or similar without the checkpoint above. A good operational screen should make the next operator action obvious within five seconds. It should not rely on a dark hero, decorative gradient bar, oversized empty illustration, or marketing-page composition; use compact controls, readable hierarchy, clear status, and obvious work regions instead.
-
-## 3.6 Operational Workspace Quality Pattern
-
-For admin, operations, moderation, analytics, creator-tool, and AI-review pages, use this pattern unless a stronger product-specific design exists:
-
-- Header: keep the app shell header factual and restrained. Do not repeat a large inner page title unless it adds task context.
-- Control bar: place scope/filter/mode switches and primary context in a compact horizontal band near the top.
-- Status strip: expose trust boundary, selected scope, permission/state, and mode as small operational facts, not as promotional copy.
-- Workbench: use a clear input/control region and a review/output region. The output region should show the shape of the future review object even before data exists.
-- Dynamic workbench: data-driven module visibility, ordering, and status are valid. The empty or no-permission view should still show the intended module structure, next action, and future data slots.
-- Empty state: prefer a compact placeholder skeleton, checklist, or next-action hint over a large illustration. Empty states should teach what will be reviewed, not fill space.
-- Review state: make generated title, summary, reasons, model/prompt/cost/status, and source/trust metadata scannable without a table dump.
-- Visual tone: quiet contrast, crisp borders, stable spacing, readable labels, no decorative gradients, no oversized cards, no unused first-screen dead area.
-- User psychology: operators need certainty and control more than delight. Show where the work came from, what changed, what is pending, what is safe to retry, and how to recover after interruption.
-- Component hierarchy: navigation, tables, modals, empty states, charts, progress steps, alerts, annotations, and toolbars are chosen for their task role. Do not drop a component onto the page until its state, density, fallback, and return behavior are defined.
-
-## 4. Required States
-
-Use `product-surface-patterns.md` as the canonical state taxonomy. For every feature, map that taxonomy to concrete UI behavior. Add community, finance/data, AI, or operational scenario states only when the target surface needs them.
-
-Do not ship only the happy path.
-
-For visual implementation, use the empty/loading/error/success templates in `layout-recipes-and-screenshot-acceptance.md`. The state must occupy the same layout geometry as the final content unless the whole surface is terminally unavailable.
-
-## 5. Component Defaults
-
-Mobile:
-
-- Navigation: `TabBar`, `NavBar`, `Tabs`, `CapsuleTabs`.
-- Feed/detail: `List`, `Card`, `Avatar`, `Image`, `ImageViewer`, `Tag`, `InfiniteScroll`, `Skeleton`.
-- Creation/AI: `ImageUploader`, `TextArea`, `Input`, `Button`, `ProgressBar`, `Toast`, `Dialog`, `Modal/Bottom sheet`.
-- Comments/actions: `FloatingPanel`, `Popup`, `ActionSheet`, `SwipeAction`.
-- Account/settings: `Form`, `List`, `Switch`, `Picker`, `CheckList`, `Radio`, `PasscodeInput`.
-
-Web/Desktop:
-
-- Feed/detail: `Card`, `List`, `Avatar`, `Image`, `Tag`, `Badge`, `Tooltip`, `Popover`, `Skeleton`, `Empty`.
-- Creator/moderation/settings: `Form`, `Input`, `Select`, `Switch`, `Radio`, `Checkbox`, `Upload`, `Steps`, `Progress`, `Drawer`, `Modal`.
-- Notifications/feedback: `Message`, `Notification`, `Alert`, `Result`.
-- AI workspace: `Layout`, `Splitter`, side panels, upload, progress, streaming/loading, retry, edit, and result states.
-
-## 6. Token Rules
-
-- Use design-system semantic tokens before raw colors.
-- Tokens should express a coherent product visual language, not fall back to generic neutral defaults without a reason.
-- Preserve Light/Dark mode support when the surface supports theming.
-- Use mobile 4/8/12 radius roles for mobile; use desktop 2/4/6/8/12/16 radius roles for web.
-- Use desktop Default mode for consumer web readability; use Compact mode for dense tools.
-- Do not invent one-off spacing, color, radius, or font rules unless the product requirement clearly needs a new token.
-
-## 7. UI Copy Guardrails
-
-**A. Domain / product copy**：
-- Do not copy old source domain words into the new product UI.
-- Use product-appropriate copy. For community products: post, reply, topic, creator, follow, join, publish, draft, review, report, block, mute, notification, AI suggestion, generated draft. For finance/data products: source, evidence, watchlist, portfolio, risk, review, explain, export, permission, data freshness, and decision support.
-- Keep destructive copy explicit: delete, report, block, publish publicly, leave community, discard draft.
-- Empty states should invite the next action, not just say no data.
-
-**B. Microcopy structural rules**（reviewer 可直接 block 不满足的 PR）：
-- **Button labels = verb + specific object**：`Save changes` / `Send message` / `Discard draft`. **Avoid generic labels when action/consequence is not obvious from context**（典型弱例：`Submit` 无对象、`OK`/`Confirm` 遮蔽结果）。在平台 dialog 标准位 `Cancel` / `Close` / `OK` / `Done` 等仍可用。Destructive 必须比中性更显式（参 [[behavioral-aesthetic-logic.md]] + `interaction-design-patterns.md` Serious/Financial 段的 destructive/irreversible/外部可见/付费 trust-sensitive 边界）：`Delete forever` 而非 `Remove`。
-- **Error message 结构**：(1) **what happened**（用户语言，非 stack trace / error code）+ (2) **why — when useful and safe to disclose**（auth/session/policy/anti-abuse/backend 内部不暴露；如 `Session expired. Sign in again.` 不必给原因）+ (3) **what to do**（具体动作：retry / contact support / 修哪个 input）. Anti-pattern：`Something went wrong` / `Error 500` / `Unknown error` 作主 copy（error code 可入 expandable technical details / support reference）。
-- **Disabled control**：默认必有原因（tooltip / inline helper / 旁边一句话）+ 启用条件，让用户知道下一步。**例外**：unavailable by policy / permission / security 且暴露条件不安全 → **隐藏 control** 或给通用 permission 解释（不暴露具体策略）；不存在"恒不可启用"且只剩 disabled 状态的 control（应直接隐藏）。
-- **Success / confirmation 必具体**：说清成功了什么 + 如适用给下一步。`Message sent to alice@example.com — view in Sent` 而非 `Success` / `Done` / `OK`。
-- **Voice consistency**（可枚举的 reviewer 检查项，不空喊）：(a) 无内部代号 / 项目代号 / 服务名出现在用户文案；(b) 同一动作 / 对象不混用术语（如不同页面别一处叫 "send"、一处叫 "submit"、一处叫 "post"）；(c) 无未解释 jargon；(d) 无翻译腔（直译机翻味）；(e) 时态 / 人称 / 大小写统一。
-
-## 8. Review Checklist
-
-Before calling a design or implementation complete, verify:
-
-- The screen supports the primary product loop: discover/enter -> inspect -> act -> confirm -> recover/return.
-- Main action and secondary actions have proper hierarchy.
-- Interaction logic passes `behavioral-aesthetic-logic.md`: the canonical Discover -> Inspect -> Act -> Confirm -> Return loop from `interaction-design-patterns.md` matches user intent, risk, trust, and motivation.
-- Aesthetic logic passes `behavioral-aesthetic-logic.md`: mood, rhythm, contrast, material treatment, and delight support the product purpose.
-- Frontend, test, and acceptance checks use `behavioral-aesthetic-logic.md`: rendered behavior preserves attention order, risk friction, recovery, trust cues, and return context, not only visual component correctness.
-- Long names, long posts, badges, tags, and metadata do not break layout.
-- Mobile keyboard/safe-area states are covered where relevant.
-- Web narrow-width behavior collapses secondary panels before damaging content readability.
-- AI states include generating, retry, edit, source/citation where relevant, and failure handling.
-- Trust/safety states are visible and understandable.
-- Trust-sensitive AI/data features expose source/context, permission state, recovery, and observable request/task outcomes.
-- Visual polish passes `visual-craft.md` anti-slop and brand-consistency checks.
-- Screenshot acceptance passes `layout-recipes-and-screenshot-acceptance.md` with realistic long text, no data, partial data, and error data.
-- The adaptation matrix was checked in the rendered implementation: primary viewport, stress viewport, collapse behavior, safe-area/keyboard where relevant, long text, empty/partial/error state, and no layout shift around loading or dynamic modules.
-- For operational/admin/AI-review workspaces, the rendered screen looks like a focused work surface, not a landing page: no hero-style banner, no decorative gradient-as-design, no oversized empty illustration, no large unused first-screen area, and no layout where the real task starts below unrelated dashboard content.
-- Component choices follow this skill and existing codebase primitives.
-- Launch readiness and iteration risks pass `product-lifecycle-acceptance-and-iteration.md` when the work is close to release or already shipped.
+# Design Execution Router
+
+For runtime work, choose one delivery-depth profile, then add every work-mode and risk lens whose trigger is present. Load the union of their references; one lens never cancels another. Delivery depth is ordered `systemic redesign → new/reshaped screen → narrow visible change → copy-only`. Every work mode below is orthogonal to delivery depth and to the other modes: a source-led systemic redesign or a shared-system redesign loads both sets; a narrow implementation review loads design-to-code plus audit/review; a code-evidence audit with naming drift loads source/code evidence plus naming/version synchronization; a same-stack theme audit loads same-stack multi-project even though no stacks differ; a cross-stack redesign loads its delivery profile plus multi-stack. A source-only audit with no requested runtime slice may omit delivery depth and stop at the source-only boundary in `delivery-contract.md`.
+
+The core workflow and state taxonomy are already in the skill entrypoint. This router is conditional context, not an always-loaded prerequisite. A runtime-visible task can enter `delivery-contract.md` directly; an unambiguous common route can enter its named reference directly. Load this router when delivery depth must be composed with specialized work-mode, platform, risk, or evidence lenses. No focused reference is always loaded. Extra context must earn its cost by changing a decision, owner, evidence layer, or acceptance criterion.
+
+## Delivery-depth profiles
+
+| Profile | Use when | Required references | Deliverable |
+| --- | --- | --- | --- |
+| Copy-only | Same component, rendering slot, or output field and behavior; no hierarchy, layout, state, interaction, navigation, or component-semantics change | `delivery-contract.md` copy-only path | Lightweight owner/evidence record plus extent/localization check |
+| Narrow visible change | Local polish, state/copy fix, or bounded review without structural redesign | `delivery-contract.md`; one focused craft/interaction reference | Observation → risk → change → evidence |
+| New or reshaped screen | New screen or material change to grouping, hierarchy, navigation, component semantics, or visual direction | `delivery-contract.md`, `design-intake-and-acceptance.md`, `behavioral-aesthetic-logic.md`, `visual-craft.md` | Context brief, state/flow, direction, criteria, owner handoff |
+| Systemic redesign | Multiple surfaces, declared redesign/restyle, continuation from a redesigned surface, or a `design-judgment`/`mixed` rejected-surface recovery | New/reshaped set plus `layout-recipes-and-screenshot-acceptance.md`, relevant platform reference, and `ui-ux-audit.md` | Per-surface records following the canonical five-step order, cross-surface consistency, rendered verdict loop |
+
+## Composable work-mode lenses
+
+Select zero or more and union their required references with the delivery-depth set.
+
+| Work mode | Use when | Required references | Deliverable |
+| --- | --- | --- | --- |
+| Shared system | Tokens, components, themes, state catalogs, or packages consumed by more than one surface/stack | `delivery-contract.md`, `tokens-and-components.md`, `design-system-source-of-truth.md`; compose with same-stack multi-project or multi-stack when their triggers apply | Consumer inventory, semantic contract, migration and evidence matrix |
+| Source/code evidence | Auditing, classifying, or refreshing rules from Figma, code, screenshots, or another source corpus; inspecting local frontend implementation evidence, reusable primitives, source boundaries, or build/launch scripts | `source-map.md`, `frontend-code-evidence-map.md`, and [`two-source-extraction-pattern.md`](../../skill-extraction-workflow/references/two-source-extraction-pattern.md) when design+code are paired | Source classification, implementation-evidence map, coverage, contradictions, keep/merge/discard decisions |
+| Design-to-code | Applying design decisions to client code, mapping a source/component/token to implementation, or choosing implementation primitives for a visible slice | `ui-ux-design-development.md` plus the affected client owner skill | Source-to-target translation, primitive/component mapping, state/adaptation implementation notes, and owner evidence plan |
+| Audit/review | UI/UX audit, design walkthrough or acceptance, implementation review, code/design comparison, or usability, accessibility, responsive QA at any delivery depth | `ui-ux-audit.md`; add the triggered craft, interaction, platform, and external-authority lenses below | Findings ordered by user impact with evidence, correction, strengths, and scope limits |
+| Naming/version synchronization | Figma↔code naming drift, deciding which `Foo`/`FooV2` artifact is active, retiring an in-flight version stamp, or maintaining the design-code terminology glossary | `design-impl-naming-and-versioning.md` | Active implementation/source resolution, migration/retirement decision, glossary evidence and recheck trigger |
+| Same-stack multi-project | Multiple subprojects on the same end/stack share a brand or theme, need a shared theme module, or may drift to vendor defaults | `multi-project-token-consistency.md`; add multi-stack only if the same framework also spans different ends | Subproject inventory, canonical token/theme source, import/drift audit, migration and evidence matrix |
+| Multi-stack | A feature or design system spans multiple client stacks or a composite host; a stack/UI-kit outlier; native-shell↔web-content ownership; or the same framework spans different ends | `multi-stack-strategy.md`; also load `multi-project-token-consistency.md` when the same framework spans different ends and shares brand/theme infrastructure | Per-stack and per-layer owner/consumer map, surface contract, divergence/retirement decision, and evidence matrix |
+
+Do not downgrade a declared redesign to narrow polish because the code diff is small. Do not upgrade copy-only work because the surrounding screen is complex; use the trigger actually changed.
+
+## Risk lenses
+
+Load a lens only when its trigger is present.
+
+| Trigger | Reference |
+| --- | --- |
+| Web/desktop layout, workbench/auth/admin surface, responsive container, browser input | `platform-web-desktop-patterns.md` |
+| Mobile/native/App/app-hosted/H5/WebView, safe area, keyboard, orientation, text scale, gesture | `platform-mobile-patterns.md` |
+| Mini-program host capability or package/platform convention | Keep design acceptance in `delivery-contract.md`; route host mechanics to `miniapp-product-dev` |
+| Terminal/TUI grid, ANSI/color fallback, PTY, resize, scrollback, selection | Keep design acceptance in `delivery-contract.md`; route mechanics to `terminal-cli-dev` |
+| Operational/admin/moderation/AI-review workspace; capture, upload/import, queue, progress monitoring, assignment/ownership, exception handling, or quality-control workflow | `operational-processing-workflows.md` |
+| Trust-sensitive AI, finance/data, permission, provenance/citation, upload, analytics, moderation decision, long-running workflow, or instrumentation | `trust-sensitive-ai-and-data-patterns.md` |
+| Analytics, charts, comparison, drill-down, metric explanation, creator/topic health, retention, or AI-quality metric | `analytics-visualization-interactions.md` |
+| Complex creation, upload/import, AI draft extraction, structured editing, matching/manual correction, preview/publish/export flow | `complex-creation-interactions.md` |
+| Resource/cloud-drive inventory, upload, batch action, media/template/content-pack center, saved prompt, knowledge source, sharing, governance, or lifecycle | `resource-management-interactions.md` |
+| Community/social/feed/creator/topic/profile/notification/moderation/AI-social product surface | `scenario-community-patterns.md` or the matching section of `product-surface-patterns.md` |
+| Detailed interaction, feedback strength, error/recovery, gesture, generated state, motion, or shortcut behavior | `interaction-design-patterns.md` |
+| Attention, motivation, perceived effort, trust psychology, habit loop, or behavioral/aesthetic judgment | `behavioral-aesthetic-logic.md` |
+| Visual polish, brand feel, anti-slop, typography/hierarchy, iconography, or material treatment | `visual-craft.md` |
+| Layout recipe, component density, workbench structure, empty/loading/error geometry, or screenshot/render acceptance | `layout-recipes-and-screenshot-acceptance.md` |
+| Design-system source authority, third-party mirror detection, brand-token ownership, or wrong design-source comments in code/theme files | `design-system-source-of-truth.md` |
+| Generic surface/loop taxonomy, account/settings, decision/review, AI-assisted or workflow-extension pattern, or no focused scenario lens fits | `product-surface-patterns.md` |
+| External theory, WCAG, platform recommendation, benchmark claim | `external-ui-ux-quality-benchmarks.md` |
+| Launch/post-launch measurement and iteration | `product-lifecycle-acceptance-and-iteration.md` |
+
+## Decision pass
+
+Before handing off implementation, confirm that the design record answers these questions:
+
+1. Who is doing which representative task, under what constraints?
+2. What observation creates which user/task risk?
+3. What information hierarchy, flow, state, and recovery behavior addresses that risk?
+4. Which details are specified by a current source, which are design freedom, and which change product behavior?
+5. What happens at narrow/large sizes, long content, alternate input, text scaling, and relevant accessibility states?
+6. Which criterion is automatic, rendered/device, independent design judgment, user-task evidence, or production evidence?
+7. Which producer, test, and client owners must return which evidence before a verdict?
+
+Use `delivery-contract.md` for the field schema and completion states. Do not restate those fields here.
+
+## Design quality checks
+
+Apply the checks relevant to the chosen delivery depth and every triggered lens:
+
+- The most prominent content/action matches the representative task and consequence.
+- Required context, current state, available actions, and result/recovery remain visible when needed. For each applicable risk, decide what users may repeat, misclick, wait for, abandon, undo, retry, cancel, or recover after interruption, and provide visible state or control; do not force users to remember hidden state across route or modal transitions.
+- States use clear signifiers and event → state → feedback mappings. Animation has a functional purpose and a reduced-motion equivalent.
+- Friction follows consequence. Routine work is not interrupted by defensive confirmation; high-consequence action is not hidden behind transient feedback.
+- The layout adapts from content/container constraints and survives long text, text scaling, intermediate widths, and relevant input modes.
+- Tokens and components express semantic roles and full states. Existing libraries do not excuse weak hierarchy, missing states, or inaccessible behavior.
+- Examples, stories, catalogs, and design-system docs used as implementation sources conform to the same token, responsive, state, and accessibility rules.
+- Each deterministic gate names its coverage boundary; each conclusion stops at its highest verified evidence rung.
+
+## Closeout
+
+The design owner records criterion results and the verdict defined in `delivery-contract.md`. A source-level review, heuristic pass, automated check, or screenshot cannot silently stand in for a missing rendered, accessibility, independent-design, user-task, or production layer.
+
+Report loaded references with their trigger when the task is large enough to persist a design record. This makes context cost and omitted lenses reviewable without forcing every task to load the corpus.

package/dist/assets/marketplace/plugins/ccl-skills/skills/product-ui-ux-design/references/design-impl-naming-and-versioning.md

@@ -17,7 +17,7 @@ Load this reference when a task crosses the Figma↔code boundary and depends on
 - **The active version must be discoverable from the runtime entry**: do not rely on intuition. To decide which of `Foo` / `FooV2` is active, follow the route table / router config / app entry import — whichever the runtime actually mounts. The unmounted sibling is dead weight even if it has more recent commits.
 - **Old versions should be retired on a date, not on vibes**: when introducing `FooV2`, write down the date or release that retires `Foo`. Same in Figma: when promoting `_ver1`, tag the old frame as deprecated rather than leaving siblings competing.
 - **Date stamps in design file names do not propagate to code**: never name a code module `Foo_0904.tsx` because the corresponding Figma page carries a date stamp. Translate the design version stamp into a clean code name plus a top-of-file comment that records the design-source revision.
-- **Verify business-axis frame labels by structural diff before treating the label as a product axis**: when paired figma frames carry business-axis vocabulary in the form "X / non-X" (tenant tier / customer segment / plan tier / region / vertical / industry / org type), structurally diff the two frames before code, tests, backend enums, or analytics dimensions branch on the named axis. **Diff unit** (specify it so two reviewers reach the same verdict): node path + node id + component/variant props + text content + bounds + layer visibility + interactive/prototype links. A changed component INSTANCE with changed variant props or overridden internal children counts as multiple deltas, not a single-element presence delta. **Procedure**: read both frames at matching depth, enumerate every node at the diff unit, list every delta. **If the only delta is presence/absence of a single permission-gated or state-driven element** (one quick-action cluster, one CTA button, one config row): UI evidence alone proves a permission/state-rendering delta — it does **NOT** alone prove the business axis is fake. The named axis may still be a real product/analytics/backend dimension that happens to surface through entitlement gating (plan tiers and regions often manifest exactly this way: one entitlement-controlled action toggles, with the axis itself living in product schema/PM intent). Confirm whether the gating permission is **derived from** an independent business axis (PM/PRD, product enum, backend schema, entitlement matrix) before deciding. Two outcomes: (i) gating is **not** derived from any business axis → label is misleading, the real axis is permission/state, raise rename to designer; (ii) gating **is** derived from the named axis → label is accurate, the axis is real even though UI manifests as one gated control, code/enums/analytics should keep the named axis (with the permission as its rendering mechanism). **Design-side judgment** (this skill's lane): record in the private glossary with source file, frame node ids, revision/version marker, observed delta summary, resolved axis (misleading / entitlement-derived from <axis>), and the entitlement-source evidence (PM/PRD doc, product enum file, etc.); the entry is **not a permanent cache** — re-diff when either frame changes revision or when a current-marker/version stamp appears. When outcome (i) holds, raise the label as a hygiene defect for designer rename (e.g. "with-<permission-name>" / "without-<permission-name>", "in-<state>" / "out-of-<state>"). **Routing for enforcement**: code gating → `web-react-dev` / `app-cross-platform-dev` / `miniapp-product-dev`; test coverage → `testing-strategy`; backend enum and analytics dimension changes → owning backend / data skill or human owner. This file's role ends at recording the judgment and routing. **If the diff returns a multi-element substantive delta** (multiple node-path differences, distinct INSTANCE trees with different variant props, different navigation patterns), the named axis is a **candidate** real axis — confirm against product / runtime / source-of-truth evidence (PM/PRD, route table, backend enum, data dictionary) before introducing axis-aware code, tests, enums, or analytics; multi-element delta alone is insufficient because it can still be state, permission combo, experiment, locale, or responsive variant.
+- **Verify business-axis frame labels by structural diff before treating the label as a product axis**: when paired figma frames carry business-axis vocabulary in the form "X / non-X" (tenant tier / customer segment / plan tier / region / vertical / industry / org type), structurally diff the two frames before code, tests, backend enums, or analytics dimensions branch on the named axis. **Diff unit** (specify it so two reviewers reach the same verdict): node path + node id + component/variant props + text content + bounds + layer visibility + interactive/prototype links. A changed component INSTANCE with changed variant props or overridden internal children counts as multiple deltas, not a single-element presence delta. **Procedure**: read both frames at matching depth, enumerate every node at the diff unit, list every delta. **If the only delta is presence/absence of a single permission-gated or state-driven element** (one quick-action cluster, one CTA button, one config row): UI evidence alone proves a permission/state-rendering delta — it does **NOT** alone prove the business axis is fake. The named axis may still be a real product/analytics/backend dimension that happens to surface through entitlement gating (plan tiers and regions often manifest exactly this way: one entitlement-controlled action toggles, with the axis itself living in product schema/PM intent). Confirm whether the gating permission is **derived from** an independent business axis (PM/PRD, product enum, backend schema, entitlement matrix) before deciding. Two outcomes: (i) gating is **not** derived from any business axis → label is misleading, the real axis is permission/state, raise rename to designer; (ii) gating **is** derived from the named axis → label is accurate, the axis is real even though UI manifests as one gated control, code/enums/analytics should keep the named axis (with the permission as its rendering mechanism). **Design-side judgment** (this skill's lane): record in the private glossary with source file, frame node ids, revision/version marker, observed delta summary, resolved axis (misleading / entitlement-derived from <axis>), and the entitlement-source evidence (PM/PRD doc, product enum file, etc.); the entry is **not a permanent cache** — re-diff when either frame changes revision or when a current-marker/version stamp appears. When outcome (i) holds, raise the label as a hygiene defect for designer rename (e.g. "with-<permission-name>" / "without-<permission-name>", "in-<state>" / "out-of-<state>"). **Routing for enforcement**: code gating follows every affected client owner in `delivery-contract.md`: 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. Test coverage → `testing-strategy`; backend enum and analytics dimension changes → owning backend / data skill or human owner. This file's role ends at recording the judgment and routing. **If the diff returns a multi-element substantive delta** (multiple node-path differences, distinct INSTANCE trees with different variant props, different navigation patterns), the named axis is a **candidate** real axis — confirm against product / runtime / source-of-truth evidence (PM/PRD, route table, backend enum, data dictionary) before introducing axis-aware code, tests, enums, or analytics; multi-element delta alone is insufficient because it can still be state, permission combo, experiment, locale, or responsive variant.
 - **Designer-side dating is acceptable but needs a current-discriminator**: Figma lacks a git-like branch/version-history mechanism, so designers commonly suffix the active page with a date stamp (e.g. a `_YYYY.MM/DD` or `_MMDD` suffix) and keep older dated pages in the same file as informal version history. This is acceptable, *provided* one page is unambiguously identifiable as the current source — any of: only one page in the file carries the latest date stamp and no other page carries a later one; a `(current)` / "use this one" / `(active)` annotation on the current page; or older dated pages renamed to start with `archive/`. Without such a discriminator, a file with two or more dated pages becomes a graveyard where the maintainer cannot tell which is the source of truth. **Conflict precedence when signals contradict**: when two discriminators point at different pages — for example, an older page is annotated `(current)` but a newer dated page exists without annotation, or a page carries both a `(current)` label and an `archive/` prefix — none of the automatic signals can be trusted. Treat the file as `freshness: candidate-needs-inspection`, hold rule extraction, and confirm with the file's designer/owner which page is the live source before proceeding. Do not pick a "winning" discriminator silently. The code-side rule above (date stamps do not propagate into module names) still holds independently.
 
 ## Decision Checklist
@@ -48,6 +48,6 @@ When you hit a Figma↔code naming mystery:
 
 ## Routing
 
-- Code-side enforcement of "no `FooV2` coexists with `Foo` after release N" → `web-react-dev` and `app-cross-platform-dev`.
+- Code-side enforcement of "no `FooV2` coexists with `Foo` after release N" follows every affected client owner in `delivery-contract.md`: React web → `web-react-dev`; Flutter/RN/native mobile → `app-cross-platform-dev`; mini-app → `miniapp-product-dev`; terminal/TUI → `terminal-cli-dev`; other web, Electron shell, desktop, TV, or another runtime → its installed owner or the fail-closed project-convention lookup.
 - Test coverage of both `V1` and `V2` paths while coexistence persists → `testing-strategy`.
 - Glossary maintenance and design-side cleanup of `_verN` / current-marker / date-stamp siblings → stays here (design discipline) plus owner update in the private archive.

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

@@ -1,6 +1,6 @@
 # Design Intake And Acceptance
 
-Use this reference before designing, implementing, or reviewing a concrete product screen. It adapts product-intent and UX-acceptance practices while staying source-agnostic and excluding source-specific visual themes.
+Use this reference before designing, implementing, or reviewing a concrete product surface. It supplies design-owned intake and criteria to the five top-level stages in `delivery-contract.md`; it does not replace Test Phase 0, producer/client execution, Test Phase 1, immutable binding, or the design verdict. It adapts product-intent and UX-acceptance practices while staying source-agnostic and excluding source-specific visual themes.
 
 ## Intake Triage
 
@@ -10,7 +10,7 @@ Clarify these points quickly before making design decisions. Do not over-ask whe
 | --- | --- |
 | Product goal | What user behavior should this screen increase: discovery, first participation, creation, retention, trust, or AI-assisted contribution? |
 | User segment | Is the user new, returning, creator, moderator, power user, or casual browser? |
-| Platform | Is this mobile app, mobile web, consumer web, creator web, moderation/admin-like web, or cross-platform? |
+| Platform | Which rendered layers are affected: React or other web, H5, native mobile/host, mini-app, ordinary CLI or terminal/TUI, Electron/desktop/TV shell, composite host, or another client? Which installed owner or fail-closed project convention applies to each? |
 | Surface | Is it feed, post detail, creation, onboarding, profile, topic/community, notification, AI workspace, trust/safety, analytics, or settings? |
 | Primary loop | What is the screen's loop: discover -> interact, create -> publish, AI -> refine -> share, report -> review, or notify -> return? |
 | Constraints | Are there known brand, component-library, accessibility, localization, privacy, moderation, or performance constraints? |
@@ -36,7 +36,7 @@ When applying or refreshing this skill:
 
 ## Deliverable Types
 
-Choose the smallest deliverable that satisfies the task.
+Choose the smallest design-owned deliverable that satisfies the task. Runtime implementation or acceptance still follows the applicable full or lightweight record and complete design/test/producer/client owner set in `delivery-contract.md`.
 
 ### UI Concept + Layout
 
@@ -62,7 +62,7 @@ Include:
 - Tokens for color, typography, spacing, radius, shadow, and mode where relevant.
 - Component selection and variants.
 - Component states: default, hover, active, disabled, selected, loading, error, success, empty, and destructive.
-- Web/mobile differences.
+- Per-affected-client differences and shared semantics across React/other web, H5, native, mini-app, terminal/CLI/TUI, Electron/desktop/TV, and composite-host layers.
 
 ### Implementation Plan
 
@@ -72,6 +72,7 @@ Include:
 - Reusable components and local primitives to use first.
 - Data/state requirements for the UI.
 - Acceptance checks and visual QA steps.
+- The changed producer owners, affected client owners, Test Phase 0 handoff, and complete design/test/producer/client binding/return plan required by `delivery-contract.md`.
 
 ### Design Review
 
@@ -85,7 +86,7 @@ Lead with issues, then recommended fixes:
 
 ## Acceptance Standards
 
-A design or implementation is not complete until it passes these checks.
+These checks become design criteria in the applicable full or lightweight record. Passing them locally is not completion: only the complete five-stage contract, immutable design/test/producer/client binding set, and allowed verdict/next-state pair can close a runtime-visible slice.
 
 ### Product Fit
 
@@ -106,8 +107,9 @@ A design or implementation is not complete until it passes these checks.
 - Uses existing design-system tokens and components before inventing new styling.
 - Has a coherent visual direction and avoids generic AI-template aesthetics; see `visual-craft.md`.
 - Maintains clear hierarchy between content, metadata, actions, and system feedback.
-- Mobile surfaces respect thumb reach, keyboard, safe area, and bottom-sheet behavior.
-- Web surfaces collapse secondary panels before harming core content readability.
+- Mobile/native surfaces respect thumb reach, keyboard, safe area, orientation, text scaling, and bottom-sheet behavior.
+- React/other Web surfaces collapse secondary panels before harming core content readability.
+- Mini-app, terminal/CLI/TUI, Electron/desktop/TV, composite-host, and other clients apply their owner-specific host, input, geometry, fallback, bridge, and rendered-evidence criteria; absence from the Web/mobile examples is not `not-applicable` proof.
 - Text fits in buttons, tabs, cards, sidebars, and compact controls.
 
 ### Trust, Safety, And AI
@@ -121,7 +123,7 @@ A design or implementation is not complete until it passes these checks.
 
 - Interactive controls have labels, keyboard/focus states where applicable, and enough hit area.
 - Color contrast, disabled state, error state, and loading state remain readable.
-- The design works at the expected mobile and desktop widths.
+- The design works across the supported sizes, host modes, input/capability modes, and adaptation matrix of every affected rendered layer.
 - Motion or animation does not block task completion and can degrade gracefully.
 
 ## Anti-Patterns

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

@@ -12,7 +12,7 @@ Load this reference when working on token decisions, theme files, design-system
 ## Rules
 
 - A Figma file labeled "design system" in the team's project list may actually be a **figma mirror of a third-party component library** (third-party kits like Ant Design, antd-mobile, Material, or Polaris are illustrative — the same pattern recurs across many ecosystems). Confirm by checking the page list for explicit names like `<Library> System for Figma` or `Figma to <Library>`; if present, treat the file as the third-party spec, not as team-authored tokens. The team's brand customisation usually lives in a smaller separate file, often named for a product framework refresh, a brand-system file, or a workbench/shell file — name conventions vary across teams.
-- A figma project that spans multiple end stacks should split design-system files by stack: one for desktop, one for mobile (and one for any non-React mini-app / native surface). Business-module files should not carry their own token/style definitions; they should reference the design-system file only.
+- A design portfolio that spans multiple rendered stacks must inventory React and other web, H5, native mobile, mini-app, terminal/TUI, Electron/desktop, TV, and any additional client. Assign each stack to one canonical design-system source or an explicit shared-source decision with stack-specific variants and evidence; do not infer that a desktop/mobile pair covers the rest. Business-module files should not carry their own token/style definitions; they should reference the applicable canonical source only.
 - A business-module Figma file is correctly scoped when its `/v1/files/<key>/styles` and `/v1/files/<key>/components` endpoints return zero file-local entries — all styles inherited from the design-system file. Non-zero counts on a business file = the file has forked tokens, which is a refactor flag.
 - Theme/token source files in code must include an explicit machine-checkable pointer to the design-system Figma source: top-of-file comment with the file's labeled name (not the team-internal nickname) and node-id of the token frame. Pointing the comment at a business-module file instead of the design-system file is a documented anti-pattern — the next person edits the wrong source.
 - Deprecated design files must carry an explicit signal: a dated deprecation page, an archive folder, or a tracked deprecation list in the private provenance archive. Do not rely only on file-name prefixes (brand prefix, copy suffix, etc.) — prefixes are easy to miss in tooling. Keep the active marker list in the private archive and audit each load.
@@ -64,7 +64,7 @@ When starting work on tokens/theme/design-system:
 0. Enumerate every file in the project's design portfolio (system, upgrade plan + supplements, combined-active monoliths, exploration, UI kit version chain, platform shells per stack, icon library, interaction-spec, per-feature). Assign a Portfolio Role from the taxonomy above to every entry, plus the predecessor / derived / supplements / succeeds-version / no-relations relation to other entries. Recording the portfolio with role AND relations is mandatory before any single-file judgment; missing relations is a portfolio-enumeration defect, not a system defect.
 1. Pull the project's Figma file inventory; mark each entry `class A1` (rules-as-source), `class A2` (business-module), or `class B` (deprecated/reference) using the source-map rules.
 2. For each `A1` file, verify whether it is team-authored or third-party-mirror via page-name pattern.
-3. For the active `A1` files, confirm one per stack (desktop / mobile H5 / native / mini-app). If multiple compete, choose one as canonical and demote the others to `class B` until merged.
+3. For the active `A1` files, map every rendered stack in the authoritative consumer inventory—React and other web, H5, native mobile, mini-app, terminal/TUI, Electron/desktop, TV, and any additional client—to exactly one canonical source or one recorded shared-source decision. If multiple sources compete for a stack, choose one as canonical and demote the others to `class B` until merged.
 4. For the theme/token source file in code, verify its top-of-file Figma comment points at the canonical `A1` file's node-id, not at a business-module file.
 5. For each `A2` business file, confirm `styles_count == 0` and `components_count == 0` via Figma API. Non-zero = file-local forked tokens; route to the design-system maintainer to merge.
 6. Cross-check deprecation: every file the team treats as deprecated must appear in the private deprecation list. Files-only-marked-by-prefix get a follow-up to add them explicitly.
@@ -92,6 +92,5 @@ This fallback exists because the standard rules above require a Figma file inven
 
 ## Routing
 
-- Implementation enforcement of the comment-pointer rule and the `styles_count == 0` audit → `web-react-dev` (tools) and `testing-strategy` (acceptance).
-- Native stack-specific design-system selection → `app-cross-platform-dev`.
-- Mini-program stack-specific design-system selection → `miniapp-product-dev`.
+- Implementation enforcement of the comment-pointer rule and the `styles_count == 0` audit follows every affected client owner in `delivery-contract.md`: React web → `web-react-dev`; other web → its installed owner or project convention; native mobile → `app-cross-platform-dev`; mini-program → `miniapp-product-dev`; terminal/TUI → `terminal-cli-dev`; Electron/desktop/TV → its installed owner or the fail-closed project-convention lookup. The check must inspect the source shape actually used by that stack; a Web-only tool is not evidence for a native, terminal, or desktop client.
+- Acceptance layer and cross-client evidence sufficiency → `testing-strategy`.