@ccoalm/ccl-skills 0.7.0 → 0.8.0

package/dist/assets/marketplace/plugins/ccl-skills/skills/terminal-cli-dev/SKILL.md

@@ -1,23 +1,24 @@
 ---
 name: terminal-cli-dev
-description: Use when designing, implementing, reviewing, debugging, testing, or shipping command-line, terminal, text UI, PTY, ANSI-rendered, keyboard-driven, or console product surfaces, including the command/subcommand/flag/help contract (owned here even when nothing is rendered), layout, input, color, wrapping, selection, scrollback, accessibility, performance, and real terminal verification. Triggers also include "命令行/TUI 界面怎么做", "CLI 界面怎么写", "重构这个终端/TUI 命令或界面(局部)", "refactor a terminal command / TUI view". Skip when the ask is CLI/tooling implementation in a language whose dev skill owns it, without terminal-UI concerns ("用 Python 写个命令行工具" → python-service-dev, Go CLI → go-microservice-dev); a CLI in a language with no such owner stays here.
+description: CLI/terminal/console/PTY/ANSI/keyboard/TUI design, implementation, review, debugging, testing, or shipping. Owns the command/subcommand/flag/help contract (owned here even when nothing is rendered), with defaults/output/exit/action/confirmation/progress/recovery, plus layout, input, accessibility, and real-terminal evidence. Triggers include "命令行/TUI 界面怎么做", "CLI 界面怎么写", "refactor a terminal command / TUI view". Skip only parser/library/tooling internals owned by a language skill ("用 Python 写个命令行工具" → python-service-dev, Go CLI → go-microservice-dev, Node.js CLI → nodejs-service-dev) that provably preserve every user-facing command tree, default/action path, help/output/exit behavior, confirmation, progress, and recovery path; compose both owners when user-visible semantics change.
 ---
 
 # Terminal CLI Dev
 
-Use this skill for terminal and command-line product surfaces. It owns implementation mechanics for text UIs, console workflows, ANSI-rendered output, PTY-backed interaction, keyboard input, terminal capability handling, and real terminal verification. It does not own web browsers, mobile apps, mini-program hosts, backend services, or product design judgment.
+Use this skill for terminal and command-line product surfaces. It owns the user-facing command/subcommand/flag/default/help/output/exit/action/confirmation/progress/recovery contract, plus implementation mechanics for text UIs, console workflows, ANSI-rendered output, PTY-backed interaction, keyboard input, terminal capability handling, and real terminal verification. A language skill may own parser or library mechanics, but those mechanics do not displace this user-visible contract. This skill does not own web browsers, mobile apps, mini-program hosts, backend services, or product design judgment.
 
 ## Routing
 
 - Use `product-rd-workflow` first when the work spans product intent, design, implementation, testing, release, or postmortem follow-up.
-- Use `product-ui-ux-design` before or alongside coding when the terminal surface is user-facing: hierarchy, density, interaction model, copy, states, accessibility, and visual acceptance.
+- A user-facing command/subcommand/flag/default/help/output/exit/action/confirmation/progress/recovery path is a terminal surface even when it emits only plain text and never enters an alternate screen.
+- Use `product-ui-ux-design` before or alongside coding for that user-facing terminal surface: hierarchy, density, interaction model, copy, states, accessibility, consequence, recovery, and visual/textual acceptance.
 - Use `testing-strategy` to choose unit, snapshot, PTY, integration, and real-terminal evidence; return here for terminal-specific implementation mechanics.
 - Use `defect-diagnosis` first for rendering regressions, input bugs, flicker, selection/copy issues, broken resize behavior, color/readability defects, or flaky terminal tests.
 - Use `platform-observability` for telemetry/log schema and `platform-release-engineering` for rollout of behavior-changing defaults, persisted settings migrations, or terminal capability fallbacks. Do not treat CLI package distribution, installer, or updater mechanics as covered unless the release skill has explicit terminal distribution guidance.
 
 ## Core Workflow
 
-Before editing terminal UI code, output formatting, keyboard handling, PTY integration, layout, color/theme logic, or terminal tests, complete enough analysis and planning for the change to be reviewable. Scale the plan to risk: a small copy or formatting change can use a short note; a new interactive surface, renderer, input mode, terminal capability change, high-risk action, release behavior, or bug fix needs explicit scenarios, target terminal environments, verification commands, and stop conditions.
+Before editing a user-facing command tree, flag/default/action path, help/output/exit behavior, confirmation/progress/recovery flow, terminal UI code, output formatting, keyboard handling, PTY integration, layout, color/theme logic, or terminal tests, complete enough analysis and planning for the change to be reviewable. Scale the plan to risk: a small copy or formatting change can use a short note; a new command path, changed default, interactive surface, renderer, input mode, terminal capability change, high-risk action, release behavior, or bug fix needs explicit scenarios, target terminal environments, verification commands, and stop conditions.
 
 Repo-local agent contracts (`AGENTS.md` at the repo root and in source directories) are part of the delivery contract: when a change moves a stable boundary, generated surface, workflow, or directory-local rule, update the nearest contract in the same MR and keep coverage in sync per `product-rd-workflow`'s spec / repo-contract sync gate.
 
@@ -33,8 +34,8 @@ When checking a terminal/CLI project against team standards, split conformance i
    - Whether the feature requires a TTY, raw mode, cursor control, bracketed paste, mouse reporting, focus reporting, hyperlinks, truecolor, or scrollback control.
    - Behavior when capabilities are missing, disabled by user preference, blocked by a multiplexer, proxied through a remote shell, or unavailable in CI.
    - State ownership for input focus, modal overlays, selection, scroll position, unseen output, pending operations, and resize recovery.
-   - For UI/UX redesign slices meeting `product-ui-ux-design`'s page-slice trigger conditions — that gate's trigger list is authoritative and must be checked, not paraphrased, whenever a screen/surface change could be a redesign, restyle, new-style declaration, structural/visual-system change, continuation, or redesigned-surface reference — apply its cross-stack page-slice gate before terminal mechanics: RED-first focused assertion, IA regrouping by user intent/consequence, behavior-contract preservation, state matrix, rendered evidence, and the design verdict (`accepted` / `rejected` / `pending`; missing = `pending`, and `design-rejected` blocks complete/MR-ready/normal/draft MR per the **Rejected-surface rule**). Translate Web/App examples into terminal cell-grid proof instead of copying browser or device commands.
-   - For any user-facing visible terminal UI change, also record `product-ui-ux-design`'s implementation-owner checkpoint before the first edit — its field list (design/stack/test owners, entry-rule evidence, rendered/device evidence status) and copy-only path are authoritative there; load the named owner skills rather than only naming them, and treat a completion claim without `captured/verified` rendered evidence as incomplete — an explicitly accepted gap closes the slice only as `pre-runtime-test ready` / handoff, never as complete/done.
+   - For every user-facing terminal/CLI contract change—including command tree, subcommand, flag/default/action path, help/output/exit behavior, confirmation, progress, or recovery—load `../product-ui-ux-design/references/delivery-contract.md` and consume either its full Design brief + Phase 0 or its valid low-risk copy-only record + lightweight Phase 0 before coding. Only parser/library internals that preserve all of those user-visible semantics may mark UI/UX `not-applicable`, with the preservation evidence recorded. The lightweight path checks semantics, accessible text, localization/width, cell extent, and target-terminal render without inventing unrelated matrices; risk-bearing copy or behavior uses the full path. For full slices, map structure, state/adaptation matrices, behavior and criteria to the screen buffer/lifecycle; record terminal classes, dimensions, input/capability modes, resize/scrollback/selection, and preserved state.
+   - Before the first implementation edit, add the canonical `client_entry` defined there: local rule identifier or short quote and implementation decision, target surface/runtime, planned run/capture command, and behavior that must remain unchanged.
 
 3. Render by terminal cells, not string length.
    - Measure display width with ANSI-stripped, Unicode-aware logic. Cover combining marks, emoji, East Asian width, zero-width code points, variation selectors, and control characters.
@@ -78,6 +79,7 @@ When checking a terminal/CLI project against team standards, split conformance i
    - Use a PTY or equivalent integration test for raw mode, resize, key/mouse/paste sequences, terminal responses, and process lifecycle.
    - Run at least one real terminal smoke for visible interactive changes when lower layers cannot prove color, cursor, scrollback, focus, selection, or resize behavior.
    - For UI/UX redesign evidence, include target terminal class, size and narrow/short stress size, color mode or no-color fallback, keyboard-only path, empty/loading/error/final states, scrollback behavior, selection/copy boundary, resize behavior, and screenshot/transcript/PTY artifact; mark each dimension covered or `N/A` with a one-line reason. `N/A` is valid only when the reason names a verifiable structural fact, explains why that fact makes the dimension unreachable or unchanged for this slice, and includes a checkable pointer such as a file path, config key, or commit that resolves at review time. Persist evidence artifacts where reviewers can access them after redacting tokens, PII, credentials, private paths, command secrets, and raw personal data; remove temporary smoke files or PTY capture helpers before commit unless the repo intentionally owns them.
+   - Return the complete canonical client-record member defined in `../product-ui-ux-design/references/delivery-contract.md` for testing Phase 1 and the design verdict. The member includes its applied rule/decision, affected files/components, preserved behavior, exact command, immutable candidate binding, producer member/version actually exercised, artifacts, tested terminal classes/dimensions/states/input/capability modes, criterion-mapped observations, coverage boundary, and gaps. A terminal capture proves only the captured states; it cannot close an unbound producer member. `testing-strategy` records aggregate sufficiency before the design owner records the candidate-bound verdict.
    - Capture evidence: command, terminal class, size, color mode, before/after screenshot or transcript, and any unavailable capability with attempted remediation.
 
 ## Reference Loading

package/dist/assets/marketplace/plugins/ccl-skills/skills/testing-strategy/SKILL.md

@@ -73,8 +73,7 @@ Use this skill to decide whether a specialized or non-functional test belongs in
 - A "skip CI" / "no runner" instruction does not by itself lower verification rigor, only ceremony. When the blocking CI gate is skipped or unavailable, substitute a same-risk independent check before treating the change as verified — for a tiny/doc/test-only change a local command or `diff --check` is enough; for a change that can break its own gate (it edits the test/tripwire/CI config it is guarded by), an adversarial review/challenge of the diff is what catches the self-break CI would have. Note where a local run is not equivalent to CI (secrets, OS matrix, merge-result pipeline) rather than treating it as full proof. Separately, a project-enforced merge gate (pipeline-must-pass, required review) is not waived by a "skip CI" instruction for convenience: require green status, or an explicit authorized break-glass/override with recorded reason + residual risk — surface the conflict and stop rather than silently bypassing.
 - Browser/E2E smoke must assert visible outcomes, not just click controls. For frontend API pages, verify loading, success, failure, disabled/retry behavior, and absence of dangerous actions where relevant. Capture or inspect console errors and failed network requests when the browser tool supports it.
 - UI tests and screenshots must prove design quality layers, not only DOM existence. Assert or visually inspect aesthetic hierarchy/density, interaction path, behavioral recovery states, and psychology-critical cues such as disabled reasons, progress certainty, retry safety, confirmation consequences, and return context.
-- For UI/UX redesign slices meeting `product-ui-ux-design`'s page-slice trigger conditions — that gate's trigger list is authoritative and must be checked, not paraphrased, whenever a screen/surface change could be a redesign, restyle, new-style declaration, structural/visual-system change, continuation, or redesigned-surface reference — derive scenario selection from that gate's recorded state matrix and RED baseline instead of re-inventing scenarios, and route rendered-evidence layer choice here as usual. A test plan that ignores a triggered page-slice record, or that lets component/DOM layers stand in for the gate's stack-routed rendered evidence, is incomplete.
-- For any runtime visible UI/UX slice, consume `product-ui-ux-design`'s implementation-owner checkpoint (its field list and copy-only path are authoritative there): this skill is the named test owner for assertion and rendered-evidence layer selection, and a test plan or completion claim whose rendered/device evidence status is not `captured/verified` is incomplete. If no checkpoint exists for the slice, that absence blocks implementation-facing test plans and completion claims — load `product-ui-ux-design` and remediate the checkpoint first; producing this skill's assertion-layer and rendered-evidence choice as an input to creating that checkpoint is the expected first step, not a blocked action. An explicitly accepted gap recorded per that checkpoint closes the slice only as `pre-runtime-test ready` / handoff with the gap stated, never as complete/done.
+- For every runtime-visible UI/UX slice, load the canonical sequence in `../product-ui-ux-design/references/delivery-contract.md` and `references/client-runtime-test-matrices.md` §UI/UX Delivery Contract before Phase 0 and after producer/client execution. Testing owns layer selection and sufficiency, binds and cites the complete design/test/producer/client record and candidate-binding sets, confirms every affected client wrote its canonical pre-edit `client_entry` and complete client-record member naming the producer version it exercised, fails closed on a missing/incomplete/mismatched/stale/changed-after-run/unexercised member, and never issues the holistic design verdict.
 - Authentication and account surfaces need an explicit scenario matrix before they can be called complete. Cover identity-input validation across relevant entries, available sign-in methods, registration, account recovery or password reset/change, logout/account switching, sensitive storage/log cleanup, permission or host-authorization denial, and UI/UX acceptance for error copy, disabled reasons, keyboard/safe-area/touch behavior, and visual evidence. If a capability such as recovery, host authorization, real message delivery, or live account verification is absent or external, record it as `product gap`, `blocked`, or `live-only` instead of silently excluding it from the test claim.
 - Test cases come before implementation and broad execution for behavior-changing work. Write a compact test-case register first: scenario, layer, assertion, data/dependency, command, expected current result (`fail`, `pass-existing`, `blocked`, or `gap`), and owner. For bug fixes and user-visible or contract-visible behavior, at least one relevant case must be added or updated and run RED before implementation unless no harness can support it after normal remediation; then record the evidence gap and strongest alternate check. The same RED-first discipline applies to defect records: a reported defect (issue, QA finding) carries the reproducible command plus the actual failing output, and the fix change references that failing test — a bug "fixed" from its description alone, without a RED reproduction, is unverified.
 - Do not answer "tests are complete" from command output alone. The claim must map each important scenario to a written case or to an explicit `blocked`, `live-only`, `product gap`, or `not applicable` row.
@@ -90,7 +89,7 @@ Use this skill to decide whether a specialized or non-functional test belongs in
 - Do not open, merge, or describe an MR as ready for a contract-visible change until the test matrix has been written and executed, or each unavailable layer is explicitly marked unavailable with reason and residual risk. The matrix must include the relevant unit, API/contract, integration, and browser/device/E2E layers; missing layers are a release risk, not an afterthought.
 - A multi-stack development-standard family is incomplete without a testing standard. The testing standard must define test deliverables, layer policy, harness expectations, CI gates, high-risk coverage, evidence format, and stack handoff rules; stack docs may specialize commands but must not redefine the layer policy.
 - Do not mark a browser/device/E2E layer unavailable just because discovery returns no device, browser, server, or dependency. First run the normal remediation path: launch the emulator/browser/server/container, wait for readiness, restart the client daemon if appropriate, run the repo setup script, and re-run discovery. Only after that fails may the layer be reported unavailable, with command evidence, residual risk, and next unblock action.
-- If a browser/device/E2E or host-smoke layer is classified as blocking, unavailable means the delivery is not complete. Use `pre-runtime-test ready` only when code, lower-layer tests, and build checks are done and a named human/device owner must finish the runtime gate; this is a handoff-only label, not merge-ready or release-ready. Otherwise use `blocked`. Do not describe such work as done, fixed, ready to merge, or ready to release.
+- If a browser/device/E2E or host-smoke layer is classified as blocking, unavailable means the delivery is not complete. Use `pre-runtime-test-ready` only when code, lower-layer tests, and build checks are done and a named human/device owner must finish the runtime gate; this is a handoff-only label, not merge-ready or release-ready. Otherwise use `blocked`. Do not describe such work as done, fixed, ready to merge, or ready to release.
 
 ## Entry Decision: TC Source and Scope
 
@@ -112,16 +111,18 @@ TCs cover functional and interaction scope (QA perspective: user journeys, accep
 - A TC entry without automated test code is also valid: manual test, deferred automation, or blocked environment.
 - The automated report (`gen_report.py`) tracks TC-mapped results (tests that register TC IDs via the `tc(...)` helper — see `test-artifact-management/references/tc-marker-conventions.md`) plus a separate "未链接 TC 的测试" section for tests without TC links. Broader code coverage is a code quality concern tracked separately (e.g. coverage reports, CI pass/fail).
 
-### Step B — Determine scope (if not specified by user)
+### Step B — Determine scope (if not already bounded)
 
-If the user has not specified scope, **ask before proceeding**:
+A current acceptance source or reviewable task artifact may already confirm scope. In particular, a UI/UX Design brief with a stable slice/surface, authoritative consumer inventory, affected owner(s), and criterion IDs is the confirmed bounded scope for its Phase 0/Phase 1 work; consume it instead of asking the user to restate global/file/function scope.
+
+If neither the request nor a current authoritative artifact bounds the work, inspect the current task, repository contract, diff/target, and available acceptance sources first. Ask only when two or more plausible scopes remain and choosing among them would materially change the test plan. Then ask the smallest concrete question, for example:
 
 > 请确认测试范围：
 > 1. 全局 — 整个仓库 / 当前 feature 所有文件
 > 2. 文件 — 指定文件（请提供路径）
 > 3. 函数 / 接口 — 指定函数或 API endpoint（请提供名称）
 
-Do not infer scope from context alone — an incorrect scope wastes implementation work. Wait for the user's answer before moving to layer assignment.
+Do not infer scope from stale conversation or an unverified guess. A current, resolvable Design brief or accepted scope artifact is evidence, not inference. If the inspection leaves one material scope, proceed and record its source; if ambiguity remains, wait for the user's answer before layer assignment.
 
 When scope is confirmed:
 - **全局**: run the full scenario matrix from `testing-strategy` workflow; consult TC list for all active TCs.
@@ -171,7 +172,7 @@ Before editing tests, CI gates, mocks/fakes, fixtures, test scripts, verificatio
    - High-risk resilience matrix: for each triggered class, choose the lowest layer that can prove the invariant, then add one release drill or real-flow smoke for the most expensive failure. Examples: idempotency unit/contract plus duplicate callback integration; auth timeout unit plus cross-tenant API integration; AI fallback eval/replay plus visible refusal E2E; client double-submit component test plus server idempotency integration.
    - High-risk backend tests should include missing tenant/actor/subject/resource-scope rejection, durable idempotency beyond cache TTL, mutation-plus-audit/outbox atomicity or repair visibility, stale/pending worker status, and operator/request/trace evidence for admin repair paths when those risks exist.
 
-   For client API-backed surfaces, mini-program/mobile/device runtime smoke, runtime-client mechanisms (route guards, permission trees, request interceptors, generated clients, upload wrappers, long-task polling, safe-area/keyboard/orientation handling, foreground/background restore, native bridges, app-hosted H5), terminal/CLI/TUI runtime tests, and streaming/async-finality changes (model streams, queued jobs, MQ consumers, scheduled prompt tasks, cron tasks, persisted tool-output artifacts, long-running exports, long-lived connections), load `references/client-runtime-test-matrices.md` before assigning layers — and again before declaring any runtime/device/browser evidence unavailable, not only at layer assignment. Non-negotiable anchors kept in view here: the default three-boundary client split (unit/component + API client/contract + browser/device smoke) applies unless the repository has a stronger convention; runtime-dependent smoke is **blocking** when lower layers cannot prove the changed behavior, and a missing runner after normal remediation stops at `pre-runtime-test ready` or `blocked` with owner, commands attempted, residual risk, and next unblock action — never converts into a code correctness claim; developer-tool compile/preview is structural evidence only; dangerous or irreversible operations require operator/confirmation/audit/duplicate-submit/final-status assertions before the UI or API is called ready. Build scenario matrices from the reference's reusable dimensions (host/container, identity/permission, data/state, async/finality, visual/interaction, high-consequence); do not paste product-specific matrices into this skill — product-specific lists belong in the project checklist or the owning product/domain skill.
+   For client API-backed surfaces, mini-program/mobile/device runtime smoke, runtime-client mechanisms (route guards, permission trees, request interceptors, generated clients, upload wrappers, long-task polling, safe-area/keyboard/orientation handling, foreground/background restore, native bridges, app-hosted H5), terminal/CLI/TUI runtime tests, and streaming/async-finality changes (model streams, queued jobs, MQ consumers, scheduled prompt tasks, cron tasks, persisted tool-output artifacts, long-running exports, long-lived connections), load `references/client-runtime-test-matrices.md` before assigning layers — and again before declaring any runtime/device/browser evidence unavailable, not only at layer assignment. Non-negotiable anchors kept in view here: the default three-boundary client split (unit/component + API client/contract + browser/device smoke) applies unless the repository has a stronger convention; runtime-dependent smoke is **blocking** when lower layers cannot prove the changed behavior, and a missing runner after normal remediation stops at `pre-runtime-test-ready` or `blocked` with owner, commands attempted, residual risk, and next unblock action — never converts into a code correctness claim; developer-tool compile/preview is structural evidence only; dangerous or irreversible operations require operator/confirmation/audit/duplicate-submit/final-status assertions before the UI or API is called ready. Build scenario matrices from the reference's reusable dimensions (host/container, identity/permission, data/state, async/finality, visual/interaction, high-consequence); do not paste product-specific matrices into this skill — product-specific lists belong in the project checklist or the owning product/domain skill.
 
 4. Define data and dependency strategy.
    - Use small fixtures named by scenario. For repeated/complex fixture construction, pick §4 (factory/builder) from the decision table in `references/test-code-authoring-patterns.md`.

package/dist/assets/marketplace/plugins/ccl-skills/skills/testing-strategy/references/client-runtime-test-matrices.md

@@ -16,10 +16,18 @@ For client API-backed surfaces, apply this default split unless the repository h
 - Browser/device/E2E smoke: open the real page or app screen, perform the primary action with controlled data or a stable test backend, verify the visible success path, then verify one realistic failure path is readable and non-crashing.
 - Mini-program smoke: compile or preview in the relevant platform developer tool, open the real page or preview build, verify route/scene params, loading/success/failure states, auth or permission behavior when relevant, and one host-platform capability path such as share, payment, subscribe message, camera, scan, or webview bridge when touched. Developer-tool compile or preview is structural evidence only; it does not replace assertion-based behavior tests or rendered flow checks.
 
+## UI/UX Delivery Contract
+
+For every runtime-visible UI/UX slice, load the canonical sequence in `../../product-ui-ux-design/references/delivery-contract.md`.
+
+- For a full UI/UX slice, Test selection Phase 0 derives its case set from the applicable Design brief's state/adaptation matrix, criterion IDs/outcomes, and RED baseline, while testing owns verifier type, assertion/rendered-evidence layers, commands/targets, independent oracles, and gaps; add risk-driven cases when needed, but do not silently replace or narrow the recorded design obligations. A valid low-risk copy-only record uses the contract's lightweight Phase 0—semantic, accessible-name, localization, extent, and target-render checks—instead of unrelated state/adaptation matrices.
+- After producer/client execution, Phase 1 cites the complete shared `design_record_ids`, `test_record_ids`, `producer_record_ids`, `client_record_ids`, and `candidate_binding_set`, adds only bound test-owned executions/artifacts, maps results to criteria using producer observations, client observations, and test artifacts, and records evidence sufficiency, combined coverage boundary, and unresolved gaps. Every changed or claim-bearing brief/criteria/source/review artifact, harness/oracle/fixture/config/protocol, backend/config/prompt/model producer, and every affected rendered layer has a keyed member; each client record names the producer member/version it exercised. A missing canonical `client_entry`, incomplete client-record member, or missing, mismatched, stale, changed-after-run, or unexercised member blocks sufficiency. Do not copy role-owned raw fields into a second record. A truly single-member `candidate_binding` is shorthand only; a branch name, abbreviated SHA, empty digest, mutable external path, or `commit:HEAD` after dirty execution does not bind evidence. Dirty bundles include result-affecting ignored inputs; inputs outside the checkout use their own exact-bytes `artifact-sha256` member. Testing does not issue the holistic design verdict or its status combination, and `accepted + complete` is invalid unless bound Phase 1 is `sufficient` with no required evidence gap.
+- Phase 0 is incomplete when the applicable full/lightweight design inputs are missing, or when DOM/component existence, a build pass, or an unreviewed screenshot is used in place of required rendered, interaction, accessibility, recovery, or design evidence. A user-accepted evidence gap remains at the contract's scoped handoff state, never `complete`.
+
 ## Runtime Smoke: Blocking Rules And Evidence Surface
 
-- Runtime-dependent client smoke is blocking when lower layers cannot prove the changed behavior, including platform request/chunking, streaming finality, foreground/background restore, host navigation, permission/capability prompts, native or mini-program bridge callbacks, storage/session restore, and host-rendered error or recovery states. If the runner is missing, first attempt normal setup/remediation; if still unavailable, stop at `pre-runtime-test ready` or `blocked` with owner, commands attempted, residual risk, and next unblock action.
-- For mini-program and mobile runtime smoke, treat app identity, plugin authorization, dev-tool login, service-port availability, and host permissions as part of the evidence surface. If those inputs are wrong or missing after remediation, classify the slice as `blocked` or `pre-runtime-test ready` rather than converting the gap into a code correctness claim.
+- Runtime-dependent client smoke is blocking when lower layers cannot prove the changed behavior, including platform request/chunking, streaming finality, foreground/background restore, host navigation, permission/capability prompts, native or mini-program bridge callbacks, storage/session restore, and host-rendered error or recovery states. If the runner is missing, first attempt normal setup/remediation; if still unavailable, stop at `pre-runtime-test-ready` or `blocked` with owner, commands attempted, residual risk, and next unblock action.
+- For mini-program and mobile runtime smoke, treat app identity, plugin authorization, dev-tool login, service-port availability, and host permissions as part of the evidence surface. If those inputs are wrong or missing after remediation, classify the slice as `blocked` or `pre-runtime-test-ready` rather than converting the gap into a code correctness claim.
 - For mini-program flows whose correctness depends on real-host completion state, classify the strategy as "real WeChat / real device required" and point the project checklist at a reusable host-flow template: target app entry, minimal real input, first-chunk observation, final closure, and evidence capture. Keep the concrete app name and search path in the project checklist; keep the skill-level rule generic.
 - Device/environment readiness: when a mobile, browser, or service runner is required, verify readiness with the runner's own discovery command and one direct health/state command. For Android, for example, do not trust a wrapper script alone; confirm `adb devices -l`, `adb -s <serial> get-state`, and boot readiness before treating the device E2E layer as available or unavailable.
 

package/dist/assets/marketplace/plugins/ccl-skills/skills/web-react-dev/SKILL.md

@@ -33,7 +33,7 @@ Use this skill for React web client engineering. It covers browser-rendered Reac
 
 ## Core Workflow
 
-Before editing components, routes, state, API clients, styles, configs, or tests, complete enough analysis and planning for the change to be reviewable. Scale the plan to risk: a simple low-risk single-component change can use a short inline plan; multi-file, user-visible, API-visible, accessibility-sensitive, release, bug-fix, branch/MR, unclear-risk, or high-risk work needs explicit task split, design checkpoint, acceptance checks, verification commands, rollback or stop conditions, and named handoffs to design, testing, miniapp/app, backend, or diagnosis skills before edits.
+Before editing components, routes, state, API clients, styles, configs, or tests, complete enough analysis and planning for the change to be reviewable. Scale the plan to risk: a simple low-risk single-component change can use a short inline plan; multi-file, API-visible, accessibility-sensitive, release, bug-fix, branch/MR, unclear-risk, or high-risk work needs explicit task split, acceptance checks, verification commands, rollback or stop conditions, and named handoffs to testing, miniapp/app, backend, or diagnosis skills before edits. Runtime-visible work additionally consumes the canonical UI/UX delivery contract's Design brief and Test selection Phase 0 before the first implementation edit.
 
 Repo-local agent contracts (`AGENTS.md` at the repo root and in source directories) are part of the delivery contract: when a change moves a stable boundary, generated surface, workflow, or directory-local rule, update the nearest contract in the same MR and keep coverage in sync per `product-rd-workflow`'s spec / repo-contract sync gate.
 
@@ -51,8 +51,8 @@ When checking a React project against team standards, split findings into determ
    - Identify whether state belongs in URL/query params, cache/server state, form state, local component state, browser storage, or global app state.
    - Read repo wrappers first: package manager, dev/build scripts, lint/typecheck/test runners, browser/E2E tools, environment variables, and generated clients.
    - If a design exists, map visible states and interactions to component ownership before implementing.
-   - For any visible UI change, map the design checkpoint to implementation ownership before coding: visual hierarchy/density, interaction flow, behavioral feedback, user psychology, responsive collapse, and screenshot acceptance. Do not reduce the design to component names. Also record `product-ui-ux-design`'s implementation-owner checkpoint before the first edit — its field list (design/stack/test owners, entry-rule evidence, rendered/device evidence status) and copy-only path are authoritative there; load the named owner skills rather than only naming them, and treat a completion claim without `captured/verified` rendered evidence as incomplete — an explicitly accepted gap closes the slice only as `pre-runtime-test ready` / handoff, never as complete/done.
-   - For UI/UX redesign slices meeting `product-ui-ux-design`'s page-slice trigger conditions — that gate's trigger list is authoritative and must be checked, not paraphrased, whenever a screen/surface change could be a redesign, restyle, new-style declaration, structural/visual-system change, continuation, or redesigned-surface reference — apply its cross-stack page-slice gate before React mechanics: RED-first focused assertion, IA regrouping by user intent/consequence, behavior-contract preservation, state matrix, rendered evidence, and the design verdict (`accepted` / `rejected` / `pending`; missing = `pending`, and `design-rejected` blocks complete/MR-ready/normal/draft MR per the **Rejected-surface rule**). Web is not a lower-evidence surface than app; component tests or DOM snapshots must be paired with browser-rendered evidence for changed layout, interaction, or visual states.
+   - For every visible UI change, load `../product-ui-ux-design/references/delivery-contract.md` and consume either its full Design brief + Phase 0 or its valid low-risk copy-only record + lightweight Phase 0 before coding. The lightweight path checks semantics, accessible name, localization, rendered extent, and target render without inventing unrelated matrices; risk-bearing copy uses the full path. For full slices, map structure, state/adaptation matrices, behavior and criteria to React ownership; record route/server, component/state owners, viewports/themes/input modes, and preserved behavior. When React is embedded in a native WebView, mini-program `web-view`, or Electron shell, this skill owns the content-layer member; the native/mini/desktop host owner must add its separate entry, binding and runtime record, even when host code is unchanged.
+   - Before the first implementation edit, add the canonical `client_entry` defined there: local rule identifier or short quote and implementation decision, target surface/runtime, planned run/capture command, and behavior that must remain unchanged.
 
 3. Structure React code by ownership.
    - Decompose UI by responsibility, not by arbitrary visual fragments.
@@ -98,7 +98,8 @@ When checking a React project against team standards, split findings into determ
    - For API-backed UI, test component states, API client parsing/error translation, and at least one browser/E2E smoke path when feasible.
    - Inspect the rendered page in a browser for any visible UI change, responsive behavior, empty/error states, and console/network errors.
    - For UI/UX redesign evidence, include the declared stress viewport, or when none exists use the minimum supported width plus one narrow stress width such as 320px; text wrapping/overflow; loading/empty/error/final states; keyboard/focus path; and a browser screenshot or equivalent visual artifact. Mark each dimension covered or `N/A` with a one-line reason; `N/A` is valid only when the reason names a verifiable structural fact, explains why that fact makes the dimension unreachable or unchanged for this slice, and includes a checkable pointer such as a file path, config key, or commit that resolves at review time. Persist evidence artifacts where reviewers can access them using sanitized/test accounts and redacting tokens, PII, credentials, private paths, and raw personal data; delete temporary smoke pages or helper scripts before commit unless the repo intentionally owns them.
-   - For browser-runtime changes, browser smoke is a completion gate when lower layers cannot prove the behavior. This includes changes to routing, browser storage/session restore, streaming/fetch finality, visibility or foreground/background behavior, permission/capability prompts, WebView bridge callbacks, upload/media flows, and rendered loading/error/final states. If the browser or app server is missing, first attempt normal setup; if still unavailable, stop at `pre-runtime-test ready` or `blocked` and name the owner, attempted commands, residual risk, and next unblock action. `pre-runtime-test ready` is handoff-only, not merge-ready, release-ready, or complete.
+   - Return the complete canonical client-record member defined in `../product-ui-ux-design/references/delivery-contract.md` for testing Phase 1 and the design verdict. The member includes its applied rule/decision, affected files/components, preserved behavior, exact command, immutable candidate binding, producer member/version actually exercised, artifacts, tested route/server, viewport/container sizes, themes/input modes/states, criterion-mapped observations, console/network checks, coverage boundary, and gaps. The browser render proves only the captured content layer; it cannot close an embedded host or unbound producer member. `testing-strategy` records aggregate sufficiency before the design owner records the candidate-bound verdict.
+   - For browser-runtime changes, browser smoke is a completion gate when lower layers cannot prove the behavior. This includes changes to routing, browser storage/session restore, streaming/fetch finality, visibility or foreground/background behavior, permission/capability prompts, WebView bridge callbacks, upload/media flows, and rendered loading/error/final states. If the browser or app server is missing, first attempt normal setup; if still unavailable, stop at `pre-runtime-test-ready` or `blocked` and name the owner, attempted commands, residual risk, and next unblock action. `pre-runtime-test-ready` is handoff-only, not merge-ready, release-ready, or complete.
    - Check accessibility names, labels, focus order, keyboard navigation, aria only when semantic HTML is insufficient, contrast, and text wrapping.
    - Check performance when relevant: bundle impact, unnecessary renders, long lists, image loading, code splitting, hydration/runtime errors, and Core Web Vitals risk.
 
@@ -114,7 +115,7 @@ When checking a React project against team standards, split findings into determ
 - Do not treat a frontend API client as done until empty response, invalid JSON, non-2xx envelope, auth expiry, network failure, cancellation, and backend error message extraction are covered at the client or component boundary when relevant.
 - Do not scatter backend enum/string literals through React components, URL/query handling, analytics, or tests. Centralize finite-value parsing, display labels, defaults, and unknown-value behavior at the API/client-domain boundary, and keep raw literals only in clearly named boundary conversion tests that cover every known external value plus unknown/default behavior. Migrate existing non-boundary test raw literals for that value in the same pull request or mark each remaining use with `finite-value-debt: <task-ref> <owner> <deadline> <reason>`, even when the current slice does not introduce a new mapper.
 - Do not debug React/browser failures from code inspection alone when a browser reproduction, console output, network trace, screenshot, or focused test can be collected.
-- Do not claim a web client fix is complete without naming the browser/rendered verification that was run. If required browser/runtime verification is unavailable after remediation, the status is `pre-runtime-test ready` or `blocked`, not complete.
+- Do not claim a web client fix is complete without naming the browser/rendered verification that was run. If required browser/runtime verification is unavailable after remediation, the status is `pre-runtime-test-ready` or `blocked`, not complete.
 
 ## Reference Loading
 

package/dist/assets/marketplace/plugins/ccl-skills/skills/web-react-dev/references/complex-workspace-patterns.md

@@ -44,4 +44,4 @@ Use this reference after `web-react-dev/SKILL.md` identifies a React surface as
 
 - State owner map exists for every selected pattern family.
 - Long content, empty/no-data, error/retry, slow/weak network, permission/disabled, narrow/responsive, accessibility text scaling, interruption/return recovery, and repeated-use/cache-hit behavior are either tested or explicitly out of scope.
-- Browser or host-container evidence captures the declared stress widths and the primary pending/final/error states. If rendered evidence cannot run after normal remediation, status is `pre-runtime-test ready` or `blocked`, not complete.
+- Browser or host-container evidence captures the declared stress widths and the primary pending/final/error states. If rendered evidence cannot run after normal remediation, status is `pre-runtime-test-ready` or `blocked`, not complete.