@ccoalm/ccl-skills 0.14.0 → 0.15.1

package/dist/assets/marketplace/plugins/ccl-skills/skills/platform-observability/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: platform-observability
-description: Use when designing, reviewing, debugging, or shipping observability — service logs, metrics, distributed tracing, log/trace correlation, dashboards, alerts, on-call routing（值班/排班 SOP、P0/P1 打断；发布值班/回滚除外）, SLI/SLO, error budgets — for a backend product. Owns the cross-cutting evidence layer — what signals must exist, what fields must propagate, what middleware must auto-wire, what verification proves a change is observable in production. Hand off mesh/routing/mTLS to `platform-service-connectivity`, release gates and rollback evidence to `platform-release-engineering`, service-internal architecture (HTTP/RPC/DB/queue) to `python-service-architecture` / `go-microservice-architecture`. Product-agnostic; do not depend on specific repository names, service names, hostnames, or business domains.
+description: Use when designing, reviewing, debugging, or shipping observability — service logs, metrics, distributed tracing, log/trace correlation, 给接口·服务加结构化日志与 trace 透传, dashboards, alerts, on-call routing（值班/排班 SOP、P0/P1 打断；发布值班/回滚除外）, SLI/SLO, error budgets, 线上是否已启用（开关·配置在生产的实际生效状态）— for a backend product. Owns the cross-cutting evidence layer — what signals must exist, what fields must propagate, what middleware must auto-wire, what verification proves a change is observable in production. Hand off mesh/routing/mTLS to `platform-service-connectivity`, release gates and rollback evidence to `platform-release-engineering`, service-internal architecture (HTTP/RPC/DB/queue) to `python-service-architecture` / `go-microservice-architecture`. Product-agnostic.
 ---
 
 # Platform Observability
@@ -30,7 +30,7 @@ Observability is the chain that turns one user action into searchable, joinable,
 2. **Instrumentation** — every service emits structured logs, metrics, and spans through the **framework default**, not ad-hoc code. A service whose middleware chain does not include `ctx_inject + metrics + recovery + tracing` is unobservable by design.
 3. **Transport** — logs go stdout → file collector (DaemonSet) → log pipeline → search index; metrics + traces go SDK → OTLP collector → metric store + trace store. Both transports must survive collector restarts and back-pressure.
 4. **Storage + display** — logs in a searchable index keyed by log-id and trace-id; metrics in a long-term store separate from scraper; traces queryable by trace-id; one dashboard tool joins all three.
-5. **Evidence consumption** — SLIs are queries against (3) + (4); alerts evaluate SLIs and route to on-call; runbooks live in a wiki that on-call can reach in under one minute.
+5. **Evidence consumption** — SLIs query (3) + (4); actionable alerts route to on-call; runbooks live in a wiki that on-call can reach in under one minute.
 
 A new service must satisfy all five before it is allowed in production. A release must produce evidence at all five before it is promoted.
 
@@ -106,9 +106,9 @@ Add domain fields with a prefix (e.g. `app_*`, `biz_*`) to avoid colliding with
 
 **Retrofit / migration contract** (the rules above are otherwise greenfield-framed): when a schema is introduced over EXISTING services, field names, metric label names, and identity env-var names are a **migration contract** — a blind rename breaks every deployed dashboard, alert, and saved query that keys on the old name. Retrofitting MUST alias or dual-write old→new and migrate consumers before retiring the old name; never rename in place. The cheap time to fix a name is before services adopt it.
 
-### R7 — Alerts are SLI-driven and route to a human
+### R7 — Alerts are actionable and route to an owner
 
-- Alerts evaluate against SLIs (query the long-term metric store), not raw metrics.
+- Use SLIs for SLO paging; actionable capacity or impending-failure alerts may use internal measurements. See `references/alerting-and-on-call.md`.
 - Severity levels: P0 (page on-call now), P1 (notify channel, ack within work hours), P2 (digest).
 - Every alert MUST link to a runbook entry. If no runbook exists, the alert is not allowed to be P0.
 - An alert-backed metric is a coverage contract, and the trigger is mechanical, not prose: any new or changed alert rule, SLO, dashboard alert annotation, or metric referenced by an alert policy fires this check (a written "alert on any increase" note also counts, but its absence is not an exemption). Enumerate every site that should feed the metric and verify each is actually instrumented — derive the site list from a static registry or lint where possible; the easiest site to miss is often the riskiest (e.g. the panic counter in a stream reader parsing untrusted bytes). Ship the site checklist with the alert.
@@ -208,7 +208,7 @@ If any phase has missing evidence, the work is not done.
 - **"Sample everything vs head-sample 1%"** → head-sample low (1–10%) for cost; retaining errors/slow requests is **tail** sampling at the Collector and requires near-full SDK export to it (head-dropped spans never arrive) — pick one model per service, do not claim both. Sampling-by-route is acceptable for known noisy paths.
 - **"Metrics egress: scrape vs push"** → each platform picks ONE canonical egress and every process uses it. A Prometheus-native platform may default to **scrape** (pull, with `up`/target-health + service discovery); an OTel-first platform, or workers/jobs/runtimes that can't be scraped, may default to **OTLP push** to a collector. Neither is universally better — don't overturn a working pull setup just to push. One egress per process for a given metric; a migration window may dual-write only with isolated pipelines / distinct metric names / a dedup plan. Long-term store stays separate from the short-term scrape/collect layer (R5).
 - **"Add a new label to a metric"** → answer the cardinality question first. If max distinct values × series count > 1e6, refuse and use an exemplar trace instead.
-- **"Alert on this symptom or that cause"** → alert on user-visible symptom; cause-based alerts produce paging spam.
+- **"Alert on this symptom or that cause"** → prefer user-visible symptoms; capacity or impending-failure warnings follow R7.
 
 ## Sanitization and Provenance
 

package/dist/assets/marketplace/plugins/ccl-skills/skills/platform-observability/references/alerting-and-on-call.md

@@ -1,5 +1,13 @@
 # Alerting and On-Call
 
+## Choose an actionable signal
+
+- **User symptoms and SLOs:** use service-level signals for user-symptom paging and the corresponding SLIs for SLO burn-rate alerts. Query the declared metric store; diagnostic counters do not become availability or latency SLIs merely because an alert uses them.
+- **Capacity and impending failures:** white-box measurements may warn before user SLIs degrade, such as a credible forecast of disk exhaustion. Record the expected failure, the evidence for the threshold or forecast, the action, and the responsible owner. Choose urgency from impact and time left to act; a high internal metric alone is not a reason to page.
+- **Diagnostic signals:** keep measurements with no actionable condition in dashboards or queries. Do not alert on every possible cause.
+
+Verify new or changed alert rules against relevant failure, healthy, and recovery cases. Preserve the severity, ownership, runbook, and delivery requirements below for both symptom and impending-failure alerts. [Google SRE's Monitoring Distributed Systems](https://sre.google/sre-book/monitoring-distributed-systems/) describes both user symptoms and imminent saturation as alerting inputs.
+
 ## Two patterns
 
 ### Pattern A — Prometheus AlertManager

package/dist/assets/marketplace/plugins/ccl-skills/skills/platform-release-engineering/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: platform-release-engineering
-description: 发布 / 灰度 / canary / rollback / rollout / 环境泳道 / promotion gate → design or review how a change moves from build to traffic and back safely, including rollout strategy, approval, rollback, secrets, config, and deploy control planes. Skip when the ask is the production release lifecycle — 上线范围确认 / 合并 main / 打 tag / 生产构建 / 发布后 reset → release-coordination; release document substance → release-doc-writer.
+description: 发布 / 灰度 / canary / rollback / rollout / 环境泳道 / promotion gate / 发布值班 SOP（P0·P1 打断排班、是否回滚）→ design or review how a change moves from build to traffic and back safely, including rollout strategy, approval, rollback, secrets, config, and deploy control planes. Skip when the ask is the production release lifecycle — 上线范围确认 / 合并 main / 打 tag / 生产构建 / 发布后 reset → release-coordination; release document substance → release-doc-writer.
 ---
 
 # Platform Release Engineering

package/dist/assets/marketplace/plugins/ccl-skills/skills/platform-service-connectivity/SKILL.md

@@ -100,10 +100,11 @@ Confusing these is the source of most "why doesn't this work" connectivity bugs.
 
 ### R4 — Default retry/timeout/circuit-breaker live at mesh, app overrides for business reasons
 
-- Mesh DestinationRule provides default per-callee policy: retries (1-2 attempts on 5xx/connect-fail), connect timeout, request timeout ceiling, outlier detection (5xx-percent → eject).
-- Framework client SDK provides per-call override: business timeout (always ≤ mesh ceiling), retry policy for idempotent calls, hedging.
+- On Istio HTTP/gRPC paths, `VirtualService` HTTP routes own request `timeout` and `retries`; `DestinationRule` owns connection-pool settings and `outlierDetection`. Other transports use their platform-owned equivalents.
+- Before configuring retries or timers, read `references/retry-timeout-circuit-breaker.md` for field paths, single-owner retry selection, and idempotency checks. Both mesh and SDK follow them; a 5xx or missing response alone never proves replay safe.
+- Framework client SDK may provide method-specific retry/hedging; its total call budget must fit the caller's remaining duration and any platform cap. A longer mesh timeout is a backstop, not an extended caller deadline.
 - App code MAY override per-RPC. App code MUST NOT silently disable mesh-level outlier detection.
-- Budget rule: total upstream timeout = caller deadline minus a safety margin (e.g. 100ms). Cascading timeouts must shrink down the call chain.
+- Budget rule: downstream work, attempts, and backoff fit the remaining duration minus a safety margin (e.g. 100ms). Propagate deadline and cancellation; never reset the full budget at each hop.
 
 ### R5 — mTLS is mesh-default, app cannot disable
 
@@ -151,14 +152,13 @@ The client middleware fills this from ctx automatically; the server middleware e
 
 For non-protobuf or metadata-only transports, an equivalent header set is compliant only when it cites a resolvable platform owner record, such as a repo/path, document URL, registry id, gateway policy, or owner-suite id. The owner record must enumerate the concrete header names. In diff-only review without resolver tooling, the diff must cite a stable owner-record locator and list the concrete header names inline; with resolver tooling, the reviewer or owner-suite may resolve the locator to those names instead. The enumerated header names must then be checked against the actual propagated and exposed headers: caller-supplied identity headers are absent unless positive authenticated-caller evidence exists. An unresolvable, non-enumerating, uncited, service-local, or unchecked header set is an open gap, not a permitted alternative. For pure HTTP (no RPC base), the equivalent is a stable owner-recorded header set, also filled by middleware.
 
-### R8 — gRPC `:authority` and DNS-label hyphenation
+### R8 — gRPC `:authority` compatibility follows the actual request path
 
-If the platform allows service names with underscores (`<owner>.<class>.<env>` containing `_`), gRPC will reject them in the HTTP/2 `:authority` pseudo-header because it must be a valid DNS label (no `_`). Two acceptable fixes:
+HTTP/2 `:authority` carries URI authority, not a single DNS label. An underscore alone does not prove a gRPC protocol violation. DNS hostnames, certificate identity checks, SDK validation, and proxy routing can impose different constraints; preserve the constraints of the deployed path.
 
-1. **Disallow underscores in new service names**; enforce in registry registration and CI.
-2. **Mesh-level rewrite**: an EnvoyFilter Lua snippet replaces `_` with `-` in `:authority` for gRPC requests, before routing.
+Before renaming a service or adding a rewrite, capture the failing request's authority, the rejecting layer and version, and the relevant error or trace. A platform may require DNS-compatible service names and enforce that policy at registration and CI, but a registry name need not be the wire authority.
 
-Option 1 is cleaner long-term; option 2 is the live-system workaround. Document which the platform uses; new services should follow option 1.
+A proxy rewrite is an option only when the request reaches that filter before the rejecting layer. It cannot fix a client rejection before transmission or an inbound parser rejection before the filter runs. Scope any verified rewrite to the affected traffic and explicit authority mappings; retain route, TLS identity, and authorization checks. Diagnosis, migration, and verification: `references/grpc-authority-workaround.md`.
 
 ### R9 — Ingress and egress are explicit, not implicit
 
@@ -200,8 +200,8 @@ Option 1 is cleaner long-term; option 2 is the live-system workaround. Document
 ### Phase B — Mesh policy
 
 1. PeerAuthentication = STRICT (mTLS namespace-wide).
-2. DestinationRule per critical callee: retry policy, timeouts, outlier detection.
-3. VirtualService rules express lane-based routing: lane header match → lane subset.
+2. DestinationRule per critical callee: connection-pool limits, connect timeout, outlier detection.
+3. VirtualService HTTP routes: lane header match → lane subset, request timeout, and the R4 retry policy.
 4. AuthorizationPolicy expresses which services may call which (zero-trust at network level).
 
 ### Phase C — Service discovery
@@ -216,7 +216,7 @@ Option 1 is cleaner long-term; option 2 is the live-system workaround. Document
 
 1. Read the framework default client/server options module. Confirm middleware chain matches R6.
 2. Confirm dev cannot build a client/server without inheriting these.
-3. Test: kill a downstream pod → verify mesh outlier-detection ejects, framework retry kicks in for idempotent calls, error propagates up with stable error-code.
+3. Test: induce the configured outlier threshold on one callee → verify ejection and recovery, the configured retry layer retries only eligible calls within its budget, and exhausted calls propagate a stable error-code.
 
 ### Phase E — Failure modes
 
@@ -234,7 +234,7 @@ Before marking work done:
 
 ## Decision Points
 
-- **"Add a new retry policy for service X"** → start at mesh DestinationRule. Move to framework client only if the retry depends on business idempotency knowledge.
+- **"Add a new retry policy for service X"** → apply R4's replay-safety and single-owner checks. Use the matching VirtualService HTTP route for Istio retries; disable and verify route retries when the SDK owns them. DestinationRule limits concurrent retries, not per-request attempts.
 - **"Service A times out calling Service B"** → check three layers in order: app deadline (ctx timeout) → framework client timeout → mesh request timeout. Whichever is smaller wins; align them.
 - **"Switch service discovery mode"** → use `references/service-discovery-choice.md`; do not mandate registry unless the platform needs registry-specific capabilities such as per-instance drain, out-of-cluster lookup, or existing registry federation.
 - **"Need mTLS to a non-mesh external service"** → egress gateway with terminating TLS, not app-managed certs.
@@ -257,7 +257,7 @@ Reused industry patterns (PSM-style identity, `<owner>.<class>.<env>` shape, `tr
 - `references/framework-middleware.md` — Server and client middleware chain (HTTP + RPC); the canonical RPC base struct shape; verification commands.
 - `references/multi-env-routing.md` — Lane label end-to-end recipe; VirtualService patterns; queue-boundary propagation; stress/shadow tags.
 - `references/retry-timeout-circuit-breaker.md` — Mesh defaults vs SDK overrides; cascading timeout budgets; idempotency awareness; outlier detection tuning.
-- `references/grpc-authority-workaround.md` — The `_` → `-` rewrite quirk; when it's needed; the cleaner long-term fix.
+- `references/grpc-authority-workaround.md` — Locate authority rejection; distinguish naming policy from protocol syntax; verify scoped compatibility changes.
 - `references/dual-sidecar-and-traffic-config-center.md` — Pod-level dual sidecar (mesh + platform), per-protocol mesh injection policy, per-caller-callee traffic config via config center (separate from mesh routing).
 - `references/rpc-framework-recipe.md` — Concrete kitex/hertz default suite: shared RPC base field contract, RPC base.Request full schema (8 fields incl From/To), dual-channel ctx propagation (metainfo + grpc metadata), 9-code error enum + framework error mapping table, three resolver strategies (registry / FQDN fallback / proxy), platform latency histogram buckets, CORS defaults exposing log-id header, server boot sequence with graceful shutdown.
 - `references/service-discovery-choice.md` — Decision framework: registry-based vs k8s-native SD; both support lane routing + canary + multi-env; pick by per-instance drain need, laptop access pattern, federation preference, operational burden; mixed mode (k8s east-west + thin registry for laptop) is workable; migration paths in both directions.
@@ -269,7 +269,7 @@ Reused industry patterns (PSM-style identity, `<owner>.<class>.<env>` shape, `tr
 
 1. **Static**: framework default options module includes all R6 middleware; mesh PeerAuthentication is STRICT; DestinationRule and VirtualService exist for every callee that participates in lane routing.
 2. **Live, identity**: cross-service trace shows log-id + lane consistent across all hops; mesh access log lines include both.
-3. **Live, mesh policy**: kill a callee pod → outlier detection ejects within outlier-detection interval; metrics show client-side error count rise then fall.
+3. **Live, mesh policy**: trigger the configured outlier threshold with an eligible pool size; verify ejection and recovery against the effective policy and metrics. Consecutive-error checks are inline, not delayed until the periodic analysis interval.
 4. **Live, lane routing**: send request with non-default lane → confirm only matching-lane instances serve it.
 5. **Static, no leakage**: grep this skill's content — zero internal hostnames, repo names, or business terms.
 

package/dist/assets/marketplace/plugins/ccl-skills/skills/platform-service-connectivity/references/dual-sidecar-and-traffic-config-center.md

@@ -36,7 +36,7 @@ Mesh injection is not all-or-nothing. Real platforms apply per-protocol policy:
 | App protocol | Inject Istio sidecar? | Reason |
 |---|---|---|
 | HTTP (REST) | YES | Envoy handles HTTP/1.1, HTTP/2; full feature support |
-| gRPC | YES | HTTP/2 + per-call routing; needs `:authority` quirk handling |
+| gRPC | YES | HTTP/2 + per-call routing; verify `:authority` routing against the actual SDK/proxy path |
 | TCP (raw) | NO (often) | Envoy TCP proxy is feature-poor; routing/auth less useful at L4 |
 | Thrift (TTHeader) | NO (often) | Same — L4-ish; tooling limited |
 

package/dist/assets/marketplace/plugins/ccl-skills/skills/platform-service-connectivity/references/grpc-authority-workaround.md

@@ -1,90 +1,47 @@
-# gRPC `:authority` and DNS-Label Hyphenation
-
-## The quirk
-
-HTTP/2's `:authority` pseudo-header (which carries the host of a gRPC request) is parsed strictly. RFC 1035 says DNS labels can contain letters, digits, and hyphens — but NOT underscores.
-
-Many platforms use PSM-style service names like `<owner>.<class>.<env>`. When any segment contains underscores (e.g. an env segment named `prod_v2` or a feature-flagged variant `payments.ledger.prod_2024`), the SDK puts that name into `:authority`. Envoy / strict gRPC implementations reject the request:
-
-```
-RST_STREAM with INTERNAL_ERROR
-```
-
-You lose the connection on every call. Frustrating to debug because it looks like network failure.
-
-## Two fixes
-
-### Fix 1 (clean, long-term): forbid underscores in service names
-
-- Naming policy: service name = lowercase, dot-separated segments, hyphens within segments allowed, underscores forbidden.
-- Enforce at registry registration (reject the registration).
-- Enforce at CI / lint when defining new services.
-- Migrate existing names by renaming + parallel registration during a deprecation window.
-
-### Fix 2 (live-system workaround): mesh-level rewrite
-
-When you can't break existing names, an Envoy Lua filter rewrites `:authority` on the fly:
-
-```yaml
-apiVersion: networking.istio.io/v1alpha3
-kind: EnvoyFilter
-metadata:
-  name: modify-grpc-authority
-  namespace: istio-system
-spec:
-  configPatches:
-    - applyTo: HTTP_FILTER
-      match:
-        context: ANY
-        listener:
-          filterChain:
-            filter:
-              name: "envoy.filters.network.http_connection_manager"
-      patch:
-        operation: INSERT_BEFORE
-        value:
-          name: envoy.filters.http.lua
-          typed_config:
-            "@type": type.googleapis.com/envoy.extensions.filters.http.lua.v3.Lua
-            inlineCode: |
-              function envoy_on_request(request_handle)
-                local authority = request_handle:headers():get(":authority")
-                local content_type = request_handle:headers():get("content-type")
-                if authority and content_type and string.find(content_type, "application/grpc") then
-                  local modified_authority = string.gsub(authority, "_", "-")
-                  request_handle:headers():replace(":authority", modified_authority)
-                end
-              end
-```
-
-Effects:
-- Applies to gRPC traffic only (content-type check).
-- Rewrites `_` to `-` in `:authority`.
-- Callee's registry instance name must also use the `-` form so routing matches.
-
-## When to use which
-
-| Situation | Fix |
+# gRPC Authority Compatibility
+
+## Separate the names and constraints
+
+HTTP/2 `:authority` conveys the target URI's authority, as defined by [RFC 9113 §8.3.1](https://www.rfc-editor.org/rfc/rfc9113.html#section-8.3.1). [RFC 3986 §3.2.2](https://www.rfc-editor.org/rfc/rfc3986.html#section-3.2.2) permits a registered name containing unreserved characters, including `_`. This syntax does not guarantee DNS resolution, certificate identity matching, or acceptance by every SDK and proxy version.
+
+Keep these values distinct when diagnosing a request:
+
+- Service-registry identifier and resolved network endpoint.
+- HTTP/2 authority used for virtual-host routing.
+- TLS server name and the certificate identity expected on each TLS hop.
+- Platform naming, routing, and authorization policies.
+
+A platform can require DNS-compatible service names and enforce that choice at registration and CI. Existing identifiers do not require migration merely because they contain an underscore; first establish which constraint the actual path violates.
+
+## Locate the rejection before choosing a fix
+
+Record the runtime/SDK, proxy versions and relevant configuration, exact authority, and the failing run's error or trace. Use a synthetic payload and redact credentials from captured evidence.
+
+| Observed boundary | Next action |
 |---|---|
-| Greenfield platform | Fix 1 — naming policy from day one |
-| Mature platform, many existing names | Fix 2 — buy time, then schedule Fix 1 migration |
-| Mixed HTTP + gRPC for same service | Fix 2 — HTTP tolerates `_`, gRPC doesn't; rewrite only at gRPC layer |
-| Service-mesh-less (direct gRPC) | Fix 1 only — no Envoy to rewrite |
+| Authority syntax is malformed | Validate URI authority syntax, including brackets around an IPv6 literal, before changing service registration or routing. |
+| Client rejects before transmitting HTTP/2 headers | Check that client's authority validation and supported configuration. Fix the client-side mapping or naming contract; a downstream proxy cannot rewrite a request it never receives. |
+| DNS resolution fails | Check the resolved hostname and resolver's naming rules. Changing a later HTTP header does not repair failed resolution. |
+| TLS handshake or certificate identity check fails | Check that hop's endpoint, server name, trust chain, and certificate identities. Retain verification; changing authority is not evidence that TLS is fixed. |
+| Proxy/parser rejects before the HTTP filter runs | Fix the supported parser/input contract or an earlier owned mapping. A Lua filter after the rejection cannot intervene. |
+| Request reaches HTTP filters, then the intended virtual-host route does not match | Compare the received authority with the generated route configuration. A supported authority mapping may be appropriate after proving the mismatch. |
+| Existing path accepts the name and reaches the intended service | Preserve it unless a separate platform naming-policy migration is required. |
 
-## Verification
+`RST_STREAM` or `INTERNAL_ERROR` alone does not identify an underscore problem. Confirm the first rejecting layer rather than treating every transport failure as the same naming defect.
 
-Fix 1:
-- Registry rejects registration with `_` in name.
-- Linter / CI rejects PR adding such a name.
+## Choose a bounded compatibility change
 
-Fix 2:
-- Synthetic gRPC call to `<svc>_<env>` → inspect Envoy access log `:authority` field → expect `<svc>-<env>`.
-- Callee's access log `host` shows the rewritten form.
+**Naming policy or client mapping.** Where a DNS-compatible name is required, define the allowed form and the mapping from registry identity to endpoint/authority. Check uniqueness before migration: replacing `_` with `-` can collapse two distinct names. Migrate registrations, routes, and callers together with a compatibility window and rollback path. Use supported client options; do not bypass certificate or authorization checks to make a name work.
+
+**Proxy mapping.** Use only if the request reaches the chosen filter and the mapping addresses a reproduced failure. Prefer the platform's supported routing mechanism. If an EnvoyFilter is necessary, verify the installed Istio/Envoy API and generated configuration, and scope it to the affected workloads, listener/direction, route, and explicit old-to-new authority mapping. Do not install an all-workload, all-direction underscore replacement. The mapping must preserve the intended destination, tenant/lane routing, authorization, and TLS identity on each hop; rewriting a header does not itself update those contracts.
+
+## Verification
 
-## Common variants of the same bug
+Retain the original failing case and expected rejecting layer. After the change, verify:
 
-- HTTP/2 SETTINGS frame rejection on cert SAN mismatch (separate issue, but presents similarly — RST_STREAM with INTERNAL_ERROR).
-- gRPC `:scheme` set to `http` while upstream expects `https` (mTLS mismatch).
-- IPv6 literal in `:authority` not bracketed.
+1. The same request succeeds through the intended path and reaches the intended service; observe authority before/after any mapping and the selected route.
+2. Unrelated authorities and non-target traffic retain their behavior. Include potentially colliding names and unknown authorities as negative controls.
+3. Certificate identity and authorization failures still reject requests; the compatibility change has not disabled those checks.
+4. Registration/client/route changes can be rolled back together without sending traffic to another service.
 
-The Lua rewrite filter is the right tool for the underscore case; do not generalize it to all of the above. Each bug has its own fix.
+Static configuration validation proves only configuration properties. Claims about a deployed SDK/proxy path require execution evidence from that path.

package/dist/assets/marketplace/plugins/ccl-skills/skills/platform-service-connectivity/references/mesh-architecture.md

@@ -33,7 +33,7 @@ Reference topology and component rules. Istio is the recurring example; rules ge
 
 ## Istio Ambient Mode (GA Nov 2024, v1.24+)
 
-- **Istio Ambient Mode reached General Availability in Istio v1.24 (announced November 2024)** per `istio.io/latest/blog/2024/ambient-reaches-ga/` — `ztunnel` + `waypoint` architecture is the stable sidecar alternative for new production mesh deployments. **Two-layer split**: `ztunnel` (Rust-based DaemonSet, one per node, L4-only — mTLS + simple L4 authz + telemetry) handles every pod's transport-layer mesh participation without per-pod sidecar injection; `waypoint` proxies (Envoy-based, scaled independently from app workloads) handle L7 features when needed (rich authz, traffic routing, resilience). Per Istio's own reported numbers, the architecture can save 90%+ memory/CPU vs the sidecar model in dense-pod-per-node workloads (Istio's claim — re-measure on the team's actual workload before quoting savings). **Architecture choice for new mesh**: (a) **choose ambient** when memory/CPU per pod is the binding constraint, sidecar injection causes restart cycles the team wants to avoid, or a subset of namespaces don't need L7 features at all; (b) **stay on sidecar mode** when the team has deep sidecar-specific tooling (custom `EnvoyFilter`s injected per pod, sidecar-aware debugging recipes, app code that expects `localhost:15001` proxy conventions), or when ambient's narrower L7-feature coverage hits a gap the team relies on. **Mixed-mode in one cluster is officially supported** per the Istio docs: sidecar-mode namespaces and ambient-mode namespaces coexist; migration can be incremental namespace-by-namespace. **CRITICAL migration block: AuthorizationPolicy enforcement loss when flipping a namespace from sidecar to ambient without waypoint** — sidecar mode enforces full L7 `AuthorizationPolicy` rules (HTTP method, path, header, JWT claims) at the per-pod proxy. In ambient mode, ztunnel alone enforces only L4-level policy (workload identity, port); any L7-condition rule (`request.method`, `request.headers[...]`, `request.path`, `request.auth.claims[...]`) silently DOES NOT MATCH on ambient-mode pods until a waypoint proxy is deployed for the namespace/service and the policy is targeted at the waypoint. The failure shape: team flips `istio.io/dataplane-mode=ambient` label, sidecar comes down, ztunnel takes over L4, and every L7 authz policy stops gating traffic — without a visible error, because L4 policy still works. **Pre-flip gate**: inventory every `AuthorizationPolicy` targeting workloads in the namespace, identify the ones using L7 conditions, ensure a waypoint is deployed and the policy `targetRefs` is set to the waypoint (not the workload) BEFORE flipping the namespace label. Validate by re-running the authz integration tests against the ambient-mode namespace before completing the migration. **Observability shift**: ztunnel emits L4 metrics; waypoint emits L7 metrics; existing dashboards keyed on sidecar `istio_requests_total` need a ambient-mode equivalent for the L7-routed traffic — route this update through `platform-observability` rather than redesigning here.
+- **Istio Ambient Mode reached General Availability in Istio v1.24 (announced November 2024)** per `istio.io/latest/blog/2024/ambient-reaches-ga/` — `ztunnel` + `waypoint` architecture is the stable sidecar alternative for new production mesh deployments. **Two-layer split**: `ztunnel` (Rust-based DaemonSet, one per node, L4-only — mTLS + simple L4 authz + telemetry) handles every pod's transport-layer mesh participation without per-pod sidecar injection; `waypoint` proxies (Envoy-based, scaled independently from app workloads) handle L7 features when needed (rich authz, traffic routing, resilience). Per Istio's own reported numbers, the architecture can save 90%+ memory/CPU vs the sidecar model in dense-pod-per-node workloads (Istio's claim — re-measure on the team's actual workload before quoting savings). **Architecture choice for new mesh**: (a) **choose ambient** when memory/CPU per pod is the binding constraint, sidecar injection causes restart cycles the team wants to avoid, or a subset of namespaces don't need L7 features at all; (b) **stay on sidecar mode** when the team has deep sidecar-specific tooling (custom `EnvoyFilter`s injected per pod, sidecar-aware debugging recipes, app code that expects `localhost:15001` proxy conventions), or when ambient's narrower L7-feature coverage hits a gap the team relies on. **Mixed-mode in one cluster is officially supported** per the Istio docs: sidecar-mode namespaces and ambient-mode namespaces coexist; migration can be incremental namespace-by-namespace. **CRITICAL migration block: L7 policy enforcement changes when moving from sidecar to ambient.** Ztunnel enforces only L4 policy. A workload-selector policy containing L7 conditions that is picked up by ztunnel [fails safe as a DENY policy](https://istio.io/latest/docs/ambient/usage/l4-policy/#policies-with-layer-7-conditions), potentially blocking legitimate traffic. L7 enforcement requires a waypoint and `targetRefs` bound to the intended Service or waypoint Gateway; deploying a waypoint alone does not migrate selector-based policies. **Pre-flip gate**: inventory affected authorization policies, prepare the waypoint and correctly scoped bindings, and plan the old-policy/pod-restart transition using the deployed version's [migration guide](https://istio.io/latest/docs/ambient/migrate/migrate-policies/). Preserve mTLS and L4 authorization; do not remove a rejecting policy merely to restore connectivity. Verify allowed, denied, and waypoint-bypass paths before completing migration. If the transition cannot maintain required L7 protection, hold migration or use an approved maintenance window. **Observability shift**: ztunnel emits L4 metrics; waypoint emits L7 metrics; existing dashboards keyed on sidecar `istio_requests_total` need a ambient-mode equivalent for the L7-routed traffic — route this update through `platform-observability` rather than redesigning here.
 
 ## Sidecar injection rules
 
@@ -94,7 +94,7 @@ Egress gateway is OFF by default. Turn ON only when a workload needs controlled
 EnvoyFilter is the escape hatch. Use sparingly; each filter is hard to test and easy to break across Envoy upgrades.
 
 Acceptable uses:
-- Header rewrite for protocol quirks (e.g. gRPC `:authority` hyphenation — see `grpc-authority-workaround.md`).
+- Header mapping for a reproduced compatibility failure, scoped to the affected workloads and explicit names while preserving routing, TLS, and authorization (see `grpc-authority-workaround.md`).
 - Adding a Lua filter for one-off business handling that doesn't yet have a first-class WASM filter.
 - Custom rate-limit before the canonical RLS is rolled out.
 

package/dist/assets/marketplace/plugins/ccl-skills/skills/platform-service-connectivity/references/retry-timeout-circuit-breaker.md

@@ -1,48 +1,48 @@
 # Retry, Timeout, Circuit Breaker
 
-Where each policy lives, how they compose, and how to keep them from killing each other.
+Where each policy lives, how timeouts compose, and how to bound retry amplification. Istio field names below apply to Istio HTTP/gRPC paths; other transports keep their platform-owned equivalents.
 
 ## Layered policy
 
-For a single call A → B, four policies can fire:
+For a single call A → B, several independent timers can end the call:
 
-```
-App business deadline             ← ctx.Deadline; "this user can wait at most 800ms"
-   ⊇
-Framework client per-call budget   ← SDK option; "give this call 500ms"
-   ⊇
-Mesh transport timeout (ceiling)   ← DestinationRule; "any call to B caps at 2s"
-   ⊇
-TCP/HTTP2 connect + idle timeouts  ← Envoy defaults; rarely tuned
-```
+| Timer | Owner | Example |
+|---|---|---|
+| Caller deadline | App context | 800ms remaining |
+| Total client-call budget | Framework client | 500ms, including retries and backoff |
+| Mesh request timeout | VirtualService HTTP route `timeout` | 2s platform cap |
+| Per-attempt timeout | VirtualService HTTP route `retries.perTryTimeout`, or the retry-owning SDK | Must fit the remaining call budget |
+| Connection / idle timeout | DestinationRule connection pool / transport | Bounds connection setup or inactivity, not total business work |
 
-Each outer policy must be ≥ the next inner one. Inversions cause "request succeeded internally but caller already returned timeout" — a hard-to-debug class.
+The earliest applicable expiry wins. With the example values measured from call start, the client ends the call at 500ms; the 2s mesh cap can remain a platform backstop. These are not nested durations that must decrease from client to mesh. Propagate cancellation so downstream work stops when the caller's budget expires; a longer transport cap does not extend the caller's deadline.
+
+Istio's [HTTPRoute and HTTPRetry fields](https://istio.io/latest/docs/reference/config/networking/virtual-service/) own request/attempt timeout and request retries. [DestinationRule connection-pool settings](https://istio.io/latest/docs/reference/config/networking/destination-rule/) own connection timeouts and concurrent-retry limits; its traffic policy owns outlier detection.
 
 ## Timeout budget rule
 
 For a chain A → B → C:
 
 ```
-A.ctx.deadline = D
-A's client-to-B budget    ≤ D - margin                   (margin: 50-100ms for serialization)
-B's internal work         ≤ (B-budget - C-budget)
-B's client-to-C budget    ≤ B-budget - margin
+A's remaining duration = A.ctx.deadline - now
+A's client-to-B budget  ≤ remaining duration - margin   (e.g. 50-100ms for serialization)
+B's client-to-C budget  ≤ B's remaining duration - margin
+All sequential work, attempts, and backoff fit within that remaining budget
 ```
 
-A framework helper should compute "remaining ctx deadline" and pass `min(ctx.Deadline, my-budget)` to outbound calls.
+A framework helper computes `min(remaining_duration - margin, configured_call_budget, applicable_platform_cap)`. If no usable duration remains, fail without dispatching another attempt. Pass the resulting deadline downstream and recompute the remainder after work or backoff; do not compare an absolute deadline with a duration or restart the full budget at each hop.
 
 ## Retry placement
 
 | Layer | Retries WHAT | When |
 |---|---|---|
-| Mesh (DestinationRule) | network errors, gRPC `UNAVAILABLE`, certain 5xx | Always-safe-to-retry transports |
+| Mesh (VirtualService HTTP route) | Explicitly selected network errors or response statuses | Declared idempotent calls, or failures proven to precede server receipt |
 | Framework client | idempotent business RPCs | Per-method opt-in |
 | App handler | nothing | App level retry usually wrong |
 | App business logic | high-level workflows | Saga / orchestration patterns, not "I'll retry the call once" |
 
-Double retry = real bad. If mesh retries 2x and framework retries 2x, you get 4x amplification on every flapping backend.
+Retry layers multiply total attempts. If mesh and framework each make at most two total attempts, one logical call can reach the backend four times. Istio `retries.attempts` counts retries after the initial request: a value of 2 permits up to 3 total attempts, subject to time and retry budgets.
 
-**Rule**: when enabling framework-level retry, disable mesh retry for that callee (DestinationRule `retries.attempts: 0`).
+**Rule**: when enabling framework-level retry, set `retries.attempts: 0` on every matching VirtualService HTTP route used by that call and verify the effective generated route configuration. Keep DestinationRule connection limits and outlier detection; they do not replace the route-level retry switch.
 
 Mesh retries back off automatically (Istio/Envoy: jittered exponential backoff with a default 25ms *base* interval — fully jittered, so an actual delay can be shorter than the base; it is not a guaranteed minimum gap); framework-level retry gets no such freebie — it must implement its own jittered backoff that fits inside the caller's remaining deadline.
 
@@ -51,24 +51,24 @@ Mesh retries back off automatically (Istio/Envoy: jittered exponential backoff w
 Per-call retry counts bound retries *per request*; they do not bound a caller's total retry share during a partial outage — at high QPS, "2 retries each" is up to a 3× load multiplier at the exact moment the upstream is sickest. Envoy's cluster circuit breakers cap this per proxy:
 
 - `max_retries` — max **concurrent** retries to the cluster, per priority. Retries beyond it overflow (fail fast, counted in `upstream_rq_retry_overflow`). The raw Envoy default is 3, but the control plane above Envoy may override it: Istio's `connectionPool.http.maxRetries` defaults to **2^32-1 — effectively unlimited** — so in an Istio mesh "leave it unset and rely on the default cap" is a trap. Set the limit explicitly and verify the *generated* Envoy cluster config, not the assumption.
-- `retry_budget` — replaces the fixed cap with a load-proportional one: concurrent retries ≤ `budget_percent` (default 20%) of active + pending requests, with a `min_retry_concurrency` floor so low-traffic clusters can still retry. When set, it overrides `max_retries`. Reachability caveat: Istio's DestinationRule API exposes only `connectionPool.http.maxRetries`, NOT `retry_budget` — on plain Istio, set a finite `maxRetries` first; adopting `retry_budget` there means an EnvoyFilter, acceptable only with the *generated* cluster config verified.
+- `retry_budget` — replaces the fixed cap with a load-proportional one: in the default instantaneous mode, concurrent retries ≤ `budget_percent` (default 20%) of active + pending requests, with a `min_retry_concurrency` floor so low-traffic clusters can still retry. Versions exposing a non-zero `budget_interval` can count requests over that interval instead; verify the configured version and mode. When set, the budget overrides `max_retries`. Reachability caveat: Istio's DestinationRule API exposes only `connectionPool.http.maxRetries`, NOT `retry_budget` — on plain Istio, set a finite `maxRetries` first; adopting `retry_budget` there means an EnvoyFilter, acceptable only with the *generated* cluster config verified.
 - Know exactly what the budget bounds — and what it doesn't. It bounds **Envoy-originated, concurrent** retries, per proxy. It does NOT bound: retry attempt *rate*; **framework-level retries** (each framework attempt arrives at Envoy as a fresh request and bypasses `max_retries`/`retry_budget` entirely — a platform running framework retries needs a framework-side budget or strict per-call caps); or the **fleet aggregate** (circuit breaking is distributed, not coordinated — each sidecar enforces its own budget and floor, so aggregate retry load still scales with caller replica count). A true service-wide load bound requires callee-side protection (admission control / load shedding, owned by the service-architecture skills) on top.
 - When tuning for a flaky dependency, set a retry budget rather than raising per-call retry counts — but pick `budget_percent` AND `min_retry_concurrency` deliberately against the callee's capacity: on a very high-QPS caller, an unexamined 20% of active requests is far looser than `max_retries: 3`, and with many low-traffic sidecars the aggregate floor (≈ replicas × `min_retry_concurrency`) dominates instead. Alert on the overflow counter: a growing overflow stat means callers are shedding retries, which is the budget doing its job; do not "fix" it by raising the cap.
 
 ## Idempotency awareness
 
-Framework client retries MUST consider idempotency:
+Both mesh and framework client retries MUST consider idempotency:
 
 ```
 RPC method declares "idempotent: true" in IDL or annotation
    ↓
-SDK retry middleware reads this; only retries idempotent methods
+The retry-owning layer applies a policy only to methods covered by that declaration
    ↓
 Non-idempotent retry happens only if the network error proves the request didn't reach the server
 (connect refused, TLS handshake failure — yes; "request sent, no response" — no)
 ```
 
-Don't trust HTTP method (POST can be idempotent; GET can have side effects). Trust the declaration.
+Don't trust HTTP method (POST can be idempotent; GET can have side effects). Trust the declaration. A 5xx, gRPC `UNAVAILABLE`, timeout, or missing response alone does not prove that a write was not applied. If the mesh cannot distinguish safe methods, keep its request retries disabled and let the method-aware SDK own the policy.
 
 ## Circuit breaker / outlier detection
 
@@ -78,12 +78,12 @@ Mesh outlier-detection (Envoy):
 trafficPolicy:
   outlierDetection:
     consecutive5xxErrors: 5         # 5 consecutive 5xx → eject this pod
-    interval: 10s                   # check every 10s
+    interval: 10s                   # periodic ejection analysis / recovery sweep
     baseEjectionTime: 30s           # eject for 30s minimum
     maxEjectionPercent: 50          # never eject more than 50% of pool
 ```
 
-This is the right place for circuit breaking. Per-host, automatic, observable via Envoy stats.
+For a meshed path, this provides per-host ejection observable through Envoy stats. [Envoy's ejection algorithm](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/outlier) checks consecutive-error thresholds inline; periodic analyses use `interval`. An ejection also depends on the configured threshold/enforcement and pool limits. Killing a pod once does not prove those conditions fired.
 
 Framework SDK circuit breakers (e.g. hystrix-style) are a fallback for environments without mesh, or for business-logic-driven breaking (e.g. "this dependency's error rate hit 10%, switch to degraded mode").
 
@@ -91,36 +91,40 @@ Don't run mesh outlier-detection AND SDK circuit breaker simultaneously without
 
 ## Cascading cancel
 
-When a caller's ctx is cancelled (deadline, client disconnect, user back-button), the cancel MUST propagate to in-flight downstream calls. Frameworks should support this natively; verify by spawning a long-running downstream call and cancelling the parent — both should terminate.
+When a caller's ctx is cancelled (deadline, client disconnect, user back-button), propagate it to in-flight downstream calls. [gRPC cancellation](https://grpc.io/docs/guides/cancellation/) requires application handlers to cooperate; outgoing-call propagation also depends on the language/runtime. Verify cancellation reaches the handler, stops its work and child calls, and releases resources within the service's documented cancellation bound. A transport cancellation signal alone does not prove application work stopped.
 
 If a service swallows ctx cancel, downstream load amplifies during user disconnects (every abandoned tab continues hammering the DB).
 
 ## Hedging
 
-Hedging = send a second request after a timeout T, return whichever responds first. Useful for latency-sensitive read APIs.
+Hedging sends an additional request while the first is still in flight and returns the first acceptable response. It can reduce tail latency for idempotent reads, at the cost of concurrent upstream work.
 
 Risks:
 - Doubles load if T is too short.
 - Not safe for non-idempotent calls.
-- Mesh-level hedging is preferred (e.g. Envoy `retry_priority` patterns); SDK hedging is workable but harder to tune.
+- Bound concurrent attempts, total deadline and admitted load; cancel losing attempts after choosing a response and propagate caller cancellation.
+- Envoy's [HedgePolicy](https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/route/v3/route_components.proto#config-route-v3-hedgepolicy) uses `hedge_policy.hedge_on_per_try_timeout` with a finite per-try timeout and a retry policy containing retry conditions and a positive retry limit. `retry_priority` selects upstream priorities; it does not enable hedging.
+- Istio's HTTPRetry API does not expose a hedging field. Use an explicitly supported platform mechanism (such as an EnvoyFilter with generated-route and runtime verification), or a method-aware SDK; do not infer hedging from `perTryTimeout` alone. Keep a single retry/hedge owner.
 
 Default: off. Enable per-method after measuring p99 latency distribution.
 
 ## Common mistakes
 
-- Setting framework client timeout > mesh timeout → client never sees mesh-side errors, retries the same call, mesh times out anyway. Align them.
-- Retrying on 4xx → client errors don't fix themselves; you just amplify load.
+- Treating a shorter mesh timeout as invisible to the client → the client can receive a mesh timeout response before its own deadline. Verify error mapping and the retry-owning layer; do not turn that response into an unsafe replay.
+- Retrying every 4xx → permanent client errors do not fix themselves. Only a documented transient condition, such as a rate-limit response with a bounded retry delay, may be eligible under the idempotency and remaining-budget rules.
 - Retrying with exponential backoff while caller deadline is 200ms → backoff exceeds deadline, retry never fires, you wasted code.
-- Mesh retry + SDK retry both on, both default 3 → 9 actual attempts per logical call.
+- Mesh and SDK each allow 3 retries after the initial request → up to 16 backend attempts per logical call, before deadline/budget limits.
 - Circuit breaker tripped but no metric → debugging blind.
 
 ## Tuning starting points
 
-| Policy | Default |
+These are example starting points for eligible traffic, not vendor defaults or a mandate to enable retries. Apply the idempotency and single-owner rules first.
+
+| Policy | Starting point |
 |---|---|
 | Mesh request timeout | 5s (HTTP), 10s (RPC); per-callee override |
-| Mesh retry attempts | 2 |
-| Mesh retry per-try timeout | 1s |
+| Mesh retry attempts | 0 unless mesh owns safe retries; then up to 2 retries within the call budget |
+| Mesh retry per-try timeout | Fit within the remaining call budget; reserve time for backoff and any later attempt |
 | Mesh outlier detection | 5 consecutive 5xx, 30s eject |
 | Framework client per-call budget | 500ms or shrunk from ctx deadline |
 | Framework client retry | OFF by default; opt-in per idempotent method |
@@ -130,6 +134,9 @@ Tune from observed p99 + error rate, not vibes.
 ## Verification
 
 - Trigger downstream 5xx storm → mesh outlier-detection metrics show ejection events; client-side error rate spikes then recovers.
-- Force a connect refusal → mesh retry attempts visible in mesh metric; final caller sees one error.
+- Force a connect refusal → only the configured retry owner produces attempts, counts fit its budget, and the final caller sees one error. With SDK-owned retries, confirm effective route retries are disabled.
 - Set per-call timeout below mesh ceiling → confirm caller sees its own deadline, not mesh's.
-- Cancel a request mid-flight → confirm downstream stops within one network round-trip.
+- Set mesh request timeout below the client budget → confirm the mapped mesh error is visible and does not trigger a second, unintended retry layer.
+- For a non-idempotent write with a lost response, confirm neither layer blindly replays it.
+- With hedging enabled, delay an eligible call past the per-try timeout → confirm bounded concurrent attempts, first acceptable response selection, loser cancellation, and no second retry/hedge owner.
+- Cancel a request mid-flight → confirm handler work and downstream calls stop and resources release within the declared cancellation bound.

package/dist/assets/marketplace/plugins/ccl-skills/skills/platform-service-connectivity/references/service-discovery-recipe.md

@@ -79,7 +79,7 @@ The framework client resolver:
 ## Cross-language registration
 
 If services span Go, Python, Java, Node: every language SDK must agree on:
-- Service name shape (lowercase, dot-separated, no underscores if gRPC is in scope — see `grpc-authority-workaround.md`).
+- Service name shape and its mapping to endpoint, authority, and TLS identity. Apply the agreed platform naming policy and actual DNS/SDK/proxy constraints; gRPC alone does not require renaming an existing working identifier (see `grpc-authority-workaround.md`).
 - Tag key names (`lane`, not `env`; pick one).
 - Heartbeat interval and TTL.
 - Health state semantics.

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

@@ -1,6 +1,6 @@
 ---
 name: product-rd-workflow
-description: 加功能 / 新需求 / 技术方案 / 方案评估 / 技术选型 / 可行性评估 / 工作量评估 / 多阶段重构 / 推倒重来 / 重新开发 / 完全重新开始 / 清除代码重新开发 / redo-from-scratch / 项目分析 / spec·PRD·需求文档实质内容写错要改对（substance 修正） / 方案评审通过开始实现 / 进入实现阶段 → end-to-end product R&D router for requirement shaping, spec/plan, implementation gates, assessment, redo/refactor, and multi-stack standards.
+description: 加功能/新需求/技术方案/方案评估/技术选型/可行性评估/工作量评估/多阶段重构/推倒重来/重新开发/完全重新开始/清除代码重新开发/redo-from-scratch/继续之前的重构·开发/resume-in-flight-delivery/项目分析/无架构兄弟栈的服务边界·数据归属/service-boundary-data-ownership/spec·PRD·需求文档实质内容写错要改对（substance 修正）/方案评审通过·进入实现阶段 → end-to-end product R&D router for requirement shaping, spec/plan, implementation gates, assessment, redo/refactor, and multi-stack standards.
 ---
 
 # Product R&D Workflow
@@ -43,7 +43,7 @@ Use this skill as the top-level workflow for new product development, feature de
 - Skill/process extraction: when asked to summarize delivery experience, preserve a workflow lesson, update a reusable skill, or decide where a lesson belongs, route to `skill-extraction-workflow` first. Update this skill only when the lesson changes product R&D routing, gates, ownership, or lifecycle policy.
 - Upstream decision propagation: when architecture, design, testing strategy, release, observability, security, or product workflow guidance changes, treat the next R&D slice as incomplete until the downstream execution owners are named. Confirm which implementation skill, test/review skill, and release or docs owner must apply the decision, or route the gap through `skill-extraction-workflow`.
 - Text artifact quality: when this workflow creates or updates a SOP, template, checklist, report, Feishu/Lark doc, task card, launch material, or other deliverable text, run `tighten-doc` before sharing, syncing, committing, or publishing. Do not ask the user for a separate optimization confirmation unless substantive decisions may change or collaborative-comment safety is at risk.
-- Product R&D standards docs: when creating or updating team development standards, stack guidelines, testing standards, engineering norms, or a multi-doc handbook that belongs to the R&D lifecycle, use the R&D standards checklist in Workflow. Cross-stack or cross-service product Specs live in one authority surface; stack/service repositories keep execution slices and links back to that authority instead of redefining product goals. A multi-stack standards family must include a testing standard owned by `testing-strategy`; stack docs specialize commands and harness mechanics but do not replace the shared test-layer and CI-gate policy. For standalone wording, editing, or polishing requests with no R&D routing decision, use `tighten-doc` directly. Authority/sync-gate and testing-standard detail: `references/rd-standards-doc-family-checklist.md`.
+- Product R&D standards docs: when creating or updating team development standards, stack guidelines, testing standards, engineering norms, or a multi-doc handbook that belongs to the R&D lifecycle, you must use the R&D standards checklist in Workflow. For standalone wording, editing, or polishing requests with no R&D routing decision, use `tighten-doc` directly. Authority/sync-gate and testing-standard detail: `references/rd-standards-doc-family-checklist.md`.
 - Standards-to-health-gate propagation: when a standards family is intended to check project compliance later, split each norm into deterministic checks and agent review checks, route the executable invariant model to `testing-strategy` fitness functions and the stack-specific mechanics to the owning dev/architecture skills, and do not leave conformance as a human-only checklist (mapping detail in `references/rd-standards-doc-family-checklist.md`).
 - High-risk resilience gating: when a feature touches money, billing, quota, permissions, tenant/user data isolation, privacy, high-impact AI answers, write-finality risk, repeated submission, async job finality, or incident explanation/compensation, require an explicit resilience gate before implementation or launch; do not escalate low-risk local edits only because they write files. Write-finality classification and gate detail: `references/high-risk-resilience-gates.md`.
 

package/dist/assets/marketplace/plugins/ccl-skills/skills/product-rd-workflow/references/delivery-lifecycle.md

@@ -180,7 +180,7 @@ Before release, confirm:
 | **Change Lead Time** | commit 到 prod 的时长 | — |
 | **Change Failure Rate (CFR)** | release 中需要 hotfix / rollback / fail forward 的比例 | — |
 | **Failed Deployment Recovery Time** | failed deployment 恢复时长 | 2023 年 DORA 重命名（原 MTTR）|
-| **Deployment Rework Rate** | release 后需要 rework 的比例 | 2024 年新增 |
+| **Deployment Rework Rate** | 由生产事故引发的非计划部署占全部部署的比例 | 2024 年新增；[当前 DORA 口径](https://dora.dev/guides/dora-metrics/) |
 
 Elite / High / Medium / Low 具体阈值**按当年 DORA Annual State of DevOps Report 取**（不同年份数字略有变化，本 ref 不固定数字以免过时）。