@ccoalm/ccl-skills 0.1.0

package/dist/assets/marketplace/plugins/ccl-skills/skills/testing-strategy/references/rd-testing-standard-template.md

@@ -0,0 +1,126 @@
+# R&D Testing Standard Template
+
+Use this template when creating a team testing standard for a product or multi-stack R&D handbook. It is a source-neutral structure: fill it with the target product's real commands, repositories, CI jobs, owners, and evidence links.
+
+## 1. Authority And Scope
+
+- Parent authority: link the product Spec or handbook overview that this testing standard belongs to.
+- Covered surfaces: mini-program, React web, mobile app / native clients, Go services, Python services, shared packages, data jobs, CI/harness, and release smoke.
+- Out of scope: exploratory-only checks, production-only verification, and stack mechanics owned by child stack standards.
+- Required CCL skills: `testing-strategy` for layer and gate design; `test-artifact-management` for structured TC artifacts; stack skills for implementation mechanics; `product-rd-workflow` for product Spec and doc-family ownership.
+
+## 2. Test Deliverables
+
+Every feature or change must produce one of these records before merge:
+
+| Deliverable | Required when | Owner | Evidence |
+| --- | --- | --- | --- |
+| Test-layer decision table | any behavior, contract, harness, or release-risk change | feature owner | unit / integration-contract / E2E-host / manual rows with command or reason |
+| Test-case register | product-visible, contract-visible, bug-fix, high-risk, or workflow change | product + QA + feature owner | scenario, layer, assertion, data, command, expected current result |
+| Automated tests | layer can prove the risk deterministically | stack owner | test file path, command, CI job |
+| Runtime smoke / manual evidence | host/device/live dependency is required | QA or runtime owner | screenshot, recording, log, run id, blocked reason |
+| Regression entry | fixed bug, incident, or confirmed bad case | feature owner | frozen case id and release gate |
+
+## 3. Layer Policy
+
+- Unit tests prove pure logic, validators, mappers, reducers, formatters, local state transitions, and error translation.
+- Contract tests prove API, protobuf, gRPC/HTTP envelope, generated client/server compatibility, schema, and adapter behavior.
+- Integration tests prove database, Redis, queue, filesystem/object storage, migrations, transactions, serialization, service clients, and permission/data-shape behavior that mocks would hide.
+- Component/page tests prove rendered states, local interaction, disabled/retry behavior, and API-client response handling.
+- E2E or host smoke proves critical user/caller workflows, host platform capabilities, login/session boundaries, navigation, release readiness, and one important failure path.
+- Scenario testing is the planning layer. Each scenario is placed at the cheapest layer that can assert the risk; do not turn every scenario into E2E.
+
+## 4. Harness Engineering
+
+Each repository or service must define a tracked test harness:
+
+- a documented local wrapper, such as `make test`, `scripts/run_tests.sh`, `npm test`, or service-local commands;
+- hermetic fast-test environment: fake credentials, temp user state, pinned timezone/locale, deterministic clocks/randomness, and no live external dependency;
+- fixture builders and reset hooks for MySQL, Redis, local files, queues, and generated data;
+- TC mapping output when structured test cases are used;
+- CI parity: the same wrapper or command family runs locally and in CI;
+- clear markers for `unit`, `contract`, `integration`, `e2e`, `slow`, `live`, and release-only gates.
+
+## 5. Stack Minimums
+
+### Mini-Program
+
+- Unit tests for page/component state, utility logic, request adapters, and permission/error translation.
+- Host-platform smoke for login/session, navigation, storage, sharing, payment or subscription entry when present, upload/download, camera/location/Bluetooth or other host capabilities when used.
+- Developer-tool preview or real-device evidence for runtime APIs that lower-layer tests cannot prove.
+
+### React Web
+
+- Unit/component tests for forms, state transitions, permission states, error/empty/loading/success states, and API-client parsing.
+- Browser E2E smoke for one critical success path and one important failure or permission path.
+- Accessibility, console error, and failed-network inspection when user-facing screens or request plumbing change.
+
+### Go Service
+
+- Unit tests for domain logic, validators, mappers, idempotency keys, permission decisions, and error classification.
+- Contract tests for protobuf/gRPC/HTTP envelopes, Kitex/Hertz handlers, generated clients, backward compatibility, and timeout/cancellation semantics.
+- Integration tests for MySQL, Redis, transactions, migrations, distributed locks, cache invalidation, message/job retry, and cross-service client behavior using local containers or approved CI infrastructure.
+- E2E/API smoke for critical caller workflows and high-risk failure classes.
+
+### Python Service
+
+- Unit tests for domain logic, validators, settings parsing, dependency adapters, idempotency decisions, permission/resource-scope resolution, and error mapping.
+- API/contract tests for FastAPI/Flask/Django routes, Pydantic/OpenAPI or protobuf/gRPC contracts, response envelopes, generated clients, compatibility-sensitive fields, and canonical validation failures.
+- Integration tests for SQLAlchemy/Django ORM, Alembic or framework migrations, Redis/cache/lock behavior, queues/workers, transactions, async cancellation, and service clients using local containers or approved CI infrastructure.
+- Mark live-provider, private-network, real dataset, model-server, or callback-delivery checks outside the default fast gate with owner, timeout, and release decision.
+
+### Mobile App / Native Client
+
+- Fast tests for reducers/view models, validation, API-client parsing, cache/persistence boundaries, permission state mapping, retry decisions, and offline or lifecycle state transitions.
+- Widget/component/UI tests for loading, empty, partial, success, error, retry, disabled, permission-denied, optimistic, and account/session states.
+- Device/simulator integration for native plugins, deep links, push opens, auth redirects, camera/files/media, background work, local database, and installable build smoke.
+- Public or staged rollout gates include mapping/dSYM or symbolication upload, app version/build metadata, crash/performance observability, store/review artifacts, and rollback or staged rollout evidence.
+
+## 6. CI Gates
+
+Use layered gates:
+
+| Gate | Blocks | Typical contents |
+| --- | --- | --- |
+| Fast PR gate | every merge | format, compile/typecheck, lint/static checks, codegen-clean, focused unit tests |
+| Contract/integration gate | contract, storage, cache, service-client, migration changes | protobuf/gRPC/HTTP contracts, MySQL/Redis/container tests, migration dry-run |
+| Scenario gate | product-visible and high-risk changes | selected scenario matrix across cheapest sufficient layers |
+| E2E/release gate | release, host platform, cross-service, or critical workflow changes | browser/device/API smoke, failure path, runtime evidence |
+| Long gate | scheduled or pre-ramp | load, replay, compatibility matrix, visual regression, migration rehearsal |
+
+CI must fail closed for required gates. Optional or live-only gates must name the owner, trigger, timeout, environment, and release decision they inform.
+
+## 7. High-Risk Coverage
+
+High-risk workflows require a compact risk matrix before implementation. Cover all triggered classes:
+
+- duplicate submit, callback, message, or job restart;
+- permission service uncertainty and cross-tenant/user/resource mismatch;
+- money, quota, billing, inventory, or write-finality side effects;
+- partial failure, retry, rollback, timeout, cancellation, and unclear final status;
+- AI provider/model failure or degraded answer path;
+- missing trace id, support id, audit log, or incident reconstruction evidence.
+
+Happy-path tests alone cannot approve these changes.
+
+## 8. Evidence And Sign-Off
+
+The completion report must include:
+
+| Layer | Command or artifact | Result | Missing layer reason | Residual risk / owner |
+| --- | --- | --- | --- | --- |
+| Unit |  |  |  |  |
+| Contract / integration |  |  |  |  |
+| E2E / host smoke |  |  |  |  |
+| Manual / exploratory |  |  |  |  |
+| Build / static / CI |  |  |  |  |
+
+Do not report "tested" from command output alone. Map important scenarios to written cases or to explicit `blocked`, `live-only`, `product gap`, or `not applicable` rows.
+
+## 9. Sync Rules
+
+- Product Spec owns acceptance scope and scenario priority.
+- This testing standard owns layer policy, harness expectations, CI gates, and evidence format.
+- Stack standards own the exact test framework, file layout, helper APIs, and command mechanics.
+- Repo-local specs or `AGENTS.md` own local boundaries and required wrappers.
+- When a feature changes a stable contract, generated surface, workflow, or CI gate, update the owning Spec, stack standard, and repo-local execution artifact in the same slice.

package/dist/assets/marketplace/plugins/ccl-skills/skills/testing-strategy/references/run-killing-mutation-walk.md

@@ -0,0 +1,43 @@
+# Run The Killing-Mutation Walk
+
+Mechanics for the entry rule's killing-mutation obligation in `SKILL.md` (Core Rules): the guarded backup recipe that makes mutating safe, the side-effect blast-radius discipline, the encoded probe for destructive artifacts, and the round-trip nuances. The obligations themselves — every named property owes a mutation, the walk is driven from named properties, destructive artifacts need the probe — live in the entry rule; this file owns how to execute them without losing work or buying false evidence.
+
+## Why The Walk Is Property-Driven, Not Assertion-Driven
+
+The entry rule drives the walk from the named properties in every changed test artifact rather than from the changed assertions, because a rename or an added docstring line introduces a new claim while touching no assertion at all — an assertion-driven walk would enumerate zero rows and let it through.
+
+## Guarded Backup Recipe
+
+The entry rule requires the restore to be guarded and the guard kept out of version control. The executable form: before mutating, copy each target OUT of the repo, and restore by copying back.
+
+- `bak=$(mktemp -d)`; per target `f=<repo-relative path>`: `mkdir -p "$bak/$(dirname "$f")" && cp -a -- "$f" "$bak/$f" || exit`.
+- Restore with the same fail-fast: `cp -a -- "$bak/$f" "$f" || exit`.
+- Verify the backup root actually landed outside the worktree — the executable spec does this with a canonical-path check against the repo root, not by assuming — since `mktemp -d` honours `TMPDIR` and a `TMPDIR` pointing inside the repo puts the snapshot right back where a later `add` can sweep it up.
+- Delete the temp directory only after every restore has succeeded: cleanup after a failed copy-back destroys the sole remaining copy while the mutation is still live. Remove the temp directory when the run ends.
+
+Scope of the recipe: it covers the in-place content mutation a killing mutation actually is — edit a function body, flip a constant, delete a guard clause. It is not a general filesystem-restore tool: a symlinked target, a mutation that changes a target's *type*, a path that resolves outside the repo through a symlinked parent, and any target you cannot hold exclusively between snapshot and restore are all outside it, since the restore is an unconditional overwrite that silently replaces a formatter's or another agent's edits. For any of those, take the disposable checkout the entry rule offers instead.
+
+Do not reach for git as the scratch buffer: `git stash` skips untracked files (exactly the new test a fresh mutation targets), `git add -A` sweeps unignored credentials into the snapshot, a bare `git commit` after a pathspec `add` still writes the whole index, and the resulting commit is publishable for its whole lifetime and survives `reset` in the object database. A copy has none of that. It also removes the ambiguity that makes the restore uncheckable: a clean tree after a rollback is evidence only when the tree was clean before it, and mutating a file that already had uncommitted edits makes `clean` the signature of loss rather than restoration — the copy sidesteps this because the restore never consults git at all.
+
+The recipe's guarantees are pinned by `../scripts/test_mutation_backup_recipe.sh` (this skill's `scripts/`, resolved from the skill root), registered in the repo regression lane.
+
+## Mutation Blast-Radius
+
+A disposable checkout protects SOURCE, not the world the test talks to: disabling an authorization check, an idempotency guard, or a deletion safeguard and then running it against a shared or live dependency can destroy real data or perform a real unauthorized action purely to obtain a RED. Mutate against isolated dependencies, or prove the property at the lowest layer that does not touch them — and if neither is possible, record the property `unverified` rather than buying evidence with a real side effect.
+
+## Encoded Probe For Destructive Artifacts
+
+For a destructive or irreversible artifact under test, the entry rule requires the walk to live inside the suite as an encoded probe rather than a one-off run. Mechanics:
+
+- Iterate the enumerated protected predicates, rebuild a mutant per predicate, and require each to make the suite fail **for the right reason**.
+- A bare non-zero exit is NOT that reason and is the trap this form most easily falls into: a mutant that breaks syntax, or breaks fixture setup, also exits non-zero, so the probe banks a broken build as proof of sensitivity while the protected assertion never ran — a false green wearing a RED's clothes. So require, per mutant, that it still parses/builds, that fixtures still set up, and that the failure is **attributable to the named protected assertion**.
+- Attribution by substring match over aggregate output is not enough on its own — an unrelated probe or a teardown can fail while the owning assertion still passes or never runs, and the expected name can appear in the output anyway; worse, the cheap repair when a probe is later renamed is to loosen the pattern, which quietly re-blinds the check. Make it **differential** instead: the owning assertion must PASS in the unmutated control run and FAIL under the mutant, and **no non-owning assertion may fail under the mutant** — so the mutant flips exactly the one thing it targets.
+- Prefer stable per-assertion identifiers or structured per-probe results over scraping prose, and fail closed when a declared owner identifier is missing rather than treating the absence as a match.
+- A one-off run certifies the author's attention at one moment; the encoded probe is what stops a later fixture change from silently re-blinding the suite, and it is what makes the sensitivity claim re-checkable by CI instead of a sentence in an MR description.
+- Two failure modes the probe must itself guard: **an anchor that stops matching** — if the mutation is applied by locating a line, a refactor that moves it yields a "mutant" byte-identical to the original, which passes and proves nothing, so assert the injection landed (literal-substring anchors, then verify the mutant differs) and fail loudly when it did not; and **a recursion guard** so the child runs skip the probe.
+- Budget it honestly — one suite-rerun per predicate — and if that is too slow for the lane, mutate the predicates directly rather than dropping the check.
+- For a pinned contract or prose artifact, the probe set grows with the artifact's own failure modes, not only the mutation list: **relocation** — a pinned section moved elsewhere in the file must still be matched (the stops-matching anchor rule above, applied per section); **reachability** — when the pinned body lives in a reference, assert the entrypoint's route to it still resolves (e.g. the firing signal and the pointer share the same entrypoint bullet), so the route cannot be dropped while every section pin stays green; **tree isolation** — mutants applied to a throwaway copy go RED there while the live tree's run stays green, making the disposable-checkout rule itself assertable; **parser completeness** — the probe discovers its pin list by parsing the fixture rather than a hand-kept list, so a newly added pin cannot be silently excluded from the walk. Coverage in the reverse direction — every obligation sentence of the pinned artifact names its pin — is the entry rule's artifact→pin discipline; the walk itself can never detect an unpinned obligation, which is why that enumeration is a separate recorded gate, not a walk output.
+
+## Round-Trip Nuance
+
+An ordinary encode/decode round-trip that feeds real output back through the real decoder is a valid invariant and does catch decoder defects; what it cannot do is prove agreement with an *external* mapping, which needs an oracle derived independently of the forward side. The narrow case the entry rule names is a reverse expectation computed from the same source as the forward one, so both drift together — not round-trips in general.

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

@@ -0,0 +1,136 @@
+# Scenario Testing
+
+Use this when the user asks for scenario tests, acceptance coverage, user workflow acceptance tests, product-risk tests, or "real user" verification.
+
+## Core Rule
+
+Scenario testing is a coverage model, not a single test runner. Do not automatically turn every scenario into browser E2E. Define the scenario, identify the risk, then place proof at the lowest layer that can assert the behavior.
+
+## Requirement-derived completeness
+
+For behavior-changing product delivery, begin with the active requirement or acceptance source and preserve its stable point IDs and explicit `in` / `out` / `deferred` decisions. Then add code-derived scenarios for boundary conditions, failure paths, permissions, compatibility, and regression risk. Implementation-derived tests alone cannot reveal a required behavior that was never implemented.
+
+| Requirement / acceptance point | Source decision | Implementation surface | Scenario / test | Layer / command | Fresh result / evidence | Status |
+| --- | --- | --- | --- | --- | --- | --- |
+| stable point ID and observable behavior | in / out / deferred, with source authority | code, API, UI, config, migration, job, or docs | assertion or real-flow proof | lowest sufficient layer and exact command | result, trace, screenshot, or response | satisfied / gap / blocked / unknown / out / deferred |
+
+Every in-scope row needs fresh evidence. `gap`, `blocked`, or `unknown` blocks a complete test verdict; `out` or `deferred` is valid only when the active product or human source made that decision. Keep this closure table beside the risk-oriented scenario matrix below rather than replacing it: the first prevents omitted scope, while the second finds failure modes within that scope.
+
+## Scenario Matrix
+
+Create a compact matrix before writing broad tests:
+
+| Scenario | Risk | Layer | Data/dependency setup | Assertion | Evidence |
+| --- | --- | --- | --- | --- | --- |
+| Primary success path | user/caller cannot complete the core action | component/API/E2E | minimal valid fixture or test tenant | visible result, response, persisted state, or emitted event | command, trace, screenshot, or API result |
+| Permission or role path | unauthorized action succeeds or authorized action is blocked | unit/contract/E2E | role/capability fixture | allowed/denied state and copy/status | focused test plus one real-flow check when UI-visible |
+| Empty/partial data path | page or workflow crashes, misleads, or blocks recovery | component/integration | empty, partial, stale, or migrated data | fallback state, disabled action, retry, or guidance | rendered assertion or API invariant |
+| Failure/retry path | dependency failure loses work or hides recovery | unit/integration/E2E | timeout, non-2xx, malformed payload, queue retry, offline | error mapping, retry, idempotency, rollback, or compensation | assertion plus logs/trace when relevant |
+| Edge-volume path | slow, clipped, paginated, or truncated behavior | unit/component/integration/perf | large but bounded fixture | pagination, virtualization, batching, backpressure, or budget | test output and performance signal |
+| Regression path | previously fixed bug returns | lowest sufficient layer | named regression fixture | exact failed behavior stays fixed | failing-before/fixed-after evidence when feasible |
+
+Keep the matrix small. It should cover distinct risks, not every permutation.
+
+### Release/Control-Plane Scenario Matrix
+
+Use this matrix when the changed system deploys, registers, proxies, migrates, or operates other services. Place most assertions at unit, contract, or integration layers; add one controlled release smoke only for cross-boundary behavior that cannot be proven lower.
+
+| Scenario | Risk | Layer | Data/dependency setup | Assertion | Evidence |
+| --- | --- | --- | --- | --- | --- |
+| Approval and release gate | unauthorized, expired, duplicate, or partial approval changes production state | unit/contract/integration | reviewer roles, expiry window, duplicate request ids, approve/reject threshold | idempotent task creation, reject/approve precedence, lock behavior, transaction status, audit fields | focused service test plus API trace |
+| Deploy progress stream | CLI or UI reports success while deployment is still pending or failed | unit/contract/integration/release smoke | fake watch events, timeout, cancellation, final success/failure event | progress events normalize status, timeout is terminal, final result controls exit code or visible state | command output, event log, or controlled smoke |
+| Service registration and sidecar health | stale instances stay registered or unhealthy services keep receiving traffic | unit/integration/release smoke | register retry failure, deregister signal, failed health threshold, recent log fetch | register retry bounded, deregister-on-stop, health failure emits metric/log and stops routing | integration test or local sidecar smoke |
+| Realtime notification channel | unread state or delivered messages diverge across connect/disconnect/MQ/cache paths | unit/integration/component | connected and offline clients, cache miss, MQ message, ack lock, reconnect | bootstrap count, persist-before-publish, offline no-op, cache increment/expiry, ack idempotency | cache/MQ assertions and rendered state when UI-visible |
+| Cursor migration/backfill | data is skipped, duplicated, deleted early, or progress is misleading | unit/integration/drill | bounded source rows, chunk size, worker count, insert failure, restart/resume case | cursor windows cover all rows, target write before source delete, durable final state, restart policy clear | dry-run/integration output with row counts |
+| Generated clients and proxy adapters | generated contract drift or missing metadata silently routes to the wrong service | contract/integration | generated client/server pair, missing destination metadata, lane fallback, EOF/error path | generator drift checked, required metadata rejected, context/log fields propagated, EOF handled deterministically | contract test, generator diff, proxy trace |
+| Operations console surface | operator cannot inspect long identifiers, stale states, disabled actions, or failure details | component/browser smoke | long names, empty list, loading/error, failed mutation, permission-hidden action, drawer close/reopen | table/detail/drawer preserves identity, reloads after mutation, long values remain inspectable, disabled reasons visible | component assertions plus browser screenshot when layout-sensitive |
+
+### Dense Analytics / Chart Workbench Matrix
+
+Use this matrix when a web or app surface contains many charts, grouped tables, comparison targets, configurable thresholds, exports, or drill-down detail.
+
+| Scenario | Risk | Layer | Data/dependency setup | Assertion | Evidence |
+| --- | --- | --- | --- | --- | --- |
+| Chart/table switch | chart and table answer different questions or lose filters/settings | component/browser smoke | same scope with chartable and tabular data | mode switch preserves scope, settings, comparison target, loading state, and export scope | component assertion plus screenshot when layout-sensitive |
+| Large category set | labels, legend, or data points clip and users cannot read the chart | component/browser smoke | more categories than the default visible window, long labels, many series | data zoom or horizontal scroll appears, labels rotate/truncate, legend scrolls, tooltip remains readable | rendered assertion or screenshot |
+| Benchmark/mark lines | baseline labels overlap or imply wrong comparison | component/browser smoke | one and multiple reference lines near data extremes | mark-line labels are visible, collision handling works, y-axis includes reference values | screenshot plus chart option/unit test when possible |
+| Definition/rule popover | users lose metric meaning or stale popovers stay open across modules | component/browser smoke | module definitions, chart/table switch, module anchor switch, comparison target switch | popover opens near the affected module, closes or updates on context change, and does not cover the next action | component assertion plus screenshot |
+| Threshold setting | local visual rules affect the wrong user or accept invalid intervals | unit/component | cached user id, valid and invalid min/max intervals, reset/default state | invalid interval disables save and shows inline error; save is user-scoped and refreshes affected module only | component test plus storage/cache assertion |
+| Comparison mode | raw threshold colors and higher/lower comparison colors get mixed | component/browser smoke | raw values, target baseline, equal/higher/lower values, missing target | mode switch updates legend/copy, colors, and no-comparison state; color is not the only cue | component assertion plus visual check |
+| Dynamic grouped table | exact-value audit becomes unreadable with many groups | component/browser smoke | many metric groups, long row labels, percent values near 100.00%, optional/additional items | fixed identity columns, grouped headers, right-aligned cells, tooltip/ellipsis, horizontal scroll boundary, no clipping, expanded parent context and collapse return position preserved | screenshot and DOM assertions |
+| Split comparison fetch | one side fails or caches stale data while the other side succeeds | unit/component/integration | source and target fetched separately, retry one side, changed target id | split loading/error/retry, cache invalidation by scope/type/id, same-entity selection blocked | component/API-client assertion |
+| Visual token consistency | chart modules pass logic tests but look inconsistent or inaccessible | component/browser smoke | loading, empty, error, chart, table, threshold, and comparison states | repeated surface, border, text, muted text, primary, semantic, and chart colors follow token/adapter rules and remain readable | visual comparison screenshot plus token/CSS assertion when possible |
+| Cross-surface brand color | the same product renders different brand-primary on web vs native vs mini-program with no per-platform role naming in the design source AND no documented migration state | per-surface computed-style/screenshot + design-source role check | the highest-traffic page on each surface (web desktop, web H5, native app, mini-program); the design-source Variables panel (NOT a derivative export — per `multi-project-token-consistency.md` Source vs Export Distinction, exports collapse cross-collection aliases and per-mode bindings, so role-presence verdicts against an export are unsound) | three-layer evidence per surface: (1) design-source brand role + resolved value, (2) code-side theme injection value, (3) rendered computed style or screenshot pixel. Two values across surfaces are NOT automatically a failure — first run Migration-State Classification (`current` / `target` / `in-flight` / `drift`): a documented brand refresh in-flight with named migration signals is a planned-rollout finding, not a per-platform-role failure. After that classification, pass when permanent divergence is expressed with explicit per-platform role naming (`colorPrimary-web` / `colorPrimary-native` etc.) and each surface's three layers resolve to its assigned role; fail when permanent divergence has no per-platform role naming, OR when a single surface's three layers diverge internally. Vendor-default literal (`#1677ff` antd, `#0d6efd` Bootstrap, `#D93025` Google Material, etc.) appearing as the surface's rendered primary against a non-vendor declared brand is a separate per-surface fail. See `product-ui-ux-design/references/multi-project-token-consistency.md` Cross-platform brand divergence sub-case and Vendor-default-literal anti-pattern | per-surface computed-style assertion + design-source role inspection log |
+| Export, drill-down, and cleanup | exported data or detail route no longer matches visible scope; chart instances leak after navigation | component/E2E smoke | active filters, selected module, table mode, detail item, export job, route leave | the export job payload (the server-side data request, not just the routed identifier) includes routed identity + filter-set + config-version + sheet/data selection + snapshot/generation token, and the artifact carries timestamp/staleness disclosure; drill-down and back restore module, filters, anchor/scroll when useful; chart instances, resize listeners, timers, and popovers clean up on leave | browser trace or screenshot + export-payload unit assertion |
+| Cross-stack metric consistency | same metric renders different numbers on web, mobile-web, and native shell for the same scope/report/level | contract/integration/scenario | fixed report id + scope on all three surfaces; record the rendered top-line metric, at least one chart series, at least one table cell; also exercise pull-to-refresh / desktop hard refresh / native shell relaunch / offline-then-online recovery on each surface | (1) the canonical API contract assertion: the same source endpoint returns the same numeric payload regardless of which surface called it; (2) per-surface presentation assertions: each surface's documented rounding, timezone, privacy-suppression, offline-stale-label, and partial-data behavior is asserted in its own test; (3) per-surface lifecycle freshness assertions: after pull-to-refresh / hard refresh / shell relaunch / online recovery, the rendered value matches the latest API value (modulo the per-surface transform). Do NOT collapse (1)–(3) into a single "all surfaces show identical pixels" test — that drives engineers to remove legitimate per-surface transforms or freshness behavior to pass, which is worse than the original drift the test was meant to catch | numeric assertion against shared API + per-surface transform assertions + per-surface refresh/relaunch/online-recovery assertions |
+| Cross-level scope ambiguity | same module key surfaces under multiple hierarchy levels (per-row / per-group / per-tenant / per-federation) with a single user-facing label, AND the same identifier is reused in route / cache / export / persistence keys across levels (analytics event taxonomy is checked separately for low-cardinality discipline, not for routed-tuple coverage) | component/browser smoke + unit | route the user directly into a per-group view of a module that also exists at per-row level; deep-link the same module key into both levels; capture the resulting route keys, data cache keys (including the per-sheetType variant), export filename / job payload, persistence keys, and — separately — analytics event identifiers and their dimensions | the surface visibly identifies the level (breadcrumb, scope chip, header copy) before the chart renders; switching level updates the visible level marker and preserves filter state; each key class composes its correct tuple: (a) routed identity (route key / deep-link / export filename) = `(moduleInstanceId | metricId, level, scope, report, tenant, schema-version)`; (b) export job payload / server-side data request = routed identity + `filter-set` + `config-version` + sheet/data selection + snapshot/generation token; (c) data cache key = `(sheetType | moduleInstanceId | metricId, report, level, scope, filter-set, tenant, schema-version, config-version)`; (d) local persistence key = `(userId, tenant, report, level, scope/resource, schema-version, surface-version)` plus `metricId | moduleInstanceId` when module-specific; (e) analytics event taxonomy stays low-cardinality (`metricId` + small enumerated dimension set), with `tenant`, `report`, `userId` only in first-party hashed/omitted correlation dimensions; deep links to two levels do not collide in any of (a)–(d) storage | component assertion + screenshot + key-shape unit assertion |
+
+## Layer Mapping
+
+- Unit: scenario logic, validators, state machines, permission decisions, retry choices, error mapping, data transforms, key builders, and edge cases.
+- Contract/API: request/response shape, auth envelope, generated client/server compatibility, idempotency, pagination, error codes, and backward compatibility.
+- Integration: DB transaction, cache, queue, file/object storage, real parser, local service adapter, migration, and worker behavior.
+- Component/widget: rendered states, form behavior, validation, keyboard/focus, accessibility labels, disabled/retry behavior, and API-client state mapping.
+- E2E/device/browser: only the critical cross-boundary flow, login/session behavior, routing/deep-link behavior, uploads/downloads, permission-sensitive visible actions, and release smoke.
+- Exploratory/manual: usability, visual polish, awkward copy, performance feel, and surprising combinations that are hard to automate. Record findings as bugs or new automated regression candidates.
+
+## High-Risk Failure Classes
+
+The risk matrix for a high-risk workflow covers the triggered failure classes from this canonical list: duplicate submit/callback/message/job restart, permission service uncertainty, cross-tenant/user/resource mismatch, partial money/quota side effects, AI provider/model failure, unclear final status after refresh/offline, and missing trace/support identifier. Cover each triggered class at the lowest layer that can prove the invariant.
+
+Cross-reference: `non-functional-specialized-scenarios.md` (High-risk resilience boundaries) states the launch-gate counterpart — which classes require scenario tests or drills at release. That is a gate-criteria list; this is the test-matrix failure-class list. The two complement each other and neither replaces the other.
+
+## Composite Pipeline Acceptance Scope
+
+The entry rule's three-layer acceptance for composite / multi-stage pipelines (module-level / chain-level / product-level) applies to behavior-affecting stage changes, contract/composition/fallback changes, or product-baseline-sensitive changes — a pure internal refactor with unchanged contracts may rely on existing lower-layer tests plus unchanged-contract evidence (do not force all three layers on every refactor).
+
+## Scenario Selection
+
+Prefer a few high-signal scenarios:
+
+- One primary success path.
+- One high-risk negative path.
+- One permission or role path when access matters.
+- One recovery path for failed dependency, retry, offline, timeout, or malformed response.
+- One edge-volume path when lists, charts, files, streams, queues, or long content are involved.
+- One regression scenario for each recently fixed defect or review finding.
+
+Do not multiply by every browser, role, locale, data size, and dependency state unless the product risk justifies it. Use pairwise or representative coverage for combinations and push low-level permutations down to unit/contract tests.
+
+## Acceptance And Evidence
+
+Every scenario test needs an assertion that matches the risk:
+
+- User-visible scenario: assert visible outcome, next action, focus/keyboard state, copy/status, or absence of dangerous control.
+- API scenario: assert status, error code, response body, idempotency, persisted state, emitted event, and trace/log id when relevant.
+- Worker/data scenario: assert terminal state, retry count, dead-letter or compensation behavior, output artifact, and data-quality invariant.
+- Release scenario: assert the smoke path in the target environment and record skipped dependencies or unavailable credentials.
+
+Screenshots, videos, traces, logs, coverage reports, and manual notes are evidence only when paired with assertions or a clear observed finding.
+
+## Existing Test Audit
+
+When extracting or reviewing an existing project's scenario coverage:
+
+- Start from the command surface and CI, then map files back to commands. File names alone do not prove coverage.
+- Preserve local markers and test lanes such as `integration`, `contract_*`, `api`, `e2e_smoke`, `failure_mode`, `drill`, `shadow`, `smoke`, or `replay`.
+- Separate automated gates from diagnostic tools. Traffic replay, benchmark, shadow, drill, manual smoke, and live-debug tests can be valuable, but they need explicit owners, environments, and assertions before they become release gates.
+- Mark tests that only log, panic on error, depend on production-like IDs, or require live services as diagnostic/live-infra tests unless they are isolated and assertion-based.
+- Convert high-value diagnostic/live-infra scenarios into deterministic unit, contract, integration, or controlled E2E tests when they protect recurring release risk.
+
+## Anti-Patterns
+
+- Calling a long browser script "scenario testing" when it has no assertions.
+- Duplicating every unit edge case through E2E.
+- Testing only the happy path because it is easiest to automate.
+- Treating mocked ideal API responses as proof that a real scenario works.
+- Mixing unrelated risks into one scenario so a failure is hard to diagnose.
+- Letting scenario fixtures become production data dumps.
+- Counting dependency, virtualenv, third-party, generated, archived, or copied tests as proof of the active product's test coverage.
+
+## Source Notes
+
+- Fowler-style test pyramid guidance supports many fast low-level tests, some service/integration tests, and few high-level E2E tests: https://martinfowler.com/articles/practical-test-pyramid.html
+- Playwright guidance supports user-visible locators and assertions against rendered outcomes rather than brittle implementation details: https://playwright.dev/docs/best-practices
+- Testing Library guidance supports tests that resemble how users interact with the UI: https://testing-library.com/docs/guiding-principles/
+- Pytest guidance supports explicit test discovery, package layout, markers, and reusable fixtures for deterministic tests: https://docs.pytest.org/en/stable/explanation/goodpractices.html

package/dist/assets/marketplace/plugins/ccl-skills/skills/testing-strategy/references/source-evidence-map.md

@@ -0,0 +1,59 @@
+# Testing Source Evidence Map
+
+Use this reference when auditing or re-extracting testing strategy. The rules below describe *how* to classify Go/Python/web/app tests and CI gates; specific local repositories and dated cross-check logs live in the private provenance archive outside this skill tree.
+
+Users without code access can still apply the distilled patterns in this file. Do not require access to specific paths unless the task explicitly asks to audit, update, or re-extract test evidence.
+
+## Source Coverage
+
+For each codebase in scope, classify before extracting rules. The shape below is the classification frame; specific entries live in the private archive.
+
+| Dimension | Typical signature | Useful extraction | Decision |
+| --- | --- | --- | --- |
+| Broad test inventory | Batch file scan across Go, Python, frontend, app, config, CI, and script-like tests while excluding dependency/generated noise | Test strategy must not infer coverage from file names; classify by command, marker/tag, infra need, CI gate, and assertion strength | Keep |
+| Go tests | Many unit, handler, logic, DAL/DDL, Redis/ES/object-store, traffic/shadow, benchmark/replay, and integration-tag tests | Supports layer split, live-infra isolation, generated-contract checks, replay/shadow as opt-in regression evidence | Merge |
+| Python tests | pytest markers, API/contract/integration/e2e scripts, inference handler tests, benchmark pipelines, local integration stacks | Supports marker-aware topology, failure/drill/shadow gates, separating live infrastructure from default fast tests | Merge |
+| Web tests | Vitest, Testing Library, Playwright e2e, structure checks, build/typecheck/lint scripts across React/Vue projects | Supports layered frontend testing: component state, API-client/contract, browser smoke, build checks | Merge |
+| App tests | Flutter test dependency and mobile manifests; native tests are typically thinner | Keep platform verification rules; do not overstate native automated-test coverage from sparse evidence | Keep with gap |
+| Weak/noise sources | Vendored SDK tests, third-party libraries, generated clients, old worktrees, static outputs | Must be excluded from topology unless the task targets those artifacts | Discard/noise |
+
+## Source Classification Method
+
+Before extracting test obligations:
+
+1. Discover local test wrappers and CI gate truth before inventing test commands. The CI file is authoritative, not the `package.json` script.
+2. Distinguish strong / medium / weak tests by assertion shape, not by file count:
+   - **Strong**: deterministic assertions, no live dependencies, runs in a default fast gate.
+   - **Medium**: assertions present but depend on fixed DB/cache/inner-network state; runs in an explicit infra gate.
+   - **Weak**: logs/prints only, randomness or long sleeps, calls live model/Ray/data paths, or sits behind `allow_failure`.
+3. Inventory by command, marker/tag, infra need, and CI gate — never by file count.
+4. Treat build/format/typecheck scripts as structural gates only; they do not substitute for behavioral assertions.
+
+## Cross-Skill Routing
+
+- Stack-specific test mechanics live in `web-react-dev` (browser), `app-cross-platform-dev` (mobile/native), the relevant backend skill (services).
+- Scenario testing is a planning layer that maps risk to the lowest sufficient assertion layer plus real-flow smoke only when cross-boundary behavior matters.
+- LLM inference/eval testing routes to the relevant inference/eval guidance, not here.
+
+## Keep / Merge / Discard
+
+- **Keep**: discover local wrappers and CI truth before inventing test commands.
+- **Keep**: scenario testing is a planning layer that maps risk to the lowest sufficient assertion layer plus real-flow smoke only when cross-boundary behavior matters.
+- **Keep**: frontend API-backed UI needs component, API-client/contract, and browser/device smoke evidence when feasible.
+- **Keep**: precision workspaces need tests for media reliability, gesture conflicts, repeated input modes, batch/default submission consequences, lock/expiry recovery, native orientation, and shell exit cleanup; a route build or click-only smoke is not enough.
+- **Keep**: complex web shells need scenario tests for route/permission shell load, hosted/embedded fallback, process tab persistence and active deletion fallback, route-versus-process selection exclusivity, measured overflow only after real overflow, permission-hidden workbench modules, shell/module minimum widths, stacked-module fallback, sticky-disabled behavior when stacked/narrow, AI launcher geometry, streaming/session/input states, and login/auth/partner branding states.
+- **Keep**: high-throughput evaluation workbenches need component/API tests for split-count state, selected-item preservation, incomplete-submit confirmation, media retry, preference restore, drawer filters, plus browser evidence for long artifact, narrow viewport, queue-end/no-work, and recovery states.
+- **Keep**: structured assignment workbenches need component tests for batch selection, disabled reasons, split/merge mode transitions, quota under/over-allocation, role conflict messages, permission-summary finalization, and read-only/started variants; API/client tests for save/autosave/finalize normalization, import failure payloads, and export job status; browser evidence for sticky headers, selected-count action bar, drawer return context, long owner names, and narrow desktop stress.
+- **Keep**: mobile/H5 hybrid work needs adapter/unit tests for storage TTL, sensitive-field transforms, route gating, bridge capability detection, and orientation fallback; component tests for async retry and foreground/background restore; device/host-container smoke for safe area, keyboard, orientation, and tab/sticky action visibility.
+- **Keep**: native-assisted media flows need test obligations for bridge callback contracts, malformed payloads, transition overlay/page-ready cleanup, camera permission/hardware/album/torch/focus states, crop/aspect/EXIF correction, processed-preview versus uploaded-byte parity, all-black/all-white and size-budget guardrails, runtime upload config fallback, signing-version switch, redacted logging, upload failure, foreground/background interruption.
+- **Keep**: client foundation auth/profile needs test obligations for splash/consent, password login, phone-code login, account-opening or binding when supported, first-login password setup, forgot/reset, verification paste/autofill/focus/backspace, resend countdown, foreground/background restore with sensitive fields, logout/delete cache cleanup across web/native storage, profile/privacy/about route clusters, version update states, and route/tab behavior after session changes.
+- **Keep (backend)**: Go service testing identifies service shape and local wrappers before choosing commands; keep generated-code drift, IDL changes, handler/logic tests, DAL/cache/MQ tests, async task finality, streaming timeout/cancel/error, and live-infra tests in separate gates instead of one undifferentiated `go test ./...`.
+- **Keep (backend)**: Python/AI testing handles readiness-before-registration, service metadata, heartbeat/unregister, version routing, request/log id propagation, parser boundaries, and inference handler/router behavior with fast tests or targeted integration tests; hosted inference capacity and quality evaluation route to LLM testing/eval guidance.
+- **Merge**: stack-specific mechanics live in Go/Python/Web/App skills after this skill chooses the layer.
+- **Discard**: test-count based confidence, click-only E2E, live credential tests in default fast gates, dependency/generated test noise, and demo modules as primary service coverage.
+
+Coverage label: broad topology inventory plus representative file-level refresh, not full assertion audit of every test.
+
+## Where The Specific Provenance Lives
+
+Specific repository inventories, test file counts, CI file lists, and dated cross-check logs live in the maintainer's private archive. They are not included in this file, so any cross-organization use of this skill stays clean.

package/dist/assets/marketplace/plugins/ccl-skills/skills/testing-strategy/references/structured-tc-input-translation.md

@@ -0,0 +1,67 @@
+# Structured TC Input Translation
+
+Use this reference when the input is a set of structured test cases from `test-artifact-management` or a Feishu Bitable TC list. This is a **translation guide** from structured TC fields into test strategy, layer selection, implementation routing, TC metadata, and result handoff; after translation, run the standard `testing-strategy` workflow from Step 1.
+
+The mapping is directional — not every TC becomes one automated test, and one TC may need assertions at multiple layers.
+
+## Pre-check before translating
+
+| TC 状态 | 处理方式 |
+|---|---|
+| `未测试` | default implementation candidate; proceed with translation |
+| `通过` | decide whether to automate for regression fixation or leave as manual evidence; do not assume automation is required |
+| `失败` | regression candidate; add or update at least one relevant test and run it RED before implementation, unless no harness can support it after normal remediation — in that case record the evidence gap and strongest alternate check |
+| `阻塞` | record as `blocked`; name the environment or product gap; do not auto-implement until unblocked. **JUnit auto-mapping**: pytest `@skip(reason="…")` with environment keywords (`requires`/`needs`/`no driver`/`no device`/`service unavailable`/`credential`/`platform`/`linux`/`windows`/`darwin`/`fixture not ready`/`environment`) maps to 阻塞. |
+| `跳过` | excluded from implementation queue; keep it in the coverage register with skip reason and source decision; do not delete or overwrite the Bitable record. **JUnit auto-mapping**: any other `<skipped>` reason (manual exclusion, deferred, deprecated feature) maps to 跳过. Use precise reason strings so the automation routes correctly. |
+| `废弃` | excluded from implementation queue; grep the sidecar (`test/results/tc-map.jsonl`) and test source for this TC ID; for each linked test, check whether the underlying business code is still valid using the per-stack import-graph commands documented in the relevant dev skill's "废弃级联：业务代码是否仍在用" subsection (Python `grep import` / Go `go list` / Web `madge` / 小程序 madge+app.json / Flutter+native `dart analyze` + grep) — single grep on the test file is the FIRST step only; the second step is verifying whether OTHER product code still depends on what the test imports. If business code is removed/feature is gone, delete the test in the same commit; if code is still active, take no action by default. If a test's `tc(...)` call covers this TC ID plus other active TC IDs, remove the deprecated ID from the `tc(...)` argument list instead of deleting the whole test; tests without `tc(...)` calls are handled separately and are not part of this check |
+| empty / unrecognized | blocks translation until status is normalized; do not infer as `未测试` |
+
+Additional pre-checks:
+
+- TC 优先级 (P0/P1/P2) is a business priority signal, not a final layer or CI gate assignment. P0 requires explicit proof of behavior or an explicit `blocked` / `gap` / `manual-only` decision with named owner, evidence artifact/location, and residual risk — it does not automatically mean automated test. Use risk, cross-boundary behavior, defect history, and assertion cost to determine the actual layer and gate.
+- Verify TC ID uniqueness and field completeness before writing any test code.
+- **Orphan detection (split responsibility).** `python gen_report.py --detect-orphans` covers ONLY tests that DO link to a TC ID: it surfaces (a) tests whose TC ID is marked `废弃` in Bitable, and (b) tests whose TC ID does not exist in Bitable at all. For each match, check if the underlying business code is still valid using the per-stack import-graph commands documented in the relevant dev skill; if code is removed, delete the test in the same commit; if code is still active, take no action by default. Tests WITHOUT any TC link (no `tc()` / `tc.Mark` / `@pytest.mark.tc` / `tcTest`) are NOT detected by this command — they are caught when the dev intentionally deletes business code and runs the per-stack "废弃级联：业务代码是否仍在用" workflow on the affected modules; that workflow prompts the user to decide on each unlinked test.
+
+## Field mapping
+
+Directional, not 1:1:
+
+| TC 字段 | 测试设计参考 |
+|---|---|
+| 前置条件 | test setup — fixture data, dependency state, permission context, or environment dimension; may map to multiple setup steps across layers, not a single setup call |
+| 操作步骤 | test body — what to render, call, interact with, or trigger |
+| 预期结果 | assertion target — visible outcome, persisted state, emitted event, contract shape, or error |
+| 优先级 | risk signal only; see pre-check above — do not map directly to a layer or gate |
+| 测试层级 | primary proof layer requested by the TC author. Treat it as the default landing target, then verify it still matches the cheapest sufficient proof. If the field and risk analysis disagree, record the discrepancy and route it back to `test-artifact-management` for TC definition update instead of silently drifting. |
+| 测试类型 | execution form / owning implementation surface. Use it to route the scenario to the right stack skill and runtime harness (`ui-automation`, `api-automation`, `device-automation`, `contract-validation`, `llm-eval`, `manual-verification`). |
+| 模块 | test file grouping or suite name (use stack-specific naming convention) |
+| 用例ID | passed to the per-stack `tc()` helper / `@pytest.mark.tc` / `tcTest` / `tc.Mark` at registration time, recorded in the sidecar `test/results/tc-map.jsonl` (NOT in the test function name — function names stay clean). See `test-artifact-management/references/tc-marker-conventions.md` |
+| 状态 | see pre-check table above |
+
+## Layer assignment rules
+
+- One TC may need assertions at multiple layers (e.g. unit + contract + one E2E smoke for a P0 cross-boundary behavior); do not assume 1:1.
+- Multiple TCs in the same module may merge into one scenario gate when they share setup and differ only in data dimension; when merging, the test register or coverage map must list all covered TC IDs (mandatory for Bitable fan-out); test name or inline comment is auxiliary only. Merged scenario results must be fanned out per TC ID: only update a TC's status when that TC's own expected result and assertion dimension are covered by the merged test.
+- Do not assign layer by priority alone. A P2 TC that is cheap, stable, and regression-prone belongs in the fast gate; a P0 TC that requires a live service belongs in the integration or E2E gate.
+- Apply the client API-backed surface split and scenario dimension rules from the Workflow section as usual.
+
+## Execution-type routing rules
+
+- `测试层级=e2e` + `测试类型=ui-automation` + web/admin frontend → route implementation to `web-react-dev`; if an in-app browser/runtime check is needed, use the browser capability the environment provides.
+- `测试层级=e2e` + `测试类型=device-automation` + mini-program → route to `miniapp-product-dev`.
+- `测试层级=e2e` + `测试类型=device-automation` + app/mobile → route to `app-cross-platform-dev`.
+- `测试类型=api-automation` + Go service → route to `go-microservice-dev`; `platform-service-connectivity` stays the contract/connectivity owner when wire behavior or shared transport policy matters.
+- `测试类型=api-automation` + Python service → route to `python-service-dev`; `platform-service-connectivity` stays the contract/connectivity owner when wire behavior or shared transport policy matters.
+- `测试类型=contract-validation` → keep the main layer at `contract`; route schema/proto/GraphQL contract execution to the owning backend/client stack skill after this skill chooses the exact gate.
+- `测试类型=llm-eval` → route model/replay/eval harness implementation to `llm-inference-integration`; do not reroute visible product-surface assertions that still belong to web/app/miniapp/client skills.
+- `测试层级=manual` or `测试类型=manual-verification` → do not fake automation. Produce the strongest executable lower-layer evidence you can, then keep the user-visible/runtime proof as manual or `blocked` with owner and residual risk.
+
+## Specialized TC routing
+
+**AI/LLM-triggered preconditions** ("触发研报检索", "模型决定调用工具") cannot be reliably reproduced via live model calls; use recorded fixtures or controlled data for the product surface (UI states, fallback behavior, error paths, permission states). Route only LLM/agent/RAG eval, replay, model/provider/inference stream protocol finality, and inference-specific observability to `llm-inference-integration`; UI streaming display finality, reconnect visible state, and button recovery remain product surface tests handled here. Do not route the entire TC to `llm-inference-integration`.
+
+**Non-functional TCs** (performance, security, accessibility, visual regression, migration): determine gate placement here using the Non-Functional And Specialized Testing section in the entrypoint and `non-functional-specialized-scenarios.md`, then route implementation detail to the relevant specialized skill.
+
+## Handoff back to test-artifact-management
+
+When automated test results are available, update the TC's 状态 and append a 信息流转 entry in Bitable. Status-only result updates are Bitable-only (local md does not need to sync). TC content changes (steps, expected results) or new regression cases discovered during implementation must go through `test-artifact-management` update sync to keep Bitable and local md consistent.