@ccoalm/ccl-skills 0.1.0

package/dist/assets/marketplace/plugins/ccl-skills/skills/code-review/scripts/verify_native_skill_binding.py

@@ -0,0 +1,123 @@
+#!/usr/bin/env python3
+"""Verify controller-selected native review skills without copying their bodies."""
+
+from __future__ import annotations
+
+import argparse
+import json
+from pathlib import Path
+import sys
+
+from review_gate import GateError, MAX_PROFILE_BYTES, _hash_skill_package
+
+MAX_LEGACY_PROFILE_BYTES = 245_000
+
+
+def fail(message: str) -> None:
+    print(message, file=sys.stderr)
+    raise SystemExit(2)
+
+
+def main() -> None:
+    parser = argparse.ArgumentParser()
+    parser.add_argument("--review-profile-file", required=True)
+    parser.add_argument("--skill-registry-root")
+    parser.add_argument("--installed-skill-registry-root")
+    parser.add_argument("--review-skill", action="append", default=[])
+    args = parser.parse_args()
+
+    profile_path = Path(args.review_profile_file)
+    registry_root = Path(args.skill_registry_root) if args.skill_registry_root else None
+    installed_registry_root = (
+        Path(args.installed_skill_registry_root)
+        if args.installed_skill_registry_root
+        else None
+    )
+    if not profile_path.is_file() or profile_path.is_symlink():
+        fail("review profile must be a readable regular file")
+    profile_size = profile_path.stat().st_size
+    if profile_size > MAX_LEGACY_PROFILE_BYTES:
+        fail("review profile exceeds the wrapper input bound")
+    if registry_root is not None and (
+        not registry_root.is_absolute()
+        or not registry_root.is_dir()
+        or registry_root.is_symlink()
+    ):
+        fail("skill registry root must be an absolute regular directory")
+    if installed_registry_root is not None and (
+        not installed_registry_root.is_absolute()
+        or not installed_registry_root.is_dir()
+        or installed_registry_root.is_symlink()
+    ):
+        fail("installed skill registry root must be an absolute regular directory")
+
+    try:
+        profile = json.loads(profile_path.read_text(encoding="utf-8"))
+    except (OSError, UnicodeError, json.JSONDecodeError) as exc:
+        fail(f"cannot read review profile: {exc}")
+    if not isinstance(profile, dict):
+        fail("review profile must be an object")
+    if profile.get("skill_delivery") != "native-installed":
+        selected_hint = profile.get("selected_skills")
+        if isinstance(selected_hint, list) and any(
+            not isinstance(item, dict) or item.get("name") != "code-review"
+            for item in selected_hint
+        ):
+            fail("review profile selects owners without native-installed delivery")
+        if args.review_skill or registry_root is not None or installed_registry_root is not None:
+            fail("review profile does not require native-installed skill delivery")
+        print(json.dumps({"skills": [], "native_required": False}, separators=(",", ":")))
+        return
+    if profile_size > MAX_PROFILE_BYTES:
+        fail("native-installed review profile exceeds the controller bound")
+
+    selected = profile.get("selected_skills")
+    if not isinstance(selected, list):
+        fail("review profile selected_skills must be a list")
+    selected_by_name: dict[str, str] = {}
+    for item in selected:
+        if not isinstance(item, dict) or set(item) != {"name", "content_sha256"}:
+            fail("review profile selected_skills entry is invalid")
+        name = item.get("name")
+        digest = item.get("content_sha256")
+        if not isinstance(name, str) or not isinstance(digest, str) or len(digest) != 64:
+            fail("review profile selected_skills entry is invalid")
+        if name in selected_by_name:
+            fail("review profile selected_skills contains a duplicate")
+        selected_by_name[name] = digest
+
+    requested = list(dict.fromkeys(args.review_skill))
+    if requested != args.review_skill:
+        fail("review skill arguments contain a duplicate")
+    expected = [name for name in selected_by_name if name != "code-review"]
+    if requested != expected:
+        fail("review skill arguments do not match the controller profile")
+
+    if expected and registry_root is None:
+        fail("native review skills require a skill registry root")
+
+    for name in requested:
+        try:
+            assert registry_root is not None
+            actual = _hash_skill_package(registry_root / name, name)
+        except (GateError, OSError) as exc:
+            fail(f"cannot verify native review skill {name}: {exc}")
+        if actual != selected_by_name[name]:
+            fail(f"native review skill hash mismatch: {name}")
+        if installed_registry_root is not None:
+            try:
+                # Host installs may advance independently of the candidate.
+                # Validate package safety/presence, but bind by selected name.
+                _hash_skill_package(installed_registry_root / name, name)
+            except (GateError, OSError) as exc:
+                fail(f"cannot verify installed native review skill {name}: {exc}")
+
+    print(
+        json.dumps(
+            {"skills": requested, "native_required": True}, separators=(",", ":")
+        )
+    )
+
+
+if __name__ == "__main__":
+    main()

package/dist/assets/marketplace/plugins/ccl-skills/skills/defect-diagnosis/SKILL.md

@@ -0,0 +1,153 @@
+---
+name: defect-diagnosis
+description: bug / 报错 / test 挂了 / 线上问题 / 复现 / 找根因 / debug → diagnose first-hand failure evidence, isolate cause, verify before fixing, add regression proof, and route prevention. Also use for AI-proposed causes or fixes.
+---
+
+# Defect Diagnosis
+
+Use this skill for the full defect discipline: diagnose the immediate failure, fix it with evidence, then decide whether root-cause prevention should update a product, architecture, development, testing, release, or tooling skill.
+
+## Non-Negotiable Rules
+
+- Do not skip the problem because another path appears to work.
+- Do not delete, comment out, or weaken a failing test just to make the suite pass.
+- Do not call a workaround the fix unless the owner explicitly accepts the tradeoff and residual risk is recorded.
+- Do not start broad refactoring while the cause is unknown. Isolate and fix first; refactor after the behavior is understood.
+- Do not stop at "this line was wrong" when the defect reveals a missing contract, guardrail, test, review check, or skill rule.
+- Do not state or act on a root-cause verdict — even as a confident aside — before you have read the failing owner's own evidence with your own eyes (assertion diff for a test, stack/exception for a crash, trace/log slice for a production symptom, source only when it is itself the failing artifact). Until then, label every cause as a hypothesis and name the evidence that would confirm or reject it. This applies to your OWN analysis, not only to LLM-proposed causes. Mitigation is exempt: you may roll back, flag-off, or shed traffic from symptoms while cause stays marked unknown — what is forbidden is choosing or applying a *fix* as though a cause is proven.
+
+## Phase A: Diagnose
+
+1. Reproduce.
+   - Record exact steps, inputs, environment, command, config, and observed failure.
+   - Prefer a failing test, trace, payload, or smallest runnable reproduction.
+   - If intermittent, record frequency, timing, data shape, and resource conditions.
+   - **Before declaring a bug non-reproducible — or an environment / service / tool / dataset needed to reproduce it "unavailable" or "blocked" — run the normal remediation for that layer first.** Start the service / emulator / container / dependency and wait for readiness, run the repo setup or fixture/seed script, restart the client daemon, provision or refresh the test data, or try a *different* reproduction strategy (smaller or adversarial input, a different transport/endpoint, added tracing, or an engineered-interleaving / race-detector harness for a concurrency bug). Only record `can't-reproduce` / `unavailable` / `blocked` **after** the bounded remediation for that layer fails, with the command evidence, the residual risk, and the next concrete unblock action. A confident "I can't reproduce it" or "the env is down" with no remediation attempt is not a closed defect — it is `pending`.
+     - **This is not an escape hatch to never close or escalate.** Remediation attempts are *bounded* and subject to the same frame-change / escalation discipline as hypotheses below (`Frame-change-or-escalate`, `Escalation does not close the defect`): after repeated failed bounded attempts, stop inventing new "different" strategies, escalate with a handoff packet, and keep the defect open under an owner — do not sit on an endless `pending`.
+     - **Safety preflight for any mutating remediation** (setup / fixture / seed / data-refresh / daemon-restart, or `docker compose up`-style stack start): first prove the target endpoint, credential, and namespace are synthetic and disposable — never a live/prod/shared DB, API, token, or environment — and disable or isolate any side-effecting consumers, webhooks, or scheduled jobs the start would wake (they can process real queued events or reconnect to shared staging). If you cannot confirm the target is safe/scratch, the remediation is itself `blocked` — do not run destructive setup/refresh to chase a repro.
+
+2. Isolate.
+   - Narrow by layer, recent change, dependency, data shape, permission, timing, or environment.
+   - Use minimal reproduction, binary search, feature flags, dependency substitution, or generated-file drift checks when useful.
+   - **When the failure has no useful binary-search axis (no orderable/partitionable commit, input, dependency version, config/env, or dataset with a reliable good/bad predicate), compare against a known-working analog** — a confirmed-passing sibling test, the same operation on another service/endpoint, or a last-good build/env/config — and enumerate *every* difference between the working and broken cases, however small; do not pre-dismiss one as "that can't matter". Verify the analog is genuinely passing and contract-comparable first (a superficially similar but different-contract analog misleads). Do this only after reading the failing owner's own evidence (per the evidence-first Non-Negotiable above; for a failing test, the assertion-first rule below), and treat each enumerated difference as a hypothesis to verify (Phase A.3), not a proven cause.
+   - **`git bisect` is the default binary-search tool when the failure is a regression with a known-good and known-bad commit**.
+     - Per `git-scm.com/docs/git-bisect`: `git bisect start && git bisect bad <bad-sha> && git bisect good <good-sha> && git bisect run <script>` automates the search.
+     - Script-exit-code contract per `git-scm.com/docs/git-bisect`: **0 = commit is good; any non-zero exit in 1..127 except 125 = commit is bad; 125 = commit is untestable (skip)**.
+     - The `make || exit 125` idiom belongs to the build / setup phase of the script — emit 125 ONLY when the commit cannot even be built/prepared, not when the actual test fails (test failure should propagate as exit 1 so bisect counts it as bad).
+     - For a regression caused inside a merge, `git bisect --first-parent` follows mainline only so the search doesn't dive into intermediate feature-branch commits that don't matter.
+     - **The script must be deterministic** — flaky-reproduction-rate < 100% will cause bisect to converge on the wrong commit; if reproduction is flaky, fix the reproduction script first (loop N times, assert ≥M failures, then exit 1) OR switch from bisect to logging/tracing diagnosis.
+     - Routing: stack-specific bisect-script idioms (`pytest -x` / `go test -run` / `npm test --bail`) belong in stack dev skills; this skill owns the workflow + exit-code contract.
+   - For build or release-tool failures, shrink the failing command to the smallest owning tool before editing application code. Examples include moving from app build to native build settings, compiler, asset/storyboard compiler, package resolver, code generator, or emulator/simulator runtime discovery.
+   - Identify whether the failure is in product logic, contract mapping, persistence, cache, async processing, dependency behavior, runtime config, release state, or test setup.
+   - If the failure appears only in tests or CI, classify the test evidence before changing code: deterministic assertion, fixed external data, live infrastructure, random/log-only behavior, long sleep, allow-failure gate, generated/vendor test, or deploy/build-only pipeline.
+   - **A red CI pipeline/job is not by itself a code/dependency defect — read the failing job's own trace (not the red/green summary) and classify the cause before touching code.** Refining the classes above into why-CI-is-red-but-code-may-be-fine: (a) **trigger-variant artifact** — when the same job runs under more than one trigger-scoped config (branch/push vs merge-request vs manual/scheduled; vendor terms vary — the analog on any CI is the trigger *event/context*), the trigger can resolve different default variables or a different checked-out ref, so a red on a non-gating trigger may be benign — but conclude that ONLY after confirming the *same failing check* ran and is green on the gating path (a gating pipeline that is overall green yet never runs the failing check does not clear it; if that check's coverage is unique to the non-gating trigger — e.g. a scheduled/manual-only suite — treat it as genuine (d), not a variant artifact); (b) **retriable infra flake** — concurrent tools colliding on a shared-runner build/lint lock, etc.: confirm per the flaky rule below (rerun N times + record the ratio; a 100%-reproducible red is deterministic, not a flake), and still read the red run's trace for the collision signature, since one green rerun cannot separate an infra flake from a genuine intermittent code bug; (c) **deterministic non-code infra fault** — toolchain/runner-image drift, stale cache/vendored artifact, credential/quota expiry: reproduces identically (NOT a flake) AND must be shown **code-independent** before disowning — confirm the same failure reproduces on a known-good baseline (parent/last-good commit, or a build without the change) under the same runner/toolchain; if the red appears only *with* the change it is (d) however much it resembles drift → route to platform/infra only after that baseline check, then do not attribute to code; (d) **genuine code/dependency failure**. (Single-variant repos skip the (a) check; the trace-first and cause-classification still apply.)
+   - **For a failing test, read the actual assertion error (Expected/Actual) and the failing test body FIRST — before diagnosing flakiness, concurrency, shared state, mock setup, or external-dependency causes.** A passing/failing count, a `REQUEST POST`-style debug log line, or "passes in isolation, fails in suite" is a symptom, not the assertion evidence; naming a cause from those alone is the exact failure this skill exists to prevent. If the test is suspected flaky, rerun N times and record the pass/fail ratio before calling it flaky (100% reproducible failure is deterministic, not flaky), and confirm the test's network/dependency boundary by reading its setup (e.g. whether it is already mocked) rather than inferring from logs.
+
+3. Hypothesize.
+   - Write concrete causes that can be proven or rejected.
+   - For each hypothesis, define the expected observation if it is true.
+
+4. Instrument.
+   - Add targeted logs, assertions, traces, metrics, local probes, or debugger breakpoints.
+   - Keep instrumentation narrow. Remove or downgrade temporary noise before finishing.
+   - **Observability-driven RCA: when the failure is observable in production telemetry, start from the bad metric/alert and walk back through traces, not from the application code reading bottom-up**.
+     - Per `opentelemetry.io/docs/specs/otel/metrics/data-model/` and the OTel exemplars spec, modern observability platforms (OpenTelemetry SDK + Prometheus + Tempo / Jaeger / Grafana / similar) link metrics to a sample of traces via **exemplars** — a metric data point can carry the trace-id of a request that produced it, letting the diagnoser jump from "p99 latency spiked at 14:23" to a representative slow-request trace with one click.
+     - The cardinality discipline rule (never put trace-id / request-id as a metric label) makes exemplars necessary — they preserve high-cardinality drill-down without exploding the metric.
+     - **Workflow**: alert fires → open dashboard → pick an exemplar trace from the spike → read the span tree (downstream service called, timing, attributes) → jump from span to logs via shared trace-id → form hypothesis.
+     - Reading application code without first checking the trace is the most common time-sink in production-symptom diagnosis.
+     - The trace-shipping pipeline / dashboard / alert routing belong to `platform-observability`; this skill owns the diagnoser-facing workflow.
+   - **AI-assisted diagnosis (Claude Code / Cursor / Copilot / similar) is a default-on hypothesis generator, NOT a default-on root-cause verdict**.
+     - The pattern that works: paste the stack trace / failing test output / log excerpt / OTel trace JSON to the assistant, ask for ranked hypothesis list with evidence-collection commands for each, then YOU verify each candidate by running the proposed commands and reading the actual output.
+     - The pattern that breaks production: accept a confident LLM-named root cause as the answer and ship a fix without running the verification commands — LLMs hallucinate plausible-sounding root causes from partial evidence routinely, especially when the stack trace is for a class of bug they've seen many times but the actual code path differs.
+     - **Required discipline when AI-assisting diagnosis**: (a) record the prompt + assistant output as part of the diagnosis evidence (so reviewers can spot a hallucinated root cause from the original conversation), (b) the human still owns the final cause verdict + the regression test, (c) never let the assistant apply a fix without first writing or strengthening a regression test that fails before the fix and passes after — the AI's "I fixed it" claim is not verification, the failing-then-passing test is, (d) **sanitize before the error leaves the trust boundary** — before pasting a stack trace / log / failing-test output / query / trace JSON to an *external* assistant or searching it on the public web, strip internal hostnames, IPs, internal URLs/paths, raw SQL and query bodies, customer data / PII, secrets / tokens, env values, and proprietary identifiers; send only the generic error class + framework/version (search the error *category*, not the raw message). A self-hosted / in-VPC assistant under a no-retention, no-training contract may receive more *diagnostic context*, but secrets / tokens, customer data / PII, request/response bodies, headers, env values, and credential-bearing variable values are minimized regardless of channel; if an error cannot be safely sanitized, do not send it externally — diagnose from local evidence. Pasting the raw trace is the convenient default and the data-leak footgun. The prompt/assistant-output you record under (a) is then subject to the same evidence-sanitization rule as any other persisted evidence (Phase B "Record evidence"), so the recording step does not re-leak what this strip removed.
+     - Safe-to-delegate work: log/trace summarization, repro-script drafting, hypothesis fan-out, refactoring-after-fix.
+     - Not-safe-to-delegate: the root-cause verdict, the fix application without test, the prevention routing decision.
+
+5. Verify cause.
+   - Prove the cause with evidence.
+   - When the cause is environment/toolchain state, prove it from the tool that owns that state, not only from the high-level wrapper. A wrapper failure is a symptom until the underlying compiler, generator, runtime registry, dependency resolver, or platform destination evidence explains it.
+   - If disproven, return to hypotheses instead of guessing.
+   - Separate symptom, immediate cause, contributing factors, and prevention.
+
+## Convergence Control And Escalation
+
+The hypothesize → instrument → verify loop must not run forever, and escalation must not drop the discipline. Apply these signals:
+
+- **Frame-change-or-escalate (three-strike).** Count evidence-backed rejected hypotheses within the same frame (same layer, evidence source, and reproduction). After about three, pause for reassessment before adding another from that frame. Continue in the same frame only when the next hypothesis is materially new, has a distinct falsifier, and is backed by new or deeper evidence that can distinguish it from the rejected class; otherwise record a material frame change (new reproduction, layer, independent evidence source, owning invariant, or a tool that exposes new evidence rather than re-reading the same signal) or escalate. Rephrasing the same hypothesis class, swapping tools that observe the same evidence, or renaming owners does not reset the count. This is a reassessment signal, not a numeric cap on valid evidence-driven hypotheses.
+- **Escalation does not close the defect.** Handoff, "instrument and wait", or re-scope leaves the defect OPEN; it never waives the verified cause, fresh verification, or regression evidence before any fix is accepted. A handoff packet carries: symptom, reproduction, rejected hypotheses with evidence, current mitigation, next owner, and the open verification/regression obligations.
+- **"Instrument and wait" needs a severity gate.** It is acceptable only with an explicit classification: no plausible user, data-integrity, security, compliance, or SLA impact; mitigation is not applicable or would be riskier; an owner accepts observe-only; and an alert + timeout + owner are recorded. Unknown or latent-uncertain severity defaults to mitigate/escalate, not wait. Emergency mitigation (roll back, flag off, shed traffic) stays available immediately while the cause is unknown, per the Non-Negotiable mitigation rule.
+- **Wrong-layer smell.** If each fix makes a new problem appear elsewhere, you are patching symptoms at the wrong layer or abstraction — stop patching and re-trace to the layer that owns the broken invariant. A fix proposed before its cause is verified by evidence (per Phase A) is a guess, not a fix.
+- **Recurring-area smell.** A defect recurring in the same module or files across separate fixes is a trigger to investigate whether the cause is structural — not a verdict that it is. Mitigate or land the minimal verified fix first, then route prevention to the owning skill via Prevention Routing (architecture only when the cause is genuinely structural — service boundary, source-of-truth, contract, auth, runtime/release, or data ownership; otherwise dev/testing/product/tooling per the table).
+
+## Phase B: Fix And Verify
+
+1. Fix minimally.
+   - Address the proven cause with the smallest correct change.
+   - Preserve contracts unless the task explicitly requires a contract change.
+   - If the minimal fix would change a shared deterministic gate/verifier (workspace verifier, conformance/contract-coverage script, status-source validator, CI harness, continuation-state checker) or shared/cross-repo contract/status/version/release/compatibility semantics — whether in a named surface or in code, generated artifacts, config, or scripts — stop before editing and route the fix through `product-rd-workflow`'s shared-gate classification (its *Enforce quality gates* shared deterministic gate/verifier rule: artifact classification + persistent repo-local plan + `feature-risk-router` shared-gate route). Diagnosis still owns the verified cause and regression test; that handoff governs only how the fix lands.
+   - Keep unrelated cleanup separate.
+
+2. Add regression evidence.
+   - Add or update a test that would have caught the defect when feasible.
+   - Prefer a test that fails before the fix and passes after the fix.
+   - Do not treat a random, log-only, sleep-heavy, or live-data script as sufficient regression evidence unless it is explicitly marked as a manual/integration probe and paired with a deterministic check.
+   - Run narrow verification first, then broader affected tests based on risk.
+
+3. Record evidence.
+   - Do not claim the defect is fixed until fresh verification has been run and read.
+   - Symptom and reproduction.
+   - Proven cause and rejected hypotheses.
+   - Fix summary.
+   - Verification command/result.
+   - Regression test or why it was not feasible.
+   - **Sanitize evidence that is persisted or shared.** Any diagnosis evidence copied to a ticket, MR, repo-local file, or shared doc — repro inputs, env/config, commands, request/response headers and bodies, logs, verification output, and AI-assist transcripts (per Phase A item (d)) — is minimized and redacted first of the *same categories* Phase A item (d) strips before an external send: secrets/tokens, customer data / PII, credential-bearing values, internal hostnames / IPs / internal URLs / paths, raw SQL and query bodies, request/response bodies, env/config values, and proprietary identifiers. Raw unredacted repro artifacts live only in an access-controlled incident store with a retention rule, referenced by link, never pasted into shared diagnosis evidence; recording the failure must not become the leak the live system avoided.
+
+## Phase C: Root Cause And Prevention
+
+Run 5 Whys after the immediate defect is understood:
+
+- Why did the observable failure happen?
+- Why did that code/data/config condition exist?
+- Why did tests, review, monitoring, or runtime checks miss it?
+- Why was the contract, workflow, or assumption unclear?
+- What durable prevention changes future behavior?
+
+Stop when the answer points to a reusable prevention mechanism, not when it only names the broken code. Reject disguised non-causes — "developer was careless / didn't follow the rule / will be more careful next time" name the human's diligence, not the mechanism. When a control that was *expected* to catch this (a test/check/review/CI/lint/type/contract/runbook) existed but did not fire, and the failure would recur for others, that is not the root cause — the next why is "why did no trigger/gate make that control fire", and the prevention is the mechanism that fires next time (a failing-first regression test, CI check, lint, type, contract, or review-checklist item). A genuine one-off low-risk human slip that an existing check already caught may stop at "no shared change needed" — but never at "try harder next time".
+
+The 5 Whys lineage is generic industrial-quality practice (popularized by Toyota Production System manufacturing-quality work; widely adopted across software incident review). For incident-class defects (production outage, data corruption, security event), pair 5 Whys with two additional named lenses commonly applied in modern SRE practice (repeated/recurring defects are routed by the complexity rule below, which fires the widen lens regardless of user-visibility):
+
+- **Blameless postmortem** (per Google SRE Book chapter on Postmortem Culture, `sre.google/sre-book/postmortem-culture/`): write the incident review assuming everyone involved acted with the right intent given the information they had at the time. The point is to extract systemic prevention (gates, alerts, contracts, runbooks) rather than to assign individual fault. Templates capture timeline, impact, contributing causes, action items with owners + due dates, and what worked/didn't in response. Influenced by the broader safety-critical-incident investigation and human-factors literature where punitive incident review demonstrably reduces report rate AND hides repeating failure classes.
+- **Swiss Cheese model** (attributed to James Reason in the safety/accident causation literature; widely applied to software incidents): every defense layer (test, code review, monitoring, alerting, runbook, on-call response) has holes; an incident reaches production when holes line up. The action items from a postmortem should close the relevant hole at MULTIPLE layers, not just the one closest to the bug — adding a unit test alone leaves the alert + the runbook + the on-call playbook still empty. List which layers had a hole this time and which closures the team commits to.
+
+Scale Phase C depth to defect **complexity**, not only to user-visible incident status:
+
+- **Simple deterministic non-incident** — one local cause plus one regression/control fully explains the defect (test caught it, dev fixed it, no user impact): the linear 5 Whys above is sufficient.
+- **Complex defect** — intermittent/flaky/racy, multi-component, repeated/recurring, required a Phase-A frame change (the three-strike signal), spans more than one Diagnosis Playbook lens category (e.g. a contract + timing + cache interaction) or the test layer is itself causal, or more than one expected control failed: **widen before deepening, even with no user-visible impact.** Enumerate the contributing factors across the Diagnosis Playbook lenses (contract / state / time / dependency / runtime / test / human-agent workflow), separate the immediate cause from the enabling/latent conditions (applying the blameless / local-rationality framing — assume right intent given the information available at the time; that framing is the *lens* and applies here, separate from the formal *ceremony* below), counterfactually rank the primary cause against the failed secondary controls (close each failed layer per Swiss Cheese, not only the one nearest the bug), then route prevention for each. A single straight 5-Why chain that stops at one cause is the documented failure mode here — a complex defect with no branches means you stopped early. Record the **complexity verdict** (`simple` / `complex` + which trigger fired) in the diagnosis evidence, so the widen path cannot be silently skipped on a bug that warranted it.
+
+The **widen + multi-layer (Swiss Cheese) lens fires on complexity above, not only on visible impact** — so a repeated regression (a named complexity trigger above) is widened even when caught in CI with no user impact. Reserve the **formal blameless-postmortem ceremony** (timeline / impact / action-items with owners + due dates) for incidents with user-visible or business-visible impact, and for the defect class below.
+
+- **A defect that escaped into a merged change, a release, or a user must get a written postmortem when all three hold — subtle, systemic, costly to rediscover.** *Subtle*: the mechanism is non-obvious and a careful engineer would re-derive it the hard way. *Systemic*: it escaped through a gap in tests, tooling, or conventions, not a one-off typo. *Costly*: it burned real debugging time and would burn it again. Below all three **and** with no user-visible or business-visible impact, the formal write-up is not required — but this exempts only the ceremony: the simple-vs-complex analysis-depth rules above still apply in full, so a repeated, flaky, multi-component, or frame-changing defect still gets the widened multi-layer analysis even when nothing is written up. An impacted incident keeps the unconditional ceremony regardless of how obvious its mechanism was — "the mechanism was just a typo" is never an exemption once users or the business saw it. The bar exists only to stop ceremony over *no-impact* trivia: writing one up for an unmerged local slip trains people to skip postmortems, while skipping one for an incident that reached users trains them to hide impact.
+- **The write-up must open with a thirty-second executive summary** — what broke, the root cause in plain terms, why it escaped, the durable lesson — before timeline and detail, and it must link the guardrails it produced (tests, rules, runbooks, decision records) so a reader can check that the class now fails loudly. A postmortem is not a decision record: it looks backward at a failure and its escaped defenses, while the design decision it triggers is written where decisions live.
+
+## Prevention Routing
+
+- Product workflow issue -> `product-rd-workflow`.
+- Go backend architecture issue -> `go-microservice-architecture`.
+- Go backend implementation, testing, codegen, DB, Redis, MQ, or protobuf issue -> `go-microservice-dev` references.
+- Python backend, AI-service host, worker, SDK/package, or batch-job architecture issue -> `python-service-architecture`.
+- Python implementation, pytest, packaging, schema, ORM/migration, Redis, queue, async, or service-wiring issue -> `python-service-dev` references.
+- LLM, inference, RAG, prompt, model-routing, streaming, fallback, evaluation, replay, shadow, token-cost, or agent-runtime/tool-call issue -> `llm-inference-integration`.
+- Mobile app issue involving Flutter, Android, iOS, navigation, state, platform bridge, device capability, build/release, crash, accessibility, or performance -> `app-cross-platform-dev`.
+- Mini-program issue involving WeChat/Alipay/Douyin/Baidu page routing, host-platform APIs, developer tools, review submission, release, real-device preview, or platform capability -> `miniapp-product-dev`.
+- React web issue involving components, routing, browser state, frontend API integration, forms, build/deploy, accessibility, or browser performance -> `web-react-dev`.
+- Terminal, CLI, or TUI issue involving ANSI rendering, text layout, PTY behavior, keyboard/mouse/paste/focus input, selection/copy, scrollback, resize, color fallback, or terminal cleanup -> `terminal-cli-dev`.
+- Tests, CI, fixture, mock, E2E, device/browser, or verification-layer miss -> `testing-strategy`.
+- Regression test case needs to be written and tracked in Feishu Bitable after a bug is fixed -> `test-artifact-management`.
+- Hands-on diagnosis method issue -> `defect-diagnosis`.
+- UI/product interaction issue -> `product-ui-ux-design` first when UX is unclear, then `app-cross-platform-dev`, `miniapp-product-dev`, `web-react-dev`, or `terminal-cli-dev` for implementation.
+- One-off business/domain issue -> do not convert to a generic skill rule.
+
+## Reference Loading
+
+- For diagnosis lenses and evidence templates, read `references/diagnosis-playbook.md`.
+- For prevention types and skill update rules, read `references/prevention-routing.md`.

package/dist/assets/marketplace/plugins/ccl-skills/skills/defect-diagnosis/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Defect Diagnosis"
+  short_description: "Diagnose defects and route prevention"
+  default_prompt: "Use $defect-diagnosis to debug a bug, failed test, or regression with root-cause evidence."

package/dist/assets/marketplace/plugins/ccl-skills/skills/defect-diagnosis/references/diagnosis-playbook.md

@@ -0,0 +1,54 @@
+# Diagnosis Playbook
+
+Use this when choosing how to isolate a defect.
+
+## Diagnosis Lenses
+
+- Contract: request/response fields, protobuf/API compatibility, enum defaults, error envelope, HTTP/RPC mapping.
+- State: database rows, transactions, cache entries, lock state, idempotency records, durable workflow status.
+- Time: deadlines, retries, async delivery, job lease, clock/time zone, race conditions, eventual consistency.
+- Dependency: RPC/HTTP status, domain status, timeout, malformed response, credential/config mismatch.
+- Runtime: environment, feature flag, dynamic config, deployment version, generated file drift.
+- Test: invalid fixture, over-mocked dependency, missing cleanup, order dependency, live-infra assumption.
+- Human/agent workflow: unclear acceptance, skipped failing path, unverified assumption, missing handoff.
+
+## Evidence Template
+
+```markdown
+## Defect Diagnosis Evidence
+
+- Symptom:
+- Reproduction:
+- Failing command/test:
+- Environment/config:
+- Narrowed layer:
+- Hypotheses tried:
+- Proven cause:
+- Complexity verdict (simple | complex; `simple` must name the complexity triggers checked and found absent; `complex` must name which trigger fired + contributing factors by playbook lens):
+- Fix:
+- Verification:
+- Regression test:
+- Prevention update:
+```
+
+## Profiler / Tracer Tool Routing By Symptom
+
+When the failure is a performance / resource / runtime-behavior symptom rather than a logic bug, pick the tool by symptom shape, not by team familiarity:
+
+| Symptom | Default tooling | Routing |
+|---|---|---|
+| CPU-heavy / hot loop / unexpected slowness with one process saturating a core | flame graph + sampling profiler — pprof (Go), `py-spy` / `scalene` (Python), `perf` + FlameGraph (Linux native), Chrome DevTools Performance panel (web) | stack dev skill owns config (build with profiler symbols, enable runtime profiling endpoint) |
+| I/O-blocked / process appears stuck but CPU is low | system trace — `strace` (Linux syscall trace; overhead varies widely with syscall load and can be large on syscall-heavy workloads, so use briefly and on representative samples), `dtrace` (macOS / BSD; broader dynamic tracing, not just I/O), `bpftrace` (eBPF, typically low overhead BUT a badly-scoped probe still hurts; verify the probe before attaching to a production process) | platform-observability owns eBPF-based pre-installed observers (Beyla / Pixie / Tetragon); stack dev skill owns app-level instrumentation |
+| Memory leak / heap growth | heap profiler — pprof heap mode (Go), `tracemalloc` (Python), Chrome DevTools Memory panel (web), Instruments / Allocations (macOS), Valgrind massif (Linux native) | stack dev skill owns "how to enable heap profiling endpoint" |
+| Concurrency / race / deadlock | race detector + lock-graph capture — Go `go test -race`, Java `ThreadMXBean.findDeadlockedThreads()`, Helgrind (Linux native pthreads), Python `faulthandler.dump_traceback_later()` + thread dump | stack dev skill owns runtime config; this skill owns "look at all threads, not just the one that hit the breakpoint" discipline |
+| UI lag / dropped frames | Chrome DevTools Performance for frame-level profiling + Lighthouse for audit-style triage (web); Android Studio CPU Profiler + GPU Inspector (Android); Xcode Instruments Time Profiler + Hitches (iOS) | product-ui-ux-design owns user-facing perception; stack dev skill owns tool config |
+| Network latency / packet loss / TLS handshake | `tcpdump` + Wireshark for capture; `curl -v` / `httpstat` for HTTP-level; `mtr` / `traceroute` for path | platform-service-connectivity owns mesh / proxy debug; this skill owns "capture both sides of the wire" discipline |
+| Distributed-system request-path mystery | OTel trace + exemplar walk per the SKILL.md Phase A observability-driven rule; do NOT default to single-service profiler when the symptom crosses service boundaries | platform-observability owns the trace UI; this skill owns the trace-first workflow |
+
+The recurring failure shape: reach for the team's most-familiar profiler regardless of symptom (a Java-shop reaches for `jstack` on a Python service; a web team reaches for Chrome DevTools on a server-side latency issue). Pick the tool whose data model matches what's broken; pull in the stack dev skill for "how to enable it" once the tool is chosen.
+
+## When Stack-Specific Skills Take Over
+
+- Use Go/Python backend development skills for concrete commands, package layout, DB/Redis/MQ/protobuf/schema tests, generated files, and code patterns.
+- Use the relevant architecture skill when the prevention changes service boundary, source of truth, contract compatibility, auth, release runtime, or data ownership.
+- Return here to finish root-cause evidence and prevention routing.

package/dist/assets/marketplace/plugins/ccl-skills/skills/defect-diagnosis/references/prevention-routing.md

@@ -0,0 +1,36 @@
+# Prevention Routing
+
+Use this when deciding what should change after a defect.
+
+## Prevention Types
+
+- Contract prevention: schema, protobuf, API validation, enum default, required field, compatibility test.
+- Data prevention: DB constraint, transaction boundary, migration check, unique key, retention policy.
+- Runtime prevention: timeout, rate limit, circuit breaker, lock lease, idempotency record, alert.
+- Test prevention: regression test, boundary case, contract test, integration test, replay check, generated-file drift check.
+- Review prevention: checklist item for security, data integrity, permission, concurrency, migration, or release.
+- Tooling prevention: deterministic generator, non-interactive command, safer default, file overwrite guard.
+- Skill prevention: concise rule in the smallest relevant skill/reference.
+
+## Skill Update Decision
+
+Add or update a skill only when all are true:
+
+- the lesson is product-agnostic.
+- it would change future behavior.
+- it can be stated as a short rule, checklist item, or workflow step.
+- it belongs to a clear owner skill.
+
+Discard or keep local when:
+
+- it depends on one business domain or one legacy repository.
+- it is already covered by an existing rule.
+- it is a temporary workaround rather than a durable pattern.
+- it would make a skill longer without improving future execution.
+
+## Examples
+
+- Missed protobuf or OpenAPI/Pydantic compatibility break -> architecture contract rule plus dev contract test rule.
+- Deleted failing test to pass CI -> defect-diagnosis rule plus development test-quality reference.
+- Repeated unclear acceptance criteria -> product-rd-workflow shaping checklist.
+- Missing Redis lock value comparison -> stack-specific Redis implementation reference, not product workflow.

package/dist/assets/marketplace/plugins/ccl-skills/skills/feature-risk-router/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: feature-risk-router
+description: 风险定级 / 要不要灰度 / 需要哪些 gate / 双人 review / 架构评审 / 安全审计 / 安全评审 / 威胁建模 / security audit / threat model / OWASP / pentest review / risky → classify a feature, fix, or change by risk tags (incl. a security-review gate) and name required design, arch, dev, test, review, security, launch, and rollout gates.
+---
+
+# Feature Risk Router
+
+Use this lightweight router before or during product delivery when the required rigor is unclear. It classifies risk and names the gates that must run; it does not replace `product-rd-workflow`, `testing-strategy`, `product-ui-ux-design`, stack-specific development skills, review skills, or release workflows.
+
+**Objective high-risk change-shapes force classification even when the change feels trivial — a low-risk intuition is not a substitute for running the tags.** The "when rigor is unclear" entry is not a licence to skip the router because you judged a change low-risk: the tags below classify well *once you are here*; the failure mode is never arriving because you felt sure. So regardless of that intuition, if the change deletes / backfills / migrates data or is otherwise irreversible, touches authentication / authorization / roles / tenant isolation, handles secrets / credentials / tokens, moves money or billing / quota, alters an external-facing or service-client API contract, changes a trust boundary or an untrusted-input sink, drives a production rollout / flag, or changes a shared deterministic gate / validator / CI harness / merge-readiness or completion-status rule (which can look docs/scripts-only yet decide future merge and completion semantics), run the classification FIRST and only then conclude low-risk if the relevant tags (`write-finality`, `data-migration`, `permission-access`, `security-review`, `api-contract`, `money-quota`, `release-ops`, `shared-gate`, `ai-action`) actually clear. Self-de-escalating one of those change-shapes to "not needed" without running its tag is the miss this prevents. (The always-on routing layer and `product-rd-workflow` owner-dispatch are the backstops for the case where the router is never invoked at all — this clause governs the case where you are deciding whether it applies.)
+
+## Output Contract
+
+Return a compact routing decision:
+
+- `risk tags`: the relevant tags below.
+- `required gates`: skills, checks, or evidence that must run before completion.
+- `skippable gates`: checks that can be skipped and why.
+- `stop reasons`: decisions or blockers that require user/product/architecture/security confirmation.
+- `verification evidence`: concrete commands, screenshots, browser/app/device checks, review artifacts, or docs that should prove completion.
+
+## Risk Tags And Gates
+
+- `visible-ui`: Any visible UI change, including layout, copy, state, interaction, navigation, user-facing error/empty/loading feedback, or operation entry. Require `product-ui-ux-design`, the relevant client skill, and rendered inspection evidence.
+- `client-plumbing`: Client request headers, telemetry, storage, API adapters, generated clients, or non-rendered behavior. If no visible surface changes, record `visible surface: no`; require focused tests or contract checks for the changed boundary.
+- `api-contract`: Backend route, request/response schema, status code, error envelope, auth/session, or service-client contract changes. Require architecture or development skill for the owning stack plus integration/contract verification.
+- `permission-access`: Authentication, authorization, roles, admin/internal access, tenant/user isolation, or data visibility. Require architecture review, negative tests, and explicit stop if identity/product boundary is unclear.
+- `money-quota`: Billing, points, quota, payment, entitlement, refund, metering, or financial finality. Require high-risk resilience gates, idempotency/replay checks, auditability, and product confirmation for user-facing semantics.
+- `write-finality`: Mutations, async jobs, repeated submission, irreversible actions, imports, deletes, or bulk operations. Require duplicate-submit/idempotency checks, pending/final state coverage, retry semantics, and recovery evidence. **Verify the authoritative postcondition, not the call's success/`ok` status** (a 2xx/ok ≠ the effect landed), via a finite ladder — direct read → operation receipt / status / version / ETag / audit-event or effect id (each counts as authoritative only if it actually proves the declared postcondition, not merely "accepted") → bounded eventual-consistency retry (cap attempts/window) → if no authoritative read exists (fire-and-forget / write-only / encrypted), report `accepted-not-applied` / `unverifiable`, never `done` and never loop unbounded; `testing-strategy` owns the side-effect-finality test mechanics.
+- `ai-output`: LLM, RAG, model routing, generated content, prompt/eval, high-impact answer, or automation decision. Require `llm-inference-integration`, eval/replay or scenario checks, degradation/refusal behavior, and traceability.
+- `ai-action`: An LLM / agent that does not just produce an answer but **takes side-effecting actions** — calls tools that mutate state, send or trigger external effects, access privileged data, or make authorization-sensitive decisions; moves money; changes permissions; or drives irreversible effects from model output (industry framing: OWASP Top 10 for LLM Applications 2025 — LLM06 *Excessive Agency* and LLM01 *Prompt Injection*).
+  - Read-only retrieval used only to form an answer stays `ai-output` unless it can expose privileged data or drive a downstream action.
+  - Require `llm-inference-integration` for tool-execution validation, fail-closed authorization, human confirmation on destructive / external / financial / permission-changing / irreversible actions, and prompt-injection defense whenever untrusted content (user input, retrieved documents, web pages, tool results) can reach a model able to act or surface privileged data.
+  - (This is the product/runtime agent surface; `multi-agent-delegation` is a different axis — it applies only when the *delivery work itself* is delegated to subagents, not to a shipped agent feature.) Also apply `write-finality`, `money-quota`, or `permission-access` when the action actually crosses that boundary — durable-state mutation, money/quota movement, or access change — but do not stack those tags for read-only, reversible, or sandboxed actions whose downstream effect stays in bounds.
+  - Where a gate does apply, the action being model-decided does not lower the bar; it raises it, because the model must never infer permission from untrusted content.
+- `genai-compliance`: A surface that **publishes or distributes** generated / synthetic content to end users (synthetic image / audio / video / voice / avatar, user-shareable AI media), or operates a generative-AI service in a covered jurisdiction.
+  - This tag only flags that legal/compliance review *may* be needed — it does NOT determine the obligations or satisfy them, and it is distinct from `ai-output` (answer quality).
+  - Ordinary ephemeral assistant answers are `ai-output`, not this.
+  - Mark it launch-blocking only when legal/compliance ownership is unknown, a target jurisdiction has a covered regime, or the surface distributes synthetic media; route the obligation through `product-rd-workflow`'s compliance/legal stop point and the legal/compliance owner (the Stop Rules below already require stopping for legal/compliance boundaries).
+  - Obligations vary by jurisdiction — transparency, labeling, provenance, content filing, safety assessment, or others — and must NOT be inferred from this router.
+  - Example: mainland China has AI-generated/synthetic-content labeling rules (explicit user-visible + implicit metadata label concepts, effective 2025-09-01 with a companion mandatory national standard); verify the current requirement for each jurisdiction and content type with legal/compliance.
+- `data-migration`: Schema, storage ownership, migration, backfill, indexing, or irreversible data movement. Require architecture review, migration rehearsal or rollback plan, and live-data boundary confirmation.
+- `external-integration`: Third-party API, webhook, browser/device, deployment platform, queue, object storage, or credential-dependent path. Require mocked fast tests plus explicit live/integration verification or recorded unavailable evidence.
+- `release-ops`: CI, deploy, observability, rollback, feature flags, canary, or platform control-plane changes. Require release/readiness checks and post-change status evidence.
+- `shared-gate`: A shared deterministic gate, verifier, conformance script, CI/harness check, status-source validator, agent-contract checker, or review/merge readiness rule that future agents or repositories rely on. This can look like docs/scripts-only work, but the changed artifact decides whether later work is allowed to merge or be called complete. Require the owning workflow skill (usually `product-rd-workflow` for product/spec normalization or `skill-extraction-workflow` for shared-skill gates), `testing-strategy` when the gate has executable or mutation-test behavior, and an explicit independent review/challenge decision before shared branch push or MR merge. Local passing gate output is required evidence, but it does not replace review of the gate's scope, false-positive/false-negative behavior, and completion semantics.
+- `security-review`: An explicit security audit / threat-model / OWASP / pentest-review request (over an existing or proposed system/design), OR a change that introduces or materially alters a trust boundary, an untrusted-input surface, a sensitive sink, authentication/authorization semantics, secret/credential handling, or data visibility, or is itself a hardening / vulnerability-fix change. Require a security-review gate before completion; conduct, gate statuses, and safety boundary are in `references/security-review-gate.md`.
+  - It **co-applies** with `permission-access`, `external-integration`, `release-ops`, and `ai-action` and **never de-escalates** another tag or a Stop Rule. An explicit security-audit / threat-model / pentest request always sets at least **pending-dedicated-review** and is **never `not-applicable`**. Only the change-triggered arm may be `not-applicable`, and only after recording `security posture unchanged` and ruling out every posture-change blocker (trust boundary, untrusted-input surface, sensitive sink, auth/authorization semantics, data visibility, secret handling, hardening, vulnerability-fix intent).
+  - This router owns the gate's **status and safety boundary, not a security-audit method**. With no dedicated security-audit skill/owner available, the most you may run is a **read-only first-pass triage** (`security-first-pass-only`, never a passed gate; never "secure" / "audit passed" / a standalone "no findings" as completeness) — a real audit needs a dedicated security owner or professional firm. Normalize findings per the shared review-finding standard.
+- `verification-scope-unclear`: The required test or runtime verification layers are unclear.
+  - Must-route only when at least two signals are present: the change spans at least two runtime domains such as browser UI, server process, live infrastructure dependency, or external API; the user mentions complete tests, integration, E2E, live dependency, browser verification, Docker, or equivalent; implementation is underway or complete and the user asks whether a test layer is missing; or the plan/spec does not assign unit, integration, E2E, live dependency, or browser-rendered coverage.
+  - Require `testing-strategy` to produce a lightweight test-layer matrix only: each layer applies yes/no, reason, and owner skill.
+- `docs-only`: Documentation/status-only change. Require consistency scan; skip code tests unless the doc changes executable instructions, product status, or release readiness claims.
+
+## Stop Rules
+
+Stop and ask before proceeding when a change affects product direction, monetization, legal/compliance boundaries, identity model, public launch scope, security/privacy assumptions, destructive data actions, or external permissions that cannot be exercised locally.
+
+Do not stop for low-risk implied follow-through such as running focused tests, checking diffs, syncing status docs after a merged slice, or recording `visible surface: no` for pure plumbing changes.
+
+## De-Escalation
+
+Keep the route as small as the risk allows:
+
+- If a change is docs-only, do not require runtime tests.
+- If a docs/scripts-only change is tagged `shared-gate`, do not de-escalate to ordinary `docs-only`; keep the review/challenge decision and executable verification required unless the owning workflow explicitly classifies the gate as non-blocking and local-only.
+- If a client change has no visible surface, do not require a design checkpoint.
+- If a backend change is internal and contract-preserving, prefer focused unit/integration tests over full E2E.
+- If `verification-scope-unclear` has only one signal, treat it as a hint, not a must-route. Single-file pure refactors, copy-only changes, tiny style tweaks, and docs-only updates do not need test-layer routing unless another risk tag applies.
+- If live infrastructure is unavailable after normal remediation, record the blocked gate with command evidence, residual risk, and next unblock action instead of pretending it passed.

package/dist/assets/marketplace/plugins/ccl-skills/skills/feature-risk-router/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Feature Risk Router"
+  short_description: "Classify feature delivery risk and route required gates."
+  default_prompt: "Classify this feature or change by risk tag, required gates, skippable gates, stop reasons, and verification evidence."

package/dist/assets/marketplace/plugins/ccl-skills/skills/feature-risk-router/references/security-review-gate.md

@@ -0,0 +1,41 @@
+# Security-Review Gate
+
+Conduct rules for the **security-review gate label** in `feature-risk-router`. This is a router label, not a skill route; this repo does not define a CCL skill named security-review. This file owns the gate's **status** and **safety boundary** only; it does NOT define a security-audit method (no checklist, phase catalog, or report schema lives here — that is the method layer, owned by a dedicated security skill or a professional firm).
+
+## Gate statuses (exactly one)
+
+The security-review gate is in exactly one state. This router can never set `passed`.
+
+- **not-applicable** — **change-triggered arm only**: `security posture unchanged` is recorded with every posture-change blocker ruled out (see "Co-applies" below). An explicit audit / threat-model / pentest request is never **not-applicable** — it is at least **pending-dedicated-review**.
+- **pending-dedicated-review** — the gate applies and no accountable security owner has completed it. **The inline first-pass triage and any external-recipe run (e.g. `gstack-cso`) land HERE — this is the ceiling for anything this router can produce.**
+- **passed** — set ONLY by a named accountable security owner or a professional review. Never set by the inline pass, by an external recipe's output, by model judgment, or by a risk acceptance.
+
+Absence of a dedicated owner or recipe does not block *unrelated* work, but it leaves the security-review gate at **pending-dedicated-review**, never satisfied. A risk owner may accept the residual risk and ship past a **pending-dedicated-review** gate, but that is a separate recorded ship / accept-risk exception (per Stop Rules) and **leaves the gate at pending-dedicated-review — it does not make it `passed`**. Proceeding past a pending gate is a risk-owner / user decision, never something the inline pass or an external recipe can grant.
+
+## Method ownership
+
+There is no ccl-owned security-audit *method*. The router owns only the gate's status and how the review is conducted safely.
+
+- If an external security-review recipe is available in the current session (for example `gstack-cso` — **external / reference-only, not a CCL owner and not a pass authority**), use it as the supplemental operational method. Its output is method *evidence* that informs the gate; it does not by itself move the gate to `passed`, and its absence does not lower the bar.
+- With no such recipe, the most you may run is a bounded read-only **first-pass triage** — OWASP-Top-10 / STRIDE used only as a lens to surface obvious questions and findings, not as a comprehensive method or coverage claim.
+
+## The inline first-pass is triage-only, never a completed review
+
+- For any case where the tag applies, the inline pass status is **pending-dedicated-review** (with `stop reason: dedicated security owner / professional review required` for an explicit audit / pentest / threat-model request, a sensitive or production system, a new trust boundary, or secret handling). It never satisfies the gate.
+- Never emit "secure", "audit passed", or a standalone "no findings" as audit completeness from the inline pass. "No findings in a bounded first pass" is not "the system is secure."
+
+## Read-only conduct — this router never runs exploit tests
+
+Verify by code-tracing and guardrail inspection only. Never use a live exploit, real or production-like credentials, a destructive / privileged / irreversible action, or production mutation as verification — the same boundary as `testing-strategy`'s runtime auth-boundary rule. Production or production-like credentials and any production mutation are **always invalid** here, not merely "stop and confirm".
+
+This router never conducts an exploit test itself. A genuine exploit test is a separate, dedicated exercise — generic "audit / pentest this" wording is **not** authorization for one. It may proceed only when routed to a dedicated security / `testing-strategy` owner AND with explicit current-turn authorization naming: target environment, synthetic tenant / account / credentials, allowed actions, a non-production / sandbox boundary, no real external side effects, rollback / stop conditions, and the responsible owner. Any missing field, or any production / production-like target, → stop.
+
+## Subordinate to Stop Rules; co-applies with other tags
+
+- The security-review gate **never de-escalates** another risk tag or a Stop Rule. If security / privacy assumptions, the identity model, external permissions, or local-verification authority are unclear, STOP and ask (per the router's Stop Rules) before treating any review gate as passed. The inline pass may only collect questions and evidence; it must not self-resolve the assumption.
+- It **co-applies** with `permission-access`, `external-integration`, `release-ops`, and `ai-action`; those tags do not suppress it. The omit (`not-applicable`) path is for the **change-triggered arm only** — an explicit audit / threat-model / pentest request is never omitted. Mark the change-triggered arm `not-applicable` only after explicitly recording `security posture unchanged` and ruling out a new / altered trust boundary, untrusted-input surface, sensitive sink, auth / authorization semantics, data visibility, secret handling, hardening, or vulnerability-fix intent. It is the security-posture lens, not a duplicate of the per-surface tags.
+
+## Finding shape and sub-routing
+
+- Normalize every finding per the shared review-finding standard (`skill-extraction-workflow/references/review-finding-standards.md`): failure_path + impact + evidence + smallest_fix; reject speculation and noise.
+- Sub-route depth to existing owners: test / proof evidence → `testing-strategy`; LLM / agent security → `llm-inference-integration`; release / rollout security → the platform owners; classifying a specific change's risk stays in `feature-risk-router`'s other tags.