@ccoalm/ccl-skills 0.6.2 → 0.8.0

package/dist/assets/marketplace/plugins/ccl-skills/skills/go-microservice-architecture/references/multi-tenant-isolation.md

@@ -2,7 +2,7 @@
 
 Use when designing the tenant-isolation architecture of a SaaS service: how tenants are kept apart at the data, compute, network, identity, observability, lifecycle, and compliance layers; how queries, jobs, caches, and external calls carry tenant context safely; how a tenant's data can be exported or deleted on demand; and how shared services keep cross-tenant aggregation auditable.
 
-> **Sibling sync.** A parallel `python-service-architecture/references/multi-tenant-isolation.md` mirrors **all non-stack-specific sections** of this file. Only the *Go-specific implementation patterns* section diverges by stack. Maintainers updating any mirrored section here must update the sibling in the same change. The mirrored sections stay free of three categories of stack-specific token: DB-engine-specific syntax, runtime/concurrency-mechanic names, and library / framework API names. The concrete token list and grep command live in the *Mirrored-section grep gate* subsection at the end of this file's stack-glue section. Before commit, run that grep against the file's mirrored sections; zero hits required. The same gate lives in the Python sibling. Routing-reference text (which sibling file each "route to" link points to) may differ between Go and Python because the sibling skill trees differ — this is the only mirrored-section divergence explicitly allowed.
+> **Sibling sync.** A parallel `python-service-architecture/references/multi-tenant-isolation.md` mirrors **all non-stack-specific sections** of this file. Only the *Go-specific implementation patterns* section diverges by stack. Maintainers updating any mirrored section here must update the sibling in the same change. The mirrored sections stay free of three categories of stack-specific token: DB-engine-specific syntax, runtime/concurrency-mechanic names, and library / framework API names. The concrete token list and grep command live in the *Mirrored-section grep gate* subsection at the end of this file's stack-glue section. Before commit, run that grep against the file's mirrored sections; zero hits required. The same gate lives in the Python sibling. Routing text that differs per tree is written inline for both trees (`x.md` on the Python tree / `y.md` on the Go tree), so the mirrored bytes stay identical. Cross-file parity is machine-checked by `skill-extraction-workflow/scripts/check-parallel-stack-parity.sh` (wired into `check-ccl-skills.sh`): it diffs the mirrored regions as a byte-identical region (no normalization; tree-specific routing references are written inline for both trees), and blocks on any divergence.
 
 > **Sanitization boundary.** Tenant identifiers, customer names, lane / region names, regulator labels, and quota numbers below are illustrative; concrete values live only in the private alias map. The list of audiences that require sanitization is **positive** (these audiences require it unless explicitly approved otherwise): external / client-facing materials, customer-specific deliverables, regulator or auditor evidence, SOC / compliance reports, procurement responses, internal compliance reviews, sales-engineering or security-questionnaire appendices, partner architecture drafts, and any document that could be forwarded to any of those. "Internal" by itself is not safety; internal documents are routinely forwarded.
 
@@ -16,7 +16,7 @@ Apply when:
 
 Skip when:
 - the service is single-tenant by deployment (per-customer dedicated stack with no shared layer); route to `platform-release-engineering/SKILL.md` and to this file's *Compliance, residency, sovereignty* section for residency commitments,
-- the service is internal-only with a single owning team (employees of one org are not "tenants" for this purpose); identity/permission boundaries still apply but route to `api-security-boundaries.md`,
+- the service is internal-only with a single owning team (employees of one org are not "tenants" for this purpose); identity/permission boundaries still apply but route to `web-framework-boundaries.md` or `api-contract-and-schema.md` on the Python tree / `api-security-boundaries.md` on the Go tree,
 - tenant-equivalent isolation is owned entirely by a platform layer above the service (e.g., per-tenant namespace owned by the platform); route to `platform-service-connectivity/SKILL.md` for the platform contract.
 
 ## Tenant isolation tiers (decision tree)

package/dist/assets/marketplace/plugins/ccl-skills/skills/go-microservice-dev/SKILL.md

@@ -18,7 +18,10 @@ Use this for implementation of new backend products and services. It should adap
 - Use codebase-specific skills only when the task is explicitly about an existing legacy/workspace repository.
 - Development references should turn already-chosen architecture into code, tests, and generated artifacts. If a change requires choosing ownership, security model, source of truth, or release governance, first apply `go-microservice-architecture`.
 - For money, billing, quota, permission, tenant/user data isolation, high-impact AI, repeated writes, async finality, or incident-explanation risk, apply `product-rd-workflow` high-risk resilience gates and route test-layer design through `testing-strategy`.
-- When a change edits strings, templates, or config values that are returned to, persisted for, emitted to, served to, synchronized with, or configured for client consumption (error copy, labels, notification text, localization payloads, content/CMS/seed rows, message or notification templates, flag-delivered content), classify the consumers with a recorded bounded check (client repo / contract / locale search) before closing on API/log evidence; if any client surface renders the value user-facing, or consumers are unknown, load `product-ui-ux-design` and record its implementation-owner checkpoint — including the consuming client stack owner(s) and `testing-strategy` per that checkpoint's field list — with client-side rendered-evidence routing. Backend-only closure without that recorded consumer check is invalid.
+- When a change can alter what a client renders or which state, action, or decision path it offers—including strings/templates/config/flags and API/event/schema fields, enums, status/progress, permission/capability signals, defaults, or result shapes—load `../product-ui-ux-design/references/delivery-contract.md`, create the applicable full or lightweight record in that contract, and follow its canonical consumer-universe classification, design/test/client handoffs, and terminal-status rules.
+- This Go owner returns only its `producer_record` delta: immutable binding, build/schema/config artifact identity, exact command/environment, and API/event/log/output observation.
+
+- For a standalone Go CLI, this skill owns Go parser/library implementation mechanics. Any change to a user-facing command tree, subcommand, flag/default/action path, help/output/exit behavior, confirmation, progress, or recovery path also loads `terminal-cli-dev`, which owns the terminal contract and its UI/UX/testing handoff. Only internal parser refactors proven to preserve all user-visible semantics may skip that owner.
 
 ## Generalization Discipline
 
@@ -75,6 +78,7 @@ Repo-local agent contracts (`AGENTS.md` at the repo root and in source directori
 
 5. Verify at the right scope.
    - Run focused unit tests for changed packages.
+   - When writing the test code itself (structure, naming, smells, fixtures, behavior-vs-state, coverage, isolation, table-driven parameterization), pick the matching § from the decision table in `testing-strategy/references/test-code-authoring-patterns.md`; enable the per-stack lint executors for its machine-decidable smells (conditional logic / sleep / assertion-free tests) per `testing-strategy/references/fitness-functions.md` §4.1.4 (e.g. `forbidigo` for `time.Sleep` in tests).
    - Run integration-ish tests for DB/Redis/MQ wrappers only when environment is available.
    - **TC traceability**: link tests via `tc.Mark(t, "TC-XX-NNN")` (helper from `test-artifact-management/references/tc_helpers/tc.go`, installed under `internal/testkit/tc/`).
      - **`tc.Mark` MUST be the first non-comment line in the test body, BEFORE any `t.Skip` / `t.Skipf` / setup that may call `t.Fatal`** — otherwise the sidecar entry won't be written for skipped tests.

package/dist/assets/marketplace/plugins/ccl-skills/skills/llm-inference-integration/SKILL.md

@@ -16,7 +16,8 @@ Use this for product backend work that calls, hosts, evaluates, or operates LLM
 - Use `product-rd-workflow` first when the request spans product goal, PRD, architecture, implementation plan, release, and learning loop.
 - Use `product-rd-workflow` first for AI/algorithm product launch SOPs, business acceptance baselines, build-vs-buy ROI, new-vs-iteration launch gates, or multi-algorithm product quality gates. This skill owns inference implementation/evaluation mechanics after the product gate is defined.
 - For high-impact answers or decisions where wrong output can mislead users, affect money/rights/access, or create support/compliance risk, use `product-rd-workflow` high-risk resilience gates before fallback, downgrade, or launch decisions.
-- When a change edits strings, templates, or config values that are returned to, persisted for, emitted to, served to, synchronized with, or configured for client consumption (error copy, labels, notification text, localization payloads, content/CMS/seed rows, message or notification templates, flag-delivered content), classify the consumers with a recorded bounded check (client repo / contract / locale search) before closing on API/log evidence; if any client surface renders the value user-facing, or consumers are unknown, load `product-ui-ux-design` and record its implementation-owner checkpoint — including the consuming client stack owner(s) and `testing-strategy` per that checkpoint's field list — with client-side rendered-evidence routing. Inference-side closure without that recorded consumer check is invalid.
+- When a change can alter what a client renders or which state, action, or decision path it offers—including strings/templates/config/flags and API/event/schema fields, enums, status/progress, permission/capability signals, defaults, or result shapes—you must load `../product-ui-ux-design/references/delivery-contract.md`, create the applicable full or lightweight record in that contract, and follow its canonical consumer-universe classification, design/test/client handoffs, and terminal-status rules.
+- This inference owner returns only its `producer_record` delta: immutable binding, prompt/model/config/artifact identity, exact command/environment, and API/event/log/output observation.
 
 ## Generalization Discipline
 

package/dist/assets/marketplace/plugins/ccl-skills/skills/miniapp-product-dev/SKILL.md

@@ -23,9 +23,9 @@ For evaluating whether Taro is the right choice for a given project (vs native,
 
 ## Maturity Baseline
 
-The current rule set is **vendor-spec + framework-canonical**, not `mature confirmed`. It is grounded in: host-platform official guidelines (WeChat/Alipay/Douyin/Baidu), Taro official documentation and examples, and canonical Taro-ecosystem UI component libraries (taroify, NutUI-Taro, tdesign React mapping). It is not yet confirmed against a production-quality miniapp portfolio observed end-to-end. Treat positive rules as defaults to apply, anti-patterns as guardrails, and upgrade rules to `confirmed` only after they pass a real feature delivery without correction.
+The current baseline is **vendor-spec + framework-canonical**, not `mature confirmed`: host-platform guidelines, Taro documentation/examples, and canonical Taro UI libraries (taroify, NutUI-Taro, tdesign React mapping). No production-quality miniapp portfolio has been observed end-to-end. Apply positive rules as defaults and anti-patterns as guardrails, and mark them `confirmed` only after a correction-free real feature delivery.
 
-**On existing team mini-program codebases**: a team already running a Taro (or other) mini-program codebase does NOT automatically supply positive rules. Production use is evidence of distribution, not of quality. Until that codebase has been audited end-to-end against this skill's rules — or piloted through one real feature delivery cycle with retrospect captured via `skill-extraction-workflow` — it carries the `quality-unverified` label from `references/source-evidence-map.md`. Forward work uses this skill from the start; lessons from the existing code flow back through the extraction workflow, not by silently lifting patterns.
+**Existing team codebases** do not automatically supply positive rules: production use proves distribution, not quality. Until audited end-to-end against this skill or piloted through one real feature with a `skill-extraction-workflow` retrospective, label them `quality-unverified` per `references/source-evidence-map.md`. Use this skill from the start and feed lessons back through extraction, not silently copy patterns.
 
 ## Runtime Compatibility
 
@@ -74,7 +74,7 @@ Treat the loop as: **risk-route → product/design → develop (this skill + web
 
 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.
 
-When checking a mini-program project against team standards, split conformance into deterministic and agent review evidence. Deterministic checks cover project config, target/platform build commands, subpackage config, generated API/IDL client usage, environment/lane config, TC traceability, CI gates, and required request/trace identifiers in central request wrappers. Agent review checks cover page/component boundaries, host capability contracts, shared adapter safety, finite-value mapping, multi-target release risk, and whether tests/device evidence cover the shipped targets. For the deterministic executor list (ecosystem ESLint/`@typescript-eslint`/dep-cruiser rules + tsconfig flags) and the mini-program-specific ESLint config that enforces the two host-boundary invariants — `no-restricted-imports` banning `react-dom`/`react-dom/*` (the logic layer has no DOM), and a `no-restricted-syntax` selector confining `process.env.TARO_ENV` branching to the adapter/platform layer (use ESLint, which runs on the AST, not a regex source-scan) — see `testing-strategy/references/fitness-functions.md` §4.1.3 (client language-basics; spec 006).
+When checking a mini-program project against team standards, split conformance into deterministic and agent review evidence. Deterministic checks cover project config, target/platform build commands, subpackage config, generated API/IDL client usage, environment/lane config, TC traceability, CI gates, and required request/trace identifiers in central request wrappers. Agent review checks cover page/component boundaries, host capability contracts, shared adapter safety, finite-value mapping, multi-target release risk, and whether tests/device evidence cover the shipped targets. For the deterministic executor list and the mini-program ESLint config enforcing the two host-boundary invariants (the `react-dom`/DOM-global ban and `TARO_ENV` adapter-layer confinement — ESLint config, not a regex source-scan), see `testing-strategy/references/fitness-functions.md` §4.1.3 (spec 006).
 
 ## Sibling Boundary With web-react-dev
 
@@ -101,7 +101,7 @@ Cross-checking rule: when editing code shared with a React web project, also che
 
 ## Core Workflow
 
-Before editing Taro/native mini-program code, page config, host capability adapters, platform project files, styles, assets, or tests, complete enough analysis and planning for the change to be reviewable. Scale the plan to risk: a simple low-risk single-page change can use a short inline plan; multi-target, user-visible, API-visible, host-capability, platform-review/release, bug-fix, branch/MR, unclear-risk, or high-risk work needs explicit task split, design checkpoint, host/target verification matrix, acceptance checks, verification commands, rollback or stop conditions, and named handoffs to design, testing, web/app, backend, release, or diagnosis skills before edits.
+Before editing Taro/native mini-program code, page config, host capability adapters, platform project files, styles, assets, or tests, complete enough analysis and planning for the change to be reviewable. Scale the plan to risk: a simple low-risk single-page change can use a short inline plan; multi-target, API-visible, host-capability, platform-review/release, bug-fix, branch/MR, unclear-risk, or high-risk work needs explicit task split, host/target verification matrix, acceptance checks, verification commands, rollback or stop conditions, and named handoffs to testing, web/app, backend, release, or diagnosis skills before edits. Runtime-visible work consumes the canonical Design brief and Test Phase 0 before implementation.
 
 1. Resolve the miniapp platform and delivery shape.
    - Host platform target(s): WeChat, Alipay, Douyin/TikTok, Baidu, or several at once. Multi-target = a separate verification matrix; one target compiling is not proof another target passes.
@@ -116,8 +116,8 @@ Before editing Taro/native mini-program code, page config, host capability adapt
    - For native miniapp: WeChat uses `app.json` + `project.config.json` + `sitemap.json` + `ext.json` (plugin/extension); Alipay uses `app.json` + `mini.project.json`; Douyin/Baidu use their own platform project files. `manifest.json` + `pages.json` is uni-app shape, not native; only include it when the repo is uni-app. Also inspect package config, build scripts, and CI jobs as applicable.
    - Identify platform-branching code paths: `process.env.TARO_ENV` checks in Taro, conditional compilation blocks, or platform-specific files (`*.weapp.tsx`, `*.alipay.tsx`). Confirm branching lives at the adapter/wrapper layer, not in render code.
    - Identify whether the change must be shared, forked, or guarded by capability detection.
-   - For visible changes, map the design checkpoint to page states, navigation/back behavior, permission prompts, loading geometry, error recovery, and screenshot acceptance. 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 Taro or host-platform 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 host developer-tool or real-device proof; a browser/H5-only preview does not satisfy mini-program UI/UX evidence.
+   - 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-host render without inventing unrelated matrices; risk-bearing copy uses the full path. For full slices, map structure, state/adaptation matrices, behavior and criteria to pages/host adapters; record route/back/share entry, hosts, capabilities, recovery geometry, and preserved behavior. A mini-program `web-view` has a host member here and a separate web-content owner member; browser/H5-only preview satisfies neither the shipped-host bridge nor the complete owner set.
+   - 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. Define the miniapp contract before coding.
    - Pages, route params, tab ownership, back behavior, deep links, scene/query entry, and share/open-from-chat behavior. Treat every scene/share/QR param as untrusted input: schema-parse it, server-authorize the referenced target against the current identity, and require backend-issued, TTL-bounded, replay-protected share tokens for attribution or unlock flows. Client-side attribution is never the final source of truth.
@@ -146,6 +146,7 @@ Before editing Taro/native mini-program code, page config, host capability adapt
 
 5. Verify in the right environment.
    - Run repo formatter, typecheck/build, focused tests, and platform compile commands. For Taro, run `taro build --type <target>` for every target the change touches; one target's success is not the others' success.
+   - Test-code authoring: pick the matching § from the decision table in `testing-strategy/references/test-code-authoring-patterns.md`; smell lint: `testing-strategy/references/fitness-functions.md` §4.1.4.
    - **TC traceability**: link tests via the `createTcSuite(test, describe)` factory wrapper. Registers at collection time so `.skip` / `.skipIf` / `.todo` still map to Bitable status. Full overloads supported: `.concurrent` / `.each` / `(name, options, fn)`. Helper from `test-artifact-management/references/tc_helpers/tc.ts`, installed under `test/tc.ts`. See `test-artifact-management/references/tc-marker-conventions.md`. Before adding tests, `grep -rn 'tcTest\|tcDescribe' src/ __tests__/` plus the sidecar `test/results/tc-map.jsonl` to check for existing coverage — extend rather than duplicate. When a TC is marked 废弃, grep both source and sidecar; follow deprecation cascade in `testing-strategy`. Tests without any TC link: prompt user only when the underlying code is also removed.
    - **废弃级联：业务代码是否仍在用** — 小程序栈混合多种引用机制，单一 grep 不够：
      1. TS/JS 模块：`npx madge --dependents src/<path>` 或 `grep -rEn "from ['\"][./]*<path>"`
@@ -154,15 +155,16 @@ Before editing Taro/native mini-program code, page config, host capability adapt
      4. 静态资源：图片/字体被 wxml/wxss 引用 → `grep -rn "<filename>" src/`；分包资源 → 查每个分包 `pages` 列表
      5. 平台条件编译（Taro 多端）：`#ifdef WEAPP / ALIPAY` 内的 import 在另一端不存在；按目标平台跑 build 看 warning
    - For visible changes, inspect the rendered page in the relevant developer tool (WeChat DevTools, Alipay IDE, Douyin DevTools, Baidu DevTools), simulator, preview build, or real device and capture evidence where feasible.
-   - For systemic UI/UX redesign slices, diff the declared host target list against repo-configured build targets; every configured target must be classified as shipped (needs rendered evidence), product-level permanently excluded (can complete) — valid only when the authoritative build/release target source already stopped shipping that target before this slice; removing or disabling a target within the slice is a separate product/release scope change that routes through its product/risk/release owners and cannot satisfy this gate's evidence for the same slice; explanatory docs or an MR comment alone are temporary-skip authority, never permanent exclusion — or temporary slice-skip for a shipped target (leaves that host `pre-runtime-test ready` / `blocked`), and any unclassified target blocks completion.
+   - For systemic UI/UX redesign slices, diff the declared host target list against repo-configured build targets; every configured target must be classified as shipped (needs rendered evidence), product-level permanently excluded (can complete) — valid only when the authoritative build/release target source already stopped shipping that target before this slice; removing or disabling a target within the slice is a separate product/release scope change that routes through its product/risk/release owners and cannot satisfy this gate's evidence for the same slice; explanatory docs or an MR comment alone are temporary-skip authority, never permanent exclusion — or temporary slice-skip for a shipped target (leaves that host `pre-runtime-test-ready` / `blocked`), and any unclassified target blocks completion.
    - For UI/UX redesign evidence, include declared host targets, host developer-tool or real-device channel, loading/empty/error/final states, long text or text-scale behavior where supported, permission/capability prompts, route/share/scene entry when relevant, and screenshot or equivalent host-rendered 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; remove temporary smoke files or generated preview helpers before commit unless the repo intentionally owns them.
-   - For mini-program runtime changes, developer-tool or real-device smoke is a completion gate, not optional evidence. This includes changes to `Taro.*` or host APIs, `wx.*`/`my.*` calls, chunked/streaming transport, foreground/background recovery, route/share/scene behavior, storage/session restore, permissions/capabilities, and host-rendered loading/error/final states. If the tool or device is missing, first attempt discovery and 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 a handoff-only label; it is 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 host/tool/device targets, states/dimensions/capabilities, criterion-mapped observations, coverage boundary, and gaps. A host render proves only the captured host/member states; it cannot close an unbound producer member. `testing-strategy` records aggregate sufficiency before the design owner records the candidate-bound verdict.
+   - For mini-program runtime changes, developer-tool or real-device smoke is a completion gate, not optional evidence. This includes changes to `Taro.*` or host APIs, `wx.*`/`my.*` calls, chunked/streaming transport, foreground/background recovery, route/share/scene behavior, storage/session restore, permissions/capabilities, and host-rendered loading/error/final states. If the tool or device is missing, first attempt discovery and 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 a handoff-only label; it is not merge-ready, release-ready, or complete.
    - If an automation, remote-control, or screenshot channel reports a blank or stale mini-program surface while a human operator can see the real host page rendering, treat it as an observation-channel conflict before treating it as an app defect. Re-check focus/window/permission state, capture the human-visible state through another channel when possible, label which evidence came from the automation channel versus the human-visible host, and only mark "blank screen" as a product defect after at least one host-visible channel reproduces it.
    - When a human operator's already-authenticated host client or device is used as the runtime test surface, treat it as a human-assisted host test: record observer role/source class, sanitized account class, host client/device, entry path, actions performed, redacted artifacts, state changes such as login/logout or permission prompts, and restoration outcome in the project evidence. Label it as manual, scenario-scoped evidence; it does not replace required automated assertions or other host checks. If requested logout/account-switch/storage/permission restoration is not confirmed, mark the host test blocked or incomplete until restored or handed off to a named owner. Do not record personal phone numbers, personal operator names, chat/contact handles, tokens, private account names, or reviewer credentials in shared artifacts.
    - Treat appid, dev-tool login, plugin authorization, service-port availability, and host identity/configuration as part of the runtime verification surface, not as background noise. A generated preview QR or a backend login success does not prove the mini-program runtime path until the correct host/app identity and permissions are exercised in the tool or on device.
    - Verify route entry, share/deep-link scene params, auth state, storage restore, network error, permission denial, and primary recovery path for affected flows.
-   - For detail pages and deep-link/share/QR entry points, test missing or stale route params, missing local storage/cache payloads, expired auth, and direct cold entry. These states must resolve to an explicit empty/error/recovery state or safe redirect; a permanent loading spinner or blank screen under cold entry or missing-param entry is a blocking defect that must be fixed or explicitly marked `blocked` with a real owner, resolution path, and target follow-up point before the flow can be called complete. For stale storage/cache, include at least one real-device or emulator state test with a prior-version or manually seeded cache payload. Developer-tool-only stale-cache evidence is fallback evidence and must be labeled as a `device-state gap`; a flow with an open `device-state gap` is `blocked` or `pre-runtime-test ready`, not complete.
-   - For payment, subscription, login, phone, camera/media, or write-finality changes, verify sandbox/mock plus one platform-specific happy path. If platform evidence is unavailable after remediation, stop at `pre-runtime-test ready` or `blocked`; do not complete the work by only recording the gap.
+   - For detail pages and deep-link/share/QR entry points, test missing or stale route params, missing local storage/cache payloads, expired auth, and direct cold entry. These states must resolve to an explicit empty/error/recovery state or safe redirect; a permanent loading spinner or blank screen under cold entry or missing-param entry is a blocking defect that must be fixed or explicitly marked `blocked` with a real owner, resolution path, and target follow-up point before the flow can be called complete. For stale storage/cache, include at least one real-device or emulator state test with a prior-version or manually seeded cache payload. Developer-tool-only stale-cache evidence is fallback evidence and must be labeled as a `device-state gap`; a flow with an open `device-state gap` is `blocked` or `pre-runtime-test-ready`, not complete.
+   - For payment, subscription, login, phone, camera/media, or write-finality changes, verify sandbox/mock plus one platform-specific happy path. If platform evidence is unavailable after remediation, stop at `pre-runtime-test-ready` or `blocked`; do not complete the work by only recording the gap.
    - For release work, verify app id/env, version, build output, platform review checklist, gray release/rollback path, analytics version tag, and owner handoff. For every **shipped** host platform, compile + developer-tool/real-device evidence is blocking — "recorded as unverified" is only acceptable for targets the release is not actually shipping. Mini-program rollback through host-platform re-review is slow; risky flows must therefore have a **server-side feature flag with safe default + tested kill-switch runbook** in place before submission. Capture the current official platform-policy doc URL + date for every review-sensitive area touched (payment, privacy, AI/generated content, minors, financial/medical/legal copy) — policy text changes faster than skill rules.
 
 ## Non-Negotiable Rules
@@ -183,7 +185,7 @@ Before editing Taro/native mini-program code, page config, host capability adapt
 - Do not scatter backend enum/string literals through mini-program pages, scene/share/QR parsing, host bridge payload handling, storage, 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 ship auth, payment, phone, location, camera, share, subscription, or generated-content flows without explicit denial/error/retry states.
 - Do not ship a host platform without compile + developer-tool/real-device evidence for that platform — "recorded as unverified" is only acceptable for non-shipped targets.
-- Do not claim a mini-program runtime fix is complete when developer-tool or real-device smoke did not run. Build output, unit tests, source-regex checks, and independent code review can make the branch `pre-runtime-test ready`; they cannot make host-runtime behavior complete.
+- Do not claim a mini-program runtime fix is complete when developer-tool or real-device smoke did not run. Build output, unit tests, source-regex checks, and independent code review can make the branch `pre-runtime-test-ready`; they cannot make host-runtime behavior complete.
 - Do not submit a risky flow for platform review without a server-side feature flag (safe default + kill-switch runbook); platform-review rollback is too slow to be the only lever. The flag does not stop client-only effects (permission prompts triggered at startup, SDK auto-collection on load, host-platform config already submitted) — the flow's **client-side code path itself must no-op when the flag is off**, the SDK must not load until the flag is on, and any host-config change submitted at review time must be reviewed for "what if we need to disable this without a new submission" before approval.
 - Do not ship review-sensitive surfaces (payment, privacy disclosure, AI/generated content, minors, financial/medical/legal copy, account deletion, SDK data collection) without naming the current platform-policy doc URL + date you read.
 - Do not claim platform review or real-device readiness without current evidence.

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/platform-observability/SKILL.md

@@ -120,7 +120,7 @@ Add domain fields with a prefix (e.g. `app_*`, `biz_*`) to avoid colliding with
 - Prefer expressing an SLI as **good events / valid events** (or good windows / valid windows), per Google SRE — define valid events/windows first, then the good ratio. A latency SLI is the **proportion of requests faster than a threshold** (`count(latency ≤ T) / total`, from histogram buckets), NOT a percentile value — P95/P99 are dashboard aids, not the SLI. An error-log counter is a diagnostic signal, not an availability-SLI input (it is skewed by log sampling, dedup, and async/non-request errors).
 - Signals you cannot compute are blind spots, not near-coverage: record each one explicitly ("can't measure X because Y" — e.g. a failure counter with no attempt total yields no error *rate*; content not collected means input-semantic drift is unmeasurable) in a blind-spot register instead of pretending coverage, so on-call never leans on a signal that does not exist.
 - Each user-visible journey gets at least one availability SLI + one latency SLI.
-- Set SLO targets, error budgets, and burn-rate alerts. Default burn-rate windows: 1h fast, 6h medium, 24h slow.
+- Set SLO targets, error budgets, and burn-rate alerts (SRE Workbook multiwindow tiers, derived for a 30d budget window — recompute for other periods: page 14.4× 1h/5m, page 6× 6h/30m, ticket 1× 3d/6h). Each tier MUST evaluate its long AND short window together, firing only when both burn above threshold; the short (~1/12) window makes paging stop soon after the burn stops.
 - An SLO without an error-budget-driven release decision is decoration. See `references/sli-slo-design.md`.
 
 ### R9 — Local dev parity

package/dist/assets/marketplace/plugins/ccl-skills/skills/platform-observability/references/sli-slo-design.md

@@ -61,19 +61,35 @@ Operational rule: if error budget is exhausted, the service stops shipping non-c
 
 ## Burn-rate alerts
 
-Multi-window, multi-burn-rate per Google SRE Workbook:
+Multi-window, multi-burn-rate per Google SRE Workbook ch. 5, Table 5-6 (2% of a 30d budget in 1h, 5% in 6h, 10% in 3d):
 
-| Severity | Window | Burn rate | Meaning |
-|---|---|---|---|
-| Page (P0) | 1h | 14x | Will exhaust 30d budget in ~2 days at this rate |
-| Page (P0) | 5min | 14x | Same, but fast detection |
-| Notify (P1) | 6h | 6x | Will exhaust in 5 days |
-| Digest (P2) | 24h | 1x | Sustained at SLO threshold |
+| Severity | Long window | Short window (~1/12 of long) | Burn rate | Meaning |
+|---|---|---|---|---|
+| Page (P0) | 1h | 5m | 14.4 | Exhausts the 30d budget in ~2 days at this rate |
+| Page (P0) | 6h | 30m | 6 | Exhausts in 5 days |
+| Ticket (P2) | 3d | 6h | 1 | Sustained exactly at the SLO threshold |
 
-Alert query template:
+A tier fires only when **both** its long AND short window burn above the threshold. The long window gives detection over meaningful budget consumption; the short window confirms the burn is *still happening now*, so the alert resets quickly once the incident ends — with a long window alone, a resolved 1h page keeps firing for up to an hour, and a 3d ticket for days.
+
+The Workbook's notification types are page and ticket; P0/P2 above are this platform's local severity mapping. The Workbook maps both the 1h and the 6h tier to **page** — that stays the default (at 6×, 5% of the monthly budget is already gone and the 30m window says it is still burning). Downgrading the 6h tier to a non-paging channel is allowed only under a documented, staffed response-time policy showing that tier is acted on before material further budget loss — record it as a deliberate local deviation, never as the Workbook default.
+
+Alert query template (per tier — the recorded metric is the raw error *ratio* per window, as in the Workbook's `slo_errors_per_request:ratio_rate1h`; the burn rate is the multiplier on `(1 - SLO)`, not a pre-divided metric):
 
 ```
-slo_burn_rate{...} > <threshold>
+slo_error_ratio_1h{...}  > 14.4 * (1 - <slo_target>)
+and
+slo_error_ratio_5m{...}  > 14.4 * (1 - <slo_target>)
+# <slo_target> is a literal scalar strictly between 0 and 1, e.g.
+# 14.4 * (1 - 0.999) — at 1.0 there is no budget to burn and at 0 the alert
+# can never fire (see the 100%-SLO anti-pattern below) —
+# a bare `SLO` token would parse as a metric selector and silently match nothing.
+# PromQL `and` intersects on the full label set. Invariant: record BOTH window
+# rules aggregated to the SAME alert-identity label set — every label that
+# distinguishes one alert instance from another (service, route, and region/
+# lane if they exist), the window living in the metric NAME, never as a label.
+# Identity labels differing between the rules → empty intersection, the page
+# silently never fires; an `on(...)` that omits an identity label → cross-match
+# (1h burn in one region and-ed with a 5m burn in another) → false page.
 ```
 
 Each burn rate alert MUST link to a runbook entry.

package/dist/assets/marketplace/plugins/ccl-skills/skills/platform-observability/references/source-register.md

@@ -9,3 +9,4 @@ Upstream-owner decision-surface changes record their downstream owners here
 | Phase C: non-mesh collector + STRICT mTLS conflict → exception required | `platform-service-connectivity` | owns the mTLS exception YAML (sidecar/ambient PeerAuthentication/DestinationRule); obs only requires it be declared | routed | Istio PeerAuthentication docs |
 | R8 SLI = good/valid events ratio; latency = threshold-bucket ratio | `platform-release-engineering` | error-budget release gate consumes these SLIs | unchanged (already references R8) | Google SRE Workbook |
 | R3 instance-identity not a metric label; instrument discipline | `go-microservice-architecture` / `python-service-architecture` | language-agnostic rule; no stack-specific glue needed | unchanged | Prometheus / OTel Metrics docs |
+| R8 burn-rate tiers aligned to Workbook Table 5-6 (long+short AND windows; 3d slow tier replaces 24h) | `platform-release-engineering` | promotion gate still consumes SLI burn-rate queries unchanged — window/threshold values are obs-owned inputs, gate shape untouched | unchanged | sre.google/workbook/alerting-on-slos (Table 5-6; short window ≈ 1/12 long) |