@ccoalm/ccl-skills 0.1.0

package/dist/assets/marketplace/plugins/ccl-skills/skills/skill-extraction-workflow/references/r0-leakage-audit.md

@@ -0,0 +1,90 @@
+# R0 Leakage Audit — Mandatory Landing Gate
+
+R0 is the mandatory landing gate enforced before every commit of a skill or reference change. The SKILL.md entrypoint states the rule in one sentence; this file is the operational mechanism. Sibling skills that reference "R0" route to this rule as a whole; the detail here is for the maintainer running the audit.
+
+## What R0 Requires
+
+Zero hits in the changed files across these categories:
+
+- design-source file keys
+- design-source URLs
+- project / team identifiers
+- real subproject paths or repository names
+- real branch names
+- contributor emails or names
+- ticket or work-item ids
+- internal domains or hostnames
+- design-source node ids
+- any non-distilled business or product nouns (in any language) that point to one specific organization rather than a reusable capability
+
+A commit that has not run this audit, or that has not closed every hit, is not landed regardless of how the work is described.
+
+## How To Run
+
+The maintainer keeps one alias file per private source product at `~/.<host>/.private-aliases/<project>.yaml`:
+
+- `<host>` is the directory chosen by the host runtime — commonly `.claude` for Claude Code or `.codex` for the Codex CLI. If multiple runtimes share the same machine, the maintainer canonicalises to one host and symlinks the others.
+- `<project>` is the maintainer's short label for the private source product — typically one alias file per separate Figma / code / document corpus, named after the team or product line, never after a specific commit or release.
+
+The alias file contains both the sanitized-label dictionary AND an `audit_cmd` block. The maintainer invokes that `audit_cmd` against the changed-file set before committing. Any non-zero hit must be either removed or explicitly recorded in the same alias file's `known_debt` list.
+
+**Audit category definitions, scan patterns, and per-project allow-lists live ONLY in those private alias files.** Do not copy the patterns themselves into shared skill content — that would re-leak them.
+
+### Generic process-retro profile
+
+When the extraction source is the current task/session, a workflow failure, review/tooling behavior, or another process-retrospective source with no single private product corpus, the maintainer MUST use a generic private alias profile such as `~/.<host>/.private-aliases/process-retro.yaml` instead of hand-writing a one-off grep in chat. That profile's `audit_cmd` scans only changed shared-skill files for cross-session leakage classes: local absolute paths, real workspace/repo/worktree names, real branch names, model/session ids, internal domains/hosts/IPs, user or teammate identifiers, ticket/work-item ids, and any source-specific nouns that were observed only in the task transcript.
+
+This generic profile is the fallback for process sources only. It does not replace a project-specific alias file when the source is a real product, Figma file, codebase, document corpus, incident, customer workflow, or team corpus. If a process-retro extraction also cites a concrete product artifact, run both the project-specific audit and the generic process-retro audit.
+
+The closeout row must name which private profile was used: `project-alias`, `process-retro`, or `both`. If no matching alias/profile exists in the contributor's environment, the change may be committed/pushed only as `interim` (for example a Draft/WIP MR) with `R0 pending maintainer audit` recorded; it must not be marked `R0-clean`, merge-ready, or landing-clean until the private profile exists and passes, or a risk owner records an explicit waiver. An ad-hoc inline `grep` may diagnose leakage risk, but it is not the durable R0 gate for clean landing.
+
+## known_debt Scope
+
+Pre-existing leakage from earlier extractions may be tracked as `known_debt` in the alias YAML and explicitly excluded from blocking the current change. New or modified content MUST remain zero-hit — `known_debt` cannot waive a newly introduced label.
+
+## Fail-Closed Clause — Maintainer Discipline
+
+Every new sanitized label introduced in this commit (e.g. an angle-bracket capability token like `<some-capability>`, a class tier like `<class-A1>`, or any other invented short name that stands for a real source artifact) MUST exist in the maintainer's alias YAML before the commit lands.
+
+A reference that uses a label not present in the alias file is treated as a hit, because the label is implicitly identifying to the source team and the audit cannot prove otherwise.
+
+## Example-Identifier Clause
+
+The audit also covers identifier-shaped tokens used as illustrative examples inside prose, code fences, anti-pattern descriptions, or rule wording — variable names, function names, class names, type names, theme-module names, file paths, package names.
+
+When such an identifier is observed verbatim in the source codebase / design source, it carries the source's product noun into shared content even when no canonical leakage pattern in the alias YAML matches it.
+
+The typical failure shape is a generic-looking compound name whose first half is a product role lifted verbatim from the source — a role-named theme / service / widget where the role word is the source app's name or domain.
+
+### Two Safe Substitution Strategies
+
+- **Generic placeholder syntax** — angle-bracket meta-token (`<AppTheme>`, `<ServiceName>`) or generic capitalized noun (`MyComponent`, `ExampleService`). Distinct from the alias-YAML-tracked sanitized label and need not be registered.
+- **Clearly-fictional substitute** — names that universally read as placeholder (Acme*, Foo*, sample*) regardless of context.
+
+Avoid any substitute that still carries a real product role.
+
+### Adversarial Review Is The Practical Safety Net
+
+Grep cannot detect this class of leak. Do not rely on R0 grep alone to catch source-shaped example identifiers — codex challenge or equivalent adversarial review is the practical safety net.
+
+## Enforcement: Private Audit Is Authoritative, Generic Public Fallback Backstops It
+
+`check-ccl-skills.sh` runs the alias-vs-label cross-check ONLY when the maintainer exports `ALIAS_AUDIT_CMD` pointing at their private audit script. That private audit is the strongest and the only clean-landing R0 evidence: it verifies every sanitized label and pattern against the private alias YAML across all file types. On success it prints `alias_audit_ok`, sets `r0_status=private-ok`, and the validator's final line is `ccl_skill_check_clean_ok`.
+
+`ALIAS_AUDIT_CMD` is whitespace-split and executed directly as argv — it is NOT evaluated by a shell, so `;`/`&&`/pipes/substitutions in the variable have no effect (injection hardening). A leading `~/` in a word is expanded to `$HOME/` (no other shell expansion happens). Use the `<script-path> <args>` form; if the audit needs shell features, put them inside the script the variable points at.
+
+When `ALIAS_AUDIT_CMD` is unset (a normal local machine), the validator no longer merely skips. It runs a deterministic PUBLIC fallback — `scripts/generic-r0-leak-scan.sh` — over the ADDED lines of the current git diff, restricted to shared-skill markdown surfaces (`skills/**/*.md`, `README.md`, `docs/**/*.md`, opencode command markdown). The fallback fails closed (`generic_r0_leak_scan_failed`, exit 1) on high-signal public leaks: absolute local paths (a user home directory, `/private/var/<seg>`, or a Windows drive path), RFC1918 private IPv4 literals (not loopback), internal-only hostnames (`.internal`/`.intranet`/`.corp`), and secret/token literals (key=concrete-value assignments and known vendor token prefixes). It is diff-scoped (never re-polices pre-existing known debt) and markdown-only (the private audit, not this fallback, is the comprehensive gate over scripts/YAML/other file types). On a clean run it prints `generic_r0_leak_scan_ok`, and the validator prints `alias_audit_unavailable`, `r0_status=public-fallback`, and a final line of `ccl_skill_check_interim_ok` (NOT the clean token).
+
+**Probe before you conclude it is unset — "a normal local machine" describes the common case, it is NOT a licence to assume `ALIAS_AUDIT_CMD` is absent without checking.** Recording `alias_audit_unavailable` / choosing the public fallback is correct ONLY after you have *observed* it is actually unset. The authoritative probe is to run `check-ccl-skills.sh` and read which branch its output took (`r0_status=private-ok` vs `public-fallback`, plus the final token) — that reflects what the validator actually did and can't be asserted without producing the line; `printenv ALIAS_AUDIT_CMD` is only a quick pre-check. Treating "unset is normal" as a default and dropping straight to the interim fallback is a blocked-verification miss (the failure class: *assuming an environment-provided capability is absent because absent is common, without the one-command check* — and the priming cuts both ways: skipping the check can just as wrongly assume the audit IS there). "Configured" ≠ "works": a non-empty var means the private audit is *configured* and MUST be run, but availability is confirmed only when it actually executes and prints `alias_audit_ok`; a set-but-broken `ALIAS_AUDIT_CMD` (missing / non-executable / wrong-path script, or a run that errors) is itself a blocked-verification failure to fix or record an explicit risk-owner waiver for — it does NOT license the public fallback. Keep the two evidences distinct: the branch-read/probe gates *recording unavailable/fallback*; *asserting the private audit ran* requires the `alias_audit_ok` token, never the probe alone. (This is the R0-surface instance of the general blocked-verification rule — see the always-on R0 bullet and SKILL.md.)
+
+The generic fallback is PUBLIC INTERIM evidence, not private-alias clean-landing evidence. It deliberately cannot detect the leaks only the private alias catches — source-shaped example identifiers, project/team nouns, real subproject/repo/branch names, ticket ids, and the maintainer's project-specific token set. So a passing fallback permits an interim commit/branch/Draft MR, but the maintainer or CI MUST still block clean merge/landing until the private audit runs clean (`alias_audit_ok`), a named private profile result is cited, or an explicit risk-owner waiver is recorded.
+
+**Neither the deprecated `ccl_skill_check_ok`, the interim `ccl_skill_check_interim_ok`, nor `generic_r0_leak_scan_ok`/`alias_audit_unavailable` satisfies clean-landing R0.** The validator now ends on a machine-distinguishable token: `ccl_skill_check_clean_ok` (with `r0_status=private-ok`) only when the private alias audit ran clean, and `ccl_skill_check_interim_ok` (with `r0_status=public-fallback`) when only the public fallback ran. It still prints a deprecated `ccl_skill_check_ok` line for backward-compatible consumers, but that line is no longer the last line and no longer a sufficient clean-landing signal. The `r0_status=` line is an auxiliary R0 hint, not an overall validator-pass signal: it can appear before later blocking gates run, so clean-landing evidence still requires exit 0 plus the final `ccl_skill_check_clean_ok` token (or a named private-profile result / waiver in the review record). A reviewer who reads only the deprecated token, who treats `r0_status=private-ok` alone as a full pass, who treats `ccl_skill_check_interim_ok` as clean, or who treats the generic fallback as if it were the private audit, will mistake a run that never executed the private alias audit (or a later-failing run) for a clean R0 pass. Treat `alias_audit_unavailable` / `ccl_skill_check_interim_ok` anywhere in the output as **private R0 not run** — the change is `interim` / missing-clean-landing-evidence regardless of the trailing tokens and regardless of a clean generic fallback. That state may be committed or opened as a Draft/WIP MR only when the commit/MR record clearly says `R0 pending maintainer audit`; it must not be merged or described as landing-clean. A closeout or review record may cite R0 as satisfied ONLY when it cites `alias_audit_ok` (the private audit actually ran and found zero hits), a named private-profile result (`project-alias`, `process-retro`, or `both`, per the generic process-retro profile section above), or an explicit risk-owner waiver. A record that cites `ccl_skill_check_ok`, `ccl_skill_check_interim_ok`, `r0_status=private-ok`, or `generic_r0_leak_scan_ok` alone while the output shows `alias_audit_unavailable` is invalid clean-landing R0 evidence and must be redone with `ALIAS_AUDIT_CMD` exported (the output must exit 0 and show final `ccl_skill_check_clean_ok`) before the change can be called landing-clean.
+
+## R0 vs Other Audits
+
+- R0 is the leakage gate (this file). Failure class: source-domain content escapes into shared skills.
+- Pre-draft example domain selection (see `references/example-domain-preselect.md`) preempts retroactive R0 cleanup cycles by choosing scenario domain before drafting examples.
+- Two-source extraction adds source-specific category extensions on top of R0; see `references/two-source-extraction-pattern.md`.
+- Incident / postmortem extraction adds incident-specific category extensions on top of R0; see `references/incident-postmortem-extraction.md`.
+- Recurring anti-patterns checklist (see `references/recurring-anti-patterns-checklist.md`) is an orthogonal gate covering structural anti-patterns; it does NOT replace R0.

package/dist/assets/marketplace/plugins/ccl-skills/skills/skill-extraction-workflow/references/recurring-anti-patterns-checklist.md

@@ -0,0 +1,320 @@
+# Recurring Anti-Patterns in Skill Content
+
+Distilled from dual-track review passes across the platform-* skill family + go-microservice-* + python-service-* during one multi-batch real-project extraction. These anti-patterns reappear across skills because they share extraction provenance, B5-style cross-skill updates, or industry myths. Before committing any skill or reference change, scan for these.
+
+## Anti-pattern 1 — source evidence map as provenance dump
+
+**Symptom**: a skill's source evidence map reference (or equivalent) contains real repo names, branch state, dates, module counts, private-package names, contributor habits, or dated re-extraction notes.
+
+**Why bad**: shared skill tree exposes the extraction corpus + process; project changes invalidate the file; new project re-extraction has to delete and rewrite.
+
+**Fix**: replace with a methodology template — describe the *shape* of source coverage tracking (which dimensions to inspect, which mini-map decisions to record, which coverage labels to use) without naming any specific project's artifacts. Real provenance migrates to `~/.<host>/.private-aliases/<project>.yaml`. The shared template tells future extractors *how* to track, not *what was tracked* for this project.
+
+**Grep**: tailor a per-project pattern set. Common ones are real service names, real branch names, module counts, dated re-extraction notes, and the project's own short name. Run the maintainer's `ALIAS_AUDIT_CMD` against `*/references/source-evidence-map.md`.
+
+## Anti-pattern 2 — Platform Boundary table with stack-specific contract names
+
+**Symptom**: a Platform Boundary table (added by B5-style cross-skill update) uses concrete platform contract names from one organization: `base.Request`, `Base{...}`, `logs.CtxInfo/Error`, `filebeat→logstash`, `conf/<env>.yml`, `PSM-style identity`, mandatory middleware names.
+
+**Why bad**: cross-language uniformity is the goal of Platform Boundary, but baking one organization's runtime/logging/config stack into the table forces every reader's product onto that stack.
+
+**Fix**: replace concrete names with reusable role names: "request-metadata envelope", "structured logger interface", "log pipeline", "per-environment static config files", "platform service identifier". Keep the *role* row; route the *implementation* to the relevant `platform-*` skill.
+
+**Grep**: `grep -l "base\.Request\|logs\.CtxInfo\|filebeat\|conf/<env>\.yml\|PSM-style" */SKILL.md`
+
+## Anti-pattern 3 — gRPC error transport via `status.message`
+
+**Symptom**: skill says typed errors ride in the gRPC "status message" field, encoded as JSON.
+
+**Why bad**: gRPC status message is freeform text with size limits, not a structured channel. Standard clients use `google.rpc.Status` with `details` (carried via `grpc-status-details-bin` trailer or framework details mechanism). Packing JSON into status message loses typed retry/security semantics and risks leaking server-rendered text.
+
+**Fix**: "encode structured details via `google.rpc.Status` with `details` (transported via the `grpc-status-details-bin` trailer or the framework's native details mechanism); do NOT pack JSON into the gRPC status message field."
+
+**Grep** (case-insensitive — the Go idiom is `status.Message()`, not lowercase `status.message`; also catch JSON packed into the message): `grep -niE "status\.message|HTTP/2 status message|status\.Message\(\)" skills/*/references/*.md skills/*/SKILL.md`
+
+## Anti-pattern 4 — Internal vocabulary leakage
+
+**Symptom**: skill content uses one platform's terminology as generic vocabulary: `NACOS`, `PSM`, `lane`, `inner-network`, `H5`, `edu`, `infra`, `bizprod`, `idl2py.sh`/`idl2go.sh`, `kerrors.ErrBiz`, `x-token`, `x-app-id`, `ctx_keys`, `ppe-`/`ofe-`, internal hostname suffixes (e.g. `code.<organization>.com` or `<product>.internal`).
+
+**Why bad**: same as anti-pattern 2 — readers from another platform get told to adopt one organization's naming conventions.
+
+**Fix**: replace with role-based vocabulary:
+- `NACOS` → "registry-based service discovery (Nacos / Consul / equivalent)"
+- `PSM` → "platform service identifier" or `<service>`
+- `lane` (when describing platform conventions) → "lane / environment label"
+- `inner-network` → "private-network"
+- `H5` → "mobile web"
+- `edu` / `infra` (as IDL dir names) → `<product-line>` / `<platform-layer>`
+- `bizprod` / `biz` (as image namespaces) → `<prod-namespace>` / `<dev-namespace>`
+- `idl2py.sh` → "one codegen script per target language"
+- `x-token` / `x-app-id` → "auth header" / "app-identity header"
+- `ctx_keys` → "tiered context-keys convention"
+- `ppe-` / `ofe-` → "designated online/offline lane prefix"
+
+**Grep**: `grep -nl "NACOS\|\\bPSM\\b\|inner-network\|\\bH5\\b\|\\bedu\\b\|bizprod\|idl2py\|idl2go\|x-token\|x-app-id\|ctx_keys\|\\bppe-\\|\\bofe-" */references/*.md */SKILL.md` — also append the maintainer's project-specific tokens via `ALIAS_AUDIT_CMD`.
+
+## Anti-pattern 5 — Dangling internal doc references
+
+**Symptom**: skill text says "see today's X notes" or "see X.md in the platform docs" pointing at internal documents not available in the shared skill tree.
+
+**Why bad**: future readers can't load the referenced doc; ad-hoc inline guidance becomes the only thing they see, and may be vague enough to mislead.
+
+**Fix**: either inline the actual pattern, or link to a stable reference file in the shared skill tree, or remove the reference entirely.
+
+**Grep**: `grep -nl "see today's\|see .*\.md\b\|today's notes\|internal doc" */references/*.md`
+
+## Anti-pattern 6 — `psm` as placeholder in path/key schemas
+
+**Symptom**: a key/path schema uses `psm` as the placeholder: `/{psm}/{namespace}/{key}`, `<psm>.svc.cluster.local`, etc.
+
+**Why bad**: `psm` is one platform family's local naming convention. Other platforms use `service`, `service.name`, `app`, etc.
+
+**Fix**: use `{service}` or `{platform-service-identifier}` as the placeholder, with a one-line gloss on the actual format the platform chose.
+
+**Grep**: `grep -nl "{psm}\|/<psm>/\|<psm>\.svc" */references/*.md`
+
+## Anti-pattern 7 — Cross-language inconsistency
+
+**Symptom**: same architectural decision is stated differently across `python-service-*` and `go-microservice-*`. Example: Go says "avoid splitting into microservices until ownership/scaling/data/release cadence justify it"; Python says "default to microservices for new backend products".
+
+**Why bad**: same backend product gets a different architecture solely because of language choice.
+
+**Fix**: align both skills on the same decision, and route language-specific *implementation* differences to dev skills. When the language genuinely changes the architecture (e.g. Python async runtime affects worker design), call out the divergence explicitly with the reason.
+
+**Grep**: cross-compare the SKILL.md "Architecture Defaults" / "Core Workflow" / opening section of each language pair; look for assertions that contradict.
+
+## Anti-pattern 8 — Outbox vs post-commit MQ ambiguity
+
+**Symptom**: skill says "publish to MQ after the transaction commits" as a normal pattern, while another reference in the same skill says "use outbox" for required async effects. Reader picks the wrong one.
+
+**Why bad**: process death between DB commit and MQ publish loses the message. Required async side effects need outbox-in-transaction; only best-effort effects may go post-commit.
+
+**Fix**: distinguish *required* (outbox in same transaction, dispatched by poller) from *best-effort* (post-commit). Document the promotion criterion: "if a side effect's failure would leave the system in an inconsistent state, it is NOT best-effort — promote it to the outbox."
+
+**Grep**: `grep -nl "after the transaction\|post-commit MQ\|MQ.*after.*commit" */references/*.md`
+
+## Anti-pattern 9 — `additive` field becomes required
+
+**Symptom**: skill says "adding an optional field is compatible" without the caveat that the moment a service starts rejecting requests where the field is absent, it's a breaking change.
+
+**Why bad**: IDL says compatible; handler validation says required; old clients break silently.
+
+**Fix**: "optional is compatible only as long as absent remains accepted forever; new required semantics need a versioned method/message OR a staged compatibility gate."
+
+**Grep**: `grep -nl "adding an optional\|optional field is compatible" */references/*.md`
+
+## Anti-pattern 10 — Generic write fallback to baseline lane
+
+**Symptom**: skill says "when the requested lane has no healthy instance, fall back to the baseline lane" without operation-specificity.
+
+**Why bad**: write requests mutate prod baseline with canary/stress assumptions. Tenant-sensitive reads leak across lanes.
+
+**Fix**: "fallback is operation-specific: read-only idempotent endpoints MAY fall back; writes + tenant-sensitive reads + side-effect routes fail closed when the requested lane has no healthy instance."
+
+**Grep**: `grep -nl "fall back to.*baseline\|fallback to baseline lane" */references/*.md`
+
+## Anti-pattern 11 — Watch reconnect without revision/monotonicity
+
+**Symptom**: skill discusses etcd/config-center watch but doesn't mention persisting last-revision, resuming on reconnect, or handling `ErrCompacted` full-resync fallback.
+
+**Why bad**: stale config remains active after disconnect; reconnect resumes from old position; auth/routing config silently doesn't update.
+
+**Fix**: "persist last-observed revision; resume from `last+1` after reconnect; full resync (re-read all subscribed keys) on `ErrCompacted` or history loss; jittered backoff; readiness probe fails on stale critical-config watcher."
+
+**Grep**: `grep -nl "watch.*callback\|watch.*reconnect\|watcher" */references/*.md`
+
+## Anti-pattern 12 — Fixed-lease lock without fencing
+
+**Symptom**: scheduled job has `lock_lease` + `max_execution_time` but no fencing tokens or renewable leases.
+
+**Why bad**: if execution exceeds lease (GC pause, slow dependency, large backfill), a second pod acquires the lock and both run.
+
+**Fix**: "renewable leases with fencing tokens for jobs whose runtime can exceed one lease window. Renew via heartbeat at < ½ TTL; every write carries the fencing token; second pod's stale token is rejected by the backend."
+
+**Grep**: `grep -nl "lock lease\|max execution time\|max_execution\|lock TTL" */references/*.md`
+
+## Anti-pattern 13 — Silent skip on invalid list-config entry
+
+**Symptom**: skill says "skip invalid entries with warning logs" for list-style config.
+
+**Why bad**: one malformed routing/credential entry disappears, shifting traffic or disabling protection without alerting.
+
+**Fix**: "fail the whole snapshot for security/routing/credentials lists; partial-skip with warning only for non-critical inventory lists with explicit degraded-mode contract."
+
+**Grep**: `grep -nl "skip invalid\|skip.*malformed" */references/*.md`
+
+## Anti-pattern 14 — Lazy endpoint refresh in hot path
+
+**Symptom**: skill says "refresh endpoints lazily on next operation" for service discovery / config center / similar clients.
+
+**Why bad**: refresh + reconnect cost (DNS, TLS handshake) lands on a user request during endpoint churn; concurrent requests stampede the reconnect.
+
+**Fix**: "background goroutine / task refresh on bounded cadence; singleflight on reconnect; serve last-known-good endpoints with bounded staleness while background refresh runs."
+
+**Grep**: `grep -nl "refresh lazily\|reconnect lazily\|refresh on next" */references/*.md`
+
+## Anti-pattern 15 — Recovery middleware ordered after auth
+
+**Symptom**: skill says middleware order is "auth, recovery, ..." or doesn't specify recovery wraps auth.
+
+**Why bad**: panic in session/token parsing happens before recovery wraps it; framework drops connection or crashes process depending on semantics.
+
+**Fix**: "recovery wraps auth, validation, metrics, handler. Order: context injection → recovery → tracing → auth → metrics/logging → handler. Verify panic-catch coverage explicitly."
+
+**Grep**: `grep -nl "middleware.*order\|recovery.*after\|auth.*recovery" */references/*.md`
+
+## Anti-pattern 16 — Storage deletion before traffic drain
+
+**Symptom**: cleanup sequence deletes pod / PVC / object storage before deregistering from service discovery and draining in-flight traffic.
+
+**Why bad**: in-flight requests hit missing state; PVC data destroyed while still being read.
+
+**Fix**: "(1) shift traffic weight to zero, (2) deregister from SD, (3) wait for in-flight drain (documented grace window), (4) snapshot or verify retention on durable storage, (5) delete workloads, (6) delete ephemeral-tagged storage, (7) remove service-level routing/metadata."
+
+**Grep**: `grep -nl "delete.*lane.*storage\|cleanup.*storage\|delete.*workload" */references/*.md`
+
+## Anti-pattern 17 — DELETE without safety gates
+
+**Symptom**: DELETE operation cascades through k8s + mesh + DB in one transaction without protected-flag, dry-run preview, two-person approval, or expected-count confirmation.
+
+**Why bad**: operator typo deletes prod. No mitigation.
+
+**Fix**: "protected lanes (online lanes etc.) require unprotect-then-delete two-step; DELETE requires a matching dry-run preview token; two-person approval for online targets; finalizer pattern + Deleting state; expected_count confirmation prevents racing add; non-empty target requires `force: true` + approval."
+
+**Grep**: `grep -nl "DELETE /lane\|cascade.*delete\|delete cascade" */references/*.md`
+
+## Anti-pattern 18 — CORS AllowAllOrigins + AllowCredentials
+
+**Symptom**: skill recommends CORS defaults with both `AllowAllOrigins: true` and `AllowCredentials: true`, OR with a permissive `AllowOriginFunc` that reflects arbitrary origins under credentials.
+
+**Why bad**: browsers reject `*` with credentials, OR frameworks reflect origin and grant credentialed access to attacker hosts.
+
+**Fix**: "default: explicit allowlist. Production admission rejects AllowAllOrigins+AllowCredentials combinations AND permissive AllowOriginFunc validators. AllowOriginFunc must exact-match against a reviewed list."
+
+**Grep**: `grep -nl "AllowAllOrigins\|AllowCredentials\|AllowOriginFunc" */references/*.md`
+
+## Anti-pattern 19 — `keys_under_root` + `overwrite_keys` letting app overwrite platform fields
+
+**Symptom**: filebeat/log-shipper config uses `keys_under_root: true` + `overwrite_keys: true` without protecting platform-reserved fields.
+
+**Why bad**: compromised or buggy service can emit `_lane=prod` from a non-prod pod; canary queries misclassify; audit searches lie.
+
+**Fix**: "set `overwrite_keys: false` for platform-reserved `_`-prefixed fields. Add pipeline filter that strips/renames app-supplied platform fields and re-injects authoritative values from pod metadata. SDK contract: only platform SDK writes `_`-prefixed fields."
+
+**Grep**: `grep -nl "keys_under_root\|overwrite_keys" */references/*.md`
+
+## Anti-pattern 20 — Chat callback without signature/replay protection
+
+**Symptom**: skill describes chat-platform card click → API callback → approve, without specifying HMAC signature verification, timestamp skew check, nonce/event-id replay check, action-task binding.
+
+**Why bad**: attacker who captures one valid signed payload can replay it to approve arbitrary deploys.
+
+**Fix**: "callback handler MUST verify: (a) platform HMAC signature, (b) timestamp skew (< 5 min), (c) nonce/event-id replay (against recently-seen set), (d) action binding (click's task_id + version + reviewer matches original send), (e) RBAC. All five required."
+
+**Grep**: `grep -nl "chat.*callback\|card.*callback\|approve.*click\|callback/.*card" */references/*.md`
+
+## Anti-pattern 21 — Stack-specific syntax in mirrored sections
+
+**Symptom**: parallel-stack reference (Go + Python files mirroring the same architecture) has DB-engine syntax, runtime-mechanic names, or library/framework API names in the supposedly stack-agnostic mirrored sections — `SET LOCAL`, `BYPASSRLS`, `FORCE ROW LEVEL SECURITY`, `context.Context`, `goroutine`, `contextvars`, `asyncio`, `GORM`, `SQLAlchemy`, `FastAPI`, `run_in_executor`, etc.
+
+**Why bad**: defeats the sibling-sync invariant; the mirrored sections drift between Go and Python; agents copying from the wrong stack produce code that does not run.
+
+**Fix**: each parallel-stack file ends its stack-glue section with a `### Mirrored-section grep gate` (token list + awk-then-grep run command). The grep runs on every commit; zero hits required. See `parallel-stack-references-pattern.md` for the gate shape. Allowed exception: the sibling-sync header itself names the category classes (without tokens) and the routing-reference text may differ per stack (`api-security-boundaries.md` vs `web-framework-boundaries.md`).
+
+**Grep**: run the file's own gate, e.g. `awk '/^## Go-specific implementation patterns/{exit} 1' <file>.md | grep -nE 'SET LOCAL|BYPASSRLS|FORCE ROW LEVEL SECURITY|context\.Context|\bgoroutine\b|contextvars|\basyncio\b|GORM|SQLAlchemy|FastAPI'`
+
+## Anti-pattern 22 — Sibling-sync header self-violation
+
+**Symptom**: the parallel-stack file's sibling-sync header itself contains the tokens it forbids — listing `SET LOCAL`, `BYPASSRLS`, `context.Context`, `contextvars`, `GORM`, `SQLAlchemy`, etc. as examples of what must NOT appear in mirrored sections. The grep gate then matches its own header and always fires.
+
+**Why bad**: the gate is now unusable; maintainers learn to ignore it; the rule it states becomes unenforceable in practice.
+
+**Fix**: header names category *classes* only ("DB-engine-specific syntax, runtime/concurrency-mechanic names, library/framework API names") and references the grep-gate subsection by name. Concrete token lists live only in the grep-gate subsection at the end of the stack-glue.
+
+**Grep**: scan the header (top ~10 lines) for stack tokens; any hit there is the violation.
+
+## Anti-pattern 23 — Body strengthened without checklist sync
+
+**Symptom**: a body section was strengthened in a way that **alters acceptance criteria, required evidence, scope, exception handling, or verification behavior** (R3 added "classify every relation, not just tables with `tenant_id`"; R3 added "denylist propagation barrier before destructive action"; R3 added six evidence artifacts for crypto-deletion). The operations checklist still uses the older weaker rule ("every table with `tenant_id` is enumerated"; "reads consult the denylist"; "the six artifacts recorded").
+
+**Why bad**: checklist regression — a launch verification that passes against the older rule misses what the stronger rule was supposed to catch; the body's safety improvement is invisible to launch readiness.
+
+**Scope (what counts as "strengthening" for this rule)**: body changes that alter (a) acceptance criteria, (b) required evidence, (c) scope of applicability, (d) exception or carve-out handling, or (e) verification behavior. Rationale-only clarifications — explaining *why* an existing rule exists without changing what it requires — do not trigger this rule and should not bloat the checklist with duplicate or wording-only checks.
+
+**Fix**: every qualifying body strengthening update must include the matching checklist update in the same commit. After each dual-track round's fixes, diff the checklist against the body's strengthened sections and verify each new clause that changes acceptance/evidence/scope/exception/verification has a corresponding verification item.
+
+**Grep**: when reviewing a fix-up commit, diff body sections against the operations-checklist section; if a body rule changed any of the five categories above but the checklist did not, flag for fix-up.
+
+## Anti-pattern 24 — Evidence-based carve-outs replaced with categorical ones
+
+**Symptom**: a rule has a carve-out (irreversible-data-loss override of threshold inflation; monitoring-as-primary for external dependencies; crypto-deletion as erasure; large-tenant priority lane on shared accelerator). The carve-out is stated as **categorical** ("for external dependencies, monitoring may be primary"; "irreversible data loss overrides recurrence calibration") with no evidence requirement.
+
+**Why bad**: agents apply the carve-out to any vaguely-fitting case; the carve-out becomes the default; the rule it carved out of is gutted.
+
+**Fix**: every carve-out requires recorded evidence per case. Examples:
+- Irreversible data loss carve-out: requires (a) category, (b) repair-impossible evidence, (c) blast radius, (d) narrowest workflow, (e) gate scope.
+- Monitoring-as-primary carve-out: requires a prevention-disqualification checklist (boundary contract / idempotency / timeout-retry / capability-auth / contract-replay test / canary) where each applicable gate is marked unavailable with evidence.
+- Crypto-deletion as erasure: requires six artifacts (key hierarchy / backup inventory / restore-path test / envelope destruction proof / backup-purge SLA / regulator acceptance) at per-store/per-tenant/per-key-version scope, freshness window, independent countersignature, non-forgeable workflow execution identifier.
+- Large-tenant priority lane on shared accelerator: requires a named workload class with a latency SLO or large-prefill characteristic, with the specific isolation mechanism (reserved capacity / priority lane / max-wait admission / dedicated partition) declared.
+
+A carve-out is a contract, not a category badge. Without the evidence row, fall back to the base rule.
+
+**Grep**: search for `categorical`, `override`, `exception`, `carve-out`, `unless` and verify each has named evidence requirements; categorical carve-outs without an evidence row are the bug.
+
+## Anti-pattern 25 — Bypass-role enforcement without bypass-path enumeration
+
+**Symptom**: skill describes engine-level enforcement (RLS / row policies / equivalent) as "the authority" without naming the bypass paths — superuser, BYPASSRLS / equivalent role attribute, table owner unless forced, bulk-truncate / schema operations, logical replication, security-invoker vs definer views, triggers under different roles.
+
+**Why bad**: every real engine has bypass paths; treating engine policy as universal authority means migration scripts, repair tools, replication streams, and admin queries silently bypass the safety the rule promised.
+
+**Fix**: every engine-policy rule must (a) enumerate the bypass paths for the chosen engine, (b) require forced policy enforcement (FORCE RLS or equivalent) where the table-owner bypass otherwise applies, (c) use distinct DB roles for application / migration / admin / replication, none carrying the bypass attribute on the production app path, (d) require explicit tenant filters or offline approval on bypass-role connections, and (e) audit every bypass-role connection — with **both data-plane independence** (audit sink is write-only to bypass roles) **and control-plane independence** (bypass operator cannot modify audit-transport network/DNS/service-account/queue routing) plus an alert on audit delivery gaps.
+
+**Grep**: `grep -nE 'RLS|row-level security|row policy|engine policy.*authoritative' */references/*.md` and verify each hit names bypass paths + role separation + audit-both-planes.
+
+## Anti-pattern 26 — "Reversible step" without time-window classification
+
+**Symptom**: migration / rollback design classifies steps as reversible or irreversible based on structural transforms (ID-scheme reshape, shard-key rewrite, encryption-key envelope change). Time-based irreversibility — TTL, retention purges, token expiry, object-lifecycle rules, backup rotation — is not classified, so "rollback safe" steps become irreversible during the migration window as old state is deleted by clock.
+
+**Why bad**: rollback attempted past a TTL deadline finds the old state already purged; the recorded "last safe rollback point" is in the past even though no explicit structural irreversible step ran.
+
+**Fix**: classify each step's reversibility along **two axes** — structural irreversibility AND time-based irreversibility. Last safe rollback point is the **earliest** of structural-irreversible boundary and any time-based deadline that touches state needed for rollback. Either freeze/extend those timers across the migration window (only where legally permitted — regulator-mandated retention maxima and data-subject deletion SLAs cannot be paused) or compute the rollback point from them.
+
+**Grep**: `grep -nE 'reversible|rollback point|migration step' */references/*.md` and verify each migration rule names both axes.
+
+## Anti-pattern 27 — Repo/worktree identity decided by PATH SHAPE instead of git structure
+
+**Symptom**: a hook, gate, or state-keyed script decides "which repository is this" or "is this checkout already isolated" from a **path-shaped** signal — matching a git-dir string against `*/worktrees/*`, or using `rev-parse --absolute-git-dir` as the identity key. Both read as "the repo" and are correct in the team's own conventional layout, which is exactly why they survive review and local testing.
+
+**Why bad**: neither signal is owned by the control. `--absolute-git-dir` is *per-worktree* (`<common>/worktrees/<id>`), so state written from a worktree is invisible from the primary checkout — and a path-name match on `worktrees/` is decided by the **user's directory naming**, so a primary checkout that merely lives under a directory called `worktrees/` (`~/work/worktrees/<repo>`) is misread as already-isolated and the control **silently fails open**. For a security/isolation gate that means every deny branch is disabled with no error, no log, and a green test suite — the suite's own fixtures are built in the conventional layout, so the trap case never occurs there.
+
+**Fix**: predicate on the git structure the control actually owns.
+- **Identity / state key** → `rev-parse --path-format=absolute --git-common-dir` (same value from every worktree of a repo; fall back to plain `--git-common-dir` + normalization for git < 2.31).
+- **"Is this a linked worktree"** → compare `--absolute-git-dir` against the common dir; they differ **iff** it is linked. Path names never enter the decision.
+- A submodule initialized inside a linked worktree keeps its git-dir under that worktree's admin dir and reports the SAME common dir, so it reads as primary; when "already isolated" must include it, detect the enclosing admin dir by the marker files git writes there (`commondir` + `gitdir`), still never by a directory *named* `worktrees`.
+- Any fixture proving such a control must include a layout the team convention does not produce (a checkout under a `worktrees/`-named path), or the probe cannot see the failure.
+
+**Grep**: `find hooks scripts -name '*.sh' -not -name 'test_*.sh' -not -name 'test.sh' | xargs grep -nE '\*['"'"'"]?/worktrees/['"'"'"]?\*'` (non-comment hits), and review every `--absolute-git-dir` whose output becomes a state path or identity key. Stars on **both** sides make it a match pattern rather than a path, so an ordinary `.work/worktrees/*` cleanup glob is not flagged. That spelling is machine-enforced by `check-ccl-skills.sh` (`git_identity_predicate_scan`); two things are deliberately **not** caught and stay human/challenge checks — a fully dynamic pattern (`*"/$seg/"*`) and `--absolute-git-dir` used as an identity key (the same call is legitimate for locating *this* worktree, so grepping it is false-positive-prone).
+
+**Occurrences that promoted it**: `scripts/owner-dispatch/owner-dispatch.sh` (state keyed per-worktree → boundary record written in a worktree unreadable from the primary checkout) and `hooks/guard-edit-isolation.sh` (path-name match → the repo's only edit-time hard-deny gate silently disabled for checkouts under a `worktrees/`-named path).
+
+## How to use this checklist
+
+Before committing any skill or reference change touching operational/architectural rules:
+
+1. Run the grep from each applicable anti-pattern against the changed file set.
+2. For each hit, decide: fix in this commit, defer with explicit reason (recorded in private alias `known_debt` if pre-existing), or confirm not-applicable (this skill's context legitimately uses the term).
+3. After the dual-track review + challenge pass, re-run this checklist on the new content (passes often introduce new patterns).
+
+The checklist grows over time. Add a new anti-pattern when:
+- A pattern appears in 2+ skills and represents a real safety / correctness / sanitization issue.
+- A codex challenge finding maps to a class, not a one-off.
+- A user correction exposes a class of mistake the workflow should prevent.
+
+## Promoting a symptom to a mechanical gate
+
+These greps are only as strong as whoever remembers to run them — a human checklist does not stop a commit by an agent (or another model) that never runs it. When a symptom keeps reaching shared skills *despite* being named here (e.g. a one-organization contract token that leaked even though it was already listed), promote it from this checklist to a **mechanical gate in `check-ccl-skills.sh`** so it blocks regardless of who commits. Building that detector:
+
+- **Anchor the pattern on the ACTUAL leaked text, not imagined variants.** Read the real leaked instances and extract their invariant (e.g. the leaked field was always the reserved number, always proto-terminated). Broadening by imagination starts a false-positive arms race that blocks legitimate docs — a real version/limit doc that merely mentions the same number.
+- **Prefer high precision + a documented recall limit over broad matching.** For a *blocking* gate, a false-positive that blocks legitimate content is worse than a recall gap: the human checklist + dual-track challenge stay the comprehensive net, while the mechanical gate is the deterministic catch for the exact recurring shape. State the accepted recall limit in the script comment.
+- Expect a multi-round precision/recall convergence — the challenge will keep surfacing one real FP or FN per round until the pattern matches the invariant and nothing else.
+- The new gate will flag this checklist itself and any provenance row that legitimately **quotes** the symptom. Allowlist the symptom-defining file(s) by anchored repo-relative path (not a bare basename, and never a caller-settable env override that neuters the gate), and **reword provenance to non-literal** rather than broadly allowlisting — keep the gate maximally strict.

package/dist/assets/marketplace/plugins/ccl-skills/skills/skill-extraction-workflow/references/resume-paused-delivery.md

@@ -0,0 +1,16 @@
+# Resume paused delivery — premature-stop recovery binding rules
+
+Companion to the **auto-trigger durable learning** Core Rule in `SKILL.md` (under *Retrospectives, corrections & auto-triggered learning*). The Core Rule carries the gate: for a premature-stop correction after affirmative continuation, immediate recovery first reruns the active owner's current continuation/blocking gate in full (for product R&D, Pre-Final Continuation Gate steps 1–6) against current state, and recovery proceeds only when a literal binding exists. This file carries the relocated binding detail: what counts as a binding, the `continuing:`-line form, and what makes a `blocked:` recovery invalid.
+
+## The two binding paths
+
+Bind recovery when either:
+
+- **(a)** the literal original `proposed-next:` action/scope (or literal explicit proposal for a pre-marker incident) and literal assent are preserved in the visible conversation or quoted exactly in trusted host-owned session/compaction state; or
+- **(b)** the current user's premature-stop correction itself literally names the paused action and scope — on path (b), quote those exact user words in the visible `continuing:` line before proceeding.
+
+A semantic compaction paraphrase or a bare "why did you stop" complaint is not path-(b) authority. Never copy real conversation text into a shared repository record, reconstruct, broaden, or substitute it. The user's challenge is a current reactivation signal for that exact slice, not a demand for redundant reconfirmation; restate and proceed only when path (a) or (b) binds, and ask again when neither path binds the slice, the user intervened, or current scope/gates changed.
+
+## Invalid `blocked:` recovery
+
+A `blocked:` recovery without the step-1 evidence and a specific missing authority/ambiguity is invalid: rerun the gate and emit a well-formed outcome before any action; if ambiguity remains, ask the blocker question in the same turn and stay blocked. Do not let correction RCA or extraction extend a still-authorized delivery, and do not let stale assent bypass a newly pending or inconclusive gate.

package/dist/assets/marketplace/plugins/ccl-skills/skills/skill-extraction-workflow/references/review-feedback-mining.md

@@ -0,0 +1,33 @@
+# Review-feedback mining — turning human review comments into skill candidates
+
+Use this layer when the source corpus is **human review feedback on merged changes** (inline PR/MR comments, review submissions, review-thread replies) and the goal is to find guidance a reviewing skill (`code-review`, `product-rd-workflow`'s review checklist, a stack `*-dev` skill, or a domain reviewer rule) should carry. It complements the incident layer (`incident-postmortem-extraction.md`) and the task-retrospective layer (`source-to-skill-extraction.md`): those mine failures; this mines what reviewers repeatedly had to say. The evidence bar below exists because the naive version — "every comment is a lesson" — produces checklist bloat, and the naive adoption test — "the thread was resolved / the author replied fixed" — promotes guidance the final code may never have implemented.
+
+## What counts as evidence
+
+- **Author filter first.** Only feedback whose author is a human reviewer counts; bot/automation comments, and human comments that merely forward automation output, are excluded before anything else is read. The change author's own comments never count as adoption of themselves.
+- **Adoption is a diff fact, not a thread state.** A comment was adopted only if the change landed *after* the comment differs from the change as it stood *when* the comment was made in the way the comment asked. Compare the **feedback-time patch** (the change's diff at the last commit that predates the comment) with the **final landed patch** (the change's diff at the landing merge against its target parent). Merge status, a resolved thread, an author reply saying "fixed", or a same-file edit are context, never proof.
+- **Fail closed when the baseline cannot be reconstructed.** After a force-push, when the reviewed commit is no longer part of the change, when the feedback predates every surviving commit, or when the landing shape cannot be reconstructed, classify the item `unclear` and exclude it — do not guess adoption from the final diff alone (that diff also contains unrelated target-branch movement).
+- **Timestamps must strictly predate the merge** for both creation and last edit; an item edited at or after merge is post-merge commentary, not pre-merge feedback.
+
+## Classification pipeline
+
+1. **Author + adoption** — classify each eligible item as `human-authored | forwarded-automation | unclear` and `adopted | rejected | unclear`. Only `human-authored ∧ adopted` proceeds.
+2. **Against the current skill** — classify each adopted item as `candidate | already-covered | implementation-specific | not-feedback`. `already-covered` is the idempotency guard: rerunning over an overlapping window must not re-propose guidance the skill already states. A **singleton may qualify** — recurrence is a strength signal, not an admission ticket; one adopted, generalizable, non-obvious correction is enough.
+3. **Draft from structured agreed guidance, never from raw review text** — the draft input is the classified, generalized statement of what the reviewer asked and why the change adopted it, with the identifying details of the source change already stripped (`r0-leakage-audit.md`, `example-domain-preselect.md`).
+4. **Independent review of the same skill diff** — the candidate diff goes through the normal dual-track gate (`dual-track-review-gate.md`); when two model reviewers are used, they must be independently configured (refuse to run when both resolve to the same executable/provider), and disagreement gets one bounded re-evaluation and stays visible in the run record if unresolved.
+
+## Operating stance
+
+- **"No candidate" is the common, correct outcome** of a maintenance pass over a window; days without a skill change are the process working, not stalling. Do not lower the bar to produce output.
+- **The operator decides; model output is never committed verbatim.** Read the candidate diff on its own merits — look for checklist bloat, historical prose, extrapolation from a single incident presented as a general rule, and duplication of what the skill or an authoritative doc already says — then discard, batch with a later candidate, or promote with edits. Small edits during promotion (tightening, folding into an existing rule, dropping an example that only made sense with the source change's context) are expected and preserve the reviewer judgment the process depends on.
+- **Skill drift stops promotion.** A candidate is drafted against a recorded skill revision; if the skill has changed since, re-run the classification (or manually rebase and re-review) rather than applying a stale complete-file rewrite over newer guidance.
+- **Idempotent, cursor-free windows.** Scan a time window with overlap rather than keeping a repository cursor; already-covered guidance classifies out, so overlap is harmless and a missed day is recovered by widening the window.
+- **Provenance stays with the promotion, identifying details stay out of the shared tree.** The promoted change records which feedback items (by stable id/URL) and which landed evidence ranges support each rule — in the private alias / provenance archive per `extraction-lifecycle-handoff.md`; the shared skill text carries the generalized rule only.
+
+## Failure shapes this layer prevents
+
+- Promoting a rule from a comment the author argued down and never implemented (thread resolved ≠ adopted).
+- Promoting the same guidance twice because the second pass did not classify against the current skill.
+- Checklist bloat from treating every nit as a lesson; a reviewer's one-off preference dressed as a standard.
+- Committing a model-drafted `SKILL.md` verbatim, including examples that only make sense with the source PR in view.
+- Diffing the reviewer's clicked commit against the landing merge and attributing target-branch movement to "adoption".

package/dist/assets/marketplace/plugins/ccl-skills/skills/skill-extraction-workflow/references/review-finding-standards.md

@@ -0,0 +1,57 @@
+# Review Finding Standards
+
+Shared output standard for any code/plan/design review, regardless of who runs it (human, Claude, Codex, an external review wrapper) or which path produced it. Two things must mean the same across all reviewers, or review and dual-track convergence are theater: **how severity is calibrated** and **what makes a finding actionable rather than noise**.
+
+This file does NOT teach what to look for — that craft is owned where it is operational (see Non-Goals). It standardizes only the finding's severity and shape.
+
+## Severity Rubric
+
+Calibrate by *consequence and reversibility*, not by how clever the bug is or how confident the reviewer feels. Definitions are behavioral, not domain-specific. This file sets what each level *means*; the accept / defer / convergence mechanics that decide whether a landing may proceed are owned by `dual-track-review-gate.md` — apply both together.
+
+- **P0 — must block landing.** Security breach, data loss/exposure, irreversible destructive action, auth / permission / tenant bypass, money/quota error, or production outage. These stay P0 *even when a later mitigation exists* — the ability to rotate keys, restore a backup, refund, or re-run a job does NOT downgrade enduring harm (exposure already happened, trust/auditability already breached). A P0 clears only by an applied fix, rollback/removal of the change, or an explicit risk-owner exception (not a routine owner sign-off) that records mitigation plus a tracking item per `dual-track-review-gate.md`. "Mitigation + ticket" must never be a rubber stamp on a known catastrophic risk.
+- **P1 — should block landing.** Serious correctness, reliability, regression, privacy, or user-trust failure with a *genuine* recovery path — defined narrowly as complete restoration with no external exposure, no tenant/user-trust breach, no lost auditability, no unrecoverable money/quota effect, and no required customer or security incident response. Clears by an applied fix or an explicit deferred acceptance recording reason + residual risk; it does not silently pass. If a failure meets the P0 categories above, it stays P0 — you cannot reclassify it P1 by asserting a recovery path.
+- **P2 — worth fixing, not landing-blocking.** Localized bug, maintainability issue, confusing copy, weak-but-present test, minor edge case. May be deferred freely; track for the next pass.
+
+Scale reconciliation: some gates add an optional **P3** tier for nits / informational notes — treat it as a non-blocking sub-tier of P2. Structured finding schemas that accept only `P0|P1|P2` (e.g. `code-review`) fold P3 into P2.
+
+Same tiers, different input: the P0/P1/P2 blocking semantics here are the canonical definition, and they are reused for **test-case priority** in `test-artifact-management` (P0 = must pass before release, P2 = nice-to-have). The difference is only the *input* that picks the tier — a review finding's tier comes from the defect's consequence/reversibility (above); a test case's tier comes from scenario centrality (primary/security path → P0, edge → P1/P2). The tier meaning (P0 blocks shipping — "landing" for a finding, "release" for a test case — P2 does not) is identical, so the two never need separate definitions.
+
+Notes:
+- When unsure between two levels, state the failure path and let consequence decide; do not average to the middle.
+- "Style / preference" with no failure path is not a finding at any level — see noise below.
+- Evidence quality is not severity. If a claimed P0/P1 lacks a concrete failure path, require clarification or mark the review **inconclusive** — do NOT lower the severity just because the report is under-specified. An under-described auth bypass is an inconclusive-blocking escalation, not a quietly-downgraded P2.
+
+## Finding Quality
+
+Every finding must carry the first three; the fourth is required when it can be known:
+
+1. **failure_path** — the concrete way it breaks or gets exploited, specific enough to reproduce or trace ("on duplicate callback the row is written twice"), not a category ("idempotency issue").
+2. **impact** — who/what is harmed and how badly; this is what sets the severity above.
+3. **evidence** — a code path, a violated invariant, a reachable precondition, a threat-model step, a prior-incident pattern, or a reproduction. A *clean reproduction is not required* — hard-to-reproduce classes (races, prompt-injection, auth edge cases, distributed flakiness, supply-chain) are legitimately evidenced by a reachable code path plus plausible exploitability. What is rejected is speculation with NO code-path, invariant, or threat-model basis.
+4. **smallest_fix** — the smallest credible change that closes it (not a redesign). When the reviewer can prove the breakage but cannot safely prescribe the patch (security, concurrency, infra, product-policy), use `owner investigation required` instead. Missing fix guidance lowers actionability; it does not erase a proven finding.
+
+Noise, to be rejected before it enters a review result:
+- vague approval/disapproval ("LGTM", "looks risky") with no failure path;
+- restating what the code does without naming a failure;
+- pure speculation with no code-path, invariant, or threat-model basis (distinct from an evidence-backed risk that merely lacks a clean repro — that is a real finding, and an uncertain high-impact one routes to `inconclusive`/escalation, never to noise);
+- scope-expansion suggestions ("while you're here, also rewrite X") unless they close a named failure;
+- duplicate findings that restate one root cause as several.
+
+**Validity contract (this file owns this; the gate owns the consequences).** A result is one of three states:
+- *findings* — one or more entries each meeting the bar above;
+- *no-findings* — a valid, strong result ONLY when accompanied by an inspection record: scope reviewed, files/diffs actually inspected, any checks/commands run, explicit limitations, and reviewer/tool attribution. An empty list with no inspection record is `inconclusive`, not "no findings";
+- *inconclusive* — empty/partial/tail-only/timed-out/unparsable output, an unverified claimed-blocking finding, or a no-findings result lacking the inspection record.
+
+`dual-track-review-gate.md` owns what each state does to a landing (block / accept / defer / rerun); this file owns what makes each state valid.
+
+## Non-Goals (route, do not duplicate)
+
+This file standardizes the *output* of a review (severity + finding shape + validity), not its *depth*. Output conformance is not review depth: a finding set that fits this shape but was produced by a shallow skim is still a weak review. So before applying this standard, **name the review lens** — pick the owner/checklist that matches the change's risk (the routes below); if none applies, state explicitly what lens you used to decide what to look for. Then do NOT grow this file into a bug taxonomy, security checklist, or test strategy — route those to their owners:
+
+- which risk classes a change carries / which gates apply → `feature-risk-router`
+- what tests miss, assertion strength, scenario coverage → `testing-strategy`
+- adversarial / chaos failure modes and when two review passes are required → `dual-track-review-gate.md`
+- stack-specific pitfalls → the per-stack dev skills
+- CLI/tool invocation mechanics for a specific reviewer → e.g. `code-review`
+
+If a candidate rule names specific bug classes, it belongs in one of those owners, not here.

package/dist/assets/marketplace/plugins/ccl-skills/skills/skill-extraction-workflow/references/review-rubric.md

@@ -0,0 +1,40 @@
+# Review Rubric — Counterexample-Oriented
+
+Phase 1 material (design source: `docs/skill-extraction-optimization-design.md`). This rubric structures the **review pass** of the dual-track gate so it hunts for counterexamples instead of agreeing. It does not replace `references/dual-track-review-gate.md` — that reference still owns the run-BOTH-tracks requirement, convergence standard, and lens-independence rules. This rubric is the question set the review pass works through; the challenge pass stays adversarial per its own runbook.
+
+The failure this prevents: an LLM reviewer that answers "looks reasonable, no problems" — confident agreement that misses over-firing, under-firing, leakage, and authority overreach. LLM-as-judge has known position / verbosity / self-enhancement biases, so a clean review is one evidence class, not a verdict.
+
+## Rubric — every L1 / L2 review answers all of these
+
+| Dimension | Required question |
+|---|---|
+| Provenance | Can every rule trace back to evidence? |
+| Generalization | Is it generalized from the specific case into a reusable capability, not copied? |
+| Boundary | Are applies / does-not-apply written explicitly? |
+| Routing | Could it mis-fire or steal another owner's task? |
+| Cognitive load | Could a reference, example, or eval carry this instead of the entrance? |
+| Privacy / R0 | Any business noun, internal host, private path, person, or source-shaped example? |
+| Behavior | Which observable agent behavior does it change? |
+| False positive | Which scenarios would over-fire? |
+| False negative | Which scenarios would it miss? |
+| Regression | Is there a should-trigger / should-not-trigger case? |
+| User authority | Does it decide on the user's behalf where it should ask? |
+| Rule budget | Could this avoid adding a new hard rule? |
+
+## Reviewer prompt direction — find counterexamples, do not affirm
+
+Do NOT ask "is this change reasonable?". Require the reviewer to produce concrete failing scenarios:
+
+```text
+Find the scenarios where this skill change would mis-fire, under-fire, bloat the rule
+set, fail sanitization, collide with another owner's boundary, override user sovereignty,
+become un-verifiable in behavior, or duplicate/contradict an existing skill.
+```
+
+A review that returns no counterexamples must say *why each rubric row is clear*, not just "no issues found". An empty finding list with no per-row reasoning is inconclusive, not a pass.
+
+## The rubric is necessary, not sufficient
+
+- For an L1 change, the rubric review plus the recorded challenge row and behavioral-evidence row close the gate.
+- For an L2 change, a clean review is explicitly NOT enough on its own: automatic R0 (`references/r0-leakage-audit.md`), deterministic checks (`check-ccl-skills.sh`, `git diff --check`, the routing analyzer where applicable), and behavioral regression (≥1 should-trigger + ≥1 should-not-trigger) must also pass.
+- Treat any LLM reviewer output — supporting or critical — as hypothesis-grade: a "looks correct" does not raise the draft's evidence grade, and a finding stays valid until specifically verified or refuted (see the Core Rules on LLM-consultation evidence).