@ccoalm/ccl-skills 0.1.0

package/dist/assets/marketplace/plugins/ccl-skills/skills/product-rd-workflow/references/implementation-entry-reentry-gate.md

@@ -0,0 +1,122 @@
+# Implementation Entry / Re-entry Gate
+
+Use this reference when a product R&D delivery is about to move from analysis, planning, or continuation into implementation. The entrypoint keeps the trigger and routing decisions; this reference carries the detailed mechanics.
+
+## Baseline Selection
+
+Use existing specs, implementation plans, assessment reports, issue or MR descriptions, or repo-local task docs only after either:
+
+- Reading them back.
+- Pointing to artifacts just produced in the current active session.
+
+Then check freshness, scope, owner skills, acceptance checks, tests, stop conditions, and landing state using the shared labels: `local status`, `MR-ready`, `landed`, `release-ready`, or `shared-status-ready`. Record the result as entry/re-entry and fill gaps before editing.
+
+An unmerged plan/spec that is already part of the current active delivery branch may remain the working baseline while that branch continues, under whichever landing label its actual evidence supports. Being pushed or attached to a draft/MR does not demote the current branch's own plan.
+
+A plan/spec belonging to a different line of work — a different branch, a prior superseded slice, or another delivery's pushed/draft/MR-ready artifact — is durable storage, not active baseline authority. It may orient the next action, but it cannot by itself select implementation work.
+
+For those external/unlanded artifacts from a different line of work, the default next slice is to make the review, merge, or status path explicit. Implementation may proceed from them only after the user explicitly selects that artifact as the working baseline and the response records that status.
+
+Explicit selection does not waive the freshness/reality check. Before a selected external/unlanded artifact drives implementation, reconcile it against landing evidence on the real target, repair or supersede stale status, and derive work only from named still-unlanded deltas. An artifact whose items are already landed or satisfied yields no implementation work, not a re-run.
+
+If no usable artifact exists, create the proportionate plan/spec before implementation. Only a simple low-risk single-file change may use a short inline plan.
+
+On a restart/redo of an in-flight delivery, if a prior design/spec/plan exists, recover it for context if available — read it back, including from git history if previously committed — then either reconcile with it or explicitly supersede it with a new/current spec. Discarding the design/spec itself needs an explicit user opt-out after clarification; record deviations in the restored/current spec, or in a restart note if the original artifact cannot be restored. Silently destroying the spec or developing plan-less on a restart without that opt-out is a delivery defect.
+
+## Bare Continuation Scan
+
+A bare "continue", "resume", or "go implement" is not a waiver when no active artifact has already been established and cited in the current session. A record that survives only in a context summary, compacted memory, or previous response residue is not establishment.
+
+When continuation may be resuming product-rd-scoped work, first verify a concrete signal on the real target:
+
+- A named, read-back spec, plan, assessment, or gate artifact.
+- A same-scope still-unlanded plan/spec/task doc visible on the current repo/worktree/branch.
+
+Record at least one low-cost scan as evidence, such as `git status --short --branch` plus `rg -n "(plan|spec|assessment|task|需求|方案|计划|规范)"`, hit or no-hit.
+
+Exclude only the off-tree artifact store that the request, branch/repo docs, or MR/issue explicitly names, such as Feishu, Bitable, or a linked repo. This is a bounded set, not a global search.
+
+An unambiguous narrow-owner continuation skips this scan. A context-summary-only or bare-continuation hint that cannot be tied to a concrete artifact pauses for confirmation or persistent-artifact recovery rather than coding.
+
+## Implementation Boundary Record
+
+Invoking or routing a slice to a stack/execution skill (`*-dev`, `*-architecture`, `multi-agent-delegation`, and similar) selects the executor. It is not establishment and is not permission to start implementing.
+
+Reading code to analyze is fine. The transition from analysis to the first implementation edit is the gate.
+
+Before that edit, record:
+
+- Active baseline.
+- Scope.
+- Implementation-mechanics owner for the slice.
+- Implementation-mechanics owner invoked/loaded in-session before the first implementation edit for hands-on product/stack code.
+- Which owner mechanical rules were triggered, or `triggered: none` with a one-line reason. Do not enumerate non-triggered rules.
+- `multi-agent-delegation` decision when delegation is plausible: `local`, `sequential delegation`, or `parallel delegation`. `local` needs a recorded reason when 2+ slices look independent. A delegating value additionally needs the in-session load, per the invoke bar below.
+- Visible-UI checkpoint when the surface is visible UI.
+- Short risk inventory routed to `feature-risk-router` when the slice touches money/quota, permission/access, data-isolation, write-finality, shared-gate, or unknown scope.
+- Test-case-first status.
+- Gate disposition: every pre-code gate above marked `triggered` or `not-applicable` with a reason — a complete accounting, not only the triggered gates.
+- Output form: a reviewable plan plus per-point acceptance-coverage matrix.
+
+### The invoke bar applies to every field that names an owner
+
+A boundary-record field that names an owner is filled only from that owner's in-session load, never from the decision alone. Writing the value is the act that feels like discharging the gate, so a field without this bar silently converts its owner gate into self-attestation — the record then reads complete while none of that owner's mechanical rules ever fired.
+
+The bar fires on the field's **triggered** values only, so a slice that legitimately needs none of these owners is not dragged through three loads:
+
+| Field | Invoke required when | No load needed when |
+|---|---|---|
+| Implementation-mechanics owner | hands-on product/stack code | `not-applicable`, or a recorded `owner-load: not-required` |
+| `multi-agent-delegation` decision | delegation is plausible at all — 2+ slices look independent — **including when the recorded value is `local`** | a genuinely single-slice task where nothing was delegable |
+| Visible-UI checkpoint | the surface is visible UI | non-visible surface |
+| `feature-risk-router` inventory | any listed risk class is present | `not-applicable` with the reason |
+
+`local` is the value that most looks like an exemption and is not one. Serial-versus-parallel is the delegation owner's own decision, taken after checking true independence, write-scope isolation, and the parent verification plan — so choosing `local` while 2+ slices look independent is exactly the owner-bearing judgment this bar exists for, and it is the one path the dispatch hook can never catch, because nothing is ever dispatched. A single-slice task with nothing delegable needs no load.
+
+Test-case-first status is deliberately **not** in that table: it names no owner, it is a status value, and recording it triggers no load. It is listed here only to close the set-diff explicitly, so a later reader does not mistake its absence for an oversight. When a slice needs an actual test-LAYER decision — which layer, what coverage, what fixtures — that judgment routes to `testing-strategy` under its own rules, not under this field's bar.
+
+Naming the owner, quoting its rules from memory, or having invoked it in an earlier unrelated session is not the load. The same reload triggers below apply per owner.
+
+The owner load is rule application, not ceremony. The stack/execution owner is the relevant `*-dev` skill, `not-applicable` with the reason, or `owner-load: not-required` for a simple low-risk single-file product/stack edit whose boundary record names why no owner mechanical-rule class can plausibly trigger. This exception must be surfaced at closeout, not silently skipped.
+
+Shared-skill and process-rule edits are out of this owner-load clause only — they follow `skill-extraction-workflow`'s gates instead of loading a stack `*-dev` owner — but they remain subject to the rest of the boundary record and to the shared-gate persistent-artifact requirement below.
+
+Two failure shapes this field closes:
+
+1. Silently inferring ownership from the repo's stack context.
+2. Naming or knowing the owner but coding from memory without loading it, so the owner's current mechanical rules never fire — directory `AGENTS.md` sync, generated-artifact handling, format/gen-before-attestation, idempotency mechanics — even when higher-level gates already passed.
+
+Loading an architecture/design owner is not loading the implementation-mechanics owner. Reload triggers in a long loop are narrow: a new owner/stack, a context resume/compaction with no visible owner-load evidence, or the owner skill file changed. Otherwise one in-session load covers later same-owner slices, cited in the next boundary record.
+
+This is a recognition-dependent firing-point sharpening, not a true mechanical gate. The backstops remain the completion-time check and user-signal escalation.
+
+## Design Gate and Risk Routing
+
+A visible-UI slice must invoke/load `product-ui-ux-design` in-session before the first edit, using the same name-to-invoke bar as the implementation-mechanics owner. Recording or naming the checkpoint from memory is not invoking it.
+
+Loading the implementation-mechanics owner, or any stack `*-dev`, is not loading the design-gate owner. This is the reverse of the architecture-vs-implementation note above.
+
+The record's depth follows the proportionality and persistence rules in the main workflow. A simple low-risk single-file change may mark gates satisfied or `not-applicable` in its short inline plan. Shared-gate, cross-repo, or high-risk changes that trigger the persistent-artifact rule need the concrete persistent artifact.
+
+A stack-skill invocation, worktree, or code-reading is not the boundary record. Reaching the first implementation edit without the boundary record is a process defect: pause, record the boundary, and report current state. This is the same firing point as a stale rule that exists but did not trigger.
+
+## Closeout Backstop
+
+A hands-on implementation slice reported done or merged with no visible in-session load of its implementation-mechanics owner is not process-complete. It owes a post-hoc owner-rule audit:
+
+- Load/read the owner.
+- Compare its mechanical-rule classes against the slice's actually touched surfaces.
+- Record applied, missed, or `not-applicable` per class.
+- Record follow-up before claiming the slice clean.
+
+A slice whose boundary record carries a valid `owner-load: not-required` exception is exempt from this post-hoc load, but closeout must still surface that recorded reason. A bare `missed: none` without touched-surface comparison is not a valid audit.
+
+The same completion-time audit applies to every owner whose boundary field was triggered, not only the implementation-mechanics owner. It governs slices whose boundary record is written under this rule — it does not reopen work already closed out under the narrower earlier bar. A slice completed before this extension is not retroactively process-incomplete; apply the wider audit from its next boundary record onward. A visible-UI slice reported done with no in-session `product-ui-ux-design` load owes a post-hoc design-gate audit; a slice that recorded a delegating `multi-agent-delegation` decision with no in-session load of that owner owes the same audit against its dispatch-blocking rules, and so does a triggered `feature-risk-router` inventory. Each stays process-incomplete until recorded. Test-case-first is excluded here for the same reason it is excluded from the table above.
+
+The git landing state, such as merged or MR-ready, is a separate fact that is not relabelled. A late token load does not clear the audit.
+
+Shared-skill changes follow `skill-extraction-workflow`'s stricter "no in-session extraction invocation ⇒ interim" closeout.
+
+An explicit, acknowledged gate opt-out follows the precedence order in the main workflow and must be recorded as such.
+
+Shared deterministic gate/verifier and cross-repo coordination-surface changes carry a stricter persistent-artifact requirement when they alter that surface's rule, scope, failure, or completion semantics. For those, a chat-only plan is not active and a concrete repo-local artifact path must be cited before implementation edits, as defined under the main workflow's *Enforce quality gates* bullet beginning "For product/spec normalization".

package/dist/assets/marketplace/plugins/ccl-skills/skills/product-rd-workflow/references/modular-monolith-heuristic.md

@@ -0,0 +1,105 @@
+# Modular Monolith vs Microservices — 决策启发
+
+不是"monolith 不好 / microservice 好"的争论，是**给当前阶段的项目选对结构**的启发清单。早期项目错误起步成 microservice = distributed monolith（最差形态）；成熟项目错把 monolith 撑过承载 = team / 部署 / scaling 受限。
+
+本 ref 给可观察 trigger 让团队知道**何时该 monolith / 何时该开始拆 / 不该拆**。
+
+## 外部来源
+
+- **Simon Brown**, "Modular Monolith" talks + *Software Architecture for Developers* (2014+) — modular monolith 概念命名
+- **Sam Newman**, *Building Microservices* (2nd ed 2021, O'Reilly) — Ch.3 splitting the monolith + when not to
+- **Martin Fowler**, "MonolithFirst" (martinfowler.com 2015) — start monolith, split when justified
+- **DDD bounded context** (Evans 2003) — split boundary 的语义基础
+
+---
+
+## §1 何时 monolith 更合适（默认起点）
+
+下列同时成立 → **modular monolith 起步**，不要 microservice。**数字阈值是本团队启发默认，非 Newman/Fowler/Brown 文献规定**；用证据覆盖默认（如 ops 成熟度足够 / 团队组织模式特殊 等）：
+
+- **团队 < 15 人**（默认值；Conway's law 给方向但不给具体数）：1 个工程团队内部，service-per-team 切分通常无必要
+- **bounded context 未稳定**：domain 模型还在变，service boundary 切了会反复挪
+- **flow 内 transaction 强一致需要**：跨多 service 的事务复杂度（saga / outbox）超过单 DB transaction 收益
+- **scale 尚未触界**：当前 / 预期 6 个月内单节点垂直扩展能撑（如 < 1k req/s / < 100k row table / < 数 TB 数据）
+- **release cadence 同步**：features 跨多模块联动发布是常态，不是个别例外
+
+### Modular monolith ≠ ball of mud
+**关键纪律**让 monolith 仍可演化：
+- **模块边界用 package / module 强制**：跨模块通信只走 public API 接口，不直接 `import` 内部
+- **Module-level fitness function**（见 `testing-strategy/references/fitness-functions.md`）：阻止跨模块违规依赖
+- **每模块自己的 DAL**：DB schema 按模块分组 / 表前缀
+- **预留 service split 接口**：模块间通信用 in-process function call，但 signature 像 RPC（可序列化、避免共享 mutable state）
+
+---
+
+## §2 何时开始拆 service
+
+下列**至少 2 个**同时成立 → 考虑开始拆某模块出去。**数字阈值是本团队启发默认（非文献规定），用证据覆盖**：
+
+| Trigger | 信号 |
+|---|---|
+| **Team scaling** | 团队 > 15 人（启发），要按 product line / 子系统分团队独立 release |
+| **Bounded context 稳定** | 该模块 6+ 个月没大改 boundary（启发），contract 清晰 |
+| **Independent release cadence** | 该模块 release 频率与主体差量级显著（启发：5x+，如主体周级、该模块小时级）|
+| **Scale heterogeneity** | 该模块 CPU / memory / DB load 比主体高量级显著（启发：10x+），需独立扩展 |
+| **不同 tech stack 收益明显** | 该模块用别的语言 / runtime 收益 > 拆分代价（如 ML 服务需 GPU + Python；rest 是 Go web）|
+| **独立故障隔离强需要** | 该模块挂不能拖垮主流程（如 payment / auth — 但要看真实流量分布，不是空想）|
+
+**不是 trigger 的 trigger**（这些**不**该作拆分理由）：
+- "感觉 monolith 太大了" — 量化 size 不是问题，coupling 才是
+- "想用 X 新框架" — 拆 service 是大成本，新框架可在 monolith 内引入
+- "面试问的都是 microservice" — 是 hiring 问题不是 architecture 问题
+- "CTO/技术总监 push microservice" — 让 Ta 给量化的 trigger，不是 mandate
+
+---
+
+## §3 不要拆的反信号（hard stop）
+
+下列任一成立 → **不**拆，先解决根因：
+
+- 团队 < 10 人 → 拆了反而每人维护多 service，运维成本陡增
+- bounded context 还在变 → 拆完发现切错位置，retrofit 比初始拆贵 3-5x
+- 跨模块强一致 transaction 是核心需求 → 拆完上 saga / 分布式事务，复杂度爆炸
+- 当前 ops / 可观察性基础设施 immature → 拆完 debug 黑盒。**最低 debug path** 要求：centralized log + 基础 metric + correlation ID + runbook；**distributed tracing 是 high-chatter / high-criticality 拆分必备**；service mesh 不是普遍前置（按场景按需）
+- **distributed monolith warning signs**：所有 service 必须同步部署 / 共享 DB / 互相 sync 调用密集 → 是 monolith 被假装成 microservice，最差形态
+
+---
+
+## §4 决策清单（在 ADR 里用）
+
+写 ADR "Service-X split from monolith" 时，§Context 段答这 7 问：
+
+1. 当前团队人数 + service 拆出后由谁维护？（< 2 人 owning team → 危险）
+2. 该模块 boundary 6 个月内变了几次？（> 1 次大变 → 暂缓）
+3. 该模块独立 release 频率 vs 主体频率比？
+4. 该模块对主体的 in-process call 路径数有多少？（高 = 拆后 RPC 噪声大）
+5. 该模块当前 DB 是否独享 schema？还是与主体共享表？（共享 → 拆 service 前先拆 schema）
+6. observability 基础设施满足该次拆分的 minimum debug path 吗？（参 §3 — central log + 基础 metric + correlation ID + runbook 是底线；distributed tracing 只在 high-chatter / high-criticality 拆分必备）
+7. 拆完 rollback 路径是什么？（无 rollback 路径 → 拆是单程，慎用）
+
+每问**给明确答案**或**标 N/A + 写 rationale**；未解决的 high-risk 项（如 1 + 6 — 维护者 owning team 缺 + 无 observability 基础）阻止 ADR Accepted。低风险拆分（如 vendor / runtime 隔离 / team-owned 抽取）部分问题 N/A 是常态。
+
+---
+
+## §5 渐进迁移 default menu（不是 big-bang，且不一定按下序）
+
+如果当前 monolith 大且 §2 多 trigger 成立，下面是**常见 default 顺序**；真实迁移可能先拆 read replica / event stream / runtime 而非按 schema 起步。按场景选起手：
+
+1. **强化模块边界**（数周）：先在 monolith 内把模块边界用 package / fitness function 锁死 — 这本身就解决很多问题，可能消除拆分需求
+2. **抽 anti-corruption layer**（数周）：模块间通信接口标准化（in-process），signature 像 RPC
+3. **抽 DB schema**（月级）：该模块用独立 schema / 独立 DB instance，但仍 in-process
+4. **拆出 service**（月级到季度级）：上面 3 步都做完后，service 化只是部署形态变化，业务代码改动小
+5. **观察 + 决定继续 or rollback**：拆完 N 个月看 §2 trigger 是否真消退，没消退 = 拆错了，回 monolith
+
+每步独立可 ADR + rollback。big-bang 不可。
+
+---
+
+## §6 故意不借鉴
+
+| 概念 | 原因 |
+|---|---|
+| Team Topologies 全套 operating model（Skelton 2019）| 本团队规模未到完整采用门槛 — 但**借 vocabulary**（team ownership boundary / cognitive load / stream-aligned vs platform team）在跨团队职责讨论时仍有用 |
+| Service mesh / sidecar 选型决策 | 是拆 service 后的实施细节，归 `platform-service-connectivity` |
+| Saga / outbox pattern 实现 | 是拆 service 后的具体技术，归 `go-microservice-architecture` / `python-service-architecture` |
+| DDD strategic patterns 全套（context map / anticorruption layer / shared kernel 等）| 太学院；本 ref 取 bounded context 概念即可 |

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

@@ -0,0 +1,115 @@
+# Pre-final continuation gate
+
+Use this reference for finalization and continuation checks after a delivery slice lands.
+
+Status-document freshness and live tracker shape remain owned by `status-tracker-sync.md`. This reference governs the landing-state proof, deferred runtime evidence, and continuation-stop classification.
+
+## Landing-state proof (gate step 1 mechanics)
+
+Confirm the landing state from real evidence — local branch, remote sync, MR/review artifact, CI/pipeline status when applicable, independent review/challenge status when required, product/status doc sync when the slice changes shared roadmap or readiness, and dirty worktree state — using this sequence:
+
+- **For behavior-changing product delivery, refuse implementation completion without both closure tables.** Reconcile the active acceptance IDs against the acceptance-to-evidence table, review the concept-delta table against the final diff, and keep `gap` / `blocked` / `unknown` rows blocking. A reviewed documentation-only diff may mark both axes `not-applicable`; a reviewed pure-refactor or mechanical-maintenance diff with no contract/behavior delta exempts only the functional axis and still carries its concept-delta table (or `none` row); the classification comes from the reviewed diff, never from the implementer's label alone. Record the closeout artifact and reviewed diff identity.
+- **Discover the status surfaces.** After any delivery slice lands or reaches pending-MR handoff, discover agent-consumed status/tracker/next-step documents from this bounded checklist: agent contract, README, repo-local handoff/status files, status-source validators, explicit user/context pointers, external issue/tracker/status sources used in step 2, and any recorded deferred-item path/ref. Report each class with its ref/result or concrete negative evidence — the checked path/glob, an absent contract field, an external tracker still unavailable after remediation, or an inspected scope showing no such surface; an undocumented or unverifiable absence/applicability claim is a blocking gap. Other plausible surfaces may be noted as best-effort context, but once found they reconcile and can block like any other agent-consumed status source.
+- **Prove the landing before reading any document**, by where the slice lives. In every path, content/tree/patch equivalence may corroborate scope but never by itself proves the slice landed.
+  - *Remote-backed* (the default unless local-only is proven by no remote tracking ref and no MR/PR/platform review): fetch/update the target ref from its remote immediately before classifying the slice landed or pending. If the fetch fails, retry once and check one alternate platform ref only as diagnostic evidence, then report `inconclusive — remote unavailable` and stop — do not fall back to a local ref. Treat the slice as landed only when the freshly fetched target ref contains the slice commit, or platform merged evidence is paired with a reachable merge/squash (or equivalent platform-produced) commit reachable from that fetched target. Read the document from that target ref; an unfetched local ref, pre-merge branch copy, or MR description alone is not enough.
+  - *Local-only*: name the authoritative local target ref and verify it contains the slice by commit ancestry or an actual merge commit before reading the document there. If that verification fails, report `inconclusive — landing unverified` and stop.
+  - *Pending MR / unmerged branch*: reconcile the document against both the MR head/branch ref and the freshly fetched target ref. "Not yet on the target ref" is not stale; a next-step pointer to work already landed on the target ref is stale.
+- **Report and re-classify.** If a document exists, report the ref/SHA read and its current/next-step state. Scan every present status surface plus any exact path/ref cited by previously recorded deferred merge-closeout items, and re-classify every next-step/status pointer that asserts current/landed/unstarted state against fresh ref state — not only recorded deferred items. Future/planned items are exempt only when their text and fresh-ref evidence make no current/landed/unstarted claim. A deferred item without a concrete path/ref, or a previously cited deferred path/ref that is no longer locatable, is a blocking gap until re-located or re-recorded with one. For each deferred item, refresh its MR/PR state and target ref, then apply the landing proof above before deciding it is merged.
+- **Repair stale status before deriving or finalizing.** When a status surface contradicts the landing evidence for the ref being checked — it points at an already-merged/pushed/completed next step, marks landed work as pending/unstarted, or a deferred item is proven merged — run a status-source repair slice first, then mark the item resolved with the repair ref/SHA and keep the audit trail. Run the repair on a non-default branch/ref distinct from the old MR head: any push to an MR head invalidates that MR's merge authorization, which must then be re-requested (exception: under a batch merge grant — "批量合并 N" — commits the agent itself pushes while executing the presented release plan stay within the authorization; see `worktree-isolation` 合并执行协议). If the repository has no discoverable status source but a deferred item must be recorded, create or update a repo-local handoff/status artifact on a non-default branch/ref distinct from the MR head (or in an explicitly user-sanctioned external status repo) and cite its path/ref.
+- **Pending-MR deferral.** Only status changes that flip solely because the merge has not happened yet may be deferred, and only when proven by a committed/pushed post-merge diff/repair artifact; if that proof is missing or unverified, treat the item as a blocking stale-status gap. Do not push these at-merge-time-only changes to the MR head — that would void its live merge authorization (single-form; a batch grant's in-plan agent pushes are the documented exception, see `worktree-isolation` 合并执行协议) — so record the deferred merge-closeout items in a discovered status artifact/ref on a non-default branch/ref distinct from the MR head, verify the committed/pushed record there, and report the turn as `pending-MR handoff, merge outstanding`, not complete. If the MR closes without merge, mark the deferred item dropped/superseded and record the closure ref instead of applying the repair. Authorization preservation never overrides a stale-status blocker: if the document affirmatively contradicts the MR head/branch or target-ref reality, either repair it (invalidating and re-requesting authorization) or stop and report the blocker — never merge it as-is.
+
+## Deferred real evidence
+
+`DFE-CONT` applies when real or runtime evidence is due and not closed:
+
+- Named by an acceptance item, status source, landing-evidence row, required gate, user correction, or the behavior's only meaningful proof.
+- Deferred, blocked by unavailable runtime/service/cluster/credential/release access, skipped at finalization, or replaced by local/mock verification.
+- `unavailable` only after the host's normal blocked-verification remediation path has failed.
+
+Evidence is **pending**, not deferred, when the command is runnable this turn with available access and simply has not run yet; no named requirement makes it optional.
+
+Evidence is **optional** only when no acceptance item, status requirement, landing evidence, gate, user correction, or current-slice requirement covers it.
+
+## Terminal deferral anchors
+
+Report deferred real evidence as `interim` / outstanding until a valid non-agent anchor closes it.
+
+A local/mock substitution or deferral can be terminal only when a cited **non-agent** anchor:
+
+- Names the same evidence command/source or behavior.
+- Declares the substitution/deferral terminal.
+
+Valid anchors:
+
+- Exact user utterance.
+- User-authored status item for the active slice/ref.
+- Status item carrying an explicit cited user approval ref/utterance.
+- Named later gate, such as `feature-risk-router`, whose ownership is set by one of those non-agent sources.
+
+Invalid anchors:
+
+- Agent-authored or agent-co-edited status/router/gate/handoff text from the same engagement.
+- A status item created or modified by the agent to grant itself permission.
+- A gate introduced or routed by the agent and then cited as permission.
+
+When the anchor is valid and carries the outstanding command/source forward for the active slice/ref, report `deferred-to-<gate>` / `deferred-accepted`.
+
+If it does not carry the outstanding command/source forward, keep the status `interim`.
+
+## Local/mock progress
+
+A cited local/mock gate counts as separate progress only when both are true:
+
+- It exercises a different command or harness from the deferred command.
+- It proves a blocker that does not need the deferred runtime, credential, or cluster path.
+
+If it exercises the same acceptance, the deferred item remains outstanding.
+
+## Hardening boundary
+
+Do not add verifier/config/test hardening solely because deferred real evidence is still missing.
+
+Hardening requires a non-agent-authored, pre-existing input:
+
+- Status-source acceptance path/ref.
+- Named `feature-risk-router` or verification-owner gate with required evidence.
+- Fresh failure from a pre-existing local gate that predates this slice, is independent of the deferred path, and covers a different acceptance.
+
+Tests asserting this slice's own implemented behavior remain allowed under normal verification rules when they are independent of the deferred command.
+
+Otherwise stop polishing that gate, re-enter the status source, and continue only with other in-scope work under the normal continue/stop conditions.
+
+Never auto-continue past a pending blocking or required gate, and never claim deferred evidence is closed.
+
+If over-polishing around deferred evidence recurs, or the user flags it as a reusable process failure, route the lesson through `skill-extraction-workflow`.
+
+## 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:
+
+- 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.
+
+## 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.
+
+- 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.
+
+## Status-source reconciliation (gate step 2 mechanics)
+
+Before deriving the next slice from a status source, reconcile it against the applicable current branch/MR/merge/CI/tag state (the landing evidence from step 1, not history-mining). Contradiction shapes: the source claims unstarted/old-version/stub work that is already implemented or merged, or the reverse — either way it is stale. On stale: stop, run a status-source repair slice before inferring anything (repair mechanics in *Landing-state proof* above), and do NOT derive the next slice from the stale source or from a git-log/grep scan. Needing to grep history to guess the next slice is itself a stale-status-source signal, not normal flow. If no status source exists, a touched-repository scan may identify only a candidate next step; do not auto-continue from that candidate unless the user has already given an active continuation instruction for the same product scope.
+
+## 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.
+
+Binding detail:
+
+- Internal developer self-use through already configured model/tool accounts is an ordinary execution detail: it requires no separate quota/cost disclosure, estimate, cap, or per-run confirmation.
+- Assent never replaces an owner gate's stricter authorization form and never broadens scope or implies an external purchase/financial commitment, merge, publish, destructive, production, external-message, or high-impact-decision authority.

package/dist/assets/marketplace/plugins/ccl-skills/skills/product-rd-workflow/references/problem-resolution-and-learning.md

@@ -0,0 +1,62 @@
+# Problem Resolution And Learning
+
+Use this when a bug, failed test, flaky behavior, production symptom, review finding, or repeated confusion appears.
+
+Prefer the dedicated skills for active work:
+
+- Use `defect-diagnosis` for reproduction, isolation, instrumentation, fixing, regression verification, 5Why, and prevention design. Use `skill-extraction-workflow` to generalize and land durable skill/reference updates.
+
+## Non-Negotiable Rules
+
+- Do not skip the problem because another path appears to work.
+- Do not delete, comment out, or weaken a failing test just to make the suite pass.
+- Do not treat a workaround as the fix unless the original issue is explicitly deprioritized by an owner and residual risk is recorded.
+- Do not start broad refactoring while the root cause is unknown; first isolate and fix the defect, then refactor if useful.
+
+## Seven-Step Debug Flow
+
+1. Reproduce: record exact steps, inputs, environment, logs, and whether it reproduces consistently.
+2. Isolate: narrow the failing layer, change, dependency, or condition. Use minimal reproduction or bisect when useful.
+3. Hypothesize: state concrete, testable causes and what evidence would prove each one.
+4. Instrument: add targeted logs, assertions, traces, metrics, or local probes. Avoid noisy logging that hides signal.
+5. Verify cause: prove or reject each hypothesis. If wrong, return to hypothesis rather than guessing.
+6. Fix minimally: address the root cause first. Keep unrelated cleanup separate.
+7. Regression test: add or update a test that fails before the fix and passes after it when feasible.
+
+## Five-Why Root Cause
+
+Use five-why analysis after the immediate failure is understood:
+
+- Why did the observable failure happen?
+- Why did the code/process allow that condition?
+- Why did tests/review/monitoring miss it?
+- Why was the assumption or contract unclear?
+- What reusable rule, guard, or skill update prevents repetition?
+
+Stop when the answer points to a durable prevention mechanism, not when it only names the broken line of code.
+
+## Evidence To Capture
+
+- user-visible symptom or failing command.
+- reproduction steps and inputs.
+- relevant logs, traces, screenshots, payloads, or database/cache state.
+- root cause and rejected hypotheses.
+- fix summary and verification command/result.
+- regression test or reason it is not feasible.
+- follow-up skill/reference update, if the lesson is reusable.
+
+## Learning Routing
+
+Update the smallest correct durable place:
+
+- Product workflow issue: update `product-rd-workflow`.
+- Go backend architecture issue: update `go-microservice-architecture`.
+- Go backend implementation, testing, codegen, DB, Redis, MQ, or protobuf issue: update `go-microservice-dev` references.
+- Python backend, AI-service host, worker, SDK/package, or batch-job architecture issue: update `python-service-architecture`.
+- Python implementation, pytest, packaging, schema, ORM/migration, Redis, queue, async, or service-wiring issue: update `python-service-dev` references.
+- UI/product interaction issue: update the relevant design or frontend skill.
+- One-off business/domain issue: do not turn it into a generic skill rule.
+
+For extraction mechanics, source triage, conflict resolution, business-leakage cleanup, pressure-scenario validation, or landing discipline, use `skill-extraction-workflow`.
+
+When in doubt, write a concise new rule only if it would change future behavior on another product.

package/dist/assets/marketplace/plugins/ccl-skills/skills/product-rd-workflow/references/quality-attributes.md

@@ -0,0 +1,112 @@
+# Quality Attributes — 架构 trade-off 共同词汇
+
+架构选择本质是 trade-off — A 增强常对 B 让位。没共同词汇就只能口头辩论 "好不好"。本 ref 提供 ISO/IEC 25010 + Bass et al. SEI 经典分类作 trade-off 讨论的 baseline 词汇。
+
+不是新方法论，是 vocabulary checklist — 用在 ADR Context/Consequences、arch review、design proposal。
+
+## 外部来源
+
+- **ISO/IEC 25010:2023** (Systems and software Quality Requirements and Evaluation, SQuaRE; 2023-11 ed.2，撤回 2011 版) — 9 个 product quality characteristics 标准；本 ref §2 列的是常用 8 类 + sub-characteristics 子集，未完全 enumerate 2023 全部 9 类与所有 sub-characteristic
+- **Bass / Clements / Kazman**, *Software Architecture in Practice* (4th ed 2021, SEI Series, Addison-Wesley) — quality attribute scenarios + tactics
+- **Mark Richards / Neal Ford**, *Fundamentals of Software Architecture* (O'Reilly 2020) — architecture characteristics taxonomy
+
+---
+
+## §1 为什么用这套词汇
+
+**反例**（无 vocabulary）：
+> "这个方案不够 robust" / "我觉得 maintainability 更重要" / "这样性能会差"
+
+**用 vocabulary 后**：
+> "方案 A 优化 throughput（每秒 N req）但牺牲 modifiability（新加 field 需改 3 处）；当前阶段（feature 探索期）modifiability > throughput，建议 A 修 throughput 留后期。"
+
+vocabulary 让 trade-off 具体到 attribute pair + 当前 priority，可在 ADR Consequences 字段精确记录。
+
+---
+
+## §2 ISO 25010 八大类 + 子类
+
+| 顶级 attribute | 子类（常用）|
+|---|---|
+| **Functional suitability** | functional completeness / correctness / appropriateness |
+| **Performance efficiency** | time behavior（latency / throughput）/ resource utilization / capacity |
+| **Compatibility** | co-existence / interoperability |
+| **Usability** | learnability / operability / accessibility / UI aesthetics / user error protection |
+| **Reliability** | maturity / availability / fault tolerance / recoverability |
+| **Security** | confidentiality / integrity / non-repudiation / authenticity / accountability |
+| **Maintainability** | modularity / reusability / analyzability / modifiability / testability |
+| **Portability** | adaptability / installability / replaceability |
+
+加 Bass et al. 常用补充：
+- **Modifiability** = maintainability 子类，但本身是常用 trade-off 轴
+- **Deployability** = 不在 25010，业内常补（独立 release 频率 / 灰度能力 / rollback 时长）
+- **Observability** = 不在 25010，业内常补（log / metric / trace 三件套覆盖度）
+
+---
+
+## §3 常见 trade-off tensions（常见张力，非铁律）
+
+下表是设计 / 评审中常见的 trade-off 张力对。**注意**：不是物理铁律 —
+- CAP 在 partition 时才强制 C-A 二选；正常 operation 下两者可共存
+- Throughput / Latency 是同一系统不同 workload / 设计下的 trade-off，不是绝对反相关（Little's Law 把它们关联）
+
+把这些当 "**讨论起点 + 常见张力提醒**"，不是 "选 A 必牺牲 B" 的数学律。
+
+| Trade-off 对 | 典型选择 |
+|---|---|
+| **Security vs Usability** | 强 auth flow vs onboarding 摩擦低 |
+| **Performance vs Modifiability** | hand-tune SQL/缓存 vs 通用 ORM 抽象 |
+| **Consistency vs Availability** | 强一致 vs partition 时高可用（CAP 经典）|
+| **Time-to-market vs Maintainability** | 快上 vs 长期改动成本低 |
+| **Throughput vs Latency** | batch 大 vs 单请求小 |
+| **Flexibility vs Simplicity** | plug-in 架构 vs 单一实现 |
+| **Cost vs Reliability** | 单 region vs 跨 region active-active |
+
+ADR Context 段应**声明本决定哪些 attribute 优先**（最多 3 个 — > 3 = 没真选）；Consequences 段写**为优先项让位的 attribute** + 后果可承受度。
+
+---
+
+## §4 在 ADR / arch review 怎么用
+
+### 4.1 Context 段
+> "当前阶段（pre-PMF 探索期）我们优先 modifiability + time-to-market；可接受 performance 和 operational complexity 的暂时妥协。"
+
+### 4.2 Consequences 段
+> "正面：modifiability 高（新字段 < 1 day）/ 部署简单（单 binary）。负面：performance 中等（p99 ~300ms 而非目标 100ms）/ scalability 受限（垂直扩展上限 ~10x 当前流量）。两者 6 个月内可承受；超过则触发 §5 fitness function 警报。"
+
+### 4.3 arch review 用 quality attribute scenarios（Bass et al.）
+每条 scenario 含 6 字段：source / stimulus / artifact / environment / response / response measure。
+
+例：
+> source: 新订单 burst<br>
+> stimulus: 1000 req/s 持续 5 分钟<br>
+> artifact: order-service<br>
+> environment: normal operation<br>
+> response: 全 request 处理完 + 无数据丢失<br>
+> response measure: p99 < 500ms, error rate < 0.1%
+
+scenario 比"performance 要好"具体得多，可作 acceptance 测试 input（→ §5 fitness functions）。
+
+---
+
+## §5 与现有 skill 的映射
+
+| Attribute 类 | 谁验证 / owner |
+|---|---|
+| Functional suitability | `testing-strategy` + stack-dev 单测 |
+| Performance efficiency | `testing-strategy` (perf 测试段) + `platform-observability` (运行时监控) |
+| Reliability / availability | `platform-release-engineering` + `platform-service-connectivity` |
+| Security | （目前散在各 skill；待将来抽独立的安全评审 skill）|
+| Maintainability / Modifiability | code review + `testing-strategy/references/fitness-functions.md` |
+| Deployability | `platform-release-engineering` |
+| Observability | `platform-observability` |
+
+---
+
+## §6 故意不借鉴
+
+| 概念 | 原因 |
+|---|---|
+| ISO 25010 完整 sub-characteristics 全 enumerate（~31 个）| 太细；§2 列的子类够日常用 |
+| ATAM (Architecture Tradeoff Analysis Method, SEI 2000) 完整流程 | 适合大企业 ~10 人参与的 architecture review，本团队规模过 heavy |
+| CBAM (Cost Benefit Analysis Method) | 同 ATAM，重；本团队用 ADR Consequences 段直接记 trade-off 即可 |