@ccoalm/ccl-skills 0.15.0 → 0.15.2

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

@@ -9,7 +9,7 @@ Use this skill as the top-level workflow for new product development, feature de
 
 **Entry precedence.** For any product idea, feature delivery, release, cross-cutting refactor, or a **restart/redo of an in-flight delivery**, invoke this workflow first to classify and route — naming a stack/execution skill (e.g. `web-react-dev`, `multi-agent-delegation`) does not by itself skip this workflow's lifecycle gates (design / test / release / acceptance); those still apply unless already covered.
 
-**Continuation-proposal output contract (session-wide for product delivery).** Every assistant message in a delivery session routed by or through this workflow carries exactly one literal line until the user explicitly ends/pauses the delivery or changes scope: `proposed-next: <action and scope>` when the message has imperative/future/next-step wording or a proposed action, otherwise `proposed-next: none — status only`. At the start of every subsequent user turn, read that line before interpreting the reply: absence, multiplicity, or a marker/wording conflict enters `blocked:`/`interim` by default, never `not-applicable`. Coverage detail and the host-layer caveat: `references/pre-final-continuation-gate.md` (Continuation-proposal output contract).
+**Continuation-proposal output contract (session-wide for product delivery).** Use `proposed-next: <action and scope>` to make a next action observable, or `proposed-next: none — status only` for a status-only handoff. A missing, repeated, or conflicting marker triggers intent recovery, not a stop. Follow the current explicit user request; bind short assent to one recoverable concrete proposal and its scope. Repair your own formatting without asking the user to repeat an already-clear instruction. Markers never grant authority. Recovery, ambiguity, and outcome rules: `references/pre-final-continuation-gate.md` (Continuation-proposal output contract).
 
 - **Restart/redo of an in-flight delivery** (清除代码重新开发 / 完全重新开始 / 推倒重来 / redo-from-scratch): a restart is a fresh delivery entry; mid-delivery coding momentum is NOT a license to skip re-classification and re-enter. Re-entry means re-ESTABLISH the plan and develop against it, not code from memory — "丢脚手架 / 重来" defaults to discarding CODE, not the design/spec artifact; discarding the design/spec itself needs an explicit user opt-out after clarification (an explicit instruction to drop the design always wins). Recovery mechanics and deviation recording live in `references/implementation-entry-reentry-gate.md` §Baseline Selection.
 - **Implementation entry / re-entry gate (active plan/spec required by default).** For product R&D deliveries that stay in this workflow, "start development" means first establish the current executable artifact set, then code against it; requests routed straight to another owning skill by the *Go straight to the owning skill* bullet below use that owner's entry rules instead. Use existing specs, implementation plans, assessment reports, issue/MR descriptions, or repo-local task docs only after reading them back or citing artifacts just produced in the active session, then checking freshness, scope, owner skills, acceptance checks, tests, stop conditions, and **landing state** (`local status`, `MR-ready`, `landed`, `release-ready`, or `shared-status-ready`). Full mechanics for every case below live in `references/implementation-entry-reentry-gate.md`.
@@ -164,7 +164,7 @@ At each stage boundary, walk the per-stage entry-state enumeration in [Stage-Ent
    - High-risk workflows cannot be accepted by happy-path tests alone. Require a risk scenario matrix and replayable incident drills for the relevant classes: duplicate money/quota/write side effects, permission uncertainty, tenant/user data isolation, AI provider/model failure, user repeated submission or unclear final state, and traceable incident explanation.
    - For UI backed by APIs or generated content, require `testing-strategy` to produce evidence that covers rendered states, contract/error handling, and one real visible flow where feasible. Do not let ideal mocked data stand in for runtime integration evidence.
    - When live infrastructure is required, keep it explicit and separate from default fast tests.
-   - Treat review status as an explicit artifact. If an independent review is required but times out, returns empty output, or is otherwise inconclusive, record it as pending and do not describe it as passed.
+   - After code/test edits, self-check and invoke `code-review` automatically before completion. Persist review status; timeout, empty output or inconclusive results remain pending, never passed.
    - For independent review runs, prefer bounded diff/file input over broad repo prompts. Load the repository's local rules such as `AGENTS.md` or equivalent review context when available, skip generated/docs noise unless it is the review target, and make timeout/inconclusive results recoverable through a durable pending record.
    - For product/spec normalization, standards-to-health-gate work, or any change that edits a shared deterministic gate/verifier (workspace verifier, conformance script, contract-coverage gate, status-source validator, CI harness, continuation-state checker, or a cross-repo contract/status/version/release/compatibility coordination surface), this workflow classifies the artifact before implementation — `spec/plan`, `gate design`, `gate implementation`, `status sync`, or `runtime/code` — without delegating that decision (do not delegate the spec-vs-plan-vs-code decision to `feature-risk-router`), then routes every shared-gate change through `feature-risk-router` and applies its `shared-gate` decision before shared branch push or MR merge; a recorded independent adversarial review names concrete objections, their disposition, and the reviewer/tool identity — prefer the session's review/challenge skill, otherwise a ccl-owned independent review (external tools supplement only; same-agent inline prose review only for explicitly low-risk, non-cross-boundary work). Rule/scope/failure/completion semantics changes require a concrete repo-local persistent artifact before editing; a `gate implementation` runs the plan/status verifier(s) before implementation and before claiming the plan active — an explicit status-source validator takes precedence, otherwise run every authoritative non-alias verifier or record why each is not applicable; a verifier gap or unavailable required review/challenge stays `interim` / pending-review. Details live in `references/shared-gate-artifact-classification.md`.
    - Do not use landing labels without matching evidence. `landed` requires the relevant local commit or persisted artifact; `MR-ready` requires branch, push, review artifact, known CI/pipeline status when applicable, known mergeability when applicable, and review status that matches reality; `release-ready` requires the relevant release checks, rollback/mitigation, and runtime verification evidence; `shared-status-ready` requires the owning status or product document to match the real branch/MR/review/verification state. For local-only or exploratory slices, report the actual uncommitted/unpushed state and use a local status label instead of treating MR evidence as mandatory.
@@ -187,16 +187,16 @@ At each stage boundary, walk the per-stage entry-state enumeration in [Stage-Ent
 
 ### Pre-Final Continuation Gate
 
-Run this gate before finalizing a product R&D turn after any delivery slice lands. The session-wide continuation-proposal output contract above creates a second, independent trigger at the start of every subsequent user turn in that delivery session when either (a) the immediately preceding assistant message carries an action-form `proposed-next:` and the user replies, (b) its marker is absent/multiple or `none` conflicts with imperative/future/next-step wording, or (c) a user reply reads as affirmative/permissive toward an explicit assistant-proposed next action. Paths (a) and (b) are unconditional literal/fail-closed checks. Before any further action or final response, visibly emit exactly one of `continuing: <action and scope>` or `blocked: <proposed action and scope> — <specific stop, missing authority, or ambiguity>`; emitting neither or both is invalid. Path-(c) examples and the full outcome contract: `references/pre-final-continuation-gate.md` (Gate triggers and outcome contract).
+Run this gate before finalizing a product R&D turn after any delivery slice lands, on every user reply immediately following an assistant message that states or implies a next action, and on any explicit continuation request. The reply need not first be classified as assent. Recover the intended action from the current request and relevant conversation; a malformed or absent marker alone never selects `blocked:`. Report `continuing: <action and scope>` for the work you will execute, or `blocked: <action and scope> — <specific blocker>` when no authorized work can proceed. A blocked dependent action may remain pending while a different authorized action continues. Apply landing checks only to actual landing claims; an already-authorized local investigation does not require inventing a prior landing. Details: `references/pre-final-continuation-gate.md` (Gate triggers and outcome contract).
 
 1. Confirm the landing state from real evidence (local branch, remote sync, MR/review artifact, CI/pipeline when applicable, review/challenge status when required, status-doc sync, dirty worktree), proving the landing before reading any document (for the remote-backed default, fetch/update the target ref from its remote immediately before classifying the slice landed) per `references/pre-final-continuation-gate.md` (Landing-state proof); content/tree/patch equivalence never by itself proves a slice landed.
 2. Inspect the current product/status source of truth, issue list, repo-local next-step artifact, unresolved acceptance item, or direct user continuation instruction for the next implied slice. **Reconcile it against the current branch/MR/merge/CI/tag state from step 1 before deriving: contradicting reality means stale — stop, repair the status source first, and do NOT derive from the stale source or a git-log/grep scan** (`references/pre-final-continuation-gate.md` §Status-source reconciliation).
    - **Deferred-evidence continuation check (`DFE-CONT`).** When real/runtime evidence is due (named by an acceptance item, status source, landing-evidence row, required gate, user correction, or because it is the behavior's only meaningful proof) yet deferred, blocked after remediation, skipped at finalization, or replaced by local/mock verification. Report deferred real evidence as `interim`/outstanding; do NOT report the turn complete while it is outstanding. A local/mock substitution is terminal only when a cited **non-agent** anchor — **agent-authored or agent-co-edited status/router/gate/handoff text never satisfies this** — names the same evidence, declares the deferral terminal, and carries the outstanding command/source forward for the active slice/ref. Never add verifier/config/test hardening motivated only by missing deferred evidence; never auto-continue past the pending gate. **Load `references/pre-final-continuation-gate.md` before treating any deferral as terminal** — it owns the valid/invalid-anchor list and hardening boundary.
-   - **Affirmative-assent binding rule** lives in `references/pre-final-continuation-gate.md` §Assent binding — **load it before selecting `continuing:` on any assent**, and any concrete next-slice proposal you issue must itself carry the `proposed-next:` marker or a later assent cannot bind — an unmarked referent is ambiguous, never self-cleared; the rule fires only when the immediately preceding assistant message itself states one concrete next action and its scope, and `continuing:` binds to that proposal, never to adjacent status or response-format prose; ambiguous assent, referent, or authority ⇒ `blocked:` with step-4 precedence — restate the proposed action/scope plus the specific ambiguity/authority, cite the step-1 evidence and ask one concise question in the same turn; self-classifying the reply or marker away is never an exit, and the `continuing:` default applies only when assent is unambiguous and no step-4 condition holds (the full rule and its fallback are stated there); the visible `continuing:`/`blocked:` outcome obligation is unchanged.
-3. Continue automatically only when no step-4 stop condition fires and: the next slice comes from an explicit status/task/acceptance source or active user continuation, is low-risk, local-only/already-authenticated, in accepted scope, clearly owned, verifiable with existing commands, and needs no destructive action, external purchase/financial commitment, production access, legal/compliance/product-strategy decision, or high-impact architecture choice. Existing configured internal developer-self-use metered model/tool accounts aren't an external purchase here.
-4. Stop only for an explicit stop/pause instruction, a user-requested status-only answer, a failed/pending/inconclusive required/blocking gate, dirty/conflicting worktree that can't be isolated, required environment unavailable after remediation, high-impact product/architecture/compliance decision, destructive action, external purchase/financial commitment, unclear owner, ambiguous assent, missing stricter authorization, materially differing viable approaches (none dominant-and-reversible), a fix lacking evidenced cause, or no low-risk slice. Exactly one dominant reversible approach and no other stop condition firing: do not stop at a recommendation: deliver a tested reviewable draft.
+   - **Affirmative-assent binding rule** lives in `references/pre-final-continuation-gate.md` §Assent binding — load it when recovering a short reply. Bind to the current explicit request or one recoverable concrete proposal, including an unmarked proposal; preserve its scope and existing authority. Ask only if action, scope, or required authority remains unresolved after recovery. A status remark or output marker cannot substitute for a proposal or permission; self-classifying the reply or marker away is never an exit from carrying out an already-clear request.
+3. Continue automatically with a clearly owned, verifiable, low-risk next slice from an explicit task/status/acceptance source or active user continuation, within accepted scope and existing authority. Apply the eligibility and stop conditions in `references/pre-final-continuation-gate.md`. Necessary fixes, tests and review inherit task authorization; a reviewer-budget flag triggers a method checkpoint and cumulative-history record, not renewed permission. Explicit user limits still govern. Existing configured internal developer-self-use metered model/tool accounts aren't an external purchase here.
+4. Stop only for an explicit stop/pause instruction, a user-requested status-only answer, or a concrete blocker for the affected action. Block materially differing viable approaches (none dominant-and-reversible) and a fix lacking evidenced cause; load `references/pre-final-continuation-gate.md` for the full stop conditions. **Scope each blocker to its dependent action or claim.** An unproven cause blocks the speculative patch, not available diagnosis; a pending gate blocks dependent landing/completion, not authorized remediation or independent work. Before ending, perform available in-scope diagnosis, owner discovery, remediation, live-handle monitoring or independent work. Quality-gate failures require diagnosis and available related behavior-preserving cleanup before escalation; preserve readability and compatibility, never game counters (`references/refactoring-discipline.md`). Never bypass the blocked gate, invent a pass, widen scope, or substitute unrelated hardening. Stop the task only at the user's stop/status-only instruction or when no safe authorized work remains. With one dominant reversible approach and no applicable stop condition, do not stop at a recommendation: deliver a tested reviewable draft.
 5. If stopping, state the concrete stop reason and the exact evidence checked; an assent-triggered `blocked:` outcome uses the action/scope-plus-blocker form and classifies the turn `interim`. Ask one concise in-turn question when ambiguity or missing authority blocks; explicit stop/pause needs no reconfirmation. A `continuing:` outcome proceeds with the named slice before finalizing. A silent/completion stop is invalid. Do not send a completion-only, solved, fixed, or fully-closed final response after a merge/sync while a required review/challenge is pending or inconclusive; report interim or blocked with the next unblock step.
-6. **Assent-outcome closeout check.** Before every final response in a product-delivery session, walk the literal immediately preceding marker and visible outcome; the agent cannot exclude a status, question, review, or dispatched-owner turn by reclassifying it outside the session. An action marker or a plausibly affirmative user reply requires exactly one already-visible `continuing:`/`blocked:` outcome; until `continuing:` has executed the accepted slice or `blocked:` has named the blocker, the current turn may not use `proposed-next: none — status only` or `not-applicable`. A valid status-only marker permits `not-applicable` only when the preceding prose has no imperative/future/next-step wording and no affirmative reply pending. A missing/multiple/conflicting marker forces a visible `blocked:`/`interim` outcome with one clarifying question; it never produces `not-applicable`. The current assistant message itself must end with exactly one action-form or status-only marker for the next turn. Omitting the marker cannot justify a silent stop.
+6. **Assent-outcome closeout check.** Every user reply immediately following an assistant message that states or implies a next action requires a visible `continuing:` or `blocked:` outcome before finalizing, even if the reply is not classified as assent; every explicit continuation request does too. Missing markers never waive it. Reconcile the current request, original proposal, scope/authority changes, tool/output evidence, and remaining blockers. Respect a current explicit stop or status-only request; name that reason in the blocked outcome without executing the prior proposal. Otherwise `continuing:` must be followed by execution in the same turn; a promised next step is not execution. If part remains blocked, report its pending state and independent work performed. A status-only handoff cannot discharge an unexecuted accepted action. Repair marker formatting; for short assent, if the original proposal cannot be recovered verbatim, select `blocked:` and ask. Formatting never requires clarification. Do not silently drop an accepted action or claim a pending gate passed.
 
 If a user later challenges "why did you stop" or "was the rule too weak", treat it as a product workflow defect: route through `skill-extraction-workflow`, strengthen the smallest owning skill or validation checklist, validate the diff, and only then claim the process issue is solved.
 

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 不固定数字以免过时）。
 

package/dist/assets/marketplace/plugins/ccl-skills/skills/product-rd-workflow/references/design-review-gate-mechanics.md

@@ -10,7 +10,7 @@ a triggered diff, and whenever the candidate diff changes after a review.
 
 ## Recorded review artifact
 
-(a) a recorded independent adversarial review is the gate for all triggered work — prefer an available review/challenge skill discovered in the session when suitable, otherwise a ccl-owned independent review (the external skill supplements, it is not itself the required gate); save an artifact naming concrete objections, their disposition, and the reviewer or tool identity; same-agent inline prose review is acceptable only for explicitly low-risk, non-cross-boundary work.
+(a) a recorded independent adversarial review is the gate for all triggered work — prefer an available review/challenge skill discovered in the session when suitable, otherwise a ccl-owned independent review (the external skill supplements, it is not itself the required gate); save an artifact naming concrete objections, their disposition, and the reviewer or tool identity; same-agent inline prose review is acceptable only for explicitly low-risk, non-cross-boundary design-only work with no implementation diff. Once code or executable tests change, invoke `code-review` automatically under its development-completion rule; green tests or low risk do not replace that invocation.
 
 ## Binds to the implementation diff
 

package/dist/assets/marketplace/plugins/ccl-skills/skills/product-rd-workflow/references/pre-final-continuation-gate.md

@@ -85,21 +85,30 @@ If over-polishing around deferred evidence recurs, or the user flags it as a reu
 
 ## Continuation-proposal output contract (session-wide coverage)
 
-The entrypoint defines the contract itself (exactly one literal `proposed-next:` line per assistant message, in one of its two forms). The coverage detail:
+The entrypoint uses `proposed-next:` as an observable handoff, not an authorization token. The contract follows the delivery across status answers, questions, reviews, and dispatched owners, before or after a slice lands. Progress messages need no ritual marker to preserve a user's request.
 
-- It binds every assistant message in a delivery session routed by or through the workflow — including "go straight to the owning skill" paths: status answers, questions, review reports, and work dispatched directly to implementation, diagnosis, or another owning skill. Neither the router nor the executor may classify its own turn out of the contract; if it is unclear whether the workflow was invoked, default to carrying it.
-- It applies before any slice lands and is not conditional on entering the Pre-Final Continuation Gate.
-- At the start of every subsequent user turn, read that literal line before interpreting the reply: an action marker enters the gate's continuing/blocked classification; absence/multiplicity enters `blocked:`/`interim` by default; a `none` marker that conflicts with proposal wording does the same.
-- This is an observable prose contract, not a host-enforced hook; a task that never loads this workflow cannot be mechanically controlled by this text, so do not claim it prevents that host-level omission.
+At the start of the next turn, recover intent in this order:
+
+1. Follow the current explicit user instruction, including a correction, changed scope, stop, or status-only request.
+2. For short assent, read back the original wording of the most recent still-active concrete proposal and check that later messages or task state have not withdrawn or superseded its action, scope, or authority. Quote that original proposal when stating the recovered action and scope; a summary or paraphrase alone cannot bind short assent. If recovery adds an action or broadens that quoted scope, select `blocked:` and ask. One recoverable action can bind with or without a marker; a stale, repeated, or conflicting marker is an assistant formatting defect to repair.
+3. If materially different proposals remain unresolved, or scope/authority is still unclear, ask one targeted question about that uncertainty. Do not ask the user to repair a marker or repeat a clear instruction. A marker alone never supplies missing authority.
+
+Use the active owner's entry and safety gates for the recovered action. An authorized task includes necessary fixes, tests and review by default; neither a router nor a dispatched owner may discard that authority by relabeling its turn or exhausting an internal review sequence. Apply the owning review checkpoint and record `continuation_basis=existing-task-scope` with cumulative history in the caller-owned task artifact, not runtime JSON. Legacy `human_decision_required` / `continuation_authorization_required` values first require checking existing authority, not asking again. Explicit user cost, round-count and stop limits prevail; new scope, missing authority or real tradeoffs need a decision. Continuation grants no merge, publication or waiver authority. This is a prose contract, not a host-enforced hook; it cannot prove compliance by a task that never loads it.
 
 ## Gate triggers and outcome contract
 
-The session-wide contract creates a second, independent trigger at the start of every subsequent user turn in that delivery session when either (a) the immediately preceding assistant message carries an action-form `proposed-next:` and the user replies, (b) its marker is absent/multiple or `none` conflicts with imperative/future/next-step wording, or (c) a user reply reads as affirmative/permissive toward an explicit assistant-proposed next action — regardless of whether a slice landed or the turn is being finalized. Paths (a) and (b) are unconditional literal/fail-closed checks; marker absence enters path (b) without first asking the agent to recognize why it was omitted.
+An eligible next slice comes from an explicit status/task/acceptance source or active user continuation, is low-risk, local-only/already-authenticated, in accepted scope, clearly owned and verifiable with existing commands. It needs no destructive action, external purchase/financial commitment, production access, legal/compliance/product-strategy decision or high-impact architecture choice. Existing configured internal developer-self-use metered model/tool accounts are not an external purchase. Apply the following conditions to each action.
+
+Action-scoped stop conditions are: an explicit stop/pause instruction; a user-requested status-only answer; a failed, pending or inconclusive required gate; a dirty/conflicting worktree that cannot be isolated; a required environment unavailable after remediation; a high-impact product, architecture or compliance decision; a destructive action; an external purchase or financial commitment; unclear ownership; ambiguous assent; missing stricter authorization; materially different viable approaches with none dominant and reversible; a speculative fix without evidenced cause; or no low-risk slice. Apply each condition to the affected action, then check for available authorized diagnosis or remediation before stopping the whole task.
+
+Check continuation on every user reply immediately following assistant prose that states or implies a next action, and on any explicit continuation request, regardless of landing status. Do not first require classifying the reply as assent; visibly report the continuing or blocked outcome even when the reply changes scope or stops the proposed action. Short replies include `ok`, `yes`, `可以`, `好`, `继续`, `proceed`, `do it`, `go ahead`, and `👍`; interpret them against the recovered action rather than formatting alone.
 
-- Path (c) examples include, but are not limited to, `ok`, `okay`, `yes`, `sure`, `可以`, `好`, `行`, `按这个来`, `继续`, `proceed`, `do it`, `go ahead`, or `👍`; any plausibly affirmative reply enters unless it explicitly says stop/pause.
-- Select `continuing:` only when the reply is unambiguously affirmative and the marker or immediately preceding message contains exactly one concrete action and scope.
-- An explicit stop/pause selects `blocked:` with that reason; a mixed/ambiguous reply, invalid/conflicting marker, or bare emoji/interjection after status-mixed or multi-proposal prose also enters but must select `blocked:`.
-- Before any further action or final response, visibly emit exactly one of `continuing: <action and scope>` or `blocked: <proposed action and scope> — <specific stop, missing authority, or ambiguity>`; emitting neither or both is invalid.
+- Select `continuing: <action and scope>` when that action is clear and authorized, then execute it in the same turn. A tool call and its result or a produced artifact establish execution; the label alone does not.
+- A blocked patch, review, or landing does not block every action. Keep that dependent action/claim pending while continuing available diagnosis, bounded remediation, monitoring of the existing live handle, or independent accepted work. These paths retain their own scope and permission checks; they cannot bypass the blocked gate or substitute unrelated hardening for missing evidence.
+- A failed quality gate calls for a repair that preserves its purpose. Before asking the user to choose a workaround, inspect and perform a safe structural cleanup related to the current change when available, then rerun the gate and affected tests. Follow [refactoring discipline](refactoring-discipline.md#responding-to-quality-gates): preserve behavior, compatibility and readability; do not shrink identifiers or necessary comments, weaken a baseline or rewrite history solely to make the counter pass. If no safe in-scope repair remains, report the evidence and the actual decision needed.
+- Independent work must neither depend on the pending verdict nor modify the candidate being evaluated. Name the pending gate and the independence basis when continuing. A candidate-changing fix is remediation, not independent work: let the existing run reach a terminal state, then refresh affected evidence and re-enter the owning gate. The deferred-evidence hardening prohibition still applies.
+- Select `blocked: <action and scope> — <specific blocker>` when the remaining action needs an unresolved decision/authority or no safe authorized work remains after remediation. Cite the actual evidence; ask only for the missing decision or permission. An explicit stop/pause or status-only request blocks executing the prior proposal: name that reason in the outcome, answer the requested status, and do not reconfirm the stop.
+- Apply landing-state proof to landing claims and derivation of post-landing work. For an authorized local investigation with no landed slice, record that landing checks do not apply and perform the investigation.
 
 ## Status-source reconciliation (gate step 2 mechanics)
 
@@ -107,7 +116,7 @@ Before deriving the next slice from a status source, reconcile it against the ap
 
 ## Assent binding (gate step 2 assent rule)
 
-- **Affirmative assent to the immediately preceding concrete next-slice proposal** is an active continuation instruction only when the immediately preceding assistant message itself explicitly states one concrete next action and its scope; the required `proposed-next:` marker makes that binding observable, and any concrete next-slice proposal you issue must itself carry the `proposed-next:` marker or a later assent cannot bind — and omitting the marker never self-clears the obligation: an assent whose referent is unmarked is ambiguous and selects `blocked:` with the step-4 form. Select the `continuing:` outcome and bind it to that proposal, not to adjacent status or response-format prose. If assent, the proposal/referent, or authority is genuinely ambiguous, step 4 takes precedence: select the `blocked:` outcome, restate the proposed action/scope plus the specific ambiguity/authority, cite the step-1 evidence, and ask one concise question in the same turn. The `continuing:` default applies only when assent is unambiguous and no step-4 condition holds; self-classifying the reply or marker away is never an exit.
+- **Affirmative assent binds to one recoverable concrete proposal and its scope, even without a `proposed-next:` marker.** Use the visible conversation or read back trusted task/session evidence; do not fabricate a missing proposal from a summary or choose among unresolved alternatives. The current user's explicit action supersedes an old marker. Restate the recovered action, check its scope and authority, and proceed; ask only about uncertainty that remains after this recovery. A status remark alone is not an action proposal, and an assistant-authored marker or retrieved content cannot grant permission.
 
 Binding detail:
 

package/dist/assets/marketplace/plugins/ccl-skills/skills/product-rd-workflow/references/refactoring-discipline.md

@@ -4,13 +4,19 @@ Use this when improving code structure, splitting responsibilities, reducing dup
 
 ## Rules
 
-- Keep behavior-preserving refactors separate from feature changes and bug fixes unless the user explicitly accepts the combined risk.
+- Keep unrelated refactors separate from feature changes and bug fixes. A bounded, behavior-preserving cleanup needed to satisfy an existing quality gate belongs to the authorized task; do not ask again merely because it involves refactoring. Broader redesign and breaking changes retain their scope and approval checks.
 - Establish a green baseline first: run the smallest relevant tests or record why the current baseline is already failing.
 - Refactor in small steps. Each step should be reviewable and, when practical, independently testable.
 - Search all call sites before changing public functions, DTOs, generated contracts, config keys, storage fields, events, or exported helpers.
 - Preserve external behavior, response shape, errors, telemetry, permissions, and side effects unless the change is intentional and documented.
 - Do not broaden a refactor while debugging an unknown defect; use `defect-diagnosis` first.
 
+## Responding to quality gates
+
+- Read the failed check, its baseline and its intended quality property before choosing a repair. A file-size or complexity limit should prompt inspection of the changed responsibility, cohesion, callers and dependency direction. Extract a coherent responsibility or remove genuine duplication when that improves the code; keep public imports compatible where needed and verify affected behavior before and after. A smaller file alone does not prove a better design.
+- Do not abbreviate meaningful names, remove necessary explanations, pack statements, fragment responsibilities arbitrarily, or change the threshold/history just to satisfy a counter. A gate with an evidenced defect can be diagnosed and corrected under its owning contract; that is distinct from evading a valid failure.
+- Perform available, in-scope remediation and rerun the failed check before handing the problem back. Ask only for a remaining material tradeoff or missing authority after this work. Force-pushing, waiving the gate and accepting lower readability are not substitutes for inspecting a safe structural repair; a failed gate grants none of those permissions.
+
 ## Impact Analysis
 
 Before changing a shared shape or function, identify:

package/dist/assets/marketplace/plugins/ccl-skills/skills/python-service-dev/SKILL.md

@@ -5,7 +5,7 @@ description: 用 Python 写接口 / FastAPI / Django model / Celery 任务 / pyt
 
 # Python Service Dev
 
-Use this for implementation of Python backend products, services, microservices, AI-service hosts, workers, packages, and batch tools. For new backend products, implement the smallest deployable or package shape justified by ownership, data boundary, runtime isolation, scaling, release cadence, and rollback needs. It should adapt to the repository in front of you, but the workflow is independent of any prior codebase.
+Use this for implementation of Python backend products, services, microservices, AI-service hosts, workers, packages, and batch tools. For new backend products, implement the smallest deployable or package shape justified by ownership, data boundary, runtime isolation, scaling, release cadence, and rollback needs. It should adapt to the repository in front of you, but the workflow is independent of any prior codebase. After code/test edits, self-check and invoke `code-review` automatically before completion.
 
 ## Skill Routing
 

package/dist/assets/marketplace/plugins/ccl-skills/skills/requirement-scope/SKILL.md

@@ -12,7 +12,10 @@ description: 改动范围 / 影响范围 / scope / 需求拆分 / MVP 边界 /
 1. **P0 核心 in/out 由 `human-decision` 关闭。** agent 不得自行决定，也不得决定产品目标、核心路径、成本级别或验收承诺。
 2. **as-is 证据不裁决 should-be 范围。** 代码、数据、架构等描述性证据不能自行决定本轮改不改。
 3. **边界要可审查。** in/out 写成行为边界，不用「优化体验」这类不可判定的模糊标签。
-4. **appetite 必须带砍项与人工兜底——用户说「不用写」也不行。** 只有投入上限、没有「超上限砍什么」和「人工怎么兜底」的 appetite **不得写进产物**：把该字段标 `blocked`、点名缺的是这两项中的哪一项、给出取得它的最小动作，然后继续交付其余字段。这是拒绝，不是提醒。
+4. **先判 appetite 是否适用，再记录投入与取舍。** [Shape Up 的 appetite](https://basecamp.com/shapeup/1.2-chapter-03) 用于在固定投入下调整范围；它不是每张影响范围表的必填前提。
+   - 任务要求投入决策，或已有适用的投入上限时，记录已确认上限和超出时可调整的范围。取舍未定就保留已知上限，把未知子项标 `open`，继续交付其余字段；不得自行砍掉核心范围、降低既有验收要求或承诺按期完成。
+   - 人工兜底只在业务连续性、降级或已批准决策确实需要时填写；不需要时写明依据，不为填表虚构人工接管。
+   - 仅做影响范围盘点、未涉及投入决策时，可按任务边界记 `not-applicable`。用户要求省略展示细节时遵从该要求，已确认约束和未决事项保留在关闭表中；省略展示不等于撤销既有约束或关闭未决承诺。
 5. **关闭表只补自己那部分。** 唯一 canonical 是 `requirement-doc-writer/references/requirement-closure-contract.md`。本技能按复合字段子项补版本、范围、appetite、依赖和验收，逐项记录推导、决策权和决策证据；只能自动填写单个低风险、可逆的非核心展示/表达细节（decision_authority 记 `bounded-agent-policy`，且须有可引用的已批准 policy），**任一适用子项 open 时复合字段和整行保持 open/blocked**。
 6. **「非目标」在这里是变更级**——本轮明确不改、延后、保持兼容、无需迁移的对象。意图级的「本轮不追求什么目标」属 `requirement-intent`。同理「验收」在这里是每个切片的验收边界与不验收项，不是功能点 pass/fail。
 
@@ -30,7 +33,7 @@ description: 改动范围 / 影响范围 / scope / 需求拆分 / MVP 边界 /
 | Out of scope（变更级非目标） | 明确不改、延后、保持兼容、无需迁移的部分 |
 | 受影响对象 | 角色、页面、入口、API、数据、运营规则、通知、报表、权限、文档 |
 | 版本切片 | MVP、后续版本、迁移/兼容切片、回滚/降级边界 |
-| Appetite / timebox | 本轮愿意投入的时间/资源上限、超出时砍掉什么、人工兜底策略 |
+| Appetite / timebox | 适用性与依据；适用时记录已确认投入上限、超限取舍和必要的兜底 |
 | 依赖 | 上游决策、外部系统、数据准备、设计、法务/运营/支持动作 |
 | 风险点 | 权限、隔离、计费/配额、删除/覆盖、数据迁移、发布复杂度 |
 | 验收范围 | 每个切片的可观察验收边界和不验收项 |
@@ -41,7 +44,7 @@ description: 改动范围 / 影响范围 / scope / 需求拆分 / MVP 边界 /
 1. 锁定目标与输入：引用已澄清需求或盘点事实。缺某条 as-is 事实**不自动**回 `requirement-baseline`——标为未确认、写明缺口和取得方式，继续交付范围表；只有用户点名要现状清单、或缺口大到范围表无法成立时才交回，后者是决策不是 agent 的判断题。
 2. 列受影响对象：用户、流程、界面/API、数据、权限、运营、文档逐项过一遍。
 3. 写 in/out scope：按硬约束 2、3。
-4. 切版本并写 appetite：P0、后续、迁移、兼容、回滚/降级分别列清；按硬约束 4 写砍项与人工兜底。
+4. 切版本：P0、后续、迁移、兼容、回滚/降级分别列清；按硬约束 4 判断并填写 appetite。
 5. 标依赖和风险：把安全 4 问命中项、跨团队/系统依赖、数据风险拉出来。
 6. 更新 `需求点关闭表`（按硬约束 5）。
 7. 写验收范围：每个切片对应 pass/fail 条件，明确不验收项；安全命中项的负向用例写进验收范围。
@@ -63,7 +66,7 @@ description: 改动范围 / 影响范围 / scope / 需求拆分 / MVP 边界 /
 - in/out 每一项都是可审查的行为边界，没有模糊标签。
 - 受影响对象十类（角色/页面/入口/API/数据/运营规则/通知/报表/权限/文档）逐类过了一遍，不适用的显式写「无」。
 - 每个切片都有可观察的验收边界**和**不验收项。
-- appetite 同时写了投入上限、超上限的候选砍项、人工兜底。
+- appetite 按硬约束 4 判定适用性；适用子项有决定或明确的未决状态，不适用有依据。未知项不被抹掉，也不阻断其余范围材料。
 - P0 核心 in/out 标了 `human-decision`，没有被 agent 自行关闭。
 - 关闭表里任一适用子项 open 时，复合字段和整行保持 open/blocked。
 - 安全 4 问：记了「无命中」，或四项逐条答案 + 写明所依据的 canonical 文件名；命中项的负向用例已在验收范围里。
@@ -77,7 +80,7 @@ description: 改动范围 / 影响范围 / scope / 需求拆分 / MVP 边界 /
 - Out of scope（变更级非目标）：
 - 受影响对象：
 - 版本切片：
-- Appetite / timebox（含砍项与人工兜底）：
+- Appetite / timebox（适用性与依据；适用时写投入、取舍与必要兜底）：
 - 依赖：
 - 风险点：
 - 验收范围（含不验收项）：

package/dist/assets/marketplace/plugins/ccl-skills/skills/skill-extraction-workflow/SKILL.md

@@ -5,7 +5,7 @@ description: 复盘 / 沉淀 / 总结经验 / 补进技能 / 技能缺陷 / 流
 
 # Skill Extraction Workflow
 
-Use this skill to turn observed experience into durable agent skills without copying business-specific codebase details. It complements public skill-authoring guidance such as `writing-skills` and `skill-creator`: those define skill format and authoring discipline; this skill defines how to mine, filter, generalize, validate, and land reusable CCL skills.
+Turn observed experience into reusable skills without business-specific details. `writing-skills` and `skill-creator` define format and authoring discipline; this skill covers mining, filtering, generalizing, validating and landing. When shared-skill changes are ready, invoke `code-review` automatically before completion. Apply `code-review/references/development-completion.md` and this owner's required review/challenge gate.
 
 ## Start here (30 秒定位)
 
@@ -137,7 +137,7 @@ Use this skill to turn observed experience into durable agent skills without cop
   - The mechanical backstops are (a) the closeout gate — a committed skill-change with neither a visible in-session `skill-extraction-workflow` invocation nor the round's durable charter/target-output record is `interim` — and (b) **user-signal escalation**: you generally cannot self-count misses you did not notice, so a user-pointed-out under-trigger is a recurrence check across the whole session (even other tasks) and, on recurrence, escalates to tightening the always-on discipline rather than landing another narrow per-case trigger.
   - **Firing-point-placement corollary:** when the SAME meta-class (a precise gate walked past at the routing → pre-code/design transition) recurs at a *new* lifecycle sub-point despite prior bootstrap-salience + the closeout gate, the durable lever is **moving the owning gate's firing point ONTO the transition itself** (pre-substance-draft AND pre-first-impl-edit) and sharpening *name→invoke* at the SAME transition — naming/knowing an owner is NOT invoking/loading it, and a named-but-unloaded owner's mechanical rules never fire — NOT another bootstrap/per-case bullet or more prose. **Record-field corollary (the forgery surface):** any field that NAMES an owner is fillable without invoking that owner, and filling it is what *feels* like discharging the gate, so it carries an explicit invoke bar on its triggered values. The self-detect firing point's authority boundary and observed shape, the output-shape and option-set siblings, the invoke-bar set-diff mechanics, the worked recurrence-chain, and the landed owner-dispatch implementation: `references/firing-point-placement.md`.
   - **Run your own adversary to convergence BEFORE any "done / fixed / passing / covered / converged / complete" claim — your own such claim is the least-trustworthy thing you emit.** For any non-trivial completion/coverage/convergence claim, you must have already run — **yourself, not deferred to the user** — the verification or adversarial pass that would catch its failure, to a **clean fresh result** (a first clean pass on the current candidate, never a "confirm my fix" pass), OR **downgrade the claim to `interim` and name what you ran vs. didn't**. "Covered / converged / already handled" is a claim, not a status — back it with firing-path or clean-pass evidence or do not emit it; this self-adversary duty never narrows the mandatory dual-track challenge. That pass is a **walked enumeration over the properties the candidate asserts, never a re-read**: a property whose killing mutation you cannot name was never verified; **a mutation you did not APPLY is a hypothesis, not evidence** (bound its blast radius; where no isolated path exists record the property `unverified`); **prove the oracle can fail before trusting its clean verdict**; **a failing anchor is first a question about the ANCHOR, not a verdict on the implementation**; a clean run is reported with the dimensions it crossed, walked before values; a property with no contradicting observation is `unverified`, never counted as audited. A scoped "X verified; Y not run" is an interim checkpoint, **not** `done`/`complete`/`landed`, unless a **risk owner — the user/maintainer, never the agent self-accepting — explicitly accepts the gap AND it is tracked to that owner** (agent self-labeling "risk accepted" or "deferred" does not qualify; scoping is a downgrade, never a license to call the narrowed slice done). **Recurrence signal:** a user prompting you to keep digging / disputing a "covered/converged/done" is a premature-completion signal — on the **2nd** such correction in a session (even across different tasks) escalate to tightening this discipline, not just fixing the one case (per the repeated-correction escalation above). The full method — mutation enumeration, the applied-mutation discipline and its blast-radius bound, independent-oracle validation, the dimension walk (`testing-strategy` owns the axis list), re-owe-after-fixes, graded-verdict calibration, the failing-anchor section, and the recognition-dependent honesty caveat: `references/dual-track-review-gate.md` §Self-audit.
-- Automatically trigger durable learning when extraction work exposes a reusable failure — **and when ordinary delivery work does, capture it here too, but without extraction taking over the delivery**: let the active owner (`product-rd-workflow` / `defect-diagnosis` / `testing-strategy` / …) handle the immediate work first, then route the durable lesson here. **For a premature-stop correction after affirmative continuation**, immediate recovery means first rerun the active owner's current continuation/blocking gate in full (for product R&D, Pre-Final Continuation Gate steps 1–6) against current state, then follow its observable outcome — proceeding only when a literal binding exists (the original proposed-next action/scope plus literal assent preserved verbatim, or the user's correction literally naming the paused action and scope — never reconstructed, broadened, or substituted, and never copied into a shared repository record); a `blocked:` recovery without the step-1 evidence and a specific missing authority/ambiguity is invalid; asking again is required when neither path binds, the user intervened, or scope/gates changed; and neither correction RCA nor stale assent may extend a still-authorized delivery or slip past a gate that is newly pending or inconclusive. After delivery recovery, correction RCA plus the durable prevention landing and verification are still due before the turn can be reported complete; otherwise report `interim`. What counts as a binding (the two paths, and why a compaction paraphrase or a bare "why did you stop" is not one), the `continuing:`-line form, and the invalid-`blocked:`-recovery rule: `references/resume-paused-delivery.md`.
+- Automatically trigger durable learning when extraction work exposes a reusable failure — **and when ordinary delivery work does, capture it here too, but without extraction taking over the delivery**: let the active owner (`product-rd-workflow` / `defect-diagnosis` / `testing-strategy` / …) handle the immediate work first, then route the durable lesson here. **For a premature-stop correction after affirmative continuation**, rerun the active owner's current continuation/blocking gate against current state (for product R&D, Pre-Final Continuation Gate steps 1–6, with landing checks only where applicable). Proceed when a literal binding exists: one recoverable concrete proposal and scope plus the user's assent, even without a marker, or the current user explicitly naming the paused action and scope. Never fabricate or broaden that binding, or copy real conversation text into shared records. Ask only if action, scope, or required authority remains unresolved after recovery; a new user message or changed gate requires reassessment, not automatic reconfirmation. Keep newly blocked dependent actions pending while continuing available authorized diagnosis, remediation, or independent work. Correction RCA and extraction must not delay that recovery or bypass a gate. After delivery recovery, correction RCA plus durable prevention and verification are still due before claiming this process defect complete; otherwise report `interim`. Binding paths, trusted evidence, and invalid-`blocked:` recovery: `references/resume-paused-delivery.md`.
   - The trigger is a correction about *reusable skill/process behavior*, NOT every bug/QA/review nit handled inside its own owner skill. Do not wait for the user to say "沉淀": if the user points out a missed source, missed sibling skill, shallow rule, overclaim, domain leakage, missing trigger, missing verification, repeated correction, **or that this workflow should have been invoked at all (an under-trigger / "should you have used 提炼/复盘" correction, including outside an active extraction)**, run correction RCA, update the smallest owning skill/reference/validator, and verify the prevention point before finalizing the turn.
 - When the user asks whether a lesson was durably landed after a failed extraction, verify the actual skill diff or file content first. Do not answer from memory or intent. If the prevention rule is not present in the owning skill, add it or state that it has not been durably landed.
 - **Consolidate and retire rules; a skill's rule set must not grow monotonically.** Every correction adds a guard, but an N-bullet wall on one theme is itself the over-prescription/unreadability failure, and "just append another bullet" is how it regrows.