Product Rd Workflow

---
name: product-rd-workflow
description: 加功能 / 新需求 / 技术方案 / 方案评估 / 技术选型 / 可行性评估 / 工作量评估 / 多阶段重构 / 推倒重来 / 重新开发 / 完全重新开始 / 清除代码重新开发 / redo-from-scratch / 项目分析 / spec·PRD·需求文档实质内容写错要改对（substance 修正） / 方案评审通过开始实现 / 进入实现阶段 → end-to-end product R&D router for requirement shaping, spec/plan, implementation gates, assessment, redo/refactor, and multi-stack standards.
---

# Product R&D Workflow

Use this skill as the top-level workflow for new product development, feature delivery, bug handling, refactoring, release preparation, or repeated process improvement. It is not a replacement for stack-specific skills; it decides which skill should own each stage and what evidence is required before moving on.

**Entry precedence.** For any product idea, feature delivery, release, cross-cutting refactor, or a **restart/redo of an in-flight delivery**, invoke this workflow first to classify and route — naming a stack/execution skill (e.g. `web-react-dev`, `multi-agent-delegation`) does not by itself skip this workflow's lifecycle gates (design / test / release / acceptance); those still apply unless already covered.

**Continuation-proposal output contract (session-wide for product delivery).** Every assistant message in a delivery session routed by or through this workflow carries exactly one literal line until the user explicitly ends/pauses the delivery or changes scope: `proposed-next: <action and scope>` when the message has imperative/future/next-step wording or a proposed action, otherwise `proposed-next: none — status only`. At the start of every subsequent user turn, read that line before interpreting the reply: absence, multiplicity, or a marker/wording conflict enters `blocked:`/`interim` by default, never `not-applicable`. Coverage detail and the host-layer caveat: `references/pre-final-continuation-gate.md` (Continuation-proposal output contract).

- **Restart/redo of an in-flight delivery** (清除代码重新开发 / 完全重新开始 / 推倒重来 / redo-from-scratch): a restart is a fresh delivery entry; mid-delivery coding momentum is NOT a license to skip re-classification and re-enter. Re-entry means re-ESTABLISH the plan and develop against it, not code from memory — "丢脚手架 / 重来" defaults to discarding CODE, not the design/spec artifact; discarding the design/spec itself needs an explicit user opt-out after clarification (an explicit instruction to drop the design always wins). Recovery mechanics and deviation recording live in `references/implementation-entry-reentry-gate.md` §Baseline Selection.
- **Implementation entry / re-entry gate (active plan/spec required by default).** For product R&D deliveries that stay in this workflow, "start development" means first establish the current executable artifact set, then code against it; requests routed straight to another owning skill by the *Go straight to the owning skill* bullet below use that owner's entry rules instead. Use existing specs, implementation plans, assessment reports, issue/MR descriptions, or repo-local task docs only after reading them back or citing artifacts just produced in the active session, then checking freshness, scope, owner skills, acceptance checks, tests, stop conditions, and **landing state** (`local status`, `MR-ready`, `landed`, `release-ready`, or `shared-status-ready`). Full mechanics for every case below live in `references/implementation-entry-reentry-gate.md`.
  - 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, 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).
- For delegated agent execution, `multi-agent-delegation` owns the execution recipe and worker verification while this workflow owns the lifecycle gate and acceptance boundary; delegated agents resuming after a pause must receive or re-verify the current plan/spec artifact set before editing.
- For multi-repo delivery, or any delivery that changes remote branch, MR, pipeline, release, or deployable-artifact state, maintain a compact per-changed-unit delivery-status ledger (row schema + persistence rules in `references/status-tracker-sync.md`) before claiming done, recommending MR/merge, or choosing the next slice. A required verification/review gate passes only when its state is `success`, `not-applicable`, or `not-required`; any other state blocks a done/merge recommendation, so remediate, wait to a terminal state, or report the delivery as pending with the unblock action. Residual-risk acceptance by the user only permits the recommendation/handoff label for that concrete action; it does **not** authorize merge, auto-merge, default-branch push, or cleanup, which still require the user's explicit merge instruction for the current MR (per `worktree-isolation`). Small local-only multi-file edits use the normal concise status unless they introduce remote, CI, MR, release, or deployable-artifact state.
- **Precedence order:** explicit user instruction > this workflow's stage/gate ownership > lower-priority default behavior from optional skill packages — but naming a stack/execution skill to carry out delivery work is not itself an instruction to waive those gates; a gate opt-out must be stated as such. See *External Skill Augmentation* for how external skills supplement specific disciplines without taking over ownership.

## Scope

- Product and requirement shaping: clarify user workflow, success criteria, non-goals, constraints, and acceptance checks. When shaping a feature, build a per-point **acceptance-coverage matrix** — one independently-failable behavior = one point, plus the risk points it touches, each mapped to an observable pass/fail acceptance check; an owning spec that already carries this coverage satisfies the gate when referenced **per point** (name which section covers each point; unnamed/stale points are gaps to fill) — don't re-author it. Risk-point enumeration and observable-criteria detail live in `references/delivery-lifecycle.md` §Product Shaping Checklist.
- **Implementation completeness/minimality gate.** For behavior-changing delivery this gate fires — functional completeness and structural minimality are independent gates — and gaps block `complete` — **load `references/implementation-completeness-and-minimality.md` before the mapping**: map every in-scope acceptance point to implementation plus fresh evidence, and speculative future need and omitted required behavior both fail — the independent-gates rule and the acceptance/concept matrices live there, and every retained new concept must map to a current acceptance point or hard constraint.
- Product requirement artifacts: route clarification to `requirement-intent`, conditionally-required current-state evidence to `requirement-baseline`, scope/version/appetite to `requirement-scope`, and Ready-only human-readable PRD assembly to `requirement-doc-writer`. All four use the canonical `requirement-doc-writer/references/requirement-closure-contract.md`. In active delivery, each narrow artifact returns here after completion; only a standalone non-PRD narrow artifact may return directly to the user. “只写个 PRD / 不走流程”仍需 lifecycle-issued Ready；WIP/会议材料不得命名为 PRD. This workflow owns the complete lifecycle's `PRD Ready` / `PRD Not Ready` verdict and cross-owner closure coordination.
- Design routing: decide when interaction, information architecture, visual system, design-system, or UX acceptance work must happen before implementation.
- Architecture routing: decide when architecture work is needed before implementation.
- Development routing: invoke stack-specific skills for implementation details, such as `app-cross-platform-dev` for Flutter/Android/iOS apps, `miniapp-product-dev` for WeChat/Alipay/Douyin/Baidu mini-programs, `web-react-dev` for React web, `terminal-cli-dev` for terminal/TUI product surfaces and CLI interface design (the rendered interface — layout, input, ANSI, scrollback — plus the command/subcommand/flag/help contract, which it owns even when nothing is rendered); CLI/tooling implementation without terminal-UI concerns must go to that language's dev skill when one owns it (`go-microservice-dev`, `python-service-dev`) and must not fall back to `terminal-cli-dev` merely because the deliverable is a command; a CLI in a language with no such dev owner stays with `terminal-cli-dev` as the default CLI owner, `go-microservice-architecture`/`go-microservice-dev` for Go services, and `python-service-architecture`/`python-service-dev` for Python services.
- Quality discipline: define test scope, review scope, release checks, and bug-fix verification.
- Defect routing: use `defect-diagnosis` for hands-on reproduction, isolation, instrumentation, fix, regression verification, root-cause analysis, and prevention routing.
- Research routing: For research groundwork behind a selection or assessment decision (技术选型、方案评估前的主题调研), this workflow must call `multi-perspective-research` for an evidence-grounded brief; the verdict itself stays with this workflow's gates.
- Existing-project assessment routing: for requests that ask to analyze a repository, product codebase, or project quality across architecture, implementation, tests, UI/UX, bugs, or risks, run codebase understanding first, then route each assessment dimension to the smallest owning skill instead of treating understanding as the final answer.
- AI/algorithm product launch discipline: for new/iterative algorithm capabilities, require product goal, business acceptance baseline, offline evaluation baseline, engineering serving baseline, rollout/rollback plan, and risk owner before launch. The workflow owns the gate; `llm-inference-integration`, testing, release, and stack skills own their narrower execution details.
- User-visible tips, nudges, release notes, and update notices: treat these as product surfaces, not harmless copy — define audience, eligibility, suppression rules, user-disable path, freshness label, repeat/cooldown policy, maximum interruption level, and success/abuse metrics before launch. Context-derived tips need a privacy review of what local behavior, files, tools, account state, or capability signals may influence eligibility; incomplete, stale, or cached update data must not imply completeness/freshness. Route terminal rendering to `terminal-cli-dev`, visual hierarchy/accessibility to `product-ui-ux-design`, behavior-changing defaults/migrations to `platform-release-engineering`, analytics/diagnostic redaction to `platform-observability`, scenario coverage to `testing-strategy`.
- **Developer-facing surfaces** (CLI / SDK / library / public API / developer docs): the user is a developer, so developer experience is an acceptance dimension. **For a new/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; do not infer DX from README / feature-list quality. Error messages are a first-class acceptance item; a non-safety default needs a safe override or a documented no-escape rationale; a **safety / security default stays fail-closed** (widening needs risk-owner approval; DX never licenses an `--insecure` bypass); breaking changes need a migration path. Journey metrics, segment proof, blocked handling, and per-surface executor routing: `references/verify-developer-experience.md`.
- **Artifact-egress confidentiality gate**: before a delivery artifact (spec/plan/requirement, status/writeback doc, launch/task card, retrospective) — or any text generated from it — **crosses the local trusted boundary**, run a confidentiality pass *before* the write/create/push/send call; it fires **only on cross-boundary egress** and owns only the **semantic confidentiality axis** that secret scanners miss. A block stops the *egress* but preserves the draft locally and never deletes the work; exception authority stays with the user/owner. Egress channels include chat/tracker surfaces (Feishu/Bitable writeback, shared/public docs, MR/issue body or review comment, external trackers), durable VCS/release metadata (commit message, branch/tag name, release note/changelog, CI metadata), external assistants/models, and delegated-worker prompts; the gate's own block reason/finding is itself egress — never quote the raw sensitive span across the boundary; secrets/PII/credentials/raw-logs/customer-data route to their existing owners (`platform-observability` redaction, `defect-diagnosis` evidence sanitization, the `feature-risk-router` security-review gate); per-category actions, severity, and the delegated-worker firing point: `references/artifact-egress-confidentiality.md`.
- Learning loop: after bugs, review findings, incidents, repeated friction, or external skill research, use `skill-extraction-workflow` to update the right skill or reference instead of leaving knowledge only in chat.
- Skill/process extraction: when asked to summarize delivery experience, preserve a workflow lesson, update a reusable skill, or decide where a lesson belongs, route to `skill-extraction-workflow` first. Update this skill only when the lesson changes product R&D routing, gates, ownership, or lifecycle policy.
- Upstream decision propagation: when architecture, design, testing strategy, release, observability, security, or product workflow guidance changes, treat the next R&D slice as incomplete until the downstream execution owners are named. Confirm which implementation skill, test/review skill, and release or docs owner must apply the decision, or route the gap through `skill-extraction-workflow`.
- Text artifact quality: when this workflow creates or updates a SOP, template, checklist, report, Feishu/Lark doc, task card, launch material, or other deliverable text, run `tighten-doc` before sharing, syncing, committing, or publishing. Do not ask the user for a separate optimization confirmation unless substantive decisions may change or collaborative-comment safety is at risk.
- Product R&D standards docs: when creating or updating team development standards, stack guidelines, testing standards, engineering norms, or a multi-doc handbook that belongs to the R&D lifecycle, use the R&D standards checklist in Workflow. Cross-stack or cross-service product Specs live in one authority surface; stack/service repositories keep execution slices and links back to that authority instead of redefining product goals. A multi-stack standards family must include a testing standard owned by `testing-strategy`; stack docs specialize commands and harness mechanics but do not replace the shared test-layer and CI-gate policy. For standalone wording, editing, or polishing requests with no R&D routing decision, use `tighten-doc` directly. Authority/sync-gate and testing-standard detail: `references/rd-standards-doc-family-checklist.md`.
- Standards-to-health-gate propagation: when a standards family is intended to check project compliance later, split each norm into deterministic checks and agent review checks, route the executable invariant model to `testing-strategy` fitness functions and the stack-specific mechanics to the owning dev/architecture skills, and do not leave conformance as a human-only checklist (mapping detail in `references/rd-standards-doc-family-checklist.md`).
- High-risk resilience gating: when a feature touches money, billing, quota, permissions, tenant/user data isolation, privacy, high-impact AI answers, write-finality risk, repeated submission, async job finality, or incident explanation/compensation, require an explicit resilience gate before implementation or launch; do not escalate low-risk local edits only because they write files. Write-finality classification and gate detail: `references/high-risk-resilience-gates.md`.

## Generalization Discipline

- Keep only reusable product-development mechanics: requirement shape, ownership boundaries, skill routing, quality gates, evidence, and learning feedback.
- Do not copy project nouns, repository paths, service names, provider names, IDs, UI themes, or domain-specific cases into this skill.
- When mining an existing product or repository for a new product/team, separate each observation into mechanism, business/domain noun, and source-quality/age. Keep mechanisms, strip or anonymize business nouns, and discard or downgrade obsolete/weak technology before it reaches executable guidance.
- For generic SOP/process docs, write abstract gates and acceptance logic. Put concrete code paths, real chain evidence, dataset rows, and module-by-module proof in project launch materials, evaluation reports, or appendices. Verify the real product chain before naming modules, but do not paste evidence tables into the generic SOP body unless the document is explicitly an audit/report.
- For cross-skill extraction, conflict resolution, or generalized lesson placement, route through `skill-extraction-workflow` instead of restating extraction doctrine here.
- Preserve product-delivery precedence locally: root-cause real defects before workarounds, define acceptance checks before broad implementation, and prefer deterministic verification over manual inspection alone.

## Workflow

At each stage boundary, walk the per-stage entry-state enumeration in [Stage-Entry State Checklist](references/delivery-lifecycle.md#stage-entry-state-checklist) — confirm every required state already exists before crossing into the next stage; it points to the owning gate for each criterion rather than restating it.

1. Classify the work.
   - **Diagnostic spec-match baseline gate** (before any current-state/spec-match judgment or change recommendation): when a request combines a diagnostic verb with a spec-match semantic, do NOT treat the user's single-utterance description as the authoritative spec — identify the evaluation baseline source first, and record it before the diff lands. Details live in `references/diagnostic-spec-match-gate.md`.
   - Product idea or feature: start with product intent, user workflow, acceptance checks, rollout constraints, and, for user-facing surfaces, an approved design or proportional design/acceptance shape before implementation.
   - Narrow product requirement artifacts follow the canonical route in Scope. Before Ready, reconcile the per-point behavior/acceptance inventory from product shaping against the closure table: every behavior has a `requirement_id` or a legitimate human decision marks it `out` / `deferred`; a missing row is a blocker, not proof of exclusion. Issue Ready with `product`, `version`, `scope`, `closure_table_revision`, `behavior_inventory_revision`, and `issued_at`; any bound input change invalidates it and requires re-evaluation. Active-delivery results return here; only standalone non-PRD narrow artifacts may return directly.
   - Existing project/codebase assessment: separate `understanding` from `judgment`. Use codebase understanding to map structure, entry points, flows, and constraints, then assess architecture, implementation, tests, UI/UX, bug/risk, release, and observability through the owning skills below. The evidence bar findings must clear — citation, confidence label, and the promote-from-docs / build-only-check bans — is one rule, owned by the Existing Project Assessment section; do not restate it here.
   - Combined preparation plus assessment: if the user first asks for setup, cleanup, reset, dependency install, checkout, or branch/worktree preparation and then asks to analyze/review/reassess the project, perform the preparation with the relevant safety/tooling skill, but classify the assessment portion here before loading stack-specific skills. Do not let the preparatory action hide the broad project-review trigger.
   - Quality remediation program / engineering-quality baseline: when the request is a cross-cutting, multi-phase engineering-quality initiative (质量专项 / planned tech-debt paydown / "整体架构-实现-质量偏差怎么治理"), or to establish and hold an engineering-quality baseline on an existing project as ongoing practice, load `references/quality-remediation-program.md` — it owns the program shape, campaign vs continuous-baseline modes, phase ownership, and per-phase exit gates; do not start refactoring before the Phase 0/1/2 exit gates pass.
   - Architecture change: define boundaries, contracts, data ownership, reliability, security, and migration before code.
   - Upstream workflow/skill change: before treating it as landed, record the owner chain from decision owner to implementation, testing/review, release/docs, and follow-up learning in `skill-extraction-workflow/references/source-register.md` per `skill-extraction-workflow`, not in chat, PR text, or commit messages. If any downstream owner lacks executable instructions, route through `skill-extraction-workflow` and patch the smallest owning skill.
   - Implementation change: use the relevant development skill and keep architecture decisions explicit.
   - Bug or regression: use `defect-diagnosis` for diagnosis, fix verification, root cause, and prevention.
   - Release or launch: define verification, rollout, rollback, observability, and owner handoff.
   - AI/algorithm launch: classify as a new capability or an iteration, then apply the per-class launch-gate focus in `references/algorithm-launch-sop.md` §9 (能力分类与门禁重点).
   - Unclear delivery risk: use `feature-risk-router` to classify risk tags, required gates, skippable gates, stop reasons, and verification evidence before selecting downstream skills. This is required for permission/access, money/quota, write-finality, data migration, cross-service API contract, AI inference/evaluation, release-ops, or multi-signal unclear verification-scope changes.
   - High-risk workflow: identify whether failure can cause financial loss, unauthorized access, cross-tenant/user data exposure, wrong high-impact AI output, duplicated writes, unclear user finality, or untraceable incidents. If yes, load `references/high-risk-resilience-gates.md` and route backend, client, design, LLM, and testing work accordingly.

2. Route responsibilities.
   - Product workflow owns intent, acceptance, sequencing, and cross-skill coordination.
   - Product requirement artifact owners update only their view of the shared closure table. This workflow coordinates unresolved owners and records the lifecycle Ready verdict; the writer consumes that verdict and does not make product decisions.
   - `codebase-analysis` or equivalent repository exploration owns initial structure/flow understanding only. It does not close quality assessment by itself.
   - Design skills own interaction model, information architecture, UI states, design-system fit, accessibility/visual acceptance, and handoff quality when the work has user-facing surfaces.
   - Architecture skills own boundaries, contracts, storage truth, reliability/security invariants, and launch readiness.
   - Development skills own code shape, generation, tests, local commands, and implementation patterns.
   - For client stack routing, use `app-cross-platform-dev` for Flutter, native Android, native iOS, mobile app build/release, device capability, and app-store-facing work; use `miniapp-product-dev` for WeChat/Alipay/Douyin/Baidu mini-program pages, host-platform capabilities, developer-tool or real-device verification, review submission, and release; use `web-react-dev` for React web, browser runtime, routing, forms, API-backed pages, build/deploy, and browser verification; use `terminal-cli-dev` for command-line/terminal/PTY-backed/ANSI-rendered/keyboard-driven/full-screen text-UI surfaces. For browser-hosted, native-embedded, or mini-program-hosted terminal surfaces, keep the host stack skill responsible for embedding, permissions, lifecycle, packaging, and release while `terminal-cli-dev` owns terminal rendering, input, PTY, ANSI, scrollback, selection, and cleanup mechanics.
   - For backend stack routing, use Go skills for Go services and Python skills for Python services; route mixed-language contracts to the architecture skill for the side that owns the changed boundary.
   - `defect-diagnosis` owns reproduction, isolation, instrumentation, fix, regression evidence, 5Why, and systemic prevention; route durable skill/reference landing to `skill-extraction-workflow`.
   - `testing-strategy` owns unit/integration/E2E layer selection, fixture strategy, CI gate design, and verification evidence.
   - `test-artifact-management` owns the end-to-end workflow of generating structured testcases and delivering their records to Feishu Bitable. It also owns the TC 废弃 state transition and the first step of the deprecation cascade (mark TCs 废弃, locate linked tests via the sidecar `test/results/tc-map.jsonl` + source `tc(...)` calls); see the Feature Deprecation section below for the full cross-skill cascade.
   - 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 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.
   - `skill-extraction-workflow` owns generalizing and landing codebase, session, review, bug, and online-example lessons into generic, validated, automatically discoverable skills.
   - Review skills own defect discovery, severity, and risk classification.
   - Learning/maintenance owns durable updates to the smallest correct skill or reference.

3. Produce only useful artifacts.
   - Before editing code, docs, skills, configs, or release artifacts for any non-trivial task, complete enough analysis and planning to make the work reviewable; plan depth scales to risk (model in `references/delivery-lifecycle.md` §Plan Authoring).
   - **Optional Feishu requirement record (after shaping):** create one only when the user or an accepted delivery contract requests it. This workflow owns the record content (`需求 ID`, title, status, and version); use `lark-base` for the concrete Base operation and `lark-wiki` only when Wiki placement is requested. Create or reuse only the requested resource; do not provision unrelated project tables or impose a repository-wide schema. Its absence does not block the requirement stage unless the record was requested; when requested, confirm the write before declaring that deliverable complete.
   - Before choosing a plan shape, check whether a usable spec/plan/assessment/issue-MR/task-doc artifact set already exists; if usable, treat the slice as re-entry — cite it, name gaps, and continue under it (`references/implementation-entry-reentry-gate.md` §Baseline Selection); if missing or stale, create or supersede before implementation.
   - 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 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`.
     - for work that is cross-repository, multi-client, touches a contract/API with any external consumer, or is high-risk per the High-risk resilience gating scope above (treat two or more accountable teams, deployable clients, or contract/API consumers as triggering), produce a review-altitude technical design before the implementation task breakdown or code.
     - Before claiming exemption, record a short risk inventory — touched repos/clients/contracts/teams and any money/permission/data/finality paths; unknown consumer or risk scope escalates to `feature-risk-router`, not to self-exemption.
     - The design may live inside the formal external spec-plan when that upgrade is selected, as long as its altitude and review gate stay explicit.
     - Content: interface/contract, architecture and data flow, key decisions with rejected alternatives and rationale, failure modes, cross-repo/contract impact, and high-risk handling (idempotency, server-side quota/rate-limit enforcement, concurrency, abuse, rollback) — at an altitude a reviewer can challenge without reading code.
     - **Mechanism-operability check** fires whenever the design proposes new mechanical enforcement or verification machinery (a CI/merge gate, pre-commit hook, schema/signature/checksum validator, evidence or attestation apparatus, migration guard), **and again when a landing withdraws or downgrades the evidentiary claim an existing mechanism rests on** — **load `references/design-review-gate-mechanics.md` before proposing the machinery, and before landing the withdrawal**; the three legs, the claim-liveness rule that re-bases or retires the mechanism in that same landing, and the shared-skill-gate instantiation all live there.
     - A product/requirements spec or a code-level implementation plan does not stand in for it; a brainstorm→plan→execute pipeline lacking an explicit design-review gate does not satisfy this, so overlay the gate on top of it.
   - The technical design gate's review is recorded, not implied — the sub-rules form ONE gate, walked individually at their firing points. **Load `references/design-review-gate-mechanics.md` when this gate is triggered** — before invoking the independent review, before merging a triggered diff, and whenever the candidate diff changes after a review; it is the authoritative full text. Firing-point registry (each anchor below is binding, not a summary to skim past):
     - **Recorded review artifact** — a recorded independent adversarial review with concrete objections, disposition, and reviewer/tool identity is the gate for all triggered work.
     - **Binds to the implementation diff** — the adversarial review must cover the actual code diff before it merges or pushes to a shared branch; green tests do NOT discharge it.
     - **Bounded mechanical-move exception** — scoped review of a move-dominated diff only under the reference's infeasibility precondition and four conditions.
     - **Cross-cutting shared-runtime primitives** — explicit adversarial pass over edge paths plus a regression test per path found.
     - **Implementer self-review row** — persisted before the independent review in a record whose history proves ordering; a late row invalidates the review.
     - **Changed candidate = refreshed row + fresh full-scope rerun** — any material post-review change mechanically triggers a full-scope rerun; the author cannot narrow the rerun's scope or self-classify the change as whitespace-only.
     - **Independent gate surfacing basics = process defect** — repair the self-review/deterministic-gate loop before rerunning, and findings still require disposition, not waiver.
     - **Green-tests-alone merge is the same defect** as reaching implementation with only spec plus plan.
     - **Human/team sign-off** — for high-risk money/permission/data paths and any contract/API change with an external consumer, before implementation, merge, or launch.
     - **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.
   - 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.

4. Enforce quality gates.
   - If work begins without the required analysis/plan depth, treat it as a process defect: pause implementation, report current branch/diff/test state, and do not revert existing, user-owned, or unrelated changes without explicit user approval. Isolate the agent's own pending changes when possible, leave them pending when isolation is unsafe, or convert them into a reviewed plan before continuing.
   - For any R&D standards/spec/guideline doc, completion requires the Workflow step 3 standards checklist result: `complete` with evidence, or `blocked: family enumeration unverified`. Do not mark docs done without recording that label.
   - Do not start implementation for a multi-step assessment/fix/test request before the plan exists and the user has accepted or the task is clearly within previously accepted scope. If the user challenges missing planning, stop further edits, report current branch/diff/test state, and fold only the agent-owned changes into a reviewed plan unless the user explicitly approves another cleanup path.
   - Never mark work complete because a workaround hides the issue.
   - Never delete, skip, or weaken a failing test just to pass; fix the code or correct an invalid test with evidence.
   - Never claim complete, fixed, or passing without fresh verification evidence from the current turn — **load `references/delivery-lifecycle.md` §Completion Evidence Gate before making that claim or handing the change to any third-party/independent review**: the deep self-audit rule (walked-enumeration method, executable/unverified discipline, re-owe rules) lives there, and a delivery whose last commit landed after the final audit is `interim`; external review is the backstop for what the audit missed, never the substitute that makes it optional.
   - 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 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`).
     - `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.
     - Encode a mechanical gate where the repository allows it — prefer a tracked verify script plus blocking CI / branch protection over an untracked local hook; any hook calls only tracked, non-destructive commands and is never the sole evidence. **No CI / shared runner is not a license to drop to a run-it-manually / prose norm** — degrade to a tracked verify script plus an *installed* hook with the tracked script as source of truth, never to discipline alone (ladder in `references/delivery-lifecycle.md` §Completion Evidence Gate).
   - For client app, miniapp, web, and terminal changes, route implementation to `app-cross-platform-dev`, `miniapp-product-dev`, `web-react-dev`, or `terminal-cli-dev` and require rendered evidence on the relevant target: device/emulator/simulator/app preview for mobile; miniapp developer tool, preview build, or real device for mini-programs; browser screenshot or inspection for React web; risk-matched terminal evidence for CLI/TUI (output-only changes may use a PTY transcript or cell-buffer snapshot; raw-mode, alternate-screen, cursor/focus, paste/selection, scrollback, resize, or color claims need PTY lifecycle/cleanup assertions and real terminal smoke).
   - 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).
   - 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.
   - When live infrastructure is required, keep it explicit and separate from default fast tests.
   - Treat review status as an explicit artifact. If an independent review is required but times out, returns empty output, or is otherwise inconclusive, record it as pending and do not describe it as passed.
   - For independent review runs, prefer bounded diff/file input over broad repo prompts. Load the repository's local rules such as `AGENTS.md` or equivalent review context when available, skip generated/docs noise unless it is the review target, and make timeout/inconclusive results recoverable through a durable pending record.
   - For product/spec normalization, standards-to-health-gate work, or any change that edits a shared deterministic gate/verifier (workspace verifier, conformance script, contract-coverage gate, status-source validator, CI harness, continuation-state checker, or a cross-repo contract/status/version/release/compatibility coordination surface), this workflow classifies the artifact before implementation — `spec/plan`, `gate design`, `gate implementation`, `status sync`, or `runtime/code` — without delegating that decision (do not delegate the spec-vs-plan-vs-code decision to `feature-risk-router`), then routes every shared-gate change through `feature-risk-router` and applies its `shared-gate` decision before shared branch push or MR merge; a recorded independent adversarial review names concrete objections, their disposition, and the reviewer/tool identity — prefer the session's review/challenge skill, otherwise a ccl-owned independent review (external tools supplement only; same-agent inline prose review only for explicitly low-risk, non-cross-boundary work). Rule/scope/failure/completion semantics changes require a concrete repo-local persistent artifact before editing; a `gate implementation` runs the plan/status verifier(s) before implementation and before claiming the plan active — an explicit status-source validator takes precedence, otherwise run every authoritative non-alias verifier or record why each is not applicable; a verifier gap or unavailable required review/challenge stays `interim` / pending-review. Details live in `references/shared-gate-artifact-classification.md`.
   - Do not use landing labels without matching evidence. `landed` requires the relevant local commit or persisted artifact; `MR-ready` requires branch, push, review artifact, known CI/pipeline status when applicable, known mergeability when applicable, and review status that matches reality; `release-ready` requires the relevant release checks, rollback/mitigation, and runtime verification evidence; `shared-status-ready` requires the owning status or product document to match the real branch/MR/review/verification state. For local-only or exploratory slices, report the actual uncommitted/unpushed state and use a local status label instead of treating MR evidence as mandatory.
   - When the delivery changes shared product status, roadmap, verification state, or cross-repository readiness, update the owning product/status document in the same delivery batch after the code MR lands. The **agent-consumed status-doc rule** is stricter: such a tracker is part of the work itself and must match the final handed-off/green/shared state — before merge and after reviewer edits/squash/rebase/platform merge, re-validate it against the final diff/ref/CI and point it at the final landed ref (`references/status-tracker-sync.md`).
   - When the delivery changes repo-local agent contracts, architecture decision records, spec hierarchy, harness scripts, or CI gates, report the sync evidence separately from ordinary test results: changed contract layer, the contracts updated, the executable command or CI job (e.g. the coverage gate) that proves it, and any boundary still on deferred adoption with owner/reason. Do not collapse this into a generic "lint passed" claim unless that lint target is shown to run the contract-coverage gate.
   - When using an internal checkout, private repository, local path, or project as a reference for a new product artifact, the artifact must name only reusable mechanisms, boundaries, and acceptance gates. Do not write source-identifying domains, filesystem paths, repository names, branch names, service/module names, people, tickets, or non-distilled business nouns into the product artifact. Before committing, scan the changed files for source-identifying strings and fix every new hit.
   - Before concluding that an internal reference checkout has no implementation evidence, inspect nested git repositories or submodules, non-default local/remote branches, tags, and tree contents with read-only git/tree inspection. If the default checkout is only a scaffold or placeholder but another branch contains the implementation, use that branch as evidence while keeping the branch and source identity out of shared artifacts.
   - For hosted code-review or release platforms, separate source-control transport from platform control-plane operations. Verify platform authentication before drawing conclusions from API errors, do not direct-push protected default branches, and update review/pipeline/merge status from real platform evidence.
   - If the repository's default branch is protected or protection is unknown, use branch plus merge request as the default landing path before pushing. If a local commit was accidentally made on a protected default branch, create or switch to a delivery branch at that commit, push the branch, and open the MR — then stop for merge authorization (MR creation is not merge authorization; merging requires the user's explicit merge instruction for that MR per `worktree-isolation`). Only after the MR is merged, fast-forward local main, instead of retrying direct pushes or self-merging.
   - When a task says to reference an existing project or skill, verify the reference's core abstraction shape before declaring alignment. Concept-level similarity is not enough; check the concrete boundary, helper/API, and ownership pattern that future code should follow.

5. Close the loop.
   - If a bug, review finding, repeated confusion, or successful extraction reveals a reusable lesson, route through `skill-extraction-workflow` before deciding the target skill.
   - Before sending a final response after any merged, committed, or otherwise landed delivery slice, run the Pre-Final Continuation Gate below. This is mandatory when the user has asked to continue, next step, keep going, proceed, or otherwise expects product development momentum.
   - A merge-and-sync checkpoint is a handoff point, not automatically an end point. If more low-risk work remains, keep working and reserve the final response for either a true stop condition, a user-requested status report, or a completed batch whose next step is no longer low-risk or implied.
   - Route design extraction lessons through `skill-extraction-workflow`; land the final generalized rule in the design skill only when that skill is the smallest correct owner.
   - Put architecture lessons in architecture skills, implementation/test lessons in development skills, and product R&D routing/lifecycle lessons in this skill after extraction ownership is clear.
   - Do not place cross-skill extraction methodology into a domain/product skill just because the latest example came from that domain.
   - Discard lessons that are only true for one business domain or one legacy codebase.

### Pre-Final Continuation Gate

Run this gate before finalizing a product R&D turn after any delivery slice lands. The session-wide continuation-proposal output contract above creates a second, independent trigger at the start of every subsequent user turn in that delivery session when either (a) the immediately preceding assistant message carries an action-form `proposed-next:` and the user replies, (b) its marker is absent/multiple or `none` conflicts with imperative/future/next-step wording, or (c) a user reply reads as affirmative/permissive toward an explicit assistant-proposed next action. Paths (a) and (b) are unconditional literal/fail-closed checks. Before any further action or final response, visibly emit exactly one of `continuing: <action and scope>` or `blocked: <proposed action and scope> — <specific stop, missing authority, or ambiguity>`; emitting neither or both is invalid. Path-(c) examples and the full outcome contract: `references/pre-final-continuation-gate.md` (Gate triggers and outcome contract).

1. Confirm the landing state from real evidence (local branch, remote sync, MR/review artifact, CI/pipeline when applicable, review/challenge status when required, status-doc sync, dirty worktree), proving the landing before reading any document (for the remote-backed default, fetch/update the target ref from its remote immediately before classifying the slice landed) per `references/pre-final-continuation-gate.md` (Landing-state proof); content/tree/patch equivalence never by itself proves a slice landed.
2. Inspect the current product/status source of truth, issue list, repo-local next-step artifact, unresolved acceptance item, or direct user continuation instruction for the next implied slice. **Reconcile it against the current branch/MR/merge/CI/tag state from step 1 before deriving: contradicting reality means stale — stop, repair the status source first, and do NOT derive from the stale source or a git-log/grep scan** (`references/pre-final-continuation-gate.md` §Status-source reconciliation).
   - **Deferred-evidence continuation check (`DFE-CONT`).** When real/runtime evidence is due (named by an acceptance item, status source, landing-evidence row, required gate, user correction, or because it is the behavior's only meaningful proof) yet deferred, blocked after remediation, skipped at finalization, or replaced by local/mock verification. Report deferred real evidence as `interim`/outstanding; do NOT report the turn complete while it is outstanding. A local/mock substitution is terminal only when a cited **non-agent** anchor — **agent-authored or agent-co-edited status/router/gate/handoff text never satisfies this** — names the same evidence, declares the deferral terminal, and carries the outstanding command/source forward for the active slice/ref. Never add verifier/config/test hardening motivated only by missing deferred evidence; never auto-continue past the pending gate. **Load `references/pre-final-continuation-gate.md` before treating any deferral as terminal** — it owns the valid/invalid-anchor list and hardening boundary.
   - **Affirmative-assent binding rule** lives in `references/pre-final-continuation-gate.md` §Assent binding — **load it before selecting `continuing:` on any assent**, and any concrete next-slice proposal you issue must itself carry the `proposed-next:` marker or a later assent cannot bind — an unmarked referent is ambiguous, never self-cleared; the rule fires only when the immediately preceding assistant message itself states one concrete next action and its scope, and `continuing:` binds to that proposal, never to adjacent status or response-format prose; ambiguous assent, referent, or authority ⇒ `blocked:` with step-4 precedence — restate the proposed action/scope plus the specific ambiguity/authority, cite the step-1 evidence and ask one concise question in the same turn; self-classifying the reply or marker away is never an exit, and the `continuing:` default applies only when assent is unambiguous and no step-4 condition holds (the full rule and its fallback are stated there); the visible `continuing:`/`blocked:` outcome obligation is unchanged.
3. Continue automatically only when no step-4 stop condition fires and: the next slice comes from an explicit status/task/acceptance source or active user continuation, is low-risk, local-only/already-authenticated, in accepted scope, clearly owned, verifiable with existing commands, and needs no destructive action, external purchase/financial commitment, production access, legal/compliance/product-strategy decision, or high-impact architecture choice. Existing configured internal developer-self-use metered model/tool accounts aren't an external purchase here.
4. Stop only for an explicit stop/pause instruction, a user-requested status-only answer, a failed/pending/inconclusive required/blocking gate, dirty/conflicting worktree that can't be isolated, required environment unavailable after remediation, high-impact product/architecture/compliance decision, destructive action, external purchase/financial commitment, unclear owner, ambiguous assent, missing stricter authorization, materially differing viable approaches (none dominant-and-reversible), a fix lacking evidenced cause, or no low-risk slice. Exactly one dominant reversible approach and no other stop condition firing: do not stop at a recommendation: deliver a tested reviewable draft.
5. If stopping, state the concrete stop reason and the exact evidence checked; an assent-triggered `blocked:` outcome uses the action/scope-plus-blocker form and classifies the turn `interim`. Ask one concise in-turn question when ambiguity or missing authority blocks; explicit stop/pause needs no reconfirmation. A `continuing:` outcome proceeds with the named slice before finalizing. A silent/completion stop is invalid. Do not send a completion-only, solved, fixed, or fully-closed final response after a merge/sync while a required review/challenge is pending or inconclusive; report interim or blocked with the next unblock step.
6. **Assent-outcome closeout check.** Before every final response in a product-delivery session, walk the literal immediately preceding marker and visible outcome; the agent cannot exclude a status, question, review, or dispatched-owner turn by reclassifying it outside the session. An action marker or a plausibly affirmative user reply requires exactly one already-visible `continuing:`/`blocked:` outcome; until `continuing:` has executed the accepted slice or `blocked:` has named the blocker, the current turn may not use `proposed-next: none — status only` or `not-applicable`. A valid status-only marker permits `not-applicable` only when the preceding prose has no imperative/future/next-step wording and no affirmative reply pending. A missing/multiple/conflicting marker forces a visible `blocked:`/`interim` outcome with one clarifying question; it never produces `not-applicable`. The current assistant message itself must end with exactly one action-form or status-only marker for the next turn. Omitting the marker cannot justify a silent stop.

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.

### External Skill Augmentation

CCL skills remain primary owners of every stage and every gate. Installed external skills may supplement a narrow lifecycle discipline, but they never replace CCL ownership, never become required gates, and never block delivery when absent; discover them from the current session's available-skills list and map each to a narrow role before use. Operational detail: `references/external-skill-augmentation.md`.

### Existing Project Assessment

For broad prompts such as "分析项目", "重新分析项目", "分析本项目", "重新分析本项目", "分析本项目，看有哪些做得好的，做得不好的，比如架构、实现、bug", "废弃本地修改后重新分析项目", or "review this repository/codebase", preserve this workflow as the top-level owner even when preparatory safety/setup work runs first. A detected stack skill owns one row of the assessment matrix; product-rd owns the whole matrix.

- Before deep code reading, fix execution, test claims, or complete conclusions, create the assessment launch checklist (product/user paths, architecture/implementation owners, test-layer matrix owner, UI/UX surfaces, runtime/host evidence surface, unavailable/live/manual boundaries, extraction/learning trigger); without it the work is interim exploration, not a complete assessment.
- Ground the evidence boundary before any per-repo gate or absence claim (repo topology, committed-vs-working-tree state, unread/unrun evidence, dirty-tree state) per `references/existing-project-assessment-report.md`.
- Findings must be evidence-backed and confidence-labeled: cite file paths, commands, and observed outputs; do not promote "docs say" to "code does"; do not let build-only checks replace assertion tests, rendered client evidence, or platform/device checks; visible product surfaces need a UI/UX row; high-consequence auth/account/permission/payment flows need a scenario matrix; reusable routing misses or process defects route through `skill-extraction-workflow`.
- A verified same-org peer exemplar is calibration input, not authority; split structural and semantic conformance into separate rows — structural presence does not prove semantic parity (calibration detail in the same reference).
- An assessment report is not permission to patch every finding: convert selected next actions into an accepted plan/checkpoint before edits, keeping quick fixes, structural refactors, test/verification debt, product/design follow-ups, release/ops follow-ups, issue/risk registration, and reusable-process disposition separate.

### Feature Deprecation

When a feature is sunset, downscoped, or replaced (需求变更导致功能下线、迭代废弃旧能力、产品方向收敛), treat it as a multi-skill delivery slice, not a one-line status change. **Load `references/feature-deprecation-cascade.md` before any TC/test/code deletion or `complete` label.** Coordinate its 7-step cascade in order — (1) confirm scope and source of truth, (2) TC layer (`test-artifact-management`), (3) test-code cascade (`testing-strategy`), (4) code removal (owning stack dev skill), (5) operational follow-through, (6) orphan detection, (7) status sync — and never delete on inline summary alone: a test or business symbol is deleted only when the underlying code is removed or has no other product callers. A deprecation slice is `complete` only when steps 2–7 each have evidence; a missing step is a release defect, not a follow-up.

## Reference Loading

- Evidence, lifecycle, and assessment references: `references/source-evidence-map.md`, `references/delivery-lifecycle.md`, `references/algorithm-launch-templates.md`, `references/existing-project-assessment-report.md`, `references/external-skill-augmentation.md`.
- Completion, status, isolation, and high-risk gates: `references/pre-final-continuation-gate.md`, `references/status-tracker-sync.md`, `references/implementation-entry-reentry-gate.md`, `references/worktree-mechanics.md`, `references/high-risk-resilience-gates.md`.
- Contract-sync mechanics: `references/sync-spec-repo-contract.md` (repo-local contract sync, upstream-authority value-set handling, upstream-silence claims).
- Developer-experience acceptance: `references/verify-developer-experience.md` (measured onboarding journey, error-message acceptance, fail-closed safety defaults, per-surface routing).
- Owner-dispatch discipline: `references/dispatch-owner-skills.md` (design-time complete owner set, firing-gate mechanics, opt-in mechanical enforcement).
- Deprecation and shared-gate references: load `references/feature-deprecation-cascade.md` before any TC/test/code deletion or `complete` label; load `references/shared-gate-artifact-classification.md` for product/spec normalization, standards-to-health-gate work, shared deterministic gate/verifier changes, or cross-repo contract/status/version/release/compatibility coordination-surface semantics changes.
- Design, quality, review, and decision records: `references/design-routing-and-readiness.md`, `references/refactoring-discipline.md`, `references/quality-remediation-program.md`, `references/code-review-checklist.md`, `references/review-reception.md`, `references/adr-convention.md`, `references/quality-attributes.md`; load `references/design-review-gate-mechanics.md` whenever the technical design gate is triggered (full recorded-review discipline, self-review row, mechanical-move exception, rerun rules).
- Behavior-changing implementation — and any implementation claiming the refactor/mechanical exemption, since the exemption is classified at entry: load `references/implementation-completeness-and-minimality.md` before implementation and again before a completion claim; it owns the acceptance-to-evidence and concept-to-current-need closure tables.
- Architecture and multi-repo coordination: `references/modular-monolith-heuristic.md` and `references/cross-repo-coordination.md`.
- Bugs, repeated issues, and reusable learning: prefer `defect-diagnosis`; use `references/problem-resolution-and-learning.md` as the compact routing summary and `skill-extraction-workflow` for durable skill extraction or validation.
- Execution owners: `testing-strategy`, `multi-agent-delegation`, `llm-inference-integration`, `app-cross-platform-dev`, `miniapp-product-dev`, `web-react-dev`, `terminal-cli-dev`.