@ccoalm/ccl-skills 0.1.0

package/dist/assets/marketplace/plugins/ccl-skills/skills/product-rd-workflow/references/dispatch-owner-skills.md

@@ -0,0 +1,35 @@
+# Dispatch Owner Skills
+
+Use this reference for the owner-dispatch discipline behind the technical design gate: the complete owner set loads during design substance production, the firing gate's two firing points, and the opt-in mechanical enforcement. The entrypoint keeps the gate names, firing points, and closeout-acquire rule; this file carries the rationale and the map-building discipline.
+
+## Why the complete owner set loads at design time
+
+When the technical design gate is triggered and the deliverable's substance spans more than one owning skill — backend/platform/architecture (`go-microservice-architecture` / `python-service-architecture` + the relevant `platform-*` skills), LLM/inference/RAG/eval (`llm-inference-integration`), the storage/data-contract owner, the client stack owner (`web-react-dev` / `app-cross-platform-dev` / `miniapp-product-dev`), `testing-strategy`, `product-ui-ux-design` — those owning skills own BOTH (a) producing the design substance and (b) the review. Invoking the router does not discharge them.
+
+- Before producing or reviewing, enumerate the concerns the deliverable touches and load the COMPLETE owner set for those concerns during design, not only at review. Do not load owners for untouched concerns, and do not discover required owners one at a time mid-review — if a new touched concern appears, add it to the inventory and load its owner before continuing.
+- A cold dispatched worker is the worst case (see `multi-agent-delegation`).
+- An external model/tool is supplement-only: it runs under the CCL owner review, never as the substitute gate.
+- Producing the design substance without loading the owner skills, using an external review as the gate, or patching owners one domain at a time (architecture, then later realizing connectivity / LLM / data was also needed) is the recurring routing defect — it treats the router invocation as if it had already dispatched the owners.
+- Exemption: a narrow single-owner task (one bug fix, implementation-only, or visible-UI-only change). Durable changes to this lifecycle rule route through `skill-extraction-workflow`.
+
+## Firing gate mechanics (non-exempt multi-owner designs only)
+
+The owner-dispatch map gates the START of design-substance production, not only design completion — build it BEFORE drafting any design doc / test plan / architecture decision, and re-confirm it before the first implementation edit. The firing point is these two transitions, not a post-hoc completion check.
+
+- Reaching either transition with the design substance produced by `product-rd-workflow` + an external/codex review but no COMPLETE applied owner-dispatch map is the exact recurring defect this gate catches: pause, invoke the owner skills, build the map, then proceed. A partial dispatch (only some owners invoked) does NOT satisfy it.
+- Build and record the map per the owner-map discipline in `skill-extraction-workflow` — its rules on accountable owner-set coverage (including cross-cutting owners), provenance location (design artifact / private register, never the shared skill tree), and applied-evidence quality apply; don't restate them here.
+- The design is `interim` until the map shows, for every touched concern, an owner with **applied** evidence — the owner rule actually used and the design decision/constraint/change it produced. A green router invocation, a merely-`loaded` owner, finished prose, or a passing external review does not substitute, and `product-rd-workflow` is never the owner of domain substance.
+- An all-`N-A` map means no domain concern was touched → that is single-owner work: use the entrypoint's exemption risk inventory (which escalates unknown repos/clients/contracts/risk to `feature-risk-router`) instead.
+
+## Mechanical firing (opt-in, per product repo)
+
+This gate is enforceable in code, not only prose:
+
+- The `owner-dispatch` PreToolUse hook gates the first product-code edit (and write-like Bash); the Stop hook gates session close when gated edits happened without a recorded boundary. `scripts/owner-dispatch/owner-dispatch.sh ci` is the host-agnostic merge/pre-commit backstop.
+- A product repo opts in by committing `.owner-dispatch.json` (product globs + excludes); absent it, the gate stays prose-only.
+- Installing the backstop in a delivery: `bash scripts/install-gates.sh <repo> --gates owner-dispatch`, then flip `enabled:true` in a separate config-only change.
+- Default posture: `ask` (not block), fail-open, Claude-Code-hard / Codex-advisory — the in-session hook raises enforcement above prose where wired; the `ci` backstop is as strong as the CI job's own enforcement (pipelines-must-succeed + protected branch).
+- After invoking the owners and building the map, record the boundary to unblock editing: `scripts/owner-dispatch/owner-dispatch.sh record --owners "…"`. See `scripts/owner-dispatch/README.md`.
+- ccl-skills itself ships no config (its own edits are shared-skill/process edits, exempt from owner-load).
+
+The closeout-acquire rule (`status` must read `opted-in: yes`, or install, or record why exempt) stays in the entrypoint because it is a closeout item, not a map mechanic.

package/dist/assets/marketplace/plugins/ccl-skills/skills/product-rd-workflow/references/dormant-code-activation.md

@@ -0,0 +1,47 @@
+# Dormant Code Activation
+
+Use this reference when a delivery slice activates previously-unused, disabled, orphaned, or never-shipped code.
+
+## Trigger
+
+Treat these as behavior-changing delivery slices by default:
+
+- Flipping a feature flag on.
+- Uncommenting an old module.
+- Wiring an orphaned helper into a real caller.
+- Enabling a disabled branch.
+
+They are not harmless config flips just because the code already exists.
+
+## First Check
+
+Before activating the path, read why it was dormant. Common causes include:
+
+- Stale or renamed imports.
+- Signature or contract drift.
+- Code abandoned as buggy.
+- Intentional product, security, or kill-switch removal.
+
+If the code was deliberately removed or disabled, especially for product, security, or kill-switch reasons, clear that original rationale before resurrecting it.
+
+If activation touches security, permission, or data paths, route the slice through `feature-risk-router` before implementation.
+
+## Verification Ladder
+
+A passing mock-backed unit test or green config check does not prove a dormant path works.
+
+Verify the real end-to-end resolution chain with actual imports and wiring, but keep execution in an isolated sandbox or staging environment with synthetic or scrubbed fixtures and no production credentials by default. Running never-shipped, possibly side-effecting code against live services or production data is a release gate with owner, rollback, observability, and permission requirements.
+
+Import or resolution reachability is a prerequisite, not acceptance. Use the owning stack skill for per-stack mechanics, such as Python import checks, Go `go list`, web dependency graph checks, or Flutter `dart analyze` plus targeted source checks. Acceptance still needs behavior assertions, negative and edge cases, and risk-matched review.
+
+Scale runtime proof to risk:
+
+- Pure, side-effect-free, contract-local helpers may mark E2E or host smoke as `not applicable` with reason in the test-layer table.
+- Routing, permission, data, or IO paths require runtime or integration evidence matched to the risk.
+- Feature flags define the rollout boundary and evidence sequence; they do not waive real-chain verification. Use the same evidence ladder: sandbox chain proof → disabled/internal-flag proof → staged/canary enablement → rollout evidence.
+
+## Routing
+
+- `testing-strategy` owns real-chain-vs-mocks test mechanics and the test-layer table.
+- `feature-risk-router` owns security, permission, data-touching, write-finality, and unclear verification scope escalation.
+- `platform-release-engineering`, `platform-observability`, and the owning stack skill apply when activation reaches live or pre-ramp environments.

package/dist/assets/marketplace/plugins/ccl-skills/skills/product-rd-workflow/references/existing-project-assessment-report.md

@@ -0,0 +1,223 @@
+# Existing Project Assessment Report
+
+Use this template for broad prompts such as "analyze this project", "review this codebase", "what is good or bad here", or "look at architecture, implementation, bugs, tests, and design". The goal is a code-evidence report, not a generic architecture essay.
+
+## When To Use
+
+- The user asks for repository or product-codebase quality across more than one dimension.
+- The answer needs positives, negatives, likely bugs, missing tests, or next actions.
+- The project may include backend, web, app, mini-program, LLM, release, observability, or design surfaces.
+
+Do not use this when the task is only a narrow diff review, a single bug reproduction, or a stack-specific implementation question.
+
+## Report Contract
+
+Every report must separate:
+
+- Evidence read: files, commands, configs, docs, local rules, generated areas excluded.
+- Evidence not verified: missing dependencies, unavailable devices, missing credentials, failed commands, live services not run.
+- Assessment launch checklist: product/user paths, architecture/implementation owners, test-layer matrix owner, UI/UX surfaces, runtime/host evidence surface, unavailable/live/manual boundaries, and extraction/learning trigger. If this checklist is absent, label the work as interim exploration, not a complete assessment.
+- Test-case register before fixes/tests: scenario, layer, assertion, data/dependency, command, expected current result (`fail`, `pass-existing`, `blocked`, or `gap`), and owner. If implementation already started before the register existed, say so and do not call the slice TDD.
+- Understanding: structure, entry points, dependencies, runtime flow.
+- Judgment: positives, problems, likely bugs, test gaps, design/product gaps, operational risks.
+- Next actions: quick fixes, structural refactors, test debt, design/product follow-ups, release/ops follow-ups.
+- Closeout outputs when the assessment continues into fixes/tests: project findings or fixes, verification evidence by layer, issue/risk registration, and reusable-process disposition (`skill-extraction-workflow` landed/routed, or `unchanged`/`routed`/`discarded` with evidence).
+
+Do not promote documentation claims to implementation facts unless code or command evidence supports them.
+
+## Skill Route Checklist
+
+Before writing conclusions, build a compact matrix:
+
+| Dimension | Owning skill | Evidence to inspect | Output |
+| --- | --- | --- | --- |
+| Orientation | `codebase-analysis` or direct repository exploration | tree, README, package/build files, entry points, local rules | structure and flow boundary |
+| Assessment launch | `product-rd-workflow` | product/user paths, architecture/implementation owners, test-layer owner, UI/UX surfaces, runtime/host evidence, unavailable/live/manual boundaries, extraction trigger | complete-vs-interim boundary before conclusions or fixes |
+| Product/workflow | `product-rd-workflow` | user flows, acceptance docs, feature scope, release status | report framing and next-action split |
+| Architecture | backend/client/platform architecture skills | module boundaries, contracts, storage truth, async flows, dependency direction | architectural positives and risks |
+| Implementation | stack dev skill (`go`, `python`, `web`, `app`, `miniapp`) | core files, adapters, state ownership, API clients, generated boundaries | implementation quality and maintainability |
+| Tests | `testing-strategy` | test configs, test commands, CI, fixtures, manual checklists, written test cases before implementation | test topology, test-case register, RED/pass-existing/blocked/gap status, and missing layers |
+| UI/UX | `product-ui-ux-design` plus client skill | visible screens, states, navigation, accessibility, rendered evidence | design quality boundary and gaps |
+| Bugs/risks | `defect-diagnosis` when reproducible, otherwise code-backed risk analysis | failure-prone code paths, edge cases, error handling, concurrency | verified bugs vs likely risks |
+| Release/ops | `platform-release-engineering`, `platform-observability`, `platform-service-connectivity` | rollout/config/rollback, logs/metrics/traces/alerts, service-to-service transport/mesh/discovery | launch and operability risks |
+| Closeout/learning | `product-rd-workflow` plus `skill-extraction-workflow` when reusable | findings/fixes, verification by layer, issue/risk register, reusable-process disposition | completion label and durable landing/no-change evidence |
+
+If a dimension does not apply, say why. If a dimension applies but cannot be verified, mark it as missing evidence.
+
+For high-consequence authentication, account, permission, payment, or similar entry flows, the scenario matrix must separate automated, manually/runtime-verified, blocked, product-gap, live-only, and not-applicable rows. Missing recovery/reset, identity validation, logout cleanup, permission denial, or UI/UX acceptance cannot be collapsed into “E2E passed”.
+
+## Recommended Report Shape
+
+### Scope And Evidence
+
+- Sanitized repository label or relative path by default. Include exact local/private paths only in local working notes or when the user explicitly asks.
+- Detected stack and shipped targets.
+- Files and docs read.
+- Commands run and results.
+- Blocked verification and residual risk.
+- Assessment launch checklist status and any row marked unavailable, live-only, manual-only, or not applicable.
+
+### Executive Summary
+
+Three to six bullets:
+
+- What is solid.
+- What is risky.
+- What is likely to break first.
+- What should be fixed first.
+
+### What Works Well
+
+Group by concrete mechanisms, not praise:
+
+- Architecture and ownership.
+- Runtime and state handling.
+- API/client contracts.
+- UX/state completeness.
+- Test/release discipline.
+
+Each point should cite files or commands.
+
+### Findings
+
+Order by severity and confidence.
+
+Use this row format:
+
+| Severity | Confidence | Area | Evidence | Impact | Recommended fix |
+| --- | --- | --- | --- | --- | --- |
+| P1/P2/P3 | verified/likely/speculative | architecture/implementation/test/design/release | file:line or command | user/system impact | smallest useful correction |
+
+Severity guidance:
+
+- P1: crash, data/security exposure, broken critical workflow, irreversible side effect, or release blocker.
+- P2: likely user-visible failure, serious maintainability risk, missing contract/test around critical behavior.
+- P3: cleanup, docs drift, lower-risk maintainability, weak but non-blocking evidence.
+
+Confidence guidance:
+
+- Verified: reproduced by command/test/runtime evidence or direct deterministic code path.
+- Likely: code path strongly suggests failure but was not executed in the current environment.
+- Speculative: plausible risk from pattern or missing evidence; keep it out of the main bug list unless useful.
+
+### Architecture Assessment
+
+Cover only what evidence supports:
+
+- Boundaries and ownership.
+- Entry points and routing.
+- Data/state source of truth.
+- Async, streaming, jobs, subscriptions, or background behavior.
+- Cross-service/client contracts.
+- Security and permission boundaries.
+
+### Implementation Assessment
+
+Cover stack-specific implementation:
+
+- State ownership and lifecycle.
+- API/request/client wrappers.
+- Error handling and recovery.
+- Concurrency, cancellation, idempotency, and finality.
+- Generated code and platform-specific branches.
+- File size and module cohesion.
+
+### Test And Verification Assessment
+
+Include:
+
+- Test commands discovered.
+- Test frameworks/configs discovered or absent.
+- Test-layer matrix owner and per-layer status: unit, integration/contract, E2E/host smoke, manual/exploratory, build/static.
+- Test-case register status before implementation: written cases, target layer, assertion, expected current result, RED evidence or blocker/gap reason.
+- Manual checklist status.
+- Build/type/lint command results.
+- Missing assertion layers.
+- Device/browser/platform evidence available or absent.
+
+Do not treat build-only or manual-only evidence as assertion-based coverage.
+
+### UI/UX Assessment
+
+When the project has visible surfaces, include:
+
+- Primary workflows and navigation.
+- Loading, empty, error, disabled, permission, retry, and recovery states.
+- Visual hierarchy and density.
+- Accessibility and text overflow risk.
+- Rendered evidence, or why rendered evidence was not available.
+
+If no visible surface changed or no rendered surface was inspected, state the limitation.
+
+### Recommended Next Actions
+
+Split actions into:
+
+- Quick fixes: small, low-risk changes that remove real bugs or sharp edges.
+- Structural work: refactors or ownership changes that reduce repeated risk.
+- Test work: missing unit, contract, integration, E2E, device, or release checks.
+- Product/design work: state, copy, workflow, trust, or accessibility follow-ups.
+- Release/ops work: flags, observability, rollback, review readiness.
+
+Each action should name the owning skill or team discipline.
+
+Close every assessment-to-fix/test loop with:
+
+- Project findings or fixes completed.
+- Verification evidence by layer, including unavailable/live/manual boundaries.
+- Issue/risk registration, or the reason no register entry is needed.
+- Reusable-process disposition: `skill-extraction-workflow` landed/routed, or `unchanged`, `routed`, or `discarded` with evidence.
+
+When the user asks to continue from assessment into fixes, add an execution-plan checkpoint before code changes:
+
+- Existing spec/plan review: name any repo-local spec, implementation plan, assessment report, issue/MR description, or prior task doc that was checked; if none exists, say so.
+- Plan-shape decision: decide whether the follow-up needs a formal external spec-plan workflow or a lightweight workflow plan, with the reason.
+- Branch/worktree boundary and landing rule.
+- Selected findings for this batch and findings explicitly deferred.
+- Test-case register before implementation, including RED/pass-existing/blocked/gap status and why any scenario is not automated.
+- Task split with files to touch.
+- Root-cause evidence required before each fix.
+- Failing-test-first target, or why the current repository cannot support it yet.
+- Design checkpoint for any visible behavior, state, copy, navigation, loading, or error change.
+- Verification commands and unavailable layers.
+- Stop conditions that require user confirmation.
+
+External planning, debugging, TDD, or QA skills may be used to enforce these steps, but the report must still name the owning CCL skill for each task.
+
+For any non-trivial follow-up task, even outside assessment-to-fix flow, require enough analysis and planning before edits:
+
+- Check existing specs/plans before writing a new one or editing code.
+- Upgrade to a formal external spec plan when the follow-up needs the extra artifact because it is multi-skill, branch/worktree-scoped, delegated/subagent-executed, high-risk, intended as a durable process sample, or likely to expand without a reviewed task split. Ordinary multi-step assessment-to-fix-to-test work still needs a reviewed plan, but not automatically an external spec plan.
+- Simple, low-risk, single-file tasks: short inline plan with target file and verification command.
+- Multi-file, user-visible, bug-fix, release, branch/MR, test, design, or unclear-risk tasks: explicit task split with acceptance checks and stop conditions.
+- High-risk tasks: root cause, risk matrix, rollback path, test matrix, and owner handoff before implementation.
+
+## Anti-Patterns
+
+- A report that only summarizes the repository tree.
+- A report that lists "good/bad" without file or command evidence.
+- Calling a third-party understanding skill's output the final analysis.
+- Treating manual checklists as automated regression coverage.
+- Saying "tests pass" when dependencies were not installed or commands were not run.
+- Mixing verified bugs with guesses without confidence labels.
+- Reporting design quality without rendered evidence or a stated static-review limitation.
+- Ignoring skill-route misses discovered during the analysis.
+- Omitting the assessment launch checklist or four closeout outputs while calling the analysis complete.
+- Running test commands before writing the test-case register, then calling the result complete.
+- Starting fixes from a broad assessment before producing and accepting a task plan.
+- Treating "low risk" as a reason to skip analysis entirely instead of scaling the plan down.
+
+## Grounding the evidence boundary
+
+Before running any per-repo gate or concluding that a file/config/tooling is absent, ground against the authoritative state on **both** axes, every time:
+
+- **Repo topology.** Determine whether the target is a single repo, a **parent-of-repos / VCS group** (sibling repos cloned side by side under a parent that is not itself a repo — e.g. a GitLab group checkout), or a **monorepo**. A per-repo gate (contract/coverage/lint) run against a group parent conflates siblings and falsely reports a missing root — run it **per member-repo boundary** (each group child repo, and in a monorepo each submodule / nested-repo root), not once over the parent. Quick check: the parent itself is not a work tree (`git -C <dir> rev-parse --is-inside-work-tree` prints `true` only for a work tree — a nonzero exit means not a repo, `false` with exit 0 means a bare repo) yet the child dirs each are work trees (verify each with `git -C <child> rev-parse --is-inside-work-tree`, not by scanning for a `.git` *directory* — a member repo's or linked worktree's `.git` may be a file). (`check-agent-contract-coverage.sh` now self-refuses on a group parent, but topology must be established for every assessment, not only that gate.)
+- **Committed vs working-tree state.** Verify file/config/tooling presence-or-absence against committed `HEAD`, not a bare filesystem check — a tracked file deleted only in the working tree (or an untracked local addition) makes a plain `[ -f … ]` lie. First `git rev-parse --verify HEAD` to confirm a commit exists (unborn `HEAD` → record "no committed baseline", not "absent"), then read the path out of `HEAD` from the repo root with a repo-root-relative `<path>` (`git cat-file -e HEAD:<path>` / `git ls-tree -r --name-only HEAD`) — not `git ls-files` / `git status`, which report the **index/working tree** (staged or unstaged adds/deletes mislead). Also record dirty-working-tree state: uncommitted local deletions/edits may be another session's WIP (do not treat them as the repo's real state, and isolate before editing).
+
+## Standardization / conformance maturity calibration
+
+For repo/family standardization or contract-conformance maturity assessment:
+
+- A verified same-org peer exemplar is calibration input, not authority. If it is absent, stale, or unverified, record `peer_exemplar: unavailable` and fall back to standards-to-health-gate conformance plus authoritative standards.
+- Split structural and semantic conformance into separate yes/no rows: structural presence does not prove semantic parity, and only a cross-consumer conformance check closes the maturity gap.
+- Detailed structural marker examples and candidate-until-verified rules live in `cross-repo-coordination.md`.

package/dist/assets/marketplace/plugins/ccl-skills/skills/product-rd-workflow/references/external-skill-augmentation.md

@@ -0,0 +1,46 @@
+# External Skill Augmentation — discovery & stage mapping
+
+Use this reference for the operational mechanics of supplementing organization gates with installed external skills.
+
+## Ownership boundary
+
+CCL skills remain primary owners of every stage and every gate. When equivalent external skills are installed locally, they may supplement specific disciplines but must not replace ownership or become required gates: test-first and verification rigor, plan discipline, browser-rendered QA, design review against an approved checkpoint, and ship/land/canary release motions. Discover available external skills through the current session's available-skills list instead of hard-listing external family names here. If an external skill is unavailable, the CCL skill's own gate still stands; never block delivery only because an external skill family is missing.
+
+For multi-step implementation after assessment, map external skills to their narrow role before using them: planning skills may produce the task checklist, debugging skills may enforce root-cause evidence before a fix, TDD skills may enforce failing-test-first for behavior changes, and browser/QA skills may verify a running web/H5 surface. External skills do not decide CCL ownership; they execute or strengthen the gate owned by `product-rd-workflow`, `defect-diagnosis`, `testing-strategy`, `product-ui-ux-design`, or the relevant stack skill.
+
+When an external spec-plan skill is available and the upgrade decision from the entrypoint is positive, run it after the existing-spec review and before implementation. Save or reference the resulting plan according to that external skill's convention, then review/challenge the plan before execution. If the external skill is unavailable, produce the same minimum content in the workflow plan and continue without treating the missing external skill as a blocker.
+
+## Operational discipline
+
+When external skills are discovered in the current session's available-skills list, the rule remains: CCL workflow owns the gate; external skill executes the recipe when present.
+
+- **Do not duplicate inline what an external skill already does as a single command**. If the session has a one-shot ship skill (covers test + diff review + version bump + commit + push + PR), this workflow's "ship" step is "invoke that skill for this slice's tier", not "manually run each sub-step". This skill keeps the rule "what tier of ship for this risk"; the external skill keeps the recipe.
+- **Suggest the discovered external skill BY NAME in chat** when about to perform that lifecycle stage manually, using the exact name shown in the session's available-skills list (do not guess a hard-coded family name). The by-name suggestion mechanics and the illustrative stage-to-candidate list live below; discovering the per-session mapping is the agent's responsibility, not this skill's to enumerate.
+- **Exemption — multi-step cascades `product-rd-workflow` explicitly owns**: when product-rd-workflow defines a specific cross-skill cascade (notably the Feature Deprecation 7-step sequence in the entrypoint, where the cascade itself is the rule), the "don't duplicate inline" guidance does not apply — the cascade IS the contract and external skills slot into individual steps without replacing the cascade structure.
+- **Cross-skill conflict resolution**: if two installed external skills give different guidance for the same lifecycle stage (e.g. a process-discipline skill family vs an operational-tool skill family disagree on plan structure), prefer the more specific operational recipe for the concrete action AND surface the principle-level disagreement to the user. Never silently pick one without naming the conflict in the slice notes.
+- **For environments lacking the external skill family entirely**: every principle in the entrypoint stands alone — brainstorm before code, plan before implementation, test before fix, verify before complete, ship with rollback, retro after incident. Do not reference a missing external skill as a blocker.
+
+## Suggest the discovered external skill by name
+
+When about to perform a lifecycle stage manually and an equivalent external skill is present, suggest it **by the exact name shown in the current session's available-skills list** (invocation surface varies: some skills are `family-name`, some are `/short-name`, some are `prefix:name`). Phrase as "About to write a plan — `<exact-discovered-skill>` is available for plan-writing; should I use it?" rather than guessing a hard-coded family name. Do not hard-code external family names in code paths; the canonical owner is whatever the session's available-skills list provides, and discovering the full per-session mapping is the agent's responsibility, not this skill's to enumerate.
+
+## Stage-to-candidate examples
+
+Illustrative only — the actual canonical owner is whatever the current session's available-skills list provides:
+
+- brainstorming / scope-shaping family (intent + requirements + scope challenge)
+- plan-writing family
+- plan-review family (architecture / design / DevEx perspectives)
+- plan-execution / subagent-dispatch family
+- branch-worktree-hygiene family
+- TDD / test-first family
+- debugging-with-RCA family (also covered by `defect-diagnosis`)
+- code-review-request and code-review-receive family
+- codex-style second-opinion (consult / review / challenge) family
+- browser/visual QA family
+- completion-verification family
+- ship-flow family (basic ship / canary / land-and-deploy variants)
+- post-ship doc-update family
+- retro family
+- repo-health family
+- skill-authoring family

package/dist/assets/marketplace/plugins/ccl-skills/skills/product-rd-workflow/references/feature-deprecation-cascade.md

@@ -0,0 +1,15 @@
+# Feature Deprecation Cascade
+
+Use this reference when a feature is sunset, downscoped, or replaced (需求变更导致功能下线、迭代废弃旧能力、产品方向收敛). Treat it as a multi-skill delivery slice, not a one-line status change. A deprecation that only updates the product doc but leaves test cases, automated tests, dead code, dashboards, alerts, or feature flags behind is incomplete and silently rots the codebase.
+
+The cascade itself is the contract: external skills slot into individual steps without replacing the cascade structure. Coordinate the steps in this order; do not skip steps even when one seems harmless.
+
+1. **Confirm scope and source of truth** — name the feature, the source decision (product doc / requirement change / launch retro), the effective date, and whether the deprecation is immediate or staged. If the source decision is missing, stop and route back to product/requirements before any code or test deletion.
+2. **TC layer (`test-artifact-management`)** — mark every affected TC as `废弃` in Bitable (not `跳过`); append a 信息流转 entry with the deprecation reason and source link; sync the same change to the local md mirror (mark `[废弃]` in the 功能点 column, do not delete the row). 废弃 TCs are frozen — automation must not change their status afterwards.
+3. **Test-code cascade (`testing-strategy`)** — for each 废弃 TC, locate linked tests via the sidecar (`test/results/tc-map.jsonl`) + source grep for `tc("<TC ID>")` / `tc.Mark(..., "<TC ID>")` / `tcTest([..."<TC ID>"]` calls; for each match, decide whether to delete the test using the per-stack import-graph commands documented in the relevant dev skill's "废弃级联：业务代码是否仍在用" subsection (Python `grep import` / Go `go list` / Web `madge` / 小程序 madge+app.json / Flutter+native `dart analyze`+grep). If the underlying business code has been removed or has no other product callers, delete the test in the same commit as the code removal; if the code is still actively imported by other product code, take no action by default (the TC may have been marked early). For tests covering multiple TCs where only some are 废弃, remove the deprecated IDs from the `tc(...)` argument list without deleting the whole test. Tests without `tc(...)` calls are handled separately — only prompt the user when the underlying code is also being removed.
+4. **Code removal (stack dev skill)** — route the actual code deletion to the owning stack skill (`go-microservice-dev`, `python-service-dev`, `web-react-dev`, `miniapp-product-dev`, `app-cross-platform-dev`, `terminal-cli-dev`); the stack skill is responsible for removing handlers, routes, models, UI components, terminal commands/text UI surfaces, and any feature-specific assets that no longer have a caller.
+5. **Operational follow-through** — explicitly check and close: dashboards/alerts that reference the removed surface, feature flags or kill switches, scheduled jobs/cron entries, generated SDK or contract artifacts, CI gates specific to the removed feature, customer-facing docs, and release notes. Record each as `removed`, `kept with reason`, or `not applicable`; do not skip silently.
+6. **Orphan detection** — after code removal lands, run `python gen_report.py --detect-orphans` to surface tests whose TC IDs are now 废弃 or missing in Bitable, and tests without TC IDs whose underlying code has been removed; resolve per `testing-strategy` orphan rules before closing the slice.
+7. **Status sync** — update the product/status source-of-truth document and any shared roadmap entry in the same delivery batch; cite the merged commit, removed surfaces, and the 废弃 TC IDs. Do not leave the product doc claiming the feature is active or "to be deprecated" after the code is gone.
+
+A deprecation slice is `complete` only when steps 2–7 each have evidence; a missing step is a release defect, not a follow-up.

package/dist/assets/marketplace/plugins/ccl-skills/skills/product-rd-workflow/references/high-risk-resilience-gates.md

@@ -0,0 +1,73 @@
+# High-Risk Resilience Gates
+
+Use this when product work can cause financial loss, authorization mistakes, tenant/user data exposure, wrong high-impact AI answers, duplicate writes, unclear user finality, or incidents that support cannot explain.
+
+## Trigger
+
+Apply this gate when the feature, workflow, or changed path includes:
+
+- money, billing, quota, credits, refund, entitlement, reconciliation, or audit-affecting state;
+- login, permissions, role/capability checks, tenant/user/resource isolation, privacy, or sensitive data;
+- write requests, callbacks, MQ consumers, scheduled jobs, imports/exports, long-running tasks, or side effects that may repeat;
+- high-impact AI answers, recommendations, summaries, decisions, or generated content that users may trust;
+- client submission flows where users can click twice, refresh, go offline, return later, or not know whether the action finished;
+- write-finality risk: externally acknowledged, irreversible, repeated-submit, async-final, money/quota, permission, bulk, delete/import, or user-finality-unclear mutations;
+- launch, rollback, degradation, customer-support explanation, compensation, or incident traceability.
+
+## Product Decisions
+
+- Define what can degrade, what must fail closed, and what must refuse instead of producing a weak or misleading result.
+- Product owns user-visible degradation, refusal, timeout, retry, support, and compensation language. Engineering must not invent these at implementation time.
+- High-risk capabilities should default disabled or fail-closed in production until explicitly configured, approved, and verified. Local developer stubs or test defaults must not imply production enablement.
+- For high-impact AI, availability cannot silently beat answer quality. Fallback or downgrade requires an explicit quality-equivalence decision; otherwise return a clear refusal/degraded state.
+- For money, permissions, privacy, tenant/user isolation, and sensitive writes, uncertainty means reject or stop before side effects.
+- Missing tenant, actor, subject, resource scope, entitlement, or authorization context must not fall back to a default identity or default tenant on high-risk paths. Defaults are allowed only for explicit bootstrap, seed, or non-user-facing maintenance flows with separate approval.
+
+## Architecture And Implementation Gates
+
+- Every P0/P1 endpoint or job has an owner, timeout budget, rate/concurrency limit where relevant, canonical error behavior, trace/request id, and observable dependency errors.
+- Write requests do not auto-retry unless idempotency is designed with a durable key, unique constraint, state machine, dedupe table, or equivalent proof.
+- Redis-only, memory-only, TTL-only, or process-local dedupe is not durable enough for money, quota, entitlement, audit, external acknowledgement, or irreversible side effects. Use durable idempotency or explicitly mark the path as best-effort/non-critical.
+- MQ, callbacks, scheduled jobs, imports, and long-running tasks assume duplicate delivery and partial failure. They need idempotency, retry/backoff, terminal failure, repair or compensation, and visible status.
+- Degradation must not bypass authorization, tenant/user isolation, quota, audit, or data retention controls.
+- Reconciliation is required for money, quota, entitlement, and externally acknowledged side effects. The system needs a way to produce a difference list or equivalent review evidence.
+- If the primary mutation and audit/outbox/governance evidence cannot commit atomically, the design needs an outbox, compensating record, replayable repair path, and alertable reconciliation gap. Throwing an error after the mutation commits is not enough.
+- Admin repair, replay, quarantine, ignore, requeue, and settlement workflows need explicit claim/complete state, stale counters, oldest-age metrics, idempotency keys, and operator/request/trace evidence.
+- AI-generated runtime config for timeout, rate limit, routing, fallback, or circuit behavior needs human approval and recorded rationale before activation.
+
+## Client And Design Gates
+
+- Users must see whether an action is pending, succeeded, failed, partially completed, queued, retryable, cancelled, or blocked. A generic toast is not enough for high-risk flows.
+- AI-generated or automation-generated output that can affect users should first appear as draft, candidate, preview, or review-required state with source/status metadata, not as silently published final content.
+- Submits must prevent accidental duplicate action through disabled state, idempotency key, optimistic-state discipline, final-status polling, or server-confirmed result display.
+- Long-running work needs durable status, recovery after refresh/app restart, timeout/failure UI, and a result or support pointer.
+- Failure views should expose a safe tracking identifier such as request id, order id, task id, or support code when the user or support needs follow-up.
+- Degraded AI/data output must be visibly marked and should not look equivalent to normal high-confidence output.
+
+## Testing And Launch Evidence
+
+Build a compact scenario matrix before launch. Include only scenarios that match the changed risk surface, but do not skip a triggered class without saying why.
+
+- Duplicate side effect: duplicate HTTP submit, callback replay, MQ redelivery, job restart, refresh/back-button retry.
+- Permission uncertainty: auth service timeout, missing capability, stale session, cross-user/tenant/resource mismatch.
+- Money/quota/accounting: double charge, partial charge, rollback/refund, quota deduction, reconciliation difference.
+- AI failure: provider timeout, rate limit, incompatible fallback, weaker model unavailable or not approved, invalid/unsafe output.
+- AI reviewability: generated output exposes status, model/prompt or policy version, cost/usage or execution metadata where useful, and remains candidate/review-required until explicitly accepted.
+- User finality: pending longer than expected, network disconnect, app/browser restart, partial success, retry after failure.
+- Incident support: trace/request id exists, logs/metrics capture the failed class, customer-support explanation and compensation path are available when required.
+- Atomicity/reconciliation: mutation plus audit/outbox either commits together, or a compensating/replayable gap is visible and alertable.
+- Missing context: absent tenant/actor/subject/resource scope is rejected; no default identity or default tenant is used on the high-risk path.
+
+Acceptance evidence should name the command, test, replay, browser/device check, trace/log id, screenshot, or runbook step that proves each selected scenario.
+
+Use this matrix before launch for any triggered high-risk class:
+
+| Risk class | Invariant to prove | Owner | Lowest proof layer | Command or drill | Evidence artifact | Skipped reason |
+| --- | --- | --- | --- | --- | --- | --- |
+| Duplicate side effect | Same intent cannot double-write or double-charge | Backend + client | Unit/contract plus integration | Duplicate submit/callback/retry test | Test name, idempotency key, persisted state | |
+| Permission/context | Missing or mismatched actor/scope is rejected before side effect | Backend | Contract/integration | Missing context and cross-scope request test | Response, audit/log trace | |
+| Async finality | User/support can tell pending, failed, partial, and final status | Product + backend + client | Integration plus rendered smoke | Job restart/refresh/retry drill | Task id, screenshot, trace/log | |
+| AI quality/safety | Weak fallback does not masquerade as trusted output | Product + AI owner | Eval/replay plus UI smoke | Provider failure/fallback/refusal drill | Eval report, refusal/degraded screenshot | |
+| Audit/reconciliation | Mutation and evidence commit together or gap is repairable | Backend + operations | Integration/reconciliation drill | Outbox/audit failure or repair replay | Difference list, alert, repair record | |
+
+Every selected row must have an artifact. A blank `Skipped reason` is acceptable only when the risk class is not triggered by the change.

package/dist/assets/marketplace/plugins/ccl-skills/skills/product-rd-workflow/references/implementation-completeness-and-minimality.md

@@ -0,0 +1,120 @@
+# Implementation Completeness And Minimality
+
+Use this gate for behavior-changing product delivery.
+
+- **Functional completeness and structural minimality are independent gates. For behavior-changing delivery, map every in-scope acceptance point to implementation plus fresh evidence, and every retained new concept to a current acceptance point or hard constraint. Gaps block `complete`; speculative future need and omitted required behavior both fail.**
+
+It answers two separate questions:
+
+1. Did the change deliver every behavior currently in scope?
+2. Did the change introduce only the structure needed by those behaviors or a hard current constraint?
+
+Passing one question never compensates for failing the other. Minimality does not permit omitted behavior; completeness does not justify speculative machinery. Objective Closure below fixes the scope that question 1 is measured against: the objective's whole authorized population and all of its outcome classes, not the slice that happened to be convenient.
+
+## Objective Closure
+
+Two records are required for every behavior-changing delivery, written into the acceptance inventory at implementation entry. A `complete` claim without them is invalid.
+
+Every record below is read against one fixed pair — the objective and its member unit. Fix that pair first, because every laundering route in this section works by moving it.
+
+**Every boundary here is an implementer claim the reviewer accepts or rejects** — the objective, the member unit, the system of record, the enumerator and its filters, the component edge, and each continuation assumption. Record them together so they can be checked as a set. This section cannot make a boundary self-proving: no wording stops an implementer who is willing to draw the line somewhere convenient, and each boundary it pins down simply moves the next one outward. What it does guarantee is that every boundary is **visible, attributed, and rejectable**. Discharge it with one line — `boundary acceptance: <reviewer identity> accepted <objective | member unit | system of record | enumerator+filters | component edge | assumptions>, <locator>` — where the *component edge* is the set of systems this delivery treats as in-scope for producing or consuming the members. A boundary with no such line is unreviewed, and an unreviewed or rejected boundary reverts the delivery to incomplete under Firing And Closeout, where the implementer rebuilds the rows.
+
+### Objective and member identity
+
+- **The objective is the enclosing product outcome the requesting authority asked for**, cited by its own locator. Choosing an authority-authored *sub*-objective is legitimate and closes **only that sub-objective**: the enclosing objective's classes stay `in` until every sub-objective under it closes. "The request also asked for a batch endpoint" makes the endpoint a sub-objective, never a replacement for "migrate every account".
+- **The member is the unit the objective counts.** If the objective says every account, the member is an account — never the request, batch, job, page, or call that happens to touch accounts. A member identity finer than the objective's unit invalidates the preflight verdict and every bound row that rests on it.
+- **The population is enumerated from the objective's system of record, not from whichever query or endpoint is convenient.** Name the enumerator and every filter it applies. A filter the authority did not state — archived, locked, soft-deleted, tenant-scoped, or simply absent from a new endpoint's result set — does not shrink the population: those members stay `in` and unprocessed, which is a `gap`. Fixing the member unit while letting a convenient query define the set is the same laundering one level down.
+- Both are recorded once, with locators, and every row below refers to them. Changing either mid-flight re-runs this section and records the old pair, the reason, and whether the new pair narrows the old; a narrowing move needs the same independent authority as an `out` class, so a silent replacement is not a re-run.
+
+### Population preflight
+
+Record `population: fires` or `population: does-not-fire`, with the instance-count or arrival basis behind the verdict.
+
+- It **fires** whenever satisfaction depends on more than one work item, event, record, or user, or on repeated arrivals — regardless of whether the goal is phrased as a quantity, a capability, a reliability claim, or a continuous behavior. Repeated-arrival and open-ended populations fire even when a point-in-time query enumerates them today. Classification, sampling, or batching in the implementation also forces `fires`.
+- `does-not-fire` must quote an authoritative source establishing both the finite member set and a boundary after which no new member can arrive, and must resolve that source's exact locator at closeout. That source must exist **independently of this delivery** — a snapshot, ID list, or "no arrivals after T0" claim authored inside this delivery is the implementer enumerating their own convenient set, not authority. An unquoted, unresolvable, or same-delivery citation counts as `fires`.
+- Low-cost single-instance exception: a verbatim user statement or a lifecycle-issued Ready PRD section naming exactly one static instance and establishing that the objective carries no collection, sampling, or repeated-arrival semantics; record and resolve its exact locator. An implementer-authored characterization, a plan artifact, a self-asserted single instance, or any assertion authored inside this same delivery is never sufficient.
+- **When the preflight fires, reconcile enumerated against covered before closing.** Record the enumerator's revision, its resolved output and count, the member set that actually reached a terminal outcome, and the difference between them. Naming the right query and writing "all members" in the class rows is not the proof — the reconciliation is; every enumerated member missing from the terminal set is a `gap`.
+- The verdict governs member-population proof only. It never removes the outcome-class row below.
+
+### Outcome-class row
+
+Always walk the positive, negative, corrected/recovered, and ambiguous-or-superficially-successful outcome classes within the already-authorized source population. This row maps existing scope; it never invents new sources or mechanisms. One row per class, all four always present:
+
+| Outcome class | Scope | Member scope it holds over | Implementation surface | Fresh evidence | Status |
+| --- | --- | --- | --- | --- | --- |
+| positive / negative / corrected-recovered / ambiguous-or-superficially-successful | `in` / `out` / `deferred` / `absent`, each with its locator or mechanism per the rules below | which members this class's handling actually covers — "all members of the population" or the named subset | the code path that handles it, or `none` | command and result, trace, or query — over the recorded member scope | satisfied / gap / blocked / unknown |
+
+- **Each class enumerates its independently-failable variants** and links them to the Functional Completeness rows that cover them. `negative` is not one behavior: timeout, authorization denial, validation rejection, conflict, and dead-letter are separate variants, and `satisfied` requires every in-scope variant closed. One passing validation test does not close the negative class.
+- A class whose scope is `in` and whose implementation surface is `none` is a `gap`, and a `gap` blocks `complete` exactly as it does in the Functional Completeness table. Four classes recorded `in` with only the happy path implemented is the failure this table exists to make visible — the row cannot be satisfied by listing the classes.
+- **Member scope is a claim about coverage, not about fixtures.** A class exercised on a hand-picked fixture, while its handling is not on the path every member takes, records that narrower member scope and stays a `gap` for the rest — it is never `satisfied` for the population.
+- Every class implied by the stated objective defaults to `in`. Universal authority language ("all real work") places every walked class in scope unless that same authority already records an exception; quote the exception and resolve its locator, or the class stays `in`.
+- A class the behavior cannot produce is marked `absent`. Because `absent` needs no product authority, it carries an evidence bar instead: cite the **mechanism** that makes the class impossible — the state machine, API contract, or schema constraint, with its locator — never the implementer's model of the behavior. `absent` is rejected when any retry, replay, manual repair, or upstream redelivery path can produce the class **outside the edited component** (an ambiguous-success class is not `absent` merely because the API returns a typed result: stale, partial, duplicated, and asynchronously-rejected successes still count). A class that can occur and is merely unhandled is `in`, never `absent`.
+- `out` or `deferred` requires a verbatim user statement or a lifecycle-issued Ready PRD section traceable to an explicit product-authority decision, the exact source locator (user turn or PRD section heading), and the rationale. The authority must exist **independently of this delivery**: a section authored or amended within this delivery by the implementer is not authority for narrowing that delivery, whatever lifecycle state it later reaches. Text authored to clear this gate, an unresolvable locator, and an implementer's reading are not authority: the class stays `in` and blocks any slice that contradicts it. This deliberately narrows the per-point `out`/`deferred` rule under Functional Completeness: dropping a whole outcome class is a scope decision, so those two forms are the only accepted shapes of the explicit product/human authority that rule requires — where they conflict, this section governs outcome classes and that rule governs individual points.
+- Never reopen a class, goal layer, or outcome axis that authority already set. Absence of an exception under an explicit universal objective is decisive, not a question to send back to the user — do not offer or solicit a hypothetical carve-out, and do not ask the user to choose arbitrary scheduling numbers when no product outcome is undecided.
+- The acceptance artifact marks every walked class and must not append optional exclusion, sampling, expiry, or scope-reconfirmation questions.
+- A deferred class makes the current slice `interim` for the objective. Report it as `slice complete; objective interim`, naming the deferred class — a bare `complete` is invalid while any class under the cited objective is unprocessed, whatever the slice achieved. This is the scoped-partial result required under Firing And Closeout, stated for outcome classes.
+
+### Per-operation bounds and no-starvation
+
+List every per-operation sample, batch, context, time, or resource bound separately from the total obligation.
+
+- Such a bound only **schedules** work. Without a verbatim user statement or Ready PRD section plus exact locator explicitly narrowing the total obligation, it never narrows it; an authority-narrowed total is recorded as product scope, never relabelled as a per-operation bound.
+- Whenever the population is open-ended **or a per-operation bound defers any member** — the two triggers are independent, because a finite `does-not-fire` population can still be processed under a bound — record observable progress/finality plus **executed** continuation evidence.
+- **The evidence must exercise the continuation mechanism, not one lucky item.** One trace of item 513 advancing past a batch of 512 proves that item advanced; it says nothing about 514 onward, and a cursor that rescans 1–513 forever satisfies it. What closes the row is an executed test, run, or query showing the selection invariant itself: the cursor/queue/marker advances monotonically and every member is eventually selected — a repeated run that drains the population, or an assertion on the selection rule. A designed-only scenario, or evidence covering a single overflow member, keeps the objective `interim` and blocks `complete` for this delivery.
+- **Continuation evidence records the assumptions it rests on** — selection ordering, arrival rate, retry, mutation, restart, and crash behavior — because no finite run proves liveness for an open population. Naming an assumption is not satisfying it: each one is either **observed** (production or staging telemetry showing it holds in the real operating envelope) or **monitored** (a named alert/invariant with an owner that fires when it stops holding). Each carries its locator — telemetry: query, window, and result; monitor: the alert identity plus a record of it having fired at least once, and the population it covers — and its owner is someone other than the implementer. An assumption that is neither, one whose monitor is self-owned or never shown to fire, or one whose monitor is currently firing or carries an unresolved incident, keeps the row `interim` — a favorable assumption asserted by the implementer over a fixture is the starvation path restated, not evidence against it. A drain over a static fixture closes a finite population only; for an open one it closes the row only when the assumptions are named and the selection rule is shown not to starve older members under them (a `ORDER BY updated_at LIMIT n` scan that retries refresh, or a cursor that resets on restart, is a starvation path, not evidence).
+- **"Defers nothing" is judged against the member identity in the population row, never the operation's own unit.** A per-request timeout, context limit, or resource cap that fully completes the *member* it handles defers nothing and closes on its bound row. A request that terminates cleanly while the business record it was processing stays unprocessed **defers that member** — redefining the member as the request is how this row gets laundered.
+- This is a no-starvation check, not a new latency or quota SLO unless the product outcome requires one.
+- A representative success, one green slice, an omitted-count report, or a bounded call proves that slice only; none of them closes an objective whose required classes can remain indefinitely unprocessed.
+
+## Functional Completeness
+
+Start from the active requirement or acceptance source, not from the implementation diff. Preserve stable IDs and explicit source decisions so a never-implemented behavior remains visible. When the source has no native numbering, assign generated trace IDs, mark them `generated`, map each to the source's literal text, and record the source revision or timestamp consulted so a later source rewrite cannot silently erase in-scope points; never present generated IDs as source-native.
+
+| Requirement / acceptance point | Source decision | Implementation surface | Verification | Fresh evidence | Status |
+| --- | --- | --- | --- | --- | --- |
+| one independently-failable behavior | in / out / deferred, with source authority | code, config, migration, UI, API, job, or docs surface (docs only when the point itself is documentation) | lowest sufficient assertion or real-flow check | command and result, trace, screenshot, or API result | satisfied / gap / blocked / unknown / out / deferred |
+
+Rules:
+
+- Every in-scope point needs an implementation surface and fresh verification evidence before the delivery is called complete.
+- `gap`, `blocked`, or `unknown` blocks a complete claim. Report the exact incomplete boundary and unblock action.
+- `out` and `deferred` are terminal only when the active product or human source explicitly made that decision; record the decision reference. A `deferred` point must also name a durable follow-up locator — a tracker row, issue, or status-document entry; a chat message alone is not durable — otherwise the row stays `gap`. An implementer may not silently downscope a point.
+- `not-applicable` is never a per-point status: a point leaves scope only as `out` or `deferred` with source authority. The two-axis `not-applicable` exists only for the whole-delivery exemption defined under Firing And Closeout.
+- Derive primary scenarios from this matrix. Code analysis may add boundary, failure, permission, compatibility, and regression risks, but cannot prove that absent behavior was never omitted.
+
+## Structural Minimality
+
+Record the concept delta before or during implementation, then revisit it against the final diff.
+
+| New concept | Current acceptance point or hard constraint | Simpler alternative | Decision |
+| --- | --- | --- | --- |
+| abstraction, indirection, module/service, state/entity, dependency, config/flag, generalized path, or extension point — including a material expansion of an existing one (new states, new generic parameters, new dependency capabilities) | stable acceptance ID or observed current constraint | inline/local/direct option considered | keep / simplify / remove |
+
+Rules:
+
+- Each new concept must point to a current acceptance point or an observed hard constraint such as repeated current duplication, required isolation, testability, reliability, security, or compatibility — with a concrete locator (the duplicated call sites, the failing or unwritable test, the incident or requirement reference). A bare label like "testability" with no locator does not justify `keep`.
+- “Might be useful later”, generic extensibility, and hypothetical reuse are not evidence. Prefer the direct implementation for the known problem.
+- Refactoring, self-testing, and code-health work are allowed when they address an observed current constraint; minimality is not a reason to preserve harmful structure.
+- When the simpler alternative is adequate, remove or collapse the new concept before closeout.
+- **Before deleting or demoting an existing surface, classify its consumers by corpus, not by grep count**: *production* (shipped source, runtime config, loader/config paths, product smoke entries), *non-production* (tests, docs, decision records, snapshots, generated expected outputs, comments), and *ambiguous* (examples/scripts that may be product smoke paths — inspect before classifying). **An exported or otherwise published interface is its own contract corpus regardless of what the repository search finds**: a library export, a public API/CLI/wire surface, a plugin or extension point, anything under a compatibility promise — its consumers are outside this tree, so "no in-repo production caller" says nothing about them, and removal goes through the deprecation/versioning path (announce, deprecate, keep or shim through the promised window) rather than a delete. With that class excluded, "only tests or docs consume it, and what they pin is not load-bearing" is the strong deletion signal; a production caller turns the removal into a feature decision, and a surface an implemented decision record or hard-won defensive pattern explicitly justifies needs new evidence that beats that reason. Search the exact symbol, event/config/wire strings, and both `.name(` and `name(` call forms, then read the call sites — a dead-code tool is not a substitute for reading public interfaces, dynamic names, and loader paths.
+- **A correct-but-tiny simplification is a tagged TODO, not a record**: `TODO(<stable-tag>)` naming the smell and the action, so it can be revisited; reserve a decision record for removals that change public API, durable formats, or behavior.
+- An empty concept delta is recorded as one row with `none` in the concept column and `no new concept` as its decision; the structural axis becomes `not-applicable` only under the whole-delivery exemption at closeout.
+- A `simplify` or `remove` decision not yet reflected in the final diff is a blocking row: closeout cannot claim `complete` while the concept it rejected is still present.
+
+## Firing And Closeout
+
+1. At implementation entry, record the Objective Closure population preflight and outcome-class row as part of the functional axis. When the preflight fires, expand its member set into the acceptance inventory; when the population is open-ended or any per-operation bound defers a member, add the continuation obligation. A delivery whose functional axis is exempt under the exemption rules below carries objective closure with it and records `objective closure: not-applicable — <exemption class>` on that axis line instead. The reviewer confirms that classification from the diff and the original acceptance source; a rejected exemption, a missing record, or an invalid preflight blocks `complete`.
+2. At implementation entry, copy or reference the complete active per-point acceptance inventory and preserve its stable IDs and source decisions.
+3. Before the first edit, identify expected new concepts and the simpler alternative; update the rows when the diff changes direction.
+4. Have `testing-strategy` derive requirement coverage first and add implementation/code-risk scenarios second.
+5. Self-review the final diff in both directions: acceptance point to implementation/evidence, and new concept to current necessity.
+6. Give reviewers the original acceptance source, both tables, the final diff, and fresh verification results; a diff alone cannot reveal missing behavior.
+7. Claim complete only when every in-scope row is satisfied and every retained concept has a current justification. Otherwise report a scoped partial or blocked result.
+
+The reviewer-visible closeout must carry both tables, even when each has only one row; when no concept was added, record `none` instead of inventing one. Keep this proportional: a low-risk change may carry both tables inline. Exemptions are per-axis, not blanket: only a documentation-only diff may mark both axes `not-applicable` (documentation-only means internal or engineering documentation with no user-visible surface — user-visible copy and published API reference content are product behavior, never documentation-only). A pure refactor with no acceptance-point behavior change, or mechanical maintenance with no contract/behavior delta, may mark only the functional axis `not-applicable` — the structural axis stays live, because refactors are exactly where new abstractions appear; record its concept-delta table (or the `none` row). No exemption waives regression evidence: the existing suite covering the touched behavior stays green and is cited. An exempted axis records one line — `axis: not-applicable — <exemption class>, reviewed diff <identity>` — in place of its table; a live axis always records its table. In every case the reviewed diff is the evidence, and a reviewer confirms the classification from the diff, not from the implementer's label: the implementer classifies at implementation entry as a recorded claim, and the reviewer confirms or rejects that claim at closeout. Diffs touching API contracts, schemas or migrations, permissions, quotas or pricing, config defaults, or user-visible copy are behavior-changing by default and never take any exemption. Claiming an exemption does not defer the question to closeout: classify at implementation entry, and when a reviewer rejects the classification the delivery reverts to incomplete — the implementer rebuilds the required tables from the acceptance source; reviewers never reconstruct the evidence themselves.
+
+## Practice Basis
+
+- [Google Engineering Practices: What to look for in a code review](https://google.github.io/eng-practices/review/reviewer/looking-for.html) treats functionality, complexity, and tests as distinct review dimensions and warns against code made more generic than present needs require.
+- [Martin Fowler: Yagni](https://martinfowler.com/bliki/Yagni.html) rejects presumptive future capability while distinguishing that rule from neglecting refactoring, self-testing, or continuous delivery.
+- [NASA Requirements Verification Matrix](https://www.nasa.gov/reference/appendix-d-requirements-verification-matrix/) demonstrates the durable pattern of assigning requirements stable identifiers and explicit verification methods.