@ccoalm/ccl-skills 0.7.0 → 0.9.0

package/dist/assets/marketplace/plugins/ccl-skills/skills/platform-release-engineering/references/canary-and-rollout-strategy.md

@@ -40,10 +40,14 @@ canary_check_task:
       # Filter by baseline label `lane` (canonical per metrics-conventions
       # Baseline labels), not raw mesh subset name.
       query: 'sum(rate(http_server_request_error_total{service="<svc>", lane="prod-canary-<v>"}[5m])) / sum(rate(http_server_request_total{service="<svc>", lane="prod-canary-<v>"}[5m]))'
-      threshold: < 0.01              # 1% error budget
+      threshold: < 0.01              # 1% rolling error-rate threshold (5m window; not an SLO error budget) — Flagger's builtin-check example value
     - name: latency_p99
       query: 'histogram_quantile(0.99, sum(rate(http_server_request_duration_seconds_bucket{service="<svc>", lane="prod-canary-<v>"}[5m])) by (le))'
-      threshold: < 0.5               # seconds (500 ms)
+      threshold: < 0.5               # seconds (500 ms) — Flagger's builtin-check example value
+      # Threshold provenance: <1% error rate / p99<500ms match Flagger's official
+      # builtin metric checks (request-success-rate min 99, request-duration max 500ms).
+      # They are NOT a cross-tool default (Argo Rollouts' official example uses 95%
+      # success); tune per service SLO — the SLO, not the template, is the authority.
   abort_thresholds:                  # immediate abort if these hit
     - name: error_spike
       query: 'sum(rate(http_server_request_error_total{service="<svc>", lane="prod-canary-<v>"}[1m]))'
@@ -155,6 +159,16 @@ Rollback path post-promotion:
 2. Walk the same rollout flow.
 3. Or, in extreme cases, immediately set the new bad version's weight to 0 and old version's to 100.
 
+## Ramp/Rollback Data Literacy (user-level experiments and flags)
+
+When the rollout is user-bucketed (A/B, percentage flag, allowlist) rather than pod-weighted, the decision data has its own failure modes; a ramp/rollback/graduate decision that ignores them reads a lying funnel:
+
+- **Exposure without a bake point lies.** Count a user as "on treatment" only from an exposure event emitted at the moment the treatment actually took effect for them — an assignment record without exposure means the funnel includes users who never saw the change.
+- **Funnel invariant:** for any feature, outcome unique-users ≤ exposure unique-users — a necessary sanity check, never attribution proof (disjoint sets can satisfy it): attribution requires joining outcome events to the same users' exposure with outcome.time > exposure.time. A dashboard violating the invariant has a data-pipeline defect, not a product effect.
+- **Analytics profile attributes are current state, not post-assignment behavior.** A profile-filtered dashboard cannot express `event.time > assigned_at`; ramp/rollback/graduate decisions must not rely on profile-filtered boards alone — use exposure/outcome event joins, and pair them with failure logs and cost data.
+- **Control-plane query ≠ execution fact.** Reading the flag service proves only what policy is *stored* at query time. Policy, assignment, exposure, actual execution path, and outcome are five separate evidence layers — never infer a user's actual arm from the configured weights.
+- **Bucketing salt is immutable mid-flight.** Changing the salt re-buckets every user (treatment users silently swap arms), destroying the experiment; weight and target changes have defined semantics for existing vs new users — write down which one the platform gives before ramping.
+
 ## Verification
 
 - Trigger a synthetic SLI breach during canary → control plane logs detection within bake window → automatic abort fires.

package/dist/assets/marketplace/plugins/ccl-skills/skills/platform-release-engineering/references/promotion-gate-and-review.md

@@ -133,6 +133,15 @@ Rules:
 - If a metric cannot be computed from the audit log, that is an audit-log gap: fix the event capture, don't estimate the metric.
 - Before publishing any of the five, verify the audit-log schema actually carries the correlation keys that metric joins on — at minimum: commit timestamp and production-exposure (traffic-reached) timestamp per deployment (lead time); a stable logical-deployment ID plus a distinct per-attempt ID (deployment frequency, and the failed-attempt/retry separation above); a causal link from each remediation event to the deployment it remediates (change fail rate); an incident link and a recovery-confirmed event (rework rate, recovery time). A metric whose keys are absent is unavailable — an audit-log gap per the rule above — not a license to join on wall-clock proximity or event-name heuristics; proximity joins are exactly how a failed attempt gets deduped into its later retry or a recovery gets inferred from an unrelated healthy reading.
 
+## Merge Topology For Gitflow-Style Release Trains
+
+Applies when a project runs Gitflow-style release branches (the default preference stays short-lived branches / trunk-based per `product-rd-workflow/references/delivery-lifecycle.md`; adopt this section only where release trains are genuinely required). Grounded in AWS Prescriptive Guidance's Gitflow pattern:
+
+- **Squash is direction-sensitive.** feature/bugfix → develop merges use squash (clean linear history). release → main and every back-merge **must not squash** — prefer fast-forward/plain merge. Why (git topology): squashing on higher branches rewrites commit identity, so the back-merge can no longer recognize already-merged changes and produces repeated conflicts or silently dropped work (AWS: "Only use a squash merge when you are merging from a feature branch to a develop branch").
+- **Back-merge promptly, both targets.** At release close, merge the release into main AND back into develop as soon as possible ("as soon as possible to consolidate work back into the primary branches") — a skipped back-merge means the next release train overwrites what only main has (the classic lost-hotfix incident).
+- **Tag only after the human confirms the main merge.** The production tag is a deploy trigger, not bookkeeping — never tag ahead of the confirmed merge, and stop after MR creation unless asked to proceed (composes with `release-coordination`'s authorization matrix, which owns who may confirm).
+- **Hotfix keeps the full environment ladder.** A hotfix branches from main and walks every promotion environment — it compresses cycle time and priority, never skips a gate (the emergency-override section below is the one sanctioned, loudly-logged exception); and it back-merges like any release into develop AND into any open release branch (an active train missing the hotfix reverts it at that train's own merge), or the next train reverts it.
+
 ## Emergency override
 
 For incidents where the gate must be bypassed (e.g. roll out an emergency fix faster than canary allows):

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

@@ -15,7 +15,7 @@ Use this skill as the top-level workflow for new product development, feature de
 - **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`.
   - Baseline authority: only an unmerged plan/spec on the current active delivery branch is the working baseline; anything else needs explicit recorded user selection plus reconciliation against landing evidence, deriving only still-unlanded deltas (§Baseline Selection).
   - A bare "continue"/"resume"/"go implement" is not a waiver: context summaries, compacted memory, and previous-response residue are not establishment (§Bare Continuation Scan); routing to a stack/execution skill selects the executor, not permission to implement — the **first implementation edit** is the gate.
-  - Before that edit, record the implementation boundary: active baseline, scope, implementation-mechanics owner named and — for hands-on product/stack code — invoked/loaded in-session before the first edit, `multi-agent-delegation` decision when delegation is plausible, a visible-UI design checkpoint with in-session `product-ui-ux-design` load, a `feature-risk-router` inventory, and test-case-first status — every pre-code gate marked triggered or `not-applicable` with a reason. **Load `references/implementation-entry-reentry-gate.md` before recording the boundary**: every owner-naming field must follow its invoke bar on its triggered values and per-field trigger table there — delegation being plausible at all loads `multi-agent-delegation`, including when you record `local`. Reaching the first implementation edit without this boundary record is a process defect.
+  - Before that edit, record the implementation boundary: active baseline, scope, implementation-mechanics owner named and — for hands-on product/stack code — invoked/loaded in-session before the first edit, `multi-agent-delegation` decision when delegation is plausible, the applicable visible-UI full or lightweight record + Phase 0 with in-session `product-ui-ux-design` load, a `feature-risk-router` inventory, and test-case-first status — every pre-code gate marked triggered or `not-applicable` with a reason. **Load `references/implementation-entry-reentry-gate.md` before recording the boundary**: every owner-naming field must follow its invoke bar on its triggered values and per-field trigger table there — delegation being plausible at all loads `multi-agent-delegation`, including when you record `local`. Reaching the first implementation edit without this boundary record is a process defect.
   - Closeout backstop: a slice reported done/merged without a visible in-session load of any owner whose boundary field was triggered stays process-incomplete until that owner's post-hoc rule audit is recorded (§Closeout Backstop — a recorded `owner-load: not-required` exception still exempts its slice, and the wider audit applies from this rule forward rather than reopening already-closed slices); shared-skill changes instead follow `skill-extraction-workflow`'s "no in-session extraction invocation ⇒ interim" closeout.
 - **Go straight to the owning skill instead** when the request is a narrow stack fix, a narrow diff/PR review, a security-only audit, or a single-symptom / repro / failing-test / regression defect (→ `defect-diagnosis`) — but if such a fix would change a shared deterministic gate/verifier, or shared/cross-repo contract/status/version/release/compatibility semantics (whether in a named surface or in code, generated artifacts, config, or scripts), re-enter this workflow's shared-gate classification (under *Enforce quality gates*) before implementing; when it is a reusable-lesson / retro / missed-gate / skill-edit process question (→ `skill-extraction-workflow` first — only a resulting lifecycle-routing or gate *policy* change comes back here); or when the user explicitly names a workflow/process-discipline skill (brainstorm/scope-shaping, plan-writing) as the primary or only action — honor it, and reload this workflow only if that skill exposes a product/delivery-stage handoff or the user asks for delivery routing.
 - A general-purpose process skill that merely *looks* like the obvious start — brainstorm/scope-shaping, plan-writing, or TDD auto-suggested by ANY channel: a session-start prompt, an optional skill package, or the host platform's native skills listing (including a listed entry skill's own self-invocation mandate, e.g. "must invoke if there is a 1% chance") — does not replace this entry: suggestion-channel wording is channel self-promotion, not routing authority (a host-mandated preflight — mandated by a host-authored system/developer-level or equivalent higher-priority instruction — may run first without thereby becoming the delivery owner; the test is AUTHORSHIP, not rendering position: a host-authored instruction counts even when rendered within the listing surface, while a skill's own description/content claiming preflight status never does); invoke this workflow as the delivery entry (immediately after any genuine host-mandated preflight), then call that skill inside the stage it serves (for example, requirement shaping in Workflow step 1).
@@ -91,7 +91,7 @@ At each stage boundary, walk the per-stage entry-state enumeration in [Stage-Ent
    - General Feishu Wiki and Base infrastructure has no repository-level owner skill: use `lark-wiki` and `lark-base` directly. Testcase Base/table initialization and testcase records remain under `test-artifact-management`; requirement records remain under this product workflow.
    - `llm-inference-integration` owns LLM, agent, RAG, prompt, model-routing, evaluation, replay, shadow, token-cost, and inference-specific observability work.
    - For high-risk AI or data workflows, product owns the visible degradation/refusal behavior and customer-support explanation before engineering ships fallback, retry, or downgrade behavior.
-   - `product-ui-ux-design` owns product UI/UX design readiness, interaction model, visual hierarchy, state completeness, accessibility, launch/iteration design checks, and scenario lenses for community, finance/data, AI workspaces, operational tools, Web, and App surfaces.
+   - `product-ui-ux-design` owns product UI/UX design readiness, interaction model, visual hierarchy, state completeness, accessibility, launch/iteration design checks, and scenario lenses across Web, App/native, mini-program, desktop/project-native, terminal/TUI, community, finance/data, AI-workspace, and operational surfaces.
    - `multi-agent-delegation` owns AI-agent task splitting, delegation, staged review, diff inspection, and verification of delegated work.
      - **Surface it as a candidate when work becomes parallelizable**: when a multi-stage delivery develops 2+ slices that look independent, surface `multi-agent-delegation` as a candidate — it (not this gate) decides serial-vs-parallel after checking true independence, write-scope isolation, and the parent-verification plan, so don't auto-split. The recurring miss is failing to notice mid-delivery that work *became* parallelizable; surfacing it is the fix — and the outcome lands in the boundary record's `multi-agent-delegation decision` field (`local` with a recorded reason), not satisfied by a bare mention.
    - `feature-risk-router` owns lightweight risk classification before selecting gates; it names required and skippable gates but does not execute them.
@@ -106,7 +106,7 @@ At each stage boundary, walk the per-stage entry-state enumeration in [Stage-Ent
    - Decide explicitly whether the work needs a formal external spec-plan workflow: multi-step assessment-to-fix-to-test work always needs a reviewed plan, but upgrades to a formal external spec plan only when scale or risk justifies the extra artifact (conditions in `references/delivery-lifecycle.md` §Plan Authoring); if not upgrading, record why a short inline plan is sufficient.
    - **Spec / repo-contract sync gate**: before implementation, name the active contract layer for the slice — product/requirements spec, technical design/ADR, and any repo-local agent contract (`AGENTS.md` or equivalent). If the change adds/removes/moves/materially changes a stable boundary, service, workflow, generated surface, directory-local rule, or architecture decision, the same slice updates the owning spec/ADR and nearest repo-local contract (`agents-file-coverage-gate` owns AGENTS.md coverage semantics). **Never restate an upstream authority's value sets — whenever the slice touches any upstream-owned value set (restating, freezing, or quoting), or asserts the upstream is silent on a point, or updates the owning spec/ADR / nearest repo-local contract, load `references/sync-spec-repo-contract.md` first**; it owns the no-copy rule and its handling mechanics (pointer + revision, value-freezing, excerpt permission, upstream-silence); for any upstream the slice depends on, cite the access-controlled pointer + revision rather than the copied value.
    - **Cross-repo feature coordination** (one feature spanning repos) — load `references/cross-repo-coordination.md` before coordinating; it owns the independent cross-repo contract/status/version/compatibility gates. Route rollout/migration mechanics to `platform-release-engineering`, semantic conformance to `testing-strategy`, and monorepo-vs-polyrepo heuristics to `references/modular-monolith-heuristic.md`.
-   - **Technical design gate** (architecture/contract altitude — separate from the section-4 visible UI design checkpoint, though one artifact may cover both):
+   - **Technical design gate** (architecture/contract altitude — separate from the section-4 visible UI delivery record, though one artifact may cover both):
      - **Owner-skill ownership covers BOTH design substance and the review gate — invoking this router does not discharge it.** When this gate is triggered and the deliverable's substance spans more than one owning skill, load the COMPLETE owner set for the touched concerns during design, not only at review; an external model/tool is **supplement-only**, never the substitute gate. Does not apply to a narrow single-owner task (one bug fix, implementation-only, or visible-UI-only change). Rationale and map discipline: `references/dispatch-owner-skills.md`.
      - **Owner-dispatch firing gate (non-exempt multi-owner designs only):** the COMPLETE owner set is recorded as an owner-dispatch map that gates **the START of design-substance production, not only design completion** — build it BEFORE drafting any design doc / test plan / architecture decision — and is re-confirmed before the first implementation edit; a partial dispatch does NOT satisfy it. The design is `interim` until the map shows, for every touched concern, an owner with **applied** evidence; an all-`N-A` map means single-owner work → use the exemption risk inventory below. Gate mechanics: `references/dispatch-owner-skills.md`.
      - **Owner-dispatch mechanical firing (opt-in, per product repo).** The `owner-dispatch` PreToolUse hook gates the first product-code edit, the Stop hook gates session close, and `scripts/owner-dispatch/owner-dispatch.sh ci` is the host-agnostic merge backstop; a repo opts in by committing `.owner-dispatch.json`, absent which the gate stays prose-only. **Closeout-acquire:** at closeout of a gated multi-owner delivery, `owner-dispatch.sh status` must read `opted-in: yes` — else install the backstop this delivery or record why exempt (single-owner / throwaway / ccl-skills itself). After invoking the owners and building the map, unblock editing via `owner-dispatch.sh record --owners "…"`. Posture and install detail: `references/dispatch-owner-skills.md` and `scripts/owner-dispatch/README.md`.
@@ -129,7 +129,7 @@ At each stage boundary, walk the per-stage entry-state enumeration in [Stage-Ent
      - **Floor** — reaching implementation with only spec plus plan on triggered work is a process defect, not a shortcut.
    - For any multi-step request that combines assessment, fixes, and verification, produce a task plan before editing code (required fields in `references/delivery-lifecycle.md` §Plan Authoring).
    - **Concurrent-session isolation**: when more than one session/agent/work-line may edit the same repository, give each line its own `git worktree` (or separate clone) on a unique per-line branch before editing — never stash another line's uncommitted changes, host-install symlinks into shared repos count as shared-tree edits, if isolation was skipped do not commit unreviewed shared changes to dodge clobber, and run the pre-merge freshness gate before merging back (recipe: `worktree-isolation`; mechanics: `references/worktree-mechanics.md`).
-   - For any code change, include an explicit test-layer decision table before implementation: `unit`, `integration/contract`, `E2E/host smoke`, and `manual/exploratory`. Each row must say `run`, `add`, `not applicable`, or `blocked`, name the command or evidence, and give the reason. For behavior-changing, bug-fix, user-visible, contract-visible, or test-harness changes, each applicable row must link to a written test case or scenario row; for behavior-neutral docs/config/mechanical-only changes, record `not applicable: behavior-neutral/docs/config-only` with the reason instead of inventing a fake scenario. If the repository lacks a relevant test framework or script, first try to add the smallest useful assertion-test harness in this slice. If that is not feasible after normal remediation, mark the automated layer `blocked`, run the strongest relevant host/runtime/manual scenario when one exists, and close only according to the blocking-gate labels below: `complete`, `pre-runtime-test ready`, or `blocked`. Do not complete code changes with no meaningful test path.
+   - For any code change, include an explicit test-layer decision table before implementation: `unit`, `integration/contract`, `E2E/host smoke`, and `manual/exploratory`. Each row must say `run`, `add`, `not applicable`, or `blocked`, name the command or evidence, and give the reason. For behavior-changing, bug-fix, user-visible, contract-visible, or test-harness changes, each applicable row must link to a written test case or scenario row; for behavior-neutral docs/config/mechanical-only changes, record `not applicable: behavior-neutral/docs/config-only` with the reason instead of inventing a fake scenario. If the repository lacks a relevant test framework or script, first try to add the smallest useful assertion-test harness in this slice. If that is not feasible after normal remediation, mark the automated layer `blocked`, run the strongest relevant host/runtime/manual scenario when one exists, and close only according to the blocking-gate labels below: `complete`, `pre-runtime-test-ready`, or `blocked`. Do not complete code changes with no meaningful test path.
    - Activating previously-unused / dormant / never-shipped code into a live path is a behavior-changing delivery slice: check why it was dormant, route security/permission/data/write-finality or unclear-verification reactivation through `feature-risk-router`, and prove the real import/wiring/runtime chain before acceptance (`references/dormant-code-activation.md`).
    - For R&D standards, specs, guidelines, or Feishu/wiki doc families, run the doc-family checklist before marking docs done: classify the layer, enumerate the family, record authority and sync gates, route testing/conformance owners, and finish only with `complete` evidence or `blocked: family enumeration unverified` (`references/rd-standards-doc-family-checklist.md`).
    - Avoid creating documents that are not needed to execute or verify the work.
@@ -144,15 +144,13 @@ At each stage boundary, walk the per-stage entry-state enumeration in [Stage-Ent
    - Never fabricate verification output, review status, source links, or install visibility to satisfy a gate; record missing evidence as missing.
    - Before sharing, publishing (Feishu/Lark/wiki/shared doc), syncing, committing, or opening a merge request for any deliverable doc — any human-readable artifact intended for another reader (spec, technical design, SOP, template, checklist, report, task card, launch material) — confirm `tighten-doc` ran on it this turn and record a one-line evidence note (mode, doc, applied-or-no-op reason), or record an explicit waiver. Exempt: private scratch or WIP not intended for review, and unchanged content whose prior tighten evidence still matches. A waiver is valid only when user-directed or naming a hard blocker (blocker, risk, next owner), not a self-authored convenience reason. This is the action-point enforcement of the Scope text-artifact-quality rule, not a duplicate: a substance/correctness review (codex review, engineering review, dual-track challenge) may comment on readability but does not satisfy the dedicated `tighten-doc` pass, which owns readability and reader orientation as a separate axis. Do not report a doc as published, shared, synced, or committed when this gate was skipped.
    - For any visible human-facing surface change, including consumer app, web, admin web, operations console, creator tool, moderation workspace, AI review workspace, or settings page, invoke `product-ui-ux-design` and run its surface classification before the first implementation edit (per the entry-gate name→invoke rule above; state/interaction acceptance may then continue alongside implementation). Component-library consistency is an implementation detail, not a substitute for design readiness.
-   - For client or admin changes that touch request plumbing, headers, telemetry, storage adapters, service clients, or other non-rendered behavior without changing visible layout, copy, state, interaction, navigation, or user-facing error handling, explicitly record `visible surface: no` and the reason. Do not route such changes to a design checkpoint unless the rendered experience or user decision flow changes.
-   - Before coding any visible UI change, produce a compact design checkpoint in the working notes or delivery artifact (field list in `references/design-routing-and-readiness.md` §Design Readiness Evidence). Visible UI changes include layout, copy, state, interaction, navigation, user-facing error/empty/loading feedback, and any user-facing operation entry — reading a design skill or naming a component library is not the checkpoint.
-   - For any visible UI change, do not commit or open a merge request until the implemented screen has been visually inspected against the design checkpoint in a real browser, app preview, screenshot, or equivalent rendered surface. Automated tests can prove behavior; they cannot prove visual taste, hierarchy, density, or whether the screen obviously follows the design skill.
-   - If rendered evidence or user review records a visible redesign — or any other page-slice-gate-triggered screen/surface/slice (a partial restyle, modernize, or visual-system change, not only a full redesign) — as `rejected`, do not continue toward commit/MR by polishing the rejected implementation. A missing or absent design verdict counts as `pending`, not acceptance, and blocks the same way. Re-enter `product-ui-ux-design`'s **Rejected-surface rule**, update the delivery artifact with the rejection and revised target, and only resume implementation after the new design checkpoint and acceptance baseline exist. The slice stays `design-rejected` — blocking complete, MR-ready, and any normal or draft MR until the re-rendered surface has a user or named independent design-owner `accepted` verdict per `product-ui-ux-design` (author self-pass cannot accept).
+   - For client or admin changes that touch request plumbing, headers, telemetry, storage adapters, service clients, or other non-rendered behavior without changing the rendered experience or user decision flow—including layout, copy, state, interaction, navigation, component semantics, accessibility/focus/keyboard behavior, or user-facing feedback/error handling—explicitly record `visible surface: no` and the reason. If any listed dimension changes, route it through the UI delivery contract.
+   - Before coding any visible UI change, load `references/design-routing-and-readiness.md` and its canonical `../product-ui-ux-design/references/delivery-contract.md`; create the applicable full Design brief or valid low-risk copy-only record and obtain Test Phase 0. Its handoff, runtime-proof, immutable-verdict, rejection, and review-only-draft boundaries are hard stops; a build or snapshot cannot imply design acceptance.
    - **Non-UI verification binds to the action, not only to the completion claim** (for non-UI code or test changes):
      - This is additive to and subordinate to the existing test rules: the verification-by-layer table below, `testing-strategy`'s MR test-matrix and blocking-runtime-gate rules, the `visible surface: no` classification, the report-only QA exception, and the closeout/landing-label rules remain authoritative and stricter wherever they apply; this gate never relaxes them.
      - Eligibility for "non-UI" is the explicit `visible surface: no` classification — user-facing error/empty/loading state, navigation, operation entry, or decision-flow changes are not non-UI.
      - Do not push to a shared branch or open a merge request until the test layer(s) the change's risk requires have run green on the final pushed state — re-run after the last code or test edit; green earlier in the turn does not count.
-     - The single exception is `pre-runtime-test ready`: when a blocking runtime/device/E2E layer's environment cannot be run here after the normal remediation path, the change may be handed off only if its lower layers and build are green, a named runtime/device owner is recorded, and the MR is opened draft / not-MR-ready (it must never be merged while only `pre-runtime-test ready`).
+     - The single exception is `pre-runtime-test-ready`: when a blocking runtime/device/E2E layer's environment cannot be run here after the normal remediation path, the change may be handed off only if its lower layers and build are green, a named runtime/device owner is recorded, and the MR is opened draft / not-MR-ready (it must never be merged while only `pre-runtime-test-ready`).
      - `blocked` (no owner or environment can run the gate) is a stop state, not a push/open-MR escape — do not push to a shared branch or open a normal MR under `blocked` unless the user has explicitly declared an evidence-only / report-only branch per `testing-strategy`.
      - A red build or red suite caused by the diff itself is never a handoff state and always blocks the action; merge always requires the blocking layers green.
      - Local or WIP commits — including a RED test-first commit during TDD — are exempt; the gate binds the shared-branch push and the MR. "executed" is insufficient; "green on the final pushed state" is the bar. This mirrors the visible-UI action gate above for non-rendered changes.
@@ -161,7 +159,7 @@ At each stage boundary, walk the per-stage entry-state enumeration in [Stage-Ent
    - If a user challenges the UI quality or asks whether the design skill was really followed, treat it as a design defect, not a preference dispute. Re-open `product-ui-ux-design` and its checklist, identify the violated design rule or missing rule, patch the UI first, then update the smallest owning skill or reference if the lesson is reusable.
    - For behavior changes, test-case-first is the default gate: write the test case before implementation, map it to the test layer and command, then add or update at least one failing/changed assertion and run it RED before coding. If no harness can support a RED test after normal remediation, record the blocker and strongest alternate check before implementation. If code was already changed before this gap is noticed, stop further implementation, add the missing test-case register, and report regression coverage honestly; do not claim TDD.
    - Verification must match risk — focused unit tests for narrow changes, integration/contract tests for cross-boundary changes, release checks for runtime-facing changes — routed through `testing-strategy` rather than redefining the split here. Code changes specifically must be tested: build, grep/static checks, typecheck, lint, manual checklist edits, and independent review/challenge are supporting evidence only; they do not replace tests. At least one relevant test layer must run for every code change before claiming complete/fixed/tested, and newly added tests must be executed in the same turn. If no relevant automated test can be created, run the strongest available host/runtime/manual scenario test and report the automation gap; if no meaningful test can be run, stop as blocked rather than completing the code change.
-   - Before calling an assessment-fix-test slice complete, report verification by layer (unit, integration/contract, E2E/host smoke, manual/exploratory, build/static, independent review); mark each missing layer `not applicable` or `blocked after remediation`. Do not collapse missing layers into a generic "verified by build", and do not use accepted risk to claim tested/fixed behavior when no relevant test ran. A layer that the step-3 test-layer decision table marks blocking blocks completion on failure or unavailability — do not reframe it as residual risk, accepted gap, or "ready". The only valid closeout labels are `complete` (all blocking gates pass), `pre-runtime-test ready` (code ready for named runtime/device handoff but not merge-ready, release-ready, or complete), or `blocked` (no owner/environment can run the gate).
+   - Before calling an assessment-fix-test slice complete, report verification by layer (unit, integration/contract, E2E/host smoke, manual/exploratory, build/static, independent review); mark each missing layer `not applicable` or `blocked after remediation`. Do not collapse missing layers into a generic "verified by build", and do not use accepted risk to claim tested/fixed behavior when no relevant test ran. A layer that the step-3 test-layer decision table marks blocking blocks completion on failure or unavailability — do not reframe it as residual risk, accepted gap, or "ready". The only valid closeout labels are `complete` (all blocking gates pass), `pre-runtime-test-ready` (code ready for named runtime/device handoff but not merge-ready, release-ready, or complete), or `blocked` (no owner/environment can run the gate).
    - Runtime-dependent client changes require runtime evidence from the affected host before completion. Browser/device/miniapp/app host smoke is blocking when the change touches platform APIs, lifecycle/foreground-background behavior, streaming/chunked transport, permissions/capabilities, navigation host semantics, storage/session restore, or rendered UI state that lower-layer tests cannot prove.
    - 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.
@@ -192,13 +190,13 @@ At each stage boundary, walk the per-stage entry-state enumeration in [Stage-Ent
 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).
 
 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: if it contradicts reality it is stale — stop, repair the status source first, and do NOT derive from the stale source or a git-log/grep scan; needing to grep history to guess the next slice is itself a stale-source signal** (`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 and 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, and never auto-continue past the pending gate. **Load `references/pre-final-continuation-gate.md` before treating any deferral as terminal** — it owns the full valid/invalid-anchor list and hardening boundary.
+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 when all of these are true: the next slice comes from an explicit status/task/acceptance source or active user continuation instruction, is low-risk, local-only or already-authenticated, within the current accepted scope, has clear ownership, can be verified with existing commands, and does not require destructive actions, an external purchase/financial commitment, production access, legal/compliance/product strategy decisions, or high-impact architecture choices. Existing internal developer self-use through configured metered model/tool accounts is not an external purchase for this gate.
-4. Stop only for an explicit stop/pause instruction, a user-requested status-only answer, a failed, pending, or inconclusive required or blocking gate, dirty/conflicting worktree that cannot be isolated, unavailable required environment after remediation, high-impact product/architecture/compliance decision, destructive action, an external purchase/financial commitment, unclear owner, ambiguous assent, missing stricter authorization, or no low-risk implied next slice.
-5. If stopping, state the concrete stop reason and the exact evidence checked; an assent-triggered `blocked:` outcome must use the required action/scope-plus-blocker form and classify the turn as `interim`. Ask one concise question in the same turn when ambiguity or missing authority is the blocker; an explicit stop/pause needs no reconfirmation. A `continuing:` outcome must proceed with the named slice before finalizing. A silent/completion-style stop is invalid. Do not send a completion-only, solved, fixed, or fully-closed final response after a merge/sync when a required review/challenge is pending or inconclusive; report the status as interim or blocked with the next unblock action.
-6. **Assent-outcome closeout check.** Before every final response in any turn of 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 contains no imperative/future/next-step wording and no affirmative reply is pending. A missing/multiple/conflicting marker forces a visible `blocked:`/`interim` outcome with one clarifying question; it can never produce `not-applicable`. Finally, 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.
+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.
+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, 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.
 
 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/code-review-checklist.md

@@ -66,6 +66,8 @@ Use this for a general product R&D review pass before merge or release. Stack-sp
 - **Review both negative space and concept delta.** Review from the original acceptance source, the acceptance-to-evidence closure table, the concept-to-current-need table, and the final diff; the diff alone cannot show required behavior that is absent.
 - For negative space, confirm every in-scope acceptance point maps to an implementation surface and fresh evidence. Reject silent omissions, implementer-created downscoping, and tests derived only from the code that happens to exist.
 - For concept delta, require every new abstraction, indirection, module/service, state/entity, dependency, config/flag, generalized path, or extension point to identify its current acceptance point or observed hard constraint and the simpler alternative considered. Reject hypothetical future reuse; allow refactoring and testability work tied to a current observed constraint.
+- Grade every stated guarantee at one of four levels — **strong / eventual / best-effort / unsupported** — and reject prose that presents a desired property as an implemented guarantee: "X is guaranteed" in a doc/comment/MR while the code delivers best-effort is a finding, not wording polish.
+- A "no impact when disabled / flag off" claim is verified by walking the disable paths, not by trusting the flag: check imports/side-effectful module init, startup/registration hooks, API surface exposure, shared state/schema touched, UI/entry visibility, and the flag-off runtime path itself (new parsing/computation/IO executed before returning the old result) — any of the six can leak behavior or cost while "disabled".
 - Reconcile the active acceptance-source stable ID set against the closeout table and verify every out/deferred row cites a real product/human decision. Accept two-axis `not-applicable` only for a reviewed documentation-only diff. For a pure refactor or mechanical maintenance with no contract/behavior delta, accept functional-axis `not-applicable` only with the concept-delta table still present. The implementer's label alone is never evidence, and diffs touching the behavior-bearing surface classes enumerated in `implementation-completeness-and-minimality.md` (contracts, schemas/migrations, permissions, quotas/pricing, config defaults, user-visible copy — that list is canonical) qualify for no exemption. A rejected classification returns the delivery to the implementer to build the required tables; do not reconstruct them in review.
 
 ## Testing And Evidence
@@ -84,3 +86,5 @@ Use this for a general product R&D review pass before merge or release. Stack-sp
 ## Review Output
 
 Lead with findings. For each issue include severity, file/line, impact, and suggested correction. If there are no findings, state residual risk and any verification gaps.
+
+Tag each load-bearing statement in the review by its evidence class — **Observed** (you observed the fact itself — ran the command, exercised the path, or read the code text — and the tag covers only what that observation proves: a runtime/concurrency/authorization property merely inferred from static code is Hypothesis until exercised; reading someone's assertion, including an implementer-authored CI or runtime claim, is Reported), **Reported** (a doc, comment, or another party asserts it), or **Hypothesis** (inferred, unverified) — and attach a suggested verification step to every non-Observed tag. An Observed tag carries its auditable receipt — the exact command or exercised path, scope/ref, and result — a bare "I exercised it" without the receipt downgrades to Reported. A review whose key claims are all Reported/Hypothesis is a reading summary, not review evidence.

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

@@ -172,7 +172,7 @@ Before release, confirm:
 
 ## Delivery Health Metrics（DORA software delivery metrics）
 
-评估 engineering delivery health 时用 DORA 系列 metrics（起源于 Forsgren / Humble / Kim *Accelerate* 2018，**模型随年度 State of DevOps Report 演进**）作可量化共同词汇。当前 DORA 模型为 5 metric：
+评估 engineering delivery health 时用 DORA 系列 metrics（起源于 2014 年 State of DevOps 研究；Forsgren / Humble / Kim *Accelerate* 2018 成书普及，**模型随年度 State of DevOps Report 演进**——演进史见 dora.dev/insights/dora-metrics-history）作可量化共同词汇。当前 DORA 模型为 5 metric：
 
 | Metric | 定义 | 备注 |
 |---|---|---|

package/dist/assets/marketplace/plugins/ccl-skills/skills/product-rd-workflow/references/design-routing-and-readiness.md

@@ -10,36 +10,32 @@ Use this reference when product work has a user-facing surface, interaction flow
 - The implementation could lock in a hard-to-change layout, data model presentation, or interaction contract.
 - The product needs a launch/readiness check for UI completeness, visual quality, or interaction polish.
 
-Small backend-only, CLI-only, config-only, or internal refactor tasks can skip design if user-facing behavior and acceptance are already clear.
+Small backend-only, parser/library-only CLI, config-only, or internal refactor tasks can skip design only when evidence proves they preserve every user-facing behavior and acceptance contract. Any changed command tree, subcommand, flag/default/action path, help/output/exit behavior, confirmation, progress, recovery, full-screen TUI, interactive terminal layout, ANSI state, or keyboard/focus flow is a user-facing terminal surface and does not qualify for that shortcut.
 
 ## Routing
 
-- Use `product-ui-ux-design` for product UI/UX design readiness across community, finance/data, AI workspaces, operational tools, Web, and App surfaces.
+- Use `product-ui-ux-design` for product UI/UX design readiness across Web, App, mini-program, desktop/native, terminal/TUI, and other user-facing surfaces.
 - Use scenario references inside that skill only when the target surface matches; community/feed/creator patterns are optional lenses, not the default model for every product.
 - Use Figma/design plugin skills when the task explicitly requires Figma file creation, design-system rules, component mapping, or design-to-code implementation.
 - Use UI/design review skills for visual QA, accessibility criteria, interaction polish, and launch-readiness review.
 - Keep product-rd-workflow responsible for sequencing, acceptance, and handoff evidence; do not duplicate detailed design-system rules here.
+- Use `../../product-ui-ux-design/references/delivery-contract.md` as the canonical design brief → test Phase 0 → producer/client execution → test Phase 1/sufficiency → design verdict record. Product R&D records the slice and sequencing decision; every changed producer and affected client writes its own runtime facts once, each client names the producer member/version it exercised, testing cites both record sets for sufficiency, and each owner fills only its part instead of restating a separate checkpoint.
 
 ## Design Readiness Evidence
 
-Before implementation, capture only the evidence proportional to risk:
+Before implementation, link one canonical delivery record, complete the applicable full Design brief or valid low-risk copy-only record, and obtain its Test selection Phase 0. This reference does not restate or partially fork the contract's schema. Record unresolved product decisions and their owner instead of filling a design gap with implementation convention.
 
-- target user/caller and primary workflow;
-- approved interaction model or wireflow for new/changed surfaces;
-- key states: empty, loading, error, success, permission denied, disabled, offline/timeout where relevant;
-- responsive/mobile expectations and accessibility constraints;
-- component/design-system reuse decisions and any intentional deviations;
-- for a visible-UI design checkpoint, also record: surface type, density mode, layout structure, trust/safety boundary, and visual acceptance criteria;
-- acceptance checks that engineering and QA can verify;
-- **cross-platform brand decisions when the same product surfaces on multiple stacks**: if the product intentionally renders different brand-primary values per platform (web vs native mobile vs mini-program), the product owner MUST record the decision explicitly — which value applies to which platform, why, and which named role in the design source carries each value (`colorPrimary-web` / `colorPrimary-native` / per-platform variable collection). Implicit "we just always used this color on Android" is the failure mode that downstream design + engineering audits keep re-discovering as drift. If the product owner decides the values should converge, that is also recorded with an owner and a target date. See `product-ui-ux-design/references/multi-project-token-consistency.md` Cross-platform brand divergence sub-case for the design-side check.
+Product-stage additions remain narrow:
 
-For dense web shells, app shells, creator workspaces, or AI/task-heavy surfaces, also capture navigation state ownership, permission-gated actions, active task/process visibility, long-label overflow behavior, global feedback placement, and how users return to their previous context after a modal, drawer, upload, generation, or detail view.
-
-For mobile surfaces, also capture safe-area behavior, keyboard avoidance, bottom navigation or sticky action behavior, update/consent dialogs, and whether errors appear inline, as toast, as a result page, or as a blocking dialog.
+- **Cross-platform brand decisions**: when the same product intentionally renders different brand-primary values per platform, the product owner records which value and named semantic role applies to each platform, why they differ, and the convergence owner/date when convergence is chosen. See `../../product-ui-ux-design/references/multi-project-token-consistency.md` for the design-side check.
+- **Dense workspaces**: select the operational/web risk lenses in `../../product-ui-ux-design/references/design-execution-checklist.md`; navigation ownership, permission-gated actions, active work, overflow, feedback placement, and return context belong in that design record rather than a second Product R&D checklist.
+- **Mobile surfaces**: select the mobile risk lens in the same router; safe area, keyboard, bottom actions/navigation, consent/update dialogs, feedback carrier, lifecycle, and recovery belong in its adaptation/state/evidence fields.
 
 ## Handoff Rules
 
 - Do not treat a vague mock, screenshot, or verbal idea as implementation-ready when states, copy, permissions, or responsive behavior are missing.
 - Do not require full design artifacts for tiny copy/state tweaks when acceptance checks are enough.
+- A visible slice may form a clearly labeled handoff commit or draft MR at `pre-runtime-test-ready` only when lower layers pass and the contract names the runtime owner and command. It is not MR-ready, merge-ready, complete, or accepted. Those stronger states require target-runtime inspection against the criteria, a complete design/test/producer/client candidate-binding set with the actually exercised versions, and an allowed verdict; builds, DOM existence, snapshots, and unreviewed screenshots prove only their stated oracle.
+- A `rejected` slice preserves its negative evidence and `rejection_basis`. A deterministic rejection permits only a failed-criterion-targeted fix, new binding, and invalidated-criterion rerun. A design-judgment or mixed rejection requires a revised target, fresh baseline/runtime evidence, and user or named independent verdict; isolated polish cannot clear it. Both paths block complete, MR-ready, merge-ready, and normal MR. A clearly labeled review-only draft MR may carry the revised bound candidate to the named independent design owner, but remains `candidate + blocked` and cannot merge until that owner records `accepted + complete`.
 - If design and architecture conflict, resolve sequence explicitly: user workflow and IA first, then service/API/data contracts that support it.
 - If design feedback reveals reusable rules, update the smallest correct design skill/reference rather than this workflow unless the lesson is about sequencing or handoff.

package/dist/assets/marketplace/plugins/ccl-skills/skills/product-rd-workflow/references/rd-standards-doc-family-checklist.md

@@ -13,6 +13,7 @@ Use this checklist for R&D standards, specs, guidelines, or Feishu/wiki doc fami
 7. If the family will drive project health checks, add a conformance appendix or sibling checklist that maps each rule to `deterministic`, `agent_review`, `manual`, or `not_automatable_yet`, with severity, evidence, command/prompt owner, and CI behavior. Route architecture fitness functions to `testing-strategy`; route directory-contract coverage to `agents-file-coverage-gate`; route stack mechanics to the owning stack skills.
 8. Before invoking `tighten-doc`, record `owner-ready` with the authority statement, doc-family layer, enumeration evidence, and conformance mapping evidence when applicable, or `blocked: family enumeration unverified`.
 9. Re-confirm the doc-set enumeration at completion/sign-off, or add the sync gate if the family has grown.
+10. Layer authority and write-back: when an execution-layer doc (runbook, repo-local execution Spec, checklist) conflicts with its governing Spec/guideline, the Spec wins the ruling AND the execution doc is corrected in the same change; when the execution doc is outside the change's write scope (other repo/owner), route the correction as a trackable item the receiving owner has accepted, and keep the cross-repo sync explicitly outstanding — the ruling is landed only when the execution doc is corrected or the accepted item is in the owner's queue with the drift marked open; a note naming an owner is not routing. Superseded rules inside a living doc are marked deprecated **with a date** and a replacement pointer, not silently deleted, so a reader can tell "current" from "was once true" (append-only ledgers keep their own stricter rules).
 
 ## Architecture / System-Overview Honesty Pass
 

package/dist/assets/marketplace/plugins/ccl-skills/skills/product-rd-workflow/references/verify-developer-experience.md

@@ -7,7 +7,7 @@ Use this reference when a delivery touches developer-facing surfaces — CLI, SD
 For a new or public developer surface, or a change touching onboarding, install/setup, first-success, defaults, error surfaces, or a breaking migration, prove DX by the measured onboarding journey: run the real discover→install→first-success path as a new user and capture steps, time-to-first-success, friction, and the actual error messages. Do not infer DX from README / feature-list quality.
 
 - A smaller change proves only its affected segment, or cites recent unchanged-journey evidence.
-- An unavailable real environment after remediation uses `testing-strategy`'s proportional / lowest-sufficient-layer model and `blocked` / `pre-runtime-test ready` handling — never a faked pass.
+- An unavailable real environment after remediation uses `testing-strategy`'s proportional / lowest-sufficient-layer model and `blocked` / `pre-runtime-test-ready` handling — never a faked pass.
 
 ## Error messages are a first-class acceptance item