@ccoalm/ccl-skills 0.7.0 → 0.8.0

package/dist/assets/marketplace/plugins/ccl-skills/skills/nodejs-service-dev/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: nodejs-service-dev
+description: Use when implementing, modifying, scaffolding, or testing Node.js backend and service code, including HTTP/RPC handlers, workers, jobs, standalone Node.js CLI/tooling, runtime configuration, TypeScript/JavaScript module setup, async cancellation, streams, graceful shutdown, and Node-specific test mechanics. Triggers include "用 Node.js 写接口", "Node 后端实现", "用 Node.js 写个命令行工具", "重构 Node 服务里的某文件/某类(局部)", "refactor a file/class within a Node.js service", "Fastify/Express/NestJS 服务", "node:test 怎么写", and "event loop / worker_threads 怎么改". Route active failures to defect-diagnosis, test-layer choices to testing-strategy, terminal contracts to terminal-cli-dev, and cross-module architecture or multi-stage delivery to product-rd-workflow.
+---
+
+# Node.js Service Development
+
+## Skill Routing
+
+- Use this skill for Node.js service implementation: handlers, middleware, adapters, workers, jobs, clients, runtime/toolchain mechanics, and focused tests.
+- New capabilities, cross-module architecture, service redesigns, and multi-stage refactors enter `product-rd-workflow`; verified repairs return here after `defect-diagnosis`.
+- `testing-strategy` chooses test layers, coverage policy, contract/E2E scope, and CI gates. This skill owns Node runner, mock, fixture, and command mechanics after that choice.
+- Standalone CLI/tooling stays here; language-stack CLI implementation must not be routed back to `terminal-cli-dev`, owner of the interface contract; logs/metrics/traces to `platform-observability`; cross-service timeout/retry/mTLS to `platform-service-connectivity`; rollout/rollback to `platform-release-engineering`.
+- Browser UI goes to `web-react-dev`; LLM/RAG/agent-runtime behavior to `llm-inference-integration`. Keep language-neutral rules in their existing owner.
+
+## Workflow
+
+### 1. Recover the contract
+
+Read the nearest `AGENTS.md`, then inspect `package.json`, lockfile/package-manager metadata, runtime-version files, `tsconfig*.json`/`jsconfig.json`, build/test scripts, deployment manifests, and the smallest relevant source path. Record:
+
+- supported and deployed Node.js line;
+- package manager and authoritative lockfile;
+- ESM/CommonJS and JS/TS execution plus type-check path;
+- framework lifecycle, verification commands, changed external contract, and non-goals.
+
+Preserve those choices unless migration is explicit. Read [runtime-and-project-contract.md](references/runtime-and-project-contract.md) when changing one.
+
+### 2. Define and implement the narrow boundary
+
+State input, output, error, cancellation, timeout, idempotency, and ownership before code. Preserve established contracts unless explicitly changed; validate untrusted data at the owning boundary.
+
+- Keep event-loop callbacks and worker-pool tasks short; bound fan-out, queues, retries, payloads, and buffering.
+- Propagate cancellation/deadlines to underlying work. A wrapper timeout that leaves work running is not cancellation.
+- Use streams with backpressure for large/unbounded data. Use a bounded `worker_threads` pool only for measured CPU-intensive JavaScript, not ordinary async I/O.
+- Preserve error causes and map once at the boundary. Do not swallow rejections or resume normal operation after an unknown fatal process error.
+
+Read [async-lifecycle-and-performance.md](references/async-lifecycle-and-performance.md) when touching concurrency, streams, CPU work, shutdown, or performance.
+
+### 3. Make lifecycle and exposure explicit
+
+Validate configuration before traffic and never log secrets. On shutdown, stop intake, drain bounded work, abort owned background work, close resources, and honor one documented deadline; handle upgraded connections separately. Treat readiness and liveness as different contracts.
+
+Keep dependency changes minimal, update the lockfile, use frozen/immutable install verification, and review scripts/transitive impact. Bound input work and treat the Node.js Permission Model as optional defense in depth, never a complete sandbox. Read [verification-diagnostics-and-security.md](references/verification-diagnostics-and-security.md) for concrete test, diagnostic, dependency, and security checks.
+
+### 4. Verify narrow to broad
+
+Use repository commands: focused behavior and failure-path test → touched-package lint/type/check → package/service suite → build/package/start check → required repo gates. Exercise cancellation, malformed input, cleanup, and shutdown when relevant.
+
+Performance/reliability claims require a representative workload plus outcome and causal evidence. Re-run the reproducer; inspection alone cannot prove a leak, stall, or regression fixed.
+
+## Hard Rules
+
+- Preserve module convention and make new package intent explicit; do not rely on ambiguous `.js` syntax detection.
+- Built-in TypeScript stripping is execution support, not type checking or general transpilation. Keep a real type-check gate and verify unsupported syntax/`tsconfig` dependencies.
+- Prefer explicit dependencies and startup wiring over mutable process-wide singletons so tests need not bind ports or mutate globals.
+- Avoid unbounded `Promise.all`, ownerless fire-and-forget promises, synchronous hot-path APIs, per-request workers/processes, and whole-stream buffering by default.
+- Do not add blanket retries, speculative caches, generic base layers, or process-level exception recovery without observed need and an owning contract.
+
+## Output Contract
+
+Report the runtime/package/module contract, changed behavior, preserved boundaries, exact checks, measurements, skips, version assumptions, and risks.
+
+Technical claims and comparison limits are recorded in [source-map.md](references/source-map.md); ordinary implementation should load only the task reference whose decision surface is reached.

package/dist/assets/marketplace/plugins/ccl-skills/skills/nodejs-service-dev/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Node.js Service Dev"
+  short_description: "Build reliable Node.js backend and service features"
+  default_prompt: "Use $nodejs-service-dev to implement a Node.js backend or service change from the repository's runtime, module, lifecycle, and verification contracts."

package/dist/assets/marketplace/plugins/ccl-skills/skills/nodejs-service-dev/references/async-lifecycle-and-performance.md

@@ -0,0 +1,72 @@
+# Async, Lifecycle, and Performance
+
+Use this reference when a change touches request concurrency, cancellation, streams, CPU work, background jobs, shutdown, or a performance claim.
+
+## Classify the work first
+
+| Work | Default execution | Main risk |
+|---|---|---|
+| Network and async file/database I/O | Native async API on the event loop | unbounded concurrency, missing timeout/cancellation, retained buffers |
+| Short JavaScript transformation | Event-loop callback | input-dependent long task, excessive allocation |
+| CPU-intensive JavaScript | Bounded `worker_threads` pool or external worker | worker creation/serialization overhead, queue growth, memory sharing |
+| Blocking/native task using libuv pool | Async API, with measured pool pressure | worker-pool starvation across unrelated requests |
+| Large or unbounded payload | Stream/pipeline with backpressure | full buffering, missing cleanup, partial output |
+
+Node.js uses a small number of threads to serve many clients. A long callback reduces event-loop throughput; a long libuv task can starve the worker pool. Both can become denial-of-service paths when complexity or input size is attacker-controlled.
+
+## Cancellation and deadlines
+
+- Accept an owning cancellation/deadline signal at service boundaries and pass it through every supported downstream API.
+- Prefer an existing `AbortSignal`; combine caller cancellation and timeout without losing the original reason when the supported runtime provides the needed API.
+- A raced timeout that rejects while the database call, fetch, stream, worker, or child process continues is not cancellation. Close/destroy/abort the underlying resource or document why it cannot be stopped and bound the orphaned work.
+- Remove listeners and timers during cleanup. Use `unref()` only when it matches lifecycle ownership; it is not a substitute for cancelling work.
+- Retries must fit inside one overall deadline, use the connectivity owner's policy, and remain bounded. Never retry non-idempotent effects without an idempotency contract.
+
+## Bounded concurrency
+
+- Replace unbounded `Promise.all(items.map(...))` on variable-size input with a repository-standard limiter, queue, or batch window.
+- Bound queue length as well as worker count. Define overload behavior: reject, shed, defer durably, or backpressure the producer.
+- Track in-flight ownership so shutdown can await or abort it. A detached promise must have an explicit supervisor and error sink.
+- Avoid per-request child processes or workers. If CPU offload is justified, measure task duration and transfer cost, then reuse a bounded pool.
+
+## Streams and backpressure
+
+- Prefer `node:stream/promises` `pipeline()` or an established equivalent so errors and teardown propagate across the chain.
+- Respect `write()` backpressure/drain semantics and configure object/buffer high-water marks from measurement, not folklore.
+- Set payload/record limits even when streaming. Streaming bounds memory growth; it does not bound total work.
+- Propagate abort signals and verify cleanup on source error, transform error, destination error, client disconnect, and timeout.
+- Do not mix flowing-mode event handlers and async iteration on the same readable unless the lifecycle is deliberately controlled.
+
+## Errors and process lifecycle
+
+- Catch errors at boundaries that can make a valid decision: translate, retry under policy, compensate, or fail the operation. Otherwise preserve `cause` and propagate.
+- Treat unknown `uncaughtException` and default-throw unhandled rejection paths as fatal. A handler is for synchronous cleanup/diagnostics before termination, not resuming normal operation from an undefined state.
+- On `SIGTERM`/the platform's shutdown signal:
+  1. mark readiness false or otherwise stop new routing;
+  2. stop accepting new work;
+  3. drain bounded in-flight work;
+  4. abort/stop owned background loops and consumers;
+  5. close database, queue, cache, HTTP, worker, and telemetry resources;
+  6. force termination only after the documented grace deadline.
+- `server.close()` and force-closing connections have version-specific semantics. Verify the deployed Node line, long-lived/upgraded connections, keep-alive behavior, and orchestrator grace period.
+- Prefer setting `process.exitCode` and allowing owned flushes to finish. Use immediate `process.exit()` only when the deliberate loss of pending asynchronous work is acceptable.
+
+## Evidence-led performance
+
+1. Reproduce with a representative payload, concurrency, runtime flags, dependency state, and warm-up period.
+2. Capture an application outcome (latency distribution, throughput, timeout/error rate) and at least one causal signal (CPU profile, event-loop delay/utilization, worker-pool/queue depth, heap/GC, active resources).
+3. Change one mechanism, rerun the same workload, and compare distributions rather than one fastest sample.
+4. Check correctness and resource cleanup under load; faster wrong or leaking code is a regression.
+
+Use CPU profiles/flame graphs for CPU attribution and heap/retainer evidence for memory claims. A heap snapshot stops the main thread and can approximately double heap use while being produced; do not take one from a sole production instance or expose an unauthenticated snapshot endpoint.
+
+## Focused adversarial cases
+
+- large but valid input;
+- malformed input that exercises worst-case parsing/regex behavior;
+- downstream never responds or ignores cancellation;
+- client disconnects mid-stream;
+- queue reaches its bound;
+- shutdown arrives during startup and during in-flight work;
+- worker crashes or returns an unserializable/oversized result;
+- retry budget/deadline is exhausted.

package/dist/assets/marketplace/plugins/ccl-skills/skills/nodejs-service-dev/references/runtime-and-project-contract.md

@@ -0,0 +1,58 @@
+# Runtime and Project Contract
+
+Use this reference when a Node.js change touches runtime selection, package-manager state, ESM/CommonJS, TypeScript execution, dependencies, or configuration.
+
+## Runtime selection
+
+1. Prefer the repository and deployment contract over a generic recommendation. Reconcile `.nvmrc`, `.node-version`, `package.json#engines`, package-manager metadata, container base image, CI matrix, and production runtime; do not silently choose one when they disagree.
+2. For a new production target with no existing contract, select a currently supported Active LTS or Maintenance LTS line from the live [Node.js release page](https://nodejs.org/en/about/previous-releases). Do not hardcode “latest” or infer support from odd/even numbering: the project announced an annual schedule beginning with Node.js 27, and the live [release schedule](https://github.com/nodejs/Release/blob/main/schedule.json) is authoritative when dates drift.
+3. Use a Current or Alpha line only for an explicit compatibility/experimentation goal. Record the fallback and do not widen the production support claim from a development smoke test.
+4. Test the lowest and highest supported runtime when a library or shared package promises a range. An application normally pins one deployment line and tests the upgrade candidate separately.
+
+## Package-manager and dependency state
+
+- Treat the committed lockfile plus package-manager metadata as the reproducibility contract. Do not switch npm/pnpm/yarn/bun or regenerate a foreign lockfile without an explicit migration.
+- Use the manager's frozen install in CI and verification. For npm, `npm ci` requires an existing lockfile, removes an existing `node_modules`, fails when `package.json` and lock state disagree, and does not rewrite either file.
+- Keep dependency additions proportional to the contract. Check maintenance, runtime support, transitive size, native build/install scripts, license constraints, and whether a built-in API already meets the need.
+- Treat provenance/signatures as origin evidence, not a safety verdict. A vulnerability scan also cannot prove that a dependency is non-malicious or that a vulnerable path is reachable.
+- Never accept automatic dependency updates solely because CI is green. Review behavior, changelog/security impact, lockfile delta, and rollback path.
+
+## ESM and CommonJS
+
+- Preserve the established module system. For a new package, set `package.json#type` explicitly and choose extensions/exports that match the actual consumers.
+- Do not rely on Node.js syntax detection for ambiguous `.js` files. Explicit intent prevents behavior changes across runtimes and tooling.
+- Treat package `exports` as a public compatibility contract. Test every promised import/require path from a packed artifact when publishing a library; service-internal path aliases still need runtime support, not only editor/type-check support.
+- Keep dynamic import, top-level await, JSON/native modules, test runner, bundler, and deployment loader behavior in the compatibility matrix when the change uses them.
+
+## TypeScript paths
+
+Choose one explicit path:
+
+| Path | Use when | Required proof |
+|---|---|---|
+| Compile/transpile before run | The service uses emitted JavaScript, transforms, decorators, path rewriting, or an older runtime | type-check, emitted artifact, source-map/error behavior, production start command |
+| Runtime loader/tool | The repository already standardizes on one | loader version/runtime matrix, type-check remains separate, production parity |
+| Node.js type stripping | The deployed runtime supports it and source uses erasable syntax only | no unsupported transform syntax, no `tsconfig`-dependent runtime behavior, explicit type-check gate |
+| Plain JavaScript | The repository does not require TypeScript | runtime syntax target, lint/check path, public type contract if shipped as a library |
+
+Node.js type stripping ignores `tsconfig.json`, performs no type checking, and does not transform syntax such as enums, runtime namespaces, parameter properties, or import aliases. Do not present it as a drop-in replacement for an existing compiler pipeline.
+
+## Configuration contract
+
+- Parse and validate configuration once during startup; pass typed/validated values inward rather than reading `process.env` throughout the codebase.
+- Separate presence, format, range, and cross-field validation. Error messages may name a key but must not echo secret values.
+- Define precedence among defaults, env files, environment variables, flags, secret mounts, and remote configuration. A newly available built-in flag is not permission to change repository precedence.
+- Keep build-time and runtime configuration distinct. Verify container/orchestrator injection and local development paths separately.
+
+## Contract checkpoint
+
+Before implementation, be able to state:
+
+```text
+Runtime: <repo/deploy evidence and supported line>
+Package manager: <manager + lockfile>
+Modules: <ESM/CJS boundary>
+Type path: <execution + type-check>
+Public contract changed: <yes/no + exact surface>
+Compatibility matrix: <minimum necessary rows>
+```

package/dist/assets/marketplace/plugins/ccl-skills/skills/nodejs-service-dev/references/source-map.md

@@ -0,0 +1,41 @@
+# Maintainer Source Map
+
+Inspected 2026-08-30. This file records provenance and extraction limits; it is not required reading for ordinary Node.js implementation work.
+
+## Primary Node.js and npm sources
+
+| Decision surface | Inspected source | Extracted constraint |
+|---|---|---|
+| production runtime | [Node.js releases](https://nodejs.org/en/about/previous-releases), [release schedule](https://github.com/nodejs/Release/blob/main/schedule.json), [2026 schedule announcement](https://nodejs.org/en/blog/announcements/evolving-the-nodejs-release-schedule) | production uses supported LTS; live schedule beats memorized odd/even rules; Node.js 27 begins the announced annual model |
+| packages/modules | [Packages API](https://nodejs.org/api/packages.html) | make module intent explicit; ambiguous `.js` syntax detection is not a project contract |
+| TypeScript | [TypeScript API](https://nodejs.org/api/typescript.html) | built-in stripping is stable on documented lines but performs no type checking, ignores `tsconfig`, and supports erasable syntax only |
+| tests | [Test runner API](https://nodejs.org/api/test.html), [CLI API](https://nodejs.org/api/cli.html) | `node:test` is capable but individual coverage/CLI features remain version-gated; preserve the repo runner and verify the supported matrix |
+| concurrency/context | [Worker threads](https://nodejs.org/api/worker_threads.html), [async context](https://nodejs.org/api/async_context.html) | workers suit CPU-intensive JavaScript, not ordinary I/O; prefer optimized `AsyncLocalStorage` over custom `async_hooks` context machinery |
+| event loop / DoS | [Don't block the event loop](https://nodejs.org/en/learn/asynchronous-work/dont-block-the-event-loop) | long event-loop or worker-pool work reduces throughput and can create denial-of-service paths |
+| cancellation/streams | [Global Abort APIs](https://nodejs.org/api/globals.html), [Streams API](https://nodejs.org/api/stream.html) | propagate cancellation to underlying work; pipeline/backpressure owns teardown for large data |
+| fatal errors / shutdown | [Process API](https://nodejs.org/api/process.html), [HTTP API](https://nodejs.org/api/http.html) | unknown uncaught failures are not safe recovery points; connection-closing behavior is version- and protocol-sensitive |
+| diagnostics | [Heap snapshots](https://nodejs.org/en/learn/diagnostics/memory/using-heap-snapshot), [flame graphs](https://nodejs.org/en/learn/diagnostics/flame-graphs) | performance claims need profiles/measurements; heap snapshots can stop the main thread and exhaust memory |
+| security | [Node.js security best practices](https://nodejs.org/en/learn/getting-started/security-best-practices) | bound input work, harden dependencies, and use runtime permissions only as defense in depth |
+| reproducible install / provenance | [npm ci](https://docs.npmjs.com/cli/v11/commands/npm-ci/), [npm provenance](https://docs.npmjs.com/generating-provenance-statements) | frozen lockfile install is the verification contract; provenance proves origin/build linkage, not code safety |
+
+## Independent industry controls
+
+- [OWASP NodeJS Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Nodejs_Security_Cheat_Sheet.html): used to challenge missing web/runtime security axes. Framework- or version-specific prescriptions were not copied without Node.js primary-source support.
+- [OpenSSF npm supply-chain guidance](https://openssf.org/blog/2022/09/01/npm-best-practices-for-the-supply-chain/): used to challenge lockfile, install-script, dependency, CI, and provenance handling. Supply-chain release governance remains routed to existing CCL owners.
+- [Node.js Best Practices](https://github.com/goldbergyoni/nodebestpractices): broad practitioner checklist consulted as coverage input only; its July 2024 edition and library preferences are not treated as current runtime authority.
+
+## Evaluation-method sources
+
+- [Anthropic, Demystifying evals for AI agents](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents): grounds the split between a task's inputs and success criteria, multiple trials for variable outputs, combined code/model/human graders, and review of both outcomes and transcripts. This supports separate routing and body-effect measurements; it does not make either one a merge gate.
+- [OpenAI, How evals drive the next chapter in AI for businesses](https://openai.com/index/evals-drive-next-chapter-of-ai/): grounds the specify → measure → improve loop and contextual evals tied to the actual workflow rather than generic benchmark scores.
+- [OpenAI, A shared playbook for trustworthy third party evaluations](https://openai.com/index/trustworthy-third-party-evaluations-foundations/): grounds binding claims to the tested system, harness, task distribution, budget, elicitation method, and validity checks. A skill-content result must therefore identify the exact skill snapshot and host conditions it tested.
+- [On Randomness in Agentic Evals](https://arxiv.org/abs/2602.07150): large-sample evidence that agent trajectories vary even at temperature zero; a future effectiveness claim needs repeated independent trials and uncertainty, not one favorable answer.
+- [Judging the Judges: A Systematic Study of Position Bias in LLM-as-a-Judge](https://aclanthology.org/2025.ijcnlp-long.18/): supports balanced answer order and human inspection for pairwise model judgments. An LLM preference is advisory evidence, not an oracle.
+
+## Extraction limits
+
+- This is a source-backed design, not proof that every rule improves agent behavior in production. The deterministic RED/GREEN baseline proves discovery/routing registration and repository conformance only.
+- The Node.js body fixtures freeze tasks and rubrics for later paired evaluation. Until repeated with/without runs bind the same model, host, tools, budget, skill snapshot, and blind grading procedure, their result class remains `insufficient-evidence`.
+- Runtime and CLI stability can change. The skill deliberately tells the agent to resolve the live release/support matrix instead of hardcoding Node.js 24/26.
+- Framework-specific internals were not generalized. Express, Fastify, NestJS, Hono, and other frameworks retain their repository-local lifecycle and security contracts.
+- No peer-skill text was copied as authoritative runtime guidance; public peer skills were used for structure and collision analysis, while technical claims were checked against primary Node.js/npm sources. Snapshot details stay in the extraction register rather than the distributed runtime skill.

package/dist/assets/marketplace/plugins/ccl-skills/skills/nodejs-service-dev/references/verification-diagnostics-and-security.md

@@ -0,0 +1,63 @@
+# Verification, Diagnostics, and Security
+
+Use this reference when selecting concrete Node.js test mechanics, proving runtime behavior, changing dependencies, or reviewing Node-specific security exposure.
+
+## Test mechanics after strategy is chosen
+
+Preserve the repository's runner. `node:test` is a first-class built-in option, not a mandatory migration target. Choose a new runner only from actual needs such as ecosystem integration, transform support, watch/UI workflow, mocking behavior, coverage maturity, or multi-project support.
+
+| Behavior | Focused proof |
+|---|---|
+| Handler/domain logic | direct unit test without port/global mutation |
+| HTTP/RPC adapter | in-process integration test for status/schema/error mapping |
+| Database/queue/cache adapter | real protocol dependency or contract-faithful test double at the adapter boundary |
+| Timeout/cancellation | fake/controlled time where sound, plus assertion that underlying work stopped |
+| Stream | backpressure, partial failure, disconnect, cleanup, size bound |
+| Worker/background job | ownership, retry/idempotency, poison input, shutdown/drain |
+| Process lifecycle | child-process test for signal, exit code, readiness/drain deadline |
+| Package/module boundary | start/import/require the built or packed artifact on the supported runtime matrix |
+
+Mock the narrow external boundary, not the implementation under test. Reset mocks/timers and avoid cross-test process-global mutation. When concurrency is meaningful, test ordering independence and run the suspected flaky case repeatedly before calling it stable.
+
+Coverage is a gap detector, not the acceptance oracle. Keep an existing threshold; change policy through `testing-strategy`. Node's built-in coverage and threshold flags have version/stability differences, so verify them against every supported runtime before making them a required gate.
+
+## Diagnostic decision table
+
+| Symptom | Start with | Avoid claiming from |
+|---|---|---|
+| high CPU / latency | reproducer, CPU profile/flame graph, event-loop and queue evidence | one stack sample or code inspection |
+| event-loop stall | event-loop delay/utilization plus long-callback attribution | total CPU alone |
+| memory growth | heap/GC trend, retained-object comparison, active resources | RSS snapshot alone |
+| process will not exit | active handles/resources, owned timers/listeners/workers, lifecycle trace | adding forced `process.exit()` |
+| worker-pool starvation | workload class, async-resource duration/concurrency, pool queue symptoms | increasing pool size first |
+| flaky async test | repeated isolated run, seed/time/concurrency capture, leaked-resource check | blanket timeout increase |
+
+Bind evidence to the candidate runtime and commit. A diagnostic command that failed, timed out, or could not attach is missing evidence, not a clean result.
+
+## Security review axes
+
+- **Input and complexity:** validate type/shape/range; limit headers, bodies, decompression, records, regex complexity, recursion, and parsing work. An input-dependent long callback is both performance and DoS risk.
+- **Injection and paths:** use parameterized database/process APIs, avoid shell construction, normalize and constrain filesystem paths, and define archive/symlink behavior.
+- **HTTP boundary:** keep secure parser defaults, schema-validate untrusted network input, set explicit timeouts/limits appropriate to the framework/runtime, and do not expose framework diagnostics or raw errors.
+- **Outbound access:** validate destinations and redirects where user input influences network access; apply platform egress controls for service-level guarantees.
+- **Secrets and logs:** never log credentials/tokens/raw sensitive payloads; redact at structured logging boundaries and test representative failure paths.
+- **Dependencies:** review direct and transitive changes, install scripts, lockfile delta, known advisories, maintainer/package identity, and rollback. `npm audit` or equivalent is one signal, not a pass/fail security proof.
+- **Runtime containment:** the Node.js Permission Model can reduce filesystem/network/process/addon/worker capabilities on supported runtimes. Verify flags and framework needs in the deployment environment. It is defense in depth and does not make malicious in-process code trustworthy.
+- **Prototype/object hazards:** accept only expected keys, use schema validation, avoid unsafe recursive merge of untrusted objects, and keep framework/runtime patched.
+
+Route threat-model and required-review gate decisions to `feature-risk-router`. Route service-wide identity, authorization, tenant isolation, data ownership, or network-policy architecture through `product-rd-workflow` and the appropriate platform/security owner before implementation.
+
+## Verification transcript
+
+Capture a compact table:
+
+| Check | Command/probe | Result | Candidate/runtime |
+|---|---|---|---|
+| focused behavior | repository command | pass/fail | SHA + Node line |
+| failure/cancellation | test or reproducer | pass/fail | same |
+| lint/type/check | repository command | pass/fail | same |
+| package/service suite | repository command | pass/fail/skipped | same |
+| build/start/package | repository command | pass/fail/skipped | same |
+| performance/diagnostic | frozen workload/probe | measured/inconclusive | same |
+
+Do not collapse skipped, unavailable, inconclusive, and passed into one “green” status.

package/dist/assets/marketplace/plugins/ccl-skills/skills/product-rd-workflow/SKILL.md

@@ -15,7 +15,7 @@ Use this skill as the top-level workflow for new product development, feature de
 - **Implementation entry / re-entry gate (active plan/spec required by default).** For product R&D deliveries that stay in this workflow, "start development" means first establish the current executable artifact set, then code against it; requests routed straight to another owning skill by the *Go straight to the owning skill* bullet below use that owner's entry rules instead. Use existing specs, implementation plans, assessment reports, issue/MR descriptions, or repo-local task docs only after reading them back or citing artifacts just produced in the active session, then checking freshness, scope, owner skills, acceptance checks, tests, stop conditions, and **landing state** (`local status`, `MR-ready`, `landed`, `release-ready`, or `shared-status-ready`). Full mechanics for every case below live in `references/implementation-entry-reentry-gate.md`.
   - Baseline authority: only an unmerged plan/spec on the current active delivery branch is the working baseline; anything else needs explicit recorded user selection plus reconciliation against landing evidence, deriving only still-unlanded deltas (§Baseline Selection).
   - A bare "continue"/"resume"/"go implement" is not a waiver: context summaries, compacted memory, and previous-response residue are not establishment (§Bare Continuation Scan); routing to a stack/execution skill selects the executor, not permission to implement — the **first implementation edit** is the gate.
-  - Before that edit, record the implementation boundary: active baseline, scope, implementation-mechanics owner named and — for hands-on product/stack code — invoked/loaded in-session before the first edit, `multi-agent-delegation` decision when delegation is plausible, a visible-UI design checkpoint with in-session `product-ui-ux-design` load, a `feature-risk-router` inventory, and test-case-first status — every pre-code gate marked triggered or `not-applicable` with a reason. **Load `references/implementation-entry-reentry-gate.md` before recording the boundary**: every owner-naming field must follow its invoke bar on its triggered values and per-field trigger table there — delegation being plausible at all loads `multi-agent-delegation`, including when you record `local`. Reaching the first implementation edit without this boundary record is a process defect.
+  - Before that edit, record the implementation boundary: active baseline, scope, implementation-mechanics owner named and — for hands-on product/stack code — invoked/loaded in-session before the first edit, `multi-agent-delegation` decision when delegation is plausible, the applicable visible-UI full or lightweight record + Phase 0 with in-session `product-ui-ux-design` load, a `feature-risk-router` inventory, and test-case-first status — every pre-code gate marked triggered or `not-applicable` with a reason. **Load `references/implementation-entry-reentry-gate.md` before recording the boundary**: every owner-naming field must follow its invoke bar on its triggered values and per-field trigger table there — delegation being plausible at all loads `multi-agent-delegation`, including when you record `local`. Reaching the first implementation edit without this boundary record is a process defect.
   - Closeout backstop: a slice reported done/merged without a visible in-session load of any owner whose boundary field was triggered stays process-incomplete until that owner's post-hoc rule audit is recorded (§Closeout Backstop — a recorded `owner-load: not-required` exception still exempts its slice, and the wider audit applies from this rule forward rather than reopening already-closed slices); shared-skill changes instead follow `skill-extraction-workflow`'s "no in-session extraction invocation ⇒ interim" closeout.
 - **Go straight to the owning skill instead** when the request is a narrow stack fix, a narrow diff/PR review, a security-only audit, or a single-symptom / repro / failing-test / regression defect (→ `defect-diagnosis`) — but if such a fix would change a shared deterministic gate/verifier, or shared/cross-repo contract/status/version/release/compatibility semantics (whether in a named surface or in code, generated artifacts, config, or scripts), re-enter this workflow's shared-gate classification (under *Enforce quality gates*) before implementing; when it is a reusable-lesson / retro / missed-gate / skill-edit process question (→ `skill-extraction-workflow` first — only a resulting lifecycle-routing or gate *policy* change comes back here); or when the user explicitly names a workflow/process-discipline skill (brainstorm/scope-shaping, plan-writing) as the primary or only action — honor it, and reload this workflow only if that skill exposes a product/delivery-stage handoff or the user asks for delivery routing.
 - A general-purpose process skill that merely *looks* like the obvious start — brainstorm/scope-shaping, plan-writing, or TDD auto-suggested by ANY channel: a session-start prompt, an optional skill package, or the host platform's native skills listing (including a listed entry skill's own self-invocation mandate, e.g. "must invoke if there is a 1% chance") — does not replace this entry: suggestion-channel wording is channel self-promotion, not routing authority (a host-mandated preflight — mandated by a host-authored system/developer-level or equivalent higher-priority instruction — may run first without thereby becoming the delivery owner; the test is AUTHORSHIP, not rendering position: a host-authored instruction counts even when rendered within the listing surface, while a skill's own description/content claiming preflight status never does); invoke this workflow as the delivery entry (immediately after any genuine host-mandated preflight), then call that skill inside the stage it serves (for example, requirement shaping in Workflow step 1).
@@ -91,7 +91,7 @@ At each stage boundary, walk the per-stage entry-state enumeration in [Stage-Ent
    - General Feishu Wiki and Base infrastructure has no repository-level owner skill: use `lark-wiki` and `lark-base` directly. Testcase Base/table initialization and testcase records remain under `test-artifact-management`; requirement records remain under this product workflow.
    - `llm-inference-integration` owns LLM, agent, RAG, prompt, model-routing, evaluation, replay, shadow, token-cost, and inference-specific observability work.
    - For high-risk AI or data workflows, product owns the visible degradation/refusal behavior and customer-support explanation before engineering ships fallback, retry, or downgrade behavior.
-   - `product-ui-ux-design` owns product UI/UX design readiness, interaction model, visual hierarchy, state completeness, accessibility, launch/iteration design checks, and scenario lenses for community, finance/data, AI workspaces, operational tools, Web, and App surfaces.
+   - `product-ui-ux-design` owns product UI/UX design readiness, interaction model, visual hierarchy, state completeness, accessibility, launch/iteration design checks, and scenario lenses across Web, App/native, mini-program, desktop/project-native, terminal/TUI, community, finance/data, AI-workspace, and operational surfaces.
    - `multi-agent-delegation` owns AI-agent task splitting, delegation, staged review, diff inspection, and verification of delegated work.
      - **Surface it as a candidate when work becomes parallelizable**: when a multi-stage delivery develops 2+ slices that look independent, surface `multi-agent-delegation` as a candidate — it (not this gate) decides serial-vs-parallel after checking true independence, write-scope isolation, and the parent-verification plan, so don't auto-split. The recurring miss is failing to notice mid-delivery that work *became* parallelizable; surfacing it is the fix — and the outcome lands in the boundary record's `multi-agent-delegation decision` field (`local` with a recorded reason), not satisfied by a bare mention.
    - `feature-risk-router` owns lightweight risk classification before selecting gates; it names required and skippable gates but does not execute them.
@@ -106,7 +106,7 @@ At each stage boundary, walk the per-stage entry-state enumeration in [Stage-Ent
    - Decide explicitly whether the work needs a formal external spec-plan workflow: multi-step assessment-to-fix-to-test work always needs a reviewed plan, but upgrades to a formal external spec plan only when scale or risk justifies the extra artifact (conditions in `references/delivery-lifecycle.md` §Plan Authoring); if not upgrading, record why a short inline plan is sufficient.
    - **Spec / repo-contract sync gate**: before implementation, name the active contract layer for the slice — product/requirements spec, technical design/ADR, and any repo-local agent contract (`AGENTS.md` or equivalent). If the change adds/removes/moves/materially changes a stable boundary, service, workflow, generated surface, directory-local rule, or architecture decision, the same slice updates the owning spec/ADR and nearest repo-local contract (`agents-file-coverage-gate` owns AGENTS.md coverage semantics). **Never restate an upstream authority's value sets — whenever the slice touches any upstream-owned value set (restating, freezing, or quoting), or asserts the upstream is silent on a point, or updates the owning spec/ADR / nearest repo-local contract, load `references/sync-spec-repo-contract.md` first**; it owns the no-copy rule and its handling mechanics (pointer + revision, value-freezing, excerpt permission, upstream-silence); for any upstream the slice depends on, cite the access-controlled pointer + revision rather than the copied value.
    - **Cross-repo feature coordination** (one feature spanning repos) — load `references/cross-repo-coordination.md` before coordinating; it owns the independent cross-repo contract/status/version/compatibility gates. Route rollout/migration mechanics to `platform-release-engineering`, semantic conformance to `testing-strategy`, and monorepo-vs-polyrepo heuristics to `references/modular-monolith-heuristic.md`.
-   - **Technical design gate** (architecture/contract altitude — separate from the section-4 visible UI design checkpoint, though one artifact may cover both):
+   - **Technical design gate** (architecture/contract altitude — separate from the section-4 visible UI delivery record, though one artifact may cover both):
      - **Owner-skill ownership covers BOTH design substance and the review gate — invoking this router does not discharge it.** When this gate is triggered and the deliverable's substance spans more than one owning skill, load the COMPLETE owner set for the touched concerns during design, not only at review; an external model/tool is **supplement-only**, never the substitute gate. Does not apply to a narrow single-owner task (one bug fix, implementation-only, or visible-UI-only change). Rationale and map discipline: `references/dispatch-owner-skills.md`.
      - **Owner-dispatch firing gate (non-exempt multi-owner designs only):** the COMPLETE owner set is recorded as an owner-dispatch map that gates **the START of design-substance production, not only design completion** — build it BEFORE drafting any design doc / test plan / architecture decision — and is re-confirmed before the first implementation edit; a partial dispatch does NOT satisfy it. The design is `interim` until the map shows, for every touched concern, an owner with **applied** evidence; an all-`N-A` map means single-owner work → use the exemption risk inventory below. Gate mechanics: `references/dispatch-owner-skills.md`.
      - **Owner-dispatch mechanical firing (opt-in, per product repo).** The `owner-dispatch` PreToolUse hook gates the first product-code edit, the Stop hook gates session close, and `scripts/owner-dispatch/owner-dispatch.sh ci` is the host-agnostic merge backstop; a repo opts in by committing `.owner-dispatch.json`, absent which the gate stays prose-only. **Closeout-acquire:** at closeout of a gated multi-owner delivery, `owner-dispatch.sh status` must read `opted-in: yes` — else install the backstop this delivery or record why exempt (single-owner / throwaway / ccl-skills itself). After invoking the owners and building the map, unblock editing via `owner-dispatch.sh record --owners "…"`. Posture and install detail: `references/dispatch-owner-skills.md` and `scripts/owner-dispatch/README.md`.
@@ -129,7 +129,7 @@ At each stage boundary, walk the per-stage entry-state enumeration in [Stage-Ent
      - **Floor** — reaching implementation with only spec plus plan on triggered work is a process defect, not a shortcut.
    - For any multi-step request that combines assessment, fixes, and verification, produce a task plan before editing code (required fields in `references/delivery-lifecycle.md` §Plan Authoring).
    - **Concurrent-session isolation**: when more than one session/agent/work-line may edit the same repository, give each line its own `git worktree` (or separate clone) on a unique per-line branch before editing — never stash another line's uncommitted changes, host-install symlinks into shared repos count as shared-tree edits, if isolation was skipped do not commit unreviewed shared changes to dodge clobber, and run the pre-merge freshness gate before merging back (recipe: `worktree-isolation`; mechanics: `references/worktree-mechanics.md`).
-   - For any code change, include an explicit test-layer decision table before implementation: `unit`, `integration/contract`, `E2E/host smoke`, and `manual/exploratory`. Each row must say `run`, `add`, `not applicable`, or `blocked`, name the command or evidence, and give the reason. For behavior-changing, bug-fix, user-visible, contract-visible, or test-harness changes, each applicable row must link to a written test case or scenario row; for behavior-neutral docs/config/mechanical-only changes, record `not applicable: behavior-neutral/docs/config-only` with the reason instead of inventing a fake scenario. If the repository lacks a relevant test framework or script, first try to add the smallest useful assertion-test harness in this slice. If that is not feasible after normal remediation, mark the automated layer `blocked`, run the strongest relevant host/runtime/manual scenario when one exists, and close only according to the blocking-gate labels below: `complete`, `pre-runtime-test ready`, or `blocked`. Do not complete code changes with no meaningful test path.
+   - For any code change, include an explicit test-layer decision table before implementation: `unit`, `integration/contract`, `E2E/host smoke`, and `manual/exploratory`. Each row must say `run`, `add`, `not applicable`, or `blocked`, name the command or evidence, and give the reason. For behavior-changing, bug-fix, user-visible, contract-visible, or test-harness changes, each applicable row must link to a written test case or scenario row; for behavior-neutral docs/config/mechanical-only changes, record `not applicable: behavior-neutral/docs/config-only` with the reason instead of inventing a fake scenario. If the repository lacks a relevant test framework or script, first try to add the smallest useful assertion-test harness in this slice. If that is not feasible after normal remediation, mark the automated layer `blocked`, run the strongest relevant host/runtime/manual scenario when one exists, and close only according to the blocking-gate labels below: `complete`, `pre-runtime-test-ready`, or `blocked`. Do not complete code changes with no meaningful test path.
    - Activating previously-unused / dormant / never-shipped code into a live path is a behavior-changing delivery slice: check why it was dormant, route security/permission/data/write-finality or unclear-verification reactivation through `feature-risk-router`, and prove the real import/wiring/runtime chain before acceptance (`references/dormant-code-activation.md`).
    - For R&D standards, specs, guidelines, or Feishu/wiki doc families, run the doc-family checklist before marking docs done: classify the layer, enumerate the family, record authority and sync gates, route testing/conformance owners, and finish only with `complete` evidence or `blocked: family enumeration unverified` (`references/rd-standards-doc-family-checklist.md`).
    - Avoid creating documents that are not needed to execute or verify the work.
@@ -144,15 +144,13 @@ At each stage boundary, walk the per-stage entry-state enumeration in [Stage-Ent
    - Never fabricate verification output, review status, source links, or install visibility to satisfy a gate; record missing evidence as missing.
    - Before sharing, publishing (Feishu/Lark/wiki/shared doc), syncing, committing, or opening a merge request for any deliverable doc — any human-readable artifact intended for another reader (spec, technical design, SOP, template, checklist, report, task card, launch material) — confirm `tighten-doc` ran on it this turn and record a one-line evidence note (mode, doc, applied-or-no-op reason), or record an explicit waiver. Exempt: private scratch or WIP not intended for review, and unchanged content whose prior tighten evidence still matches. A waiver is valid only when user-directed or naming a hard blocker (blocker, risk, next owner), not a self-authored convenience reason. This is the action-point enforcement of the Scope text-artifact-quality rule, not a duplicate: a substance/correctness review (codex review, engineering review, dual-track challenge) may comment on readability but does not satisfy the dedicated `tighten-doc` pass, which owns readability and reader orientation as a separate axis. Do not report a doc as published, shared, synced, or committed when this gate was skipped.
    - For any visible human-facing surface change, including consumer app, web, admin web, operations console, creator tool, moderation workspace, AI review workspace, or settings page, invoke `product-ui-ux-design` and run its surface classification before the first implementation edit (per the entry-gate name→invoke rule above; state/interaction acceptance may then continue alongside implementation). Component-library consistency is an implementation detail, not a substitute for design readiness.
-   - For client or admin changes that touch request plumbing, headers, telemetry, storage adapters, service clients, or other non-rendered behavior without changing visible layout, copy, state, interaction, navigation, or user-facing error handling, explicitly record `visible surface: no` and the reason. Do not route such changes to a design checkpoint unless the rendered experience or user decision flow changes.
-   - Before coding any visible UI change, produce a compact design checkpoint in the working notes or delivery artifact (field list in `references/design-routing-and-readiness.md` §Design Readiness Evidence). Visible UI changes include layout, copy, state, interaction, navigation, user-facing error/empty/loading feedback, and any user-facing operation entry — reading a design skill or naming a component library is not the checkpoint.
-   - For any visible UI change, do not commit or open a merge request until the implemented screen has been visually inspected against the design checkpoint in a real browser, app preview, screenshot, or equivalent rendered surface. Automated tests can prove behavior; they cannot prove visual taste, hierarchy, density, or whether the screen obviously follows the design skill.
-   - If rendered evidence or user review records a visible redesign — or any other page-slice-gate-triggered screen/surface/slice (a partial restyle, modernize, or visual-system change, not only a full redesign) — as `rejected`, do not continue toward commit/MR by polishing the rejected implementation. A missing or absent design verdict counts as `pending`, not acceptance, and blocks the same way. Re-enter `product-ui-ux-design`'s **Rejected-surface rule**, update the delivery artifact with the rejection and revised target, and only resume implementation after the new design checkpoint and acceptance baseline exist. The slice stays `design-rejected` — blocking complete, MR-ready, and any normal or draft MR until the re-rendered surface has a user or named independent design-owner `accepted` verdict per `product-ui-ux-design` (author self-pass cannot accept).
+   - For client or admin changes that touch request plumbing, headers, telemetry, storage adapters, service clients, or other non-rendered behavior without changing the rendered experience or user decision flow—including layout, copy, state, interaction, navigation, component semantics, accessibility/focus/keyboard behavior, or user-facing feedback/error handling—explicitly record `visible surface: no` and the reason. If any listed dimension changes, route it through the UI delivery contract.
+   - Before coding any visible UI change, load `references/design-routing-and-readiness.md` and its canonical `../product-ui-ux-design/references/delivery-contract.md`; create the applicable full Design brief or valid low-risk copy-only record and obtain Test Phase 0. Its handoff, runtime-proof, immutable-verdict, rejection, and review-only-draft boundaries are hard stops; a build or snapshot cannot imply design acceptance.
    - **Non-UI verification binds to the action, not only to the completion claim** (for non-UI code or test changes):
      - This is additive to and subordinate to the existing test rules: the verification-by-layer table below, `testing-strategy`'s MR test-matrix and blocking-runtime-gate rules, the `visible surface: no` classification, the report-only QA exception, and the closeout/landing-label rules remain authoritative and stricter wherever they apply; this gate never relaxes them.
      - Eligibility for "non-UI" is the explicit `visible surface: no` classification — user-facing error/empty/loading state, navigation, operation entry, or decision-flow changes are not non-UI.
      - Do not push to a shared branch or open a merge request until the test layer(s) the change's risk requires have run green on the final pushed state — re-run after the last code or test edit; green earlier in the turn does not count.
-     - The single exception is `pre-runtime-test ready`: when a blocking runtime/device/E2E layer's environment cannot be run here after the normal remediation path, the change may be handed off only if its lower layers and build are green, a named runtime/device owner is recorded, and the MR is opened draft / not-MR-ready (it must never be merged while only `pre-runtime-test ready`).
+     - The single exception is `pre-runtime-test-ready`: when a blocking runtime/device/E2E layer's environment cannot be run here after the normal remediation path, the change may be handed off only if its lower layers and build are green, a named runtime/device owner is recorded, and the MR is opened draft / not-MR-ready (it must never be merged while only `pre-runtime-test-ready`).
      - `blocked` (no owner or environment can run the gate) is a stop state, not a push/open-MR escape — do not push to a shared branch or open a normal MR under `blocked` unless the user has explicitly declared an evidence-only / report-only branch per `testing-strategy`.
      - A red build or red suite caused by the diff itself is never a handoff state and always blocks the action; merge always requires the blocking layers green.
      - Local or WIP commits — including a RED test-first commit during TDD — are exempt; the gate binds the shared-branch push and the MR. "executed" is insufficient; "green on the final pushed state" is the bar. This mirrors the visible-UI action gate above for non-rendered changes.
@@ -161,7 +159,7 @@ At each stage boundary, walk the per-stage entry-state enumeration in [Stage-Ent
    - If a user challenges the UI quality or asks whether the design skill was really followed, treat it as a design defect, not a preference dispute. Re-open `product-ui-ux-design` and its checklist, identify the violated design rule or missing rule, patch the UI first, then update the smallest owning skill or reference if the lesson is reusable.
    - For behavior changes, test-case-first is the default gate: write the test case before implementation, map it to the test layer and command, then add or update at least one failing/changed assertion and run it RED before coding. If no harness can support a RED test after normal remediation, record the blocker and strongest alternate check before implementation. If code was already changed before this gap is noticed, stop further implementation, add the missing test-case register, and report regression coverage honestly; do not claim TDD.
    - Verification must match risk — focused unit tests for narrow changes, integration/contract tests for cross-boundary changes, release checks for runtime-facing changes — routed through `testing-strategy` rather than redefining the split here. Code changes specifically must be tested: build, grep/static checks, typecheck, lint, manual checklist edits, and independent review/challenge are supporting evidence only; they do not replace tests. At least one relevant test layer must run for every code change before claiming complete/fixed/tested, and newly added tests must be executed in the same turn. If no relevant automated test can be created, run the strongest available host/runtime/manual scenario test and report the automation gap; if no meaningful test can be run, stop as blocked rather than completing the code change.
-   - Before calling an assessment-fix-test slice complete, report verification by layer (unit, integration/contract, E2E/host smoke, manual/exploratory, build/static, independent review); mark each missing layer `not applicable` or `blocked after remediation`. Do not collapse missing layers into a generic "verified by build", and do not use accepted risk to claim tested/fixed behavior when no relevant test ran. A layer that the step-3 test-layer decision table marks blocking blocks completion on failure or unavailability — do not reframe it as residual risk, accepted gap, or "ready". The only valid closeout labels are `complete` (all blocking gates pass), `pre-runtime-test ready` (code ready for named runtime/device handoff but not merge-ready, release-ready, or complete), or `blocked` (no owner/environment can run the gate).
+   - Before calling an assessment-fix-test slice complete, report verification by layer (unit, integration/contract, E2E/host smoke, manual/exploratory, build/static, independent review); mark each missing layer `not applicable` or `blocked after remediation`. Do not collapse missing layers into a generic "verified by build", and do not use accepted risk to claim tested/fixed behavior when no relevant test ran. A layer that the step-3 test-layer decision table marks blocking blocks completion on failure or unavailability — do not reframe it as residual risk, accepted gap, or "ready". The only valid closeout labels are `complete` (all blocking gates pass), `pre-runtime-test-ready` (code ready for named runtime/device handoff but not merge-ready, release-ready, or complete), or `blocked` (no owner/environment can run the gate).
    - Runtime-dependent client changes require runtime evidence from the affected host before completion. Browser/device/miniapp/app host smoke is blocking when the change touches platform APIs, lifecycle/foreground-background behavior, streaming/chunked transport, permissions/capabilities, navigation host semantics, storage/session restore, or rendered UI state that lower-layer tests cannot prove.
    - High-risk workflows cannot be accepted by happy-path tests alone. Require a risk scenario matrix and replayable incident drills for the relevant classes: duplicate money/quota/write side effects, permission uncertainty, tenant/user data isolation, AI provider/model failure, user repeated submission or unclear final state, and traceable incident explanation.
    - For UI backed by APIs or generated content, require `testing-strategy` to produce evidence that covers rendered states, contract/error handling, and one real visible flow where feasible. Do not let ideal mocked data stand in for runtime integration evidence.

package/dist/assets/marketplace/plugins/ccl-skills/skills/product-rd-workflow/references/design-routing-and-readiness.md

@@ -10,36 +10,32 @@ Use this reference when product work has a user-facing surface, interaction flow
 - The implementation could lock in a hard-to-change layout, data model presentation, or interaction contract.
 - The product needs a launch/readiness check for UI completeness, visual quality, or interaction polish.
 
-Small backend-only, CLI-only, config-only, or internal refactor tasks can skip design if user-facing behavior and acceptance are already clear.
+Small backend-only, parser/library-only CLI, config-only, or internal refactor tasks can skip design only when evidence proves they preserve every user-facing behavior and acceptance contract. Any changed command tree, subcommand, flag/default/action path, help/output/exit behavior, confirmation, progress, recovery, full-screen TUI, interactive terminal layout, ANSI state, or keyboard/focus flow is a user-facing terminal surface and does not qualify for that shortcut.
 
 ## Routing
 
-- Use `product-ui-ux-design` for product UI/UX design readiness across community, finance/data, AI workspaces, operational tools, Web, and App surfaces.
+- Use `product-ui-ux-design` for product UI/UX design readiness across Web, App, mini-program, desktop/native, terminal/TUI, and other user-facing surfaces.
 - Use scenario references inside that skill only when the target surface matches; community/feed/creator patterns are optional lenses, not the default model for every product.
 - Use Figma/design plugin skills when the task explicitly requires Figma file creation, design-system rules, component mapping, or design-to-code implementation.
 - Use UI/design review skills for visual QA, accessibility criteria, interaction polish, and launch-readiness review.
 - Keep product-rd-workflow responsible for sequencing, acceptance, and handoff evidence; do not duplicate detailed design-system rules here.
+- Use `../../product-ui-ux-design/references/delivery-contract.md` as the canonical design brief → test Phase 0 → producer/client execution → test Phase 1/sufficiency → design verdict record. Product R&D records the slice and sequencing decision; every changed producer and affected client writes its own runtime facts once, each client names the producer member/version it exercised, testing cites both record sets for sufficiency, and each owner fills only its part instead of restating a separate checkpoint.
 
 ## Design Readiness Evidence
 
-Before implementation, capture only the evidence proportional to risk:
+Before implementation, link one canonical delivery record, complete the applicable full Design brief or valid low-risk copy-only record, and obtain its Test selection Phase 0. This reference does not restate or partially fork the contract's schema. Record unresolved product decisions and their owner instead of filling a design gap with implementation convention.
 
-- target user/caller and primary workflow;
-- approved interaction model or wireflow for new/changed surfaces;
-- key states: empty, loading, error, success, permission denied, disabled, offline/timeout where relevant;
-- responsive/mobile expectations and accessibility constraints;
-- component/design-system reuse decisions and any intentional deviations;
-- for a visible-UI design checkpoint, also record: surface type, density mode, layout structure, trust/safety boundary, and visual acceptance criteria;
-- acceptance checks that engineering and QA can verify;
-- **cross-platform brand decisions when the same product surfaces on multiple stacks**: if the product intentionally renders different brand-primary values per platform (web vs native mobile vs mini-program), the product owner MUST record the decision explicitly — which value applies to which platform, why, and which named role in the design source carries each value (`colorPrimary-web` / `colorPrimary-native` / per-platform variable collection). Implicit "we just always used this color on Android" is the failure mode that downstream design + engineering audits keep re-discovering as drift. If the product owner decides the values should converge, that is also recorded with an owner and a target date. See `product-ui-ux-design/references/multi-project-token-consistency.md` Cross-platform brand divergence sub-case for the design-side check.
+Product-stage additions remain narrow:
 
-For dense web shells, app shells, creator workspaces, or AI/task-heavy surfaces, also capture navigation state ownership, permission-gated actions, active task/process visibility, long-label overflow behavior, global feedback placement, and how users return to their previous context after a modal, drawer, upload, generation, or detail view.
-
-For mobile surfaces, also capture safe-area behavior, keyboard avoidance, bottom navigation or sticky action behavior, update/consent dialogs, and whether errors appear inline, as toast, as a result page, or as a blocking dialog.
+- **Cross-platform brand decisions**: when the same product intentionally renders different brand-primary values per platform, the product owner records which value and named semantic role applies to each platform, why they differ, and the convergence owner/date when convergence is chosen. See `../../product-ui-ux-design/references/multi-project-token-consistency.md` for the design-side check.
+- **Dense workspaces**: select the operational/web risk lenses in `../../product-ui-ux-design/references/design-execution-checklist.md`; navigation ownership, permission-gated actions, active work, overflow, feedback placement, and return context belong in that design record rather than a second Product R&D checklist.
+- **Mobile surfaces**: select the mobile risk lens in the same router; safe area, keyboard, bottom actions/navigation, consent/update dialogs, feedback carrier, lifecycle, and recovery belong in its adaptation/state/evidence fields.
 
 ## Handoff Rules
 
 - Do not treat a vague mock, screenshot, or verbal idea as implementation-ready when states, copy, permissions, or responsive behavior are missing.
 - Do not require full design artifacts for tiny copy/state tweaks when acceptance checks are enough.
+- A visible slice may form a clearly labeled handoff commit or draft MR at `pre-runtime-test-ready` only when lower layers pass and the contract names the runtime owner and command. It is not MR-ready, merge-ready, complete, or accepted. Those stronger states require target-runtime inspection against the criteria, a complete design/test/producer/client candidate-binding set with the actually exercised versions, and an allowed verdict; builds, DOM existence, snapshots, and unreviewed screenshots prove only their stated oracle.
+- A `rejected` slice preserves its negative evidence and `rejection_basis`. A deterministic rejection permits only a failed-criterion-targeted fix, new binding, and invalidated-criterion rerun. A design-judgment or mixed rejection requires a revised target, fresh baseline/runtime evidence, and user or named independent verdict; isolated polish cannot clear it. Both paths block complete, MR-ready, merge-ready, and normal MR. A clearly labeled review-only draft MR may carry the revised bound candidate to the named independent design owner, but remains `candidate + blocked` and cannot merge until that owner records `accepted + complete`.
 - If design and architecture conflict, resolve sequence explicitly: user workflow and IA first, then service/API/data contracts that support it.
 - If design feedback reveals reusable rules, update the smallest correct design skill/reference rather than this workflow unless the lesson is about sequencing or handoff.

package/dist/assets/marketplace/plugins/ccl-skills/skills/product-rd-workflow/references/verify-developer-experience.md

@@ -7,7 +7,7 @@ Use this reference when a delivery touches developer-facing surfaces — CLI, SD
 For a new or public developer surface, or a change touching onboarding, install/setup, first-success, defaults, error surfaces, or a breaking migration, prove DX by the measured onboarding journey: run the real discover→install→first-success path as a new user and capture steps, time-to-first-success, friction, and the actual error messages. Do not infer DX from README / feature-list quality.
 
 - A smaller change proves only its affected segment, or cites recent unchanged-journey evidence.
-- An unavailable real environment after remediation uses `testing-strategy`'s proportional / lowest-sufficient-layer model and `blocked` / `pre-runtime-test ready` handling — never a faked pass.
+- An unavailable real environment after remediation uses `testing-strategy`'s proportional / lowest-sufficient-layer model and `blocked` / `pre-runtime-test-ready` handling — never a faked pass.
 
 ## Error messages are a first-class acceptance item