create-dwy 0.21.0 → 0.22.0

package/templates/ai-tools/skills//345/217/221/345/270/203/345/217/221/347/211/210/dwy-publish/references/ios.md

@@ -10,7 +10,7 @@
 ## 版本（通用步，固化）
 
 - 语义版本号 `CFBundleShortVersionString`，走 `../dwy-semver` 决策 + bump.py。
-- **build 号 `CFBundleVersion` = 时间戳 `yyyyMMddHHmm` 12 位**（如 `202606231430`，`date +%Y%m%d%H%M`），每次发布重新生成，单调递增。app 和 SDK 都适用。
+- 构建号 `CFBundleVersion` 遵循项目及发布渠道约定；重新上传构建时满足渠道的递增要求。
 - 多文件同步见 `version-sync.md`。
 
 ## build / publish（项目步，不写死命令）
@@ -27,7 +27,7 @@
 
 ## changelog / tag / 安全检查 / 监控
 
-- changelog → `changelog.md`（写该项目的 `ios/CHANGELOG.md`；工厂里多个项目时每个项目各一份）
-- tag → `git-tag.md`（每次 bump 必打；版本串与 changelog `##` 标题一致）
+- changelog → `changelog.md`（使用该工程既有路径和格式）
+- tag → `git-tag.md`（每次 bump 必打；版本串与 changelog 标题一致）
 - 安全检查 → `../dwy-sdk-spec`（SDK 发布尤其要查泄露）
 - 监控 + 结果 → `monitor-notify.md`

package/templates/ai-tools/skills//345/217/221/345/270/203/345/217/221/347/211/210/dwy-publish/references/publish-config.md

@@ -1,6 +1,6 @@
 # 发布方式缓存 + 命令探测
 
-发布方式与 build/publish 命令**因项目而异，不写死**。按应用目录探测 → 问 → 缓存复用。
+仅在需要发布时探测项目已有发布方式和 build/publish 命令；根据项目上下文及授权判断，存在歧义时询问。缓存仅作为线索，执行前核实现有配置和权限。
 
 ## 缓存机制
 
@@ -17,7 +17,7 @@
    - 未命中（首次进入该目录）→ 走第 3 步
 3. 首次配置：
    - 探测真实命令（见下方探测线索）
-   - AskUserQuestion 问发布方式（见下方各平台候选）
+   - 按项目现有配置判断发布方式；无法确定时询问
    - 检查对应配置就绪（GA workflow 是否存在 / TestFlight 凭据线索 / maven·pod publish 配置）
    - `release_config.sh set <root> <rel_dir> <platform> <method> <channel> <configured> [build_cmd] [publish_cmd] [verify_cmd] [cmd_source]`
    - 提醒把 `.dwy/` 加进 `.gitignore`
@@ -51,7 +51,7 @@
 | harmony（har / har app） | `ohpm`(推荐) / `github-action` / `local` |
 | frontend | `github-action`(CI，推荐 OIDC) / `local` |
 | backend | `github-action`(CI，推荐 OIDC) / `local` |
-| generic — PyPI/npm | `github-action-oidc`(**推荐**，无静态凭据、符合团队准则) / `local` |
+| generic — PyPI/npm | `github-action-oidc`（必须，无长期静态发布凭据） |
 | generic — Cython wheel | `github-action`(cibuildwheel) / `local` |
 | generic — Electron | `github-action`(多平台 runner) / `local` |
 | generic — Docker/二进制 | `github-action` / `local` |
@@ -62,4 +62,4 @@ PyPI / npm 且未配置 GA 时，**主动推荐 `github-action-oidc`**（OIDC Tr
 
 - 给 workflow 模板：见 `../dwy-github-action-publish`（Python wheel / 纯包 OIDC）。
 - 给 Trusted Publisher 网页配置步骤：PyPI/npmjs 后台绑定 repo + workflow 文件名 + environment。
-- 用户仍可选 `local`（`uv publish` / `pnpm publish` 等），按其选择缓存。
+- 按仓库要求通过 GitHub Actions OIDC 发布，不使用本地命令或长期静态发布凭据。

package/templates/ai-tools/skills//345/217/221/345/270/203/345/217/221/347/211/210/dwy-publish/references/version-sync.md

@@ -1,6 +1,6 @@
 # 版本号多文件同步
 
-版本号定好后，**同一次发布的所有版本来源文件必须改到完全一致**。一个技术栈往往有多处版本声明，漏改一处就会导致包内版本不一致、构建产物版本错乱。
+版本号定好后，**同一工程中代表该版本的来源文件必须一致**；不同工程的独立版本不要求相同。先核对项目实际版本来源，不假设所有技术栈都存在表中全部文件。
 
 ## 各技术栈版本来源清单
 
@@ -9,14 +9,14 @@
 | Python | `pyproject.toml` + 包 `__init__.py` | `version` / `__version__` |
 | Node/Vue | `package.json` | `version` |
 | Android | `build.gradle(.kts)` | `versionName`（语义号）+ `versionCode`（整数，每次发布递增） |
-| iOS | `Info.plist` 或 `project.pbxproj` | `CFBundleShortVersionString`（语义号）+ `CFBundleVersion`（build 号，见 `sdk-ios.md`） |
+| iOS | `Info.plist` 或 `project.pbxproj` | `CFBundleShortVersionString`（语义号）+ `CFBundleVersion`（build 号，见 `ios.md`） |
 | 鸿蒙 | `oh-package.json5` | `version` |
 
 ## 规则
 
-- **Python**：`pyproject.toml` 的 `version` 与包 `__init__.py` 的 `__version__` 两处必须一致。
-- **Android**：`versionName` 用语义版本号；`versionCode` 是单调递增整数，与语义号无关，每次发布 +1。
-- **iOS**：`CFBundleShortVersionString` 用语义版本号；`CFBundleVersion`（build 号）用时间戳，规则见 `sdk-ios.md`。
+- **Python**：项目同时维护 `pyproject.toml` 的 `version` 与包 `__init__.py` 的 `__version__` 时，两处必须一致。
+- **Android**：`versionName` 用语义版本号；新上传构建的 `versionCode` 遵循渠道及项目的递增要求。
+- **iOS**：`CFBundleShortVersionString` 用语义版本号；`CFBundleVersion`（build 号）规则见 `ios.md`。
 - 改完后用 grep 全仓库扫一遍旧版本号，确认无遗漏：
 
 ```bash
@@ -25,6 +25,6 @@ grep -rn "<旧版本号>" --include=pyproject.toml --include=package.json --incl
 
 ## 禁止
 
-- 禁止只改一处版本来源就发布（如只改 `pyproject.toml` 漏改 `__init__.py`）
+- 禁止漏改项目实际维护的版本来源（如已有的 `__init__.py` 版本）
 - 禁止用会自动 commit 的版本命令（`npm version` / `bumpversion` 等），直接编辑文件，保持提交边界可控
-- 禁止 `versionCode` / `CFBundleVersion` 不递增就重发（应用商店会拒）
+- 重新上传构建时遵循对应应用商店的构建号要求；直接重部署已记录的相同产物可复用原构建号。

package/templates/ai-tools/skills//345/217/221/345/270/203/345/217/221/347/211/210/dwy-semver/SKILL.md

@@ -87,13 +87,9 @@ description: "语义化版本号（SemVer 2.0.0）决策助手。涉及以下任
 
 预发布优先级排序、版本比较 11 条规则等细节见 [references/semver-spec.md](references/semver-spec.md)。
 
-## 分支上用哪个号
+## 正式版与预发布版
 
-只认两条长期分支，和 `rules/开发流程/dwy-prod-branch.md` 同一条。不在发版时不要为了这条去改版本号。
-
-- 在 `develop` 发：必须带 `-beta` 或 `-rc`。还在改用 `beta`，准备进 `preview` 用 `rc`。
-- 在 `preview` 发正式版：不带预发布。`rc` 收成正式号时用 `bump.py` 转到正式版。
-- 仓库没有这两条分支：先告诉用户，不要改用 `main` 充当正式分支。
+按用户意图和目标仓库的版本及发布约定判断正式版或预发布版，不根据分支判断。测试版本按项目惯例使用 `beta`、`rc` 等标识，正式版本不带预发布标识。判断不明确时询问用户。
 
 ## 算出具体版本号
 
@@ -128,7 +124,7 @@ python3 scripts/bump.py 2.0.0-rc.1 major             # -> 2.0.0  (预发布转
 ## 与 dwy-publish 的边界
 
 - **dwy-semver**（本 skill）：只回答"该升哪一位、新号是多少"
-- **dwy-publish**：拿到版本号后执行发版流程（测试 → bump 版本文件 → changelog → 安全检查 → **打 tag（版本串与 changelog 标题一致）** → build → publish）
+- **dwy-publish**：管理工程版本、changelog 和 tag；是否构建和发布按项目上下文及用户授权判断。
 
 发版时若不确定版本号，先用本 skill 决策，再交给 dwy-publish 落地。
 

package/templates/ai-tools/skills//351/200/232/347/224/250/dwy-development-review/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: dwy-development-review
+description: Use when starting or completing code development, implementing features, fixing bugs, refactoring, or preparing a code delivery; also when architecture review, module boundaries, or reusable capability extraction is requested. 每次代码开发、修复、重构和交付前均适用；纯咨询、翻译和文案修改不触发。
+---
+
+# 开发、审查与复用闭环
+
+每次代码开发开始时加载，以功能成功交付为首要目标，自主完成开发、验证、审查与必要修复，再集中输出结果和确实需要用户确认的事项。识别架构、规范和模块边界问题，积累有证据的复用能力；允许结论为「无需抽取」。
+
+本 Skill 只定义通用流程，不依赖特定 CLI、模型、语言、框架或其他 Skill。自动加载取决于宿主的技能发现能力；本文件本身不是强制执行器，也不授予额外权限。
+
+## 入口与决策
+
+- **开发任务**：从第 1 步走完整闭环，不把计划、候选方案或测试通过当作最终交付。
+- **单独审查**：确认范围后直接进入第 4 步，不要求先开发或测试全绿。只读审查已有实现，说明验证缺口；用户未要求修复时不改代码。
+- 根据需求、项目约定、已有实现及实际运行环境，自行决定常规实现、检查与排障方式。环境问题先检查现有工具、配置和可用替代，不将能自行解决的问题交还用户。
+- 目标含部署时，核实已授权的目标环境、运行版本和部署条件，完成必要部署及运行时验收。持有凭据或发现可用服务器不等于获得部署授权；本地测试不能替代目标环境的功能成功。
+- 已有授权覆盖的下一步直接执行，不重复询问。遇到无法安全推断的关键条件或确需额外授权的动作，先完成其余可独立交付的工作，再只询问该具体阻断；不能先执行越权动作再补确认。
+
+## 1. 确定范围
+
+- 读取当前项目规则、需求和验收条件，确认工作目录、分支与已有改动。纯分析请求只输出分析，不进入开发。
+- 列出本次涉及的实现、调用方、测试、配置、迁移、导出和文档；无关文件保留原样。发现需求或授权边界不清时先解决该问题。
+- 定义可验证的成功标准与简短步骤，先分析依赖和共享资源，再选择直接执行、工具批处理、串行派发或并行子代理；只有实际收益超过派发、通信、集成和返工成本时才拆分。
+- 确认任务代码基线。有 Git 时核对基准提交及任务路径的现有差异，无 Git 时核对任务文件；后续新增、删除和未跟踪文件也计入范围。按审查指南决定记录粒度，不为小改动机械生成全套摘要。
+
+多步骤任务有派发收益，或长任务需要阶段续接时，读取 [references/delegation-guide.md](references/delegation-guide.md)。主代理保留目标、接口决策、用户交互、集成及最终验收责任；子代理承担边界明确的执行工作。默认只传必要上下文、只回收摘要和证据；宿主支持且确需历史决策时才继承会话，后续变化另行同步。
+
+## 2. 查找与开发
+
+- 先检索项目已有实现、能力目录及复用候选，再查标准库、平台能力、已安装依赖及匹配工具；跨项目只检索已授权的仓库或目录，不扫描无关位置。核实候选的实际实现与版本，不能把待抽取建议当作现成能力。
+- 按项目规则核实新工具的来源、权限、数据去向和维护成本；不因本 Skill 自动安装依赖、连接账户或上传代码。
+- 按项目测试约定开发；缺陷修复先建立重现证据，非平凡行为补充有意义的测试。只实现本次需求，不为未来复用提前扩展接口。
+
+## 3. 验证当前实现
+
+执行项目要求的测试、类型检查、静态检查与构建；按影响范围选择检查，项目明确要求的检查不得省略。记录命令、结果、跳过原因及对应的任务代码快照。
+
+检查后代码、测试或配置发生变化，相关旧结果失效。无法运行、超时和环境故障均记录为「未完成」，不能当作通过；区分源码、单测、真实设备、外部服务与部署验收。
+
+## 4. 执行审查
+
+读取 [references/review-guide.md](references/review-guide.md)，按其中的审查维度与输出契约执行。开发任务通常先完成必需检查；环境阻断验证时，仍完成可执行的审查，并将受影响验收项标为未完成，不伪造整体通过。
+
+有可用且获授权的独立审查能力时，给审查者需求、规则、变更快照和检查证据，让其自行读取实现及影响范围，不传开发者的自我评价。否则重新读取最终代码进行自审，并注明自审。审查只读，不修改当前工作树、索引、分支或 HEAD；审查者不再递归启动审查者。
+
+## 5. 修复与复审
+
+- 主执行者先复核问题证据；已授权范围内的明确缺陷直接做最小修复。存在分歧时核对调用链或测试，不盲目接受建议。
+- 修复后重跑受影响检查并复审变更及其影响范围。测试通过不能替代架构审查，架构建议也不能替代测试。
+- 不按固定轮数停工；只要有明确可执行的下一步且持续取得进展，就自主修复、复测和复审直到满足验收。相同失败反复出现时根据证据调整方案，不重复无效尝试；只有排查后仍无法自行解除的外部阻断、额外授权或用户停止要求才中止相应工作，并报告真实状态。
+
+## 6. 沉淀与交付
+
+- 记录粒度按审查指南选择，优先使用项目既有位置。需要完整报告且没有约定时，写入 `.dwy/reviews/<task-id>/review.md`；有复用候选时更新 `.dwy/reuse-candidates.md`。`<task-id>` 使用本任务稳定的短标识，续跑复用原记录，不覆盖其他任务。
+- 记录只绑定任务代码、测试和配置；更新审查记录本身不会使验收失效。无文件写权限时返回同样内容并注明尚未落盘，不宣称已沉淀。
+- 候选先查重，保留来源与证据；迁移落地后更新能力目录的实际入口、调用方和验证结果，让后续任务能够检索使用。非本轮必需的抽取记录为后续候选，不阻塞功能交付。沉淀规则遵循项目现有约定，不擅自修改全局配置、个人记忆或无关项目。
+- 只有当前任务快照的必需检查、审查及需求包含的目标环境验收通过，才报告功能交付成功。先完成已授权的实施与验证，再输出结果、环境证据、剩余限制，以及集中列出的交付验收确认或可选后续决策；能自行决定的事项不列为待确认，没有则写「无需额外确认」。

package/templates/ai-tools/skills//351/200/232/347/224/250/dwy-development-review/references/delegation-guide.md

@@ -0,0 +1,46 @@
+# 子代理派发与长任务续接
+
+## 先判断收益和依赖
+
+复用宿主已有的子代理、消息和状态能力，不引入新调度框架。工具未提供这些能力时由主代理执行，不假装已派发。简单任务直接完成；独立查询先考虑工具批处理；独立且工作量足够的任务再派发。并发数服从宿主实际容量和资源条件，不为占满名额而派发。
+
+| 工作 | 并行条件 |
+| --- | --- |
+| 独立文档调研、调用链追踪、不同根因的日志分析 | 各自可独立产出，范围明确；没有共享写入。 |
+| 不同模块开发 | 接口和行为契约已确定，文件归属清楚，配置、锁文件、数据库及构建资源不会互相干扰。 |
+| 测试与验证 | 测试数据、端口、设备、缓存及构建目录可独立使用；争用可写资源时串行或使用项目已有隔离方式。 |
+| 独立审查 | 被审查快照稳定，只读且上下文独立；审查时仍被修改的范围必须在集成后重新审查。 |
+| 契约设计、公共配置、依赖锁、数据库迁移、集成与部署 | 先明确责任人与顺序；不能因文件不同就默认可并行。共享工作区的 Git 写操作由主代理统一执行。 |
+
+先解决依赖链上的前置任务，再派发后续实现。没有接口契约时，可以并行调研，不能让各模块自行猜接口。遵守项目分支和工作目录规则，不为并行擅自另建分支或 worktree。主代理可同时推进独立工作，不重复子代理正在做的同一任务。
+
+## 派发最小上下文
+
+每个子任务说明以下内容，缺少的信息由主代理先查证或明确为待调查项：
+
+- **目标与验收**：本任务需要交付的具体行为与检查，关联总目标的哪一部分。
+- **范围与归属**：准确的仓库和工作目录、可改文件、只读范围、已有改动；不得覆盖其他人的修改。
+- **输入与契约**：相关需求、项目规则、入口位置、接口约定、当前快照和已确认事实；使用路径和定向摘录，不倾倒完整日志与历史。
+- **依赖与资源**：前置任务、共享资源及其责任人，是否需要等待；涉及环境时写明实际目标，不由子代理自行切换环境。
+- **执行边界**：允许读写、可执行的检查及原任务授权范围；子代理不因收到任务而获得额外外部操作权限，也不自行递归派发。
+- **返回内容**：结论、实际改动路径、检查命令与结果、阻断或待决策项；较长产物放文件并返回路径，原始日志只保留定位问题所需片段。
+
+默认新建独立上下文并传上述信息。只有任务确实依赖难以准确摘取的历史决策、且宿主支持时才继承必要历史；继承的是启动时的上下文，不代表后续自动同步。它不会删除主代理已有上下文，也不保证降低总 token 消耗；节省来自把后续探索和执行细节留在子代理侧。
+
+审查任务传需求、规则、代码快照与验证证据，不传开发者自我评价。主代理接收摘要后按风险核实关键代码、接口和证据；不能仅凭子代理说「通过」就判定整体成功，也不必重复读取全部日志。
+
+## 协调与集成
+
+- 用户的新要求由主代理解释并检查影响，尽快通知受影响的子代理；接口或范围改变时让旧任务暂停相应修改，更新契约后再继续。旧契约下的产物不能直接合入。
+- 子代理发现需要修改其他责任人的文件、公共接口或共享配置时，报告具体依赖，由主代理协调归属与顺序；可独立完成的部分继续，不私自扩大修改范围。
+- 共享工作区的修改即时可见，不能把“完成”消息当作代码才开始出现的时间。集成前核对在途任务和实际差异，避免测试读到尚未完成的修改。
+- 子任务完成后按依赖顺序集成，检查冲突及调用方，再验证最终组合的代码。子任务测试通过不能替代集成验收；沿用主 Skill 的持续修复和交付标准。
+- 主代理持续处理交互。用户询问状态时简要回答后继续；纠正和约束同步到相关任务，只有明确取消或替换目标时才放弃原目标。
+
+## 长任务的最小状态记录
+
+多阶段、可能跨会话或有较长等待的任务，复用项目已有计划或任务记录；没有约定时写入 `.dwy/tasks/<task-id>/progress.md`。短任务不额外建状态文件。
+
+只记录可恢复执行所需的信息：目标与验收条件、最新接口决策、子任务状态和责任范围、产物路径及对应快照、已执行检查和结果、当前阻断与下一步。代理标识或后台进程只作为定位线索，不记录凭据或整段会话。
+
+在阶段完成、接口或需求变更、出现阻断以及交接时更新记录。恢复时先读记录，再核对实际工作目录、代码、环境、代理与后台任务状态，确认哪些产物和检查仍有效；已经完成且仍有效的工作不重复做，失效部分重新验证。不假设宿主会在会话结束后继续运行代理、自动唤醒或自动恢复；不具备持续运行能力时留下明确的下一步并如实说明。

package/templates/ai-tools/skills//351/200/232/347/224/250/dwy-development-review/references/review-guide.md

@@ -0,0 +1,57 @@
+# 审查与复用判断
+
+## 审查范围
+
+从最终变更出发，追踪调用方、被调用模块、公共接口、测试、配置、迁移和文档。项目有代码索引时按项目规则使用并核实当前源码；没有索引就使用现有搜索能力，不自动建立索引。
+
+先复用项目的格式、类型、依赖边界等现有检查，AI 再审查工具无法覆盖的语义；不为一次审查搭建新平台。改动小也要检查相关边界；不扩大成全仓重构。单独审查不以测试全绿为前提，测试缺口限制相应结论，不阻止其他有证据的分析。
+
+| 维度 | 必须回答的问题 |
+| --- | --- |
+| 需求与正确性 | 是否满足需求？边界输入、错误、权限、并发和兼容性是否按实际风险验证？ |
+| 代码规范 | 是否符合项目规则？是否复用了现有能力？是否增加无依据的兜底、重复实现或多余抽象？ |
+| 架构 | 依赖方向是否符合现有架构？是否有循环依赖、基础层依赖业务、实现细节泄漏？没有明确分层约定时，根据实际职责和调用关系判断，不强推某种架构。 |
+| 模块边界 | 职责与生命周期是否清晰？业务规则与基础设施能否分别变化和测试？抽取后调用方是否更简单？ |
+| 验证与交付 | 测试是否证明行为且对应当前代码？调用方、导出、迁移、文档是否同步？哪些运行环境尚未验证？ |
+| 复用机会 | 是已有能力未复用、可沉淀的新能力，还是仅代码相似？有什么真实消费者或稳定契约证据？ |
+
+每条问题提供文件位置、触发条件或调用关系、实际影响、最小修复建议及验证方式。区分已确认问题与待验证疑点；没读过的代码不作确定结论。
+
+## 问题等级
+
+- **阻断**：需求不满足、可证明的行为缺陷、安全或数据损失风险、公共接口不兼容、违反项目明确的架构约束。确认的问题解决前不能判定通过。
+- **建议**：尚无实际影响的可读性、整理或抽取机会。不能把个人风格偏好当作阻断理由。
+- **待验证**：证据不足。影响必需验收条件时结论为未完成，否则说明疑点与剩余验证，不伪装成已确认缺陷。
+
+## 抽取决策
+
+先根据当前项目的依赖、源码和文档识别团队自己的基础库，不硬编码库名；社区依赖不算团队基础库。没有依据时明确写「未识别」，不假设存在目标库。
+
+| 类型 | 合适落点 | 核对条件 |
+| --- | --- | --- |
+| 业务无关 | 已有通用基础库的对应模块 | 接口不依赖业务实体、项目单例、宿主导航或私有配置；必要的安全校验与错误语义保留。 |
+| 业务相关但跨项目稳定 | 领域模块或领域库 | 明确共同业务契约与差异；宿主策略通过已有合理边界注入，不把不同规则强塞进通用接口。 |
+| 当前项目特有 | 项目内部业务模块 | 按职责归位；没有复用证据时保留，避免提前做公共库。 |
+
+真实的第二个消费者、已有稳定公共契约、或已确认的跨项目需求可支持抽取；仅名称相近或「以后可能用到」不足。比较迁移、版本兼容、测试与维护成本，成本大于收益时记录暂不抽取的原因。
+
+初步候选只记录来源、分类、复用证据、未直接抽取原因和下一步；需要实施时再补齐已有能力检索结果、消费者、目标接口及迁移兼容成本。落地后将状态改为已落地，在项目既有能力目录记录实际入口、版本、调用方和验证结果；没有目录时更新同一候选记录，不新建管理平台。开发前检索这些记录并核实实际代码。
+
+记录不包含凭据、个人信息或业务敏感原文；公共库还需确认内容适合公开。非本轮必需的抽取与整理不拖延交付，集中列为后续决策。
+
+任务范围内且已获授权的模块整理可以直接执行并验证。跨仓库抽取、破坏性 API 变更、新运行时依赖和发布按已有授权及项目规则处理；记录候选不等于授权实施，已授权的动作不重复询问。
+
+## 审查记录契约
+
+小范围、低风险改动在最终回复或项目既有任务记录中简要说明改动、验证、审查与复用结论，不强制新建报告或计算内容哈希。涉及公共接口、架构、迁移、安全、部署或复杂跨模块改动时保存完整报告；项目明确要求完整报告时遵守项目约定。
+
+完整报告使用以下结构，不需要额外创建空清单或强制 JSON：
+
+1. **结论**：通过 / 需修复 / 未完成，并注明是开发交付还是只读审查。只读审查可以完成并给出结论，不代表功能开发、测试或部署验收通过。
+2. **范围与快照**：需求、任务路径、基准提交及任务变更的内容摘要（含新增、删除、未跟踪内容）；无 Git 时使用文件内容摘要。记录独立审查或自审及未覆盖范围。
+3. **验证**：实际执行的检查命令、结果、对应快照和未验证项；必需项无法执行时结论不得为通过。
+4. **发现与处理**：按等级记录证据、修复、复测和剩余问题；无发现则明确说明。
+5. **复用决策**：逐项记录候选、复用已有能力或无需抽取及理由。
+6. **后续动作**：先完成当前授权内可执行的动作，再集中列交付验收确认、可选后续决策或无法自行解除的阻断；不把常规实施选择交还用户。提交、推送、发布及跨仓库操作遵守已有授权，不能用事后确认替代必要的事前授权。
+
+例：账号设置页面既包含通用邮箱输入，也包含当前产品的购买门槛。先查已有输入组件；组件可复用时直接使用。购买门槛留在宿主业务模块。账号管理流程只有在共同契约明确后才成为领域库候选，不能因两个页面相似就把购买逻辑一起移入公共 UI 库。