openone-workflow-kit 0.1.0

package/workflow/core/capabilities/release-safety-checker.md

@@ -0,0 +1,61 @@
+# Capability: release-safety-checker
+
+- **Tier**: essential
+- **Stage**: `/05`, `/07`, `/08`, `/09`
+- **Purpose**: 对比发布候选分支与生产基线，确保发布范围与文档一致，防止无关提交进入生产。
+
+## 为什么需要
+
+从集成分支、测试分支或污染分支派生发布候选，是范围泄漏的常见原因。发布安全判断必须默认按“整条分支可能上线”处理，用生产基线差异核查代替主观判断。
+
+## 输入
+
+- `workflow/team-profile.yaml#branch_model.production_branch`
+- 发布候选分支名
+- `02-产品文档.md` 和 `04-代码实现.md` 中登记的发布范围
+- 用户手动刷新后的本地 Git 引用或明确标记的本地缓存引用
+- `workflow/team-profile.yaml#risk_policy.high_risk_files`
+
+## 输出
+
+```yaml
+result: PASS | WARN | BLOCK
+checks:
+  - name: production_is_ancestor
+    status: pass | block
+    detail: "生产基线是否为发布候选祖先"
+  - name: commit_count
+    status: pass | warn | block
+    detail: "<N> commits ahead"
+  - name: file_diff_count
+    status: pass | warn | block
+    detail: "<N> files changed"
+  - name: high_risk_files_touched
+    status: pass | block
+    files: ["..."]
+overall_risk: P0 | P1 | P2 | P3
+blocked_reason: "..."
+recommended_action: "从生产基线重建干净分支，只带入本期登记提交。"
+```
+
+## 阻断规则
+
+- 生产基线不是发布候选祖先时阻断。
+- 提交数或文件范围显著超过文档登记范围时阻断。
+- 高风险文件被修改但未进入发布范围说明时阻断。
+- 未由用户手动刷新远端引用时，必须标记“本地缓存引用，未经远端刷新确认”。
+
+## Adapter 示例
+
+- **L0**: 在发布清单中写明标准 Git 检查项。
+- **L1**: checklist 提供命令，由用户手动执行并粘贴结果。
+- **L2**: slash command 对本地已有 refs 做只读核查。
+- **L3**: 发布前 hook 遇到阻断项时失败。
+- **L4**: subagent 专门做发布范围核查并返回 Go / No-Go。
+
+## 反模式
+
+- 用“测试通过”替代发布分支干净性核查。
+- 只相信分支名，不做祖先关系和 diff 检查。
+- 只看当前工作树，不看生产基线到发布候选的全量差异。
+- 明知分支污染仍继续作为上线候选。

package/workflow/core/capabilities/repo-baseline-scanner.md

@@ -0,0 +1,48 @@
+# Capability: repo-baseline-scanner
+
+- **Tier**: recommended
+- **Stage**: `/03`，也可在会话开始时运行
+- **Purpose**: 记录每个受影响仓库的真实本地基线，避免把当前工作树误写成生产事实。
+
+## 为什么需要
+
+多仓工作区里，不同仓库可能处于不同分支、dirty 状态或本地快照。架构和审查文档必须写清事实来源：生产基线、当前分支、用户手动刷新后的远端引用，还是本地缓存。
+
+## 输入
+
+- 受影响仓库列表
+- 当前分支、dirty 文件、Git 元数据状态
+- team-profile 中的生产分支、集成分支和功能分支规则
+- 用户是否已手动刷新远端引用
+
+## 输出
+
+```yaml
+result: PASS | WARN
+repos:
+  - path: "<repo>"
+    git: yes | no
+    branch: "<branch>"
+    dirty: true | false
+    baseline_source: production_ref | current_branch | local_snapshot | cached_remote_ref
+    caveat: "..."
+```
+
+## 阻断规则
+
+本能力通常不直接阻断，但会为分支闸门、发布核查和线上排查提供事实来源。未经用户手动刷新确认的远端引用，不得写成“已确认最新线上事实”。
+
+## Adapter 示例
+
+- **L0**: 在 `/03` 模板固定仓库基线表。
+- **L1**: prompt 要求记录分支和 dirty 状态。
+- **L2**: slash command 生成仓级扫描表。
+- **L3**: hook 阻止缺少基线表时关闭 `/03`。
+- **L4**: subagent 维护多仓基线摘要。
+
+## 反模式
+
+- 默认当前工作树就是生产事实。
+- 没有 Git 元数据还写“prod 已核查”。
+- 只记录主仓，不记录配套前端、脚本或发布资产仓。
+- 远端未刷新却声称引用最新。

package/workflow/core/capabilities/rule-extractor.md

@@ -0,0 +1,48 @@
+# Capability: rule-extractor
+
+- **Tier**: optional
+- **Stage**: `/10`
+- **Purpose**: 从真实复盘中提炼可进入 workflow core 的通用规则候选，让工作流持续进化。
+
+## 为什么需要
+
+复盘结论只有进入模板、命令、闸门或 checklist，才会影响下一次交付。但不是所有经验都适合做硬规则，必须区分项目级结论、个人工作区建议和通用 core 规则。
+
+## 输入
+
+- `memory-curator` 输出的结构化记忆
+- 当前 `workflow/core/` 规则
+- `workflow/team-profile.yaml`
+- 用户对规则强度的确认
+
+## 输出
+
+```yaml
+result: PASS | WARN
+proposals:
+  - target: core | team-profile | adapter | example | docs
+    rule_type: hard_gate | checklist | template_field | guidance
+    wording: "<建议规则>"
+    rationale: "<为什么需要>"
+    scope_limit: "<适用边界>"
+    requires_human_approval: true
+```
+
+## 阻断规则
+
+本能力不直接阻断。任何规则变更都必须由维护者确认，不能由 agent 自动把复盘经验升级为全局硬闸门。
+
+## Adapter 示例
+
+- **L0**: 复盘模板要求标注规则候选。
+- **L1**: prompt 给出规则草案和适用范围。
+- **L2**: slash command 生成待审 PR 草稿。
+- **L3**: hook 检查 core 规则变更是否有复盘依据。
+- **L4**: subagent 比较多次复盘，提炼稳定规则。
+
+## 反模式
+
+- 把公司特有流程写进通用 core。
+- 缺少维护者确认就改硬闸门。
+- 只增加规则，不说明触发条件和边界。
+- 新规则与既有 adapter 能力不兼容。

package/workflow/core/capabilities/runtime-evidence-triage.md

@@ -0,0 +1,53 @@
+# Capability: runtime-evidence-triage
+
+- **Tier**: recommended
+- **Stage**: `/03`, `/05`, `/07`
+- **Purpose**: 用运行态证据替代静态猜测，排查部署、路由、配置、日志、消息和定时任务等问题。
+
+## 为什么需要
+
+代码静态阅读只能说明“理论上会怎样”，不能证明目标环境实际加载了什么配置、路由、版本或数据。运行态排查必须记录证据链，并明确每条证据来自哪个环境、哪个时间点、哪个入口。
+
+## 输入
+
+- 目标环境、入口、请求样例或任务触发方式
+- 可访问的日志、健康检查、配置快照、管理台或监控结果
+- 本地代码与当前分支 / 生产基线说明
+- 用户手动提供的运行结果
+
+## 输出
+
+```yaml
+result: PASS | WARN | BLOCK
+evidence_chain:
+  - source: "<日志 / 探针 / 配置 / 请求 / 管理台>"
+    environment: "<环境>"
+    time: "<时间>"
+    observation: "<观察结果>"
+    conclusion: "<能证明什么，不能证明什么>"
+gaps:
+  - "<缺少的证据>"
+next_checks:
+  - "<下一步只读核查建议>"
+```
+
+## 阻断规则
+
+- 缺少目标环境证据时，不得把本地代码结论写成线上事实。
+- 涉及线上问题时，如未由用户手动刷新或提供生产基线，必须标记“未经远端刷新确认”。
+- 运行态证据互相冲突时，阻断“已定位根因”结论，必须先补证据。
+
+## Adapter 示例
+
+- **L0**: 要求排查记录必须包含环境、时间、入口和证据来源。
+- **L1**: prompt 按日志、配置、版本、路由、数据五类索要证据。
+- **L2**: slash command 生成排查表。
+- **L3**: 本地 validator 检查报告中是否存在证据链字段。
+- **L4**: subagent 读取用户提供结果并整理事实 / 推断 / 缺口。
+
+## 反模式
+
+- 只看代码就断言线上行为。
+- 只有报错截图，没有请求、时间和环境。
+- 把配置文件存在等同于目标环境已加载。
+- 没有区分“请求到达应用但路由不匹配”和“请求根本没到应用”。

package/workflow/core/capabilities/security-reviewer.md

@@ -0,0 +1,48 @@
+# Capability: security-reviewer
+
+- **Tier**: recommended
+- **Stage**: `/05`
+- **Purpose**: 审查凭证、认证、授权、隐私、审计、配置和生产影响面，补足功能测试覆盖不到的安全风险。
+
+## 为什么需要
+
+安全回归往往不会在普通功能测试中暴露。需要独立检查明文凭证、权限谓词、隐私字段、审计字段、配置来源和高风险文件改动。
+
+## 输入
+
+- 真实 Git diff
+- `workflow/team-profile.yaml#risk_policy`
+- 当前工作区或目标项目的合规、隐私和安全要求
+- 运行或测试证据
+
+## 输出
+
+```yaml
+result: PASS | WARN | BLOCK
+findings:
+  - severity: P0 | P1 | P2 | P3
+    category: credential | auth | privacy | audit | config | dependency
+    evidence: "<file:line 或验证证据>"
+    recommendation: "..."
+```
+
+## 阻断规则
+
+- 明文凭证、私有 token、生产配置或真实敏感数据进入仓库时阻断。
+- 删除或放宽授权、访问控制、数据脱敏、审计记录且无明确需求依据时阻断。
+- 高风险配置文件被改动但没有发布影响说明时阻断。
+
+## Adapter 示例
+
+- **L0**: 在代码审查模板中固定安全章节。
+- **L1**: prompt 按安全分类逐项审查。
+- **L2**: slash command 扫描高风险文件和敏感模式。
+- **L3**: pre-commit 或 pre-review hook 阻断敏感内容。
+- **L4**: subagent 专门做安全边界审查。
+
+## 反模式
+
+- 只看功能是否可用，不看权限是否变宽。
+- 将本地 `.env`、token 或私有 URL 写进示例。
+- 以“测试环境能跑”为理由跳过审计字段。
+- 忽略依赖升级和构建配置带来的生产影响。

package/workflow/core/capabilities/test-evidence-reviewer.md

@@ -0,0 +1,50 @@
+# Capability: test-evidence-reviewer
+
+- **Tier**: optional
+- **Stage**: `/06`, `/07`
+- **Purpose**: 检查测试是否真正证明了需求行为，包括正常流、异常流、边界、兼容和明确跳过路径。
+
+## 为什么需要
+
+“测试通过”不等于覆盖充分。很多缺陷来自测试矩阵缺行，尤其是异常分支、重复请求、权限边界、旧数据兼容和跨端展示不一致。
+
+## 输入
+
+- `02-产品文档.md` 的验收标准
+- `04-代码实现.md` 的实现范围
+- `06-测试用例.md`
+- `07-测试执行报告.md` 的真实结果
+
+## 输出
+
+```yaml
+result: PASS | WARN | BLOCK
+coverage:
+  - requirement: "<验收项>"
+    test_case: "<测试用例>"
+    execution: pass | fail | not-run
+    evidence: "<证据>"
+gaps:
+  - "<缺失用例或未执行原因>"
+```
+
+## 阻断规则
+
+- P0/P1 验收项没有测试用例或执行证据时阻断。
+- 缺少关键异常路径、边界路径或权限路径时降级为 WARN 或 BLOCK。
+- 被跳过的路径必须记录原因和后续复测计划。
+
+## Adapter 示例
+
+- **L0**: 测试报告固定覆盖矩阵。
+- **L1**: prompt 按验收项逐条核对。
+- **L2**: slash command 生成测试证据审查表。
+- **L3**: hook 阻止无执行证据的测试完成状态。
+- **L4**: subagent 独立复核测试充分性。
+
+## 反模式
+
+- 只记录“通过”，不记录用例和证据。
+- 没有负例、边界和权限验证。
+- 把未执行项从报告中删掉。
+- 用开发自测替代验收用例。

package/workflow/core/capabilities/ui-baseline-reviewer.md

@@ -0,0 +1,50 @@
+# Capability: ui-baseline-reviewer
+
+- **Tier**: optional
+- **Stage**: `/02`, `/04A`, `/05`
+- **Purpose**: 检查 UI 实现是否符合设计基线、前端规范，以及展示、校验、提交和后端表示的一致性。
+
+## 为什么需要
+
+UI 问题常发生在“页面能打开”之后：字段展示不一致、回显缺失、校验口径不同、按钮状态不全、移动端溢出或与后端枚举不一致。需要把设计基线和真实实现放在一起审查。
+
+## 输入
+
+- `workflow/team-profile.yaml#source_materials.ui_specs`
+- `workflow/team-profile.yaml#source_materials.frontend_rules`
+- UI 相关 diff、截图或运行页面
+- API / DTO / 枚举等后端契约
+
+## 输出
+
+```yaml
+result: PASS | WARN | BLOCK
+ui_checks:
+  - surface: "<页面或组件>"
+    baseline: "<设计或规范来源>"
+    implementation: "<file:line 或截图>"
+    verdict: pass | warn | block
+gaps:
+  - "<缺少设计、截图或后端契约证据>"
+```
+
+## 阻断规则
+
+- 需求涉及 UI 但没有设计基线、页面参考或待确认说明时阻断产品文档完成。
+- 展示、校验、提交字段与后端契约不一致时阻断实现完成。
+- 未验证移动端 / 小屏 / 长文本等关键布局风险时降级为 WARN。
+
+## Adapter 示例
+
+- **L0**: PRD 和前端实现文档固定 UI 基线字段。
+- **L1**: prompt 要求提供设计来源和截图。
+- **L2**: slash command 生成 UI 审查清单。
+- **L3**: hook 检查 UI 阶段是否有截图或阻塞说明。
+- **L4**: subagent 专门做 UI 和契约一致性审查。
+
+## 反模式
+
+- 没有设计依据就臆造页面。
+- 只看页面截图，不查提交字段。
+- 忽略错误态、空态、加载态和权限态。
+- 移动端文本溢出但未记录。

package/workflow/core/capabilities/verify-app.md

@@ -0,0 +1,51 @@
+# Capability: verify-app
+
+- **Tier**: recommended
+- **Stage**: `/04` 结束前，`/07` 全程
+- **Purpose**: 用真实执行的验证计划替代“看起来可用”，记录构建、单测、集成、浏览器或人工验证证据。
+
+## 为什么需要
+
+验证质量直接决定审查和交付质量。即使验证很小，也要写清命令、结果和证据；不能把未执行的测试、跳过的测试或构建通过写成业务验证通过。
+
+## 输入
+
+- `workflow/team-profile.yaml#repos[*].tech_stack`
+- `04-代码实现.md` 中的实现范围
+- 可用 CI 命令、本地脚本和人工流程
+- 历史成功验证命令
+
+## 输出
+
+```yaml
+result: PASS | WARN | BLOCK
+verifications:
+  - repo: "<repo>"
+    method: unit | integration | e2e | manual | build-only
+    command: "<实际执行命令>"
+    status: pass | fail | not-run
+    evidence: "<日志、截图或观察记录>"
+gaps:
+  - "<未执行原因>"
+```
+
+## 阻断规则
+
+- 实现阶段结束时，所有受影响仓库都没有成功验证且无原因记录时阻断。
+- 测试命令跳过测试、无断言输出或只有编译成功时，不能写成业务验证通过。
+- 只能人工验证时，必须记录步骤和观察结果；否则降级为 WARN。
+
+## Adapter 示例
+
+- **L0**: `04-代码实现.md` 必须有验证章节。
+- **L1**: prompt 根据技术栈建议验证命令。
+- **L2**: slash command 执行本地验证并写入结果。
+- **L3**: hook 阻止缺少验证记录的完成状态。
+- **L4**: subagent 专门执行和整理验证结果。
+
+## 反模式
+
+- 没有证据就标记实现完成。
+- 只贴日志，不写命令。
+- `BUILD SUCCESS` 但测试被跳过，仍写“测试通过”。
+- 用一个技术栈的验证方式套所有项目。

package/workflow/core/capabilities/worktree-isolator.md

@@ -0,0 +1,53 @@
+# Capability: worktree-isolator
+
+- **Tier**: recommended
+- **Stage**: `/04`, `/04A`, `/04B`
+- **Purpose**: 同一仓库多个需求并行实现时，强制一个需求一个 worktree，避免改动混在同一工作目录。
+
+## 为什么需要
+
+同仓多需求在一个目录里反复切分支，最容易产生未保存改动、暂存区残留、错分支提交和同文件冲突。进入实现阶段后必须用物理目录隔离。
+
+## 输入
+
+- 活跃开发登记表，例如 `features/00-active-branches.md`
+- 当前需求、受影响仓库、功能分支和 worktree 路径
+- 当前 `pwd`、分支、dirty 状态
+- 本次影响文件清单
+
+## 输出
+
+```yaml
+result: PASS | WARN | BLOCK
+repo: "<repo>"
+current_worktree: "<path>"
+registered_worktree: "<path>"
+same_repo_active_features:
+  - feature: "<feature>"
+    branch: "<branch>"
+    files: ["..."]
+conflicts:
+  - type: same_file | same_sql | same_method | same_business_rule
+    detail: "..."
+```
+
+## 阻断规则
+
+- 同仓已有其他活跃 04 阶段需求，且当前需求未使用独立 worktree 时阻断。
+- 两个活跃需求改同一文件、SQL、方法或业务口径时，默认阻断后进入实现的需求。
+- agent 不得自动创建开发分支；worktree 创建也必须先由用户确认已有本地功能分支。
+
+## Adapter 示例
+
+- **L0**: 在 `AGENTS.md` 写明同仓并行策略。
+- **L1**: prompt 要求用户确认 worktree 路径。
+- **L2**: slash command 读取活跃登记表并输出准入结论。
+- **L3**: 写入前 hook 检查当前目录是否为登记 worktree。
+- **L4**: subagent 维护活跃需求冲突矩阵。
+
+## 反模式
+
+- 在一个目录里切两个功能分支同时开发。
+- 只按分支名判断隔离完成，不检查 `pwd`。
+- 同文件不同区域也默认并行。
+- 把 integration 分支当正式开发分支。

package/workflow/core/commands/01-/351/234/200/346/261/202/350/256/250/350/256/272.md

@@ -0,0 +1,36 @@
+# /01-需求讨论
+
+## Goal
+
+需求讨论: 澄清业务目标、边界、验收口径和待确认项。
+
+## Required Inputs
+
+- `AGENTS.md`
+- `workflow/team-profile.yaml`
+- `workflow/constitution.md`（既定原则不再重新讨论）
+- Workspace-level `specs/` 现有行为基线（brownfield 需求必读：先弄清现在是什么，再定义改成什么）
+- Previous stage documents under workspace-level `features/{feature}/`
+- Local code, local docs, and user-provided source materials listed in team-profile
+- 商业化基线（如存在）：workspace-level `business/{product}/B1-业务定位.md`、`B3-PMF与客户画像.md`、`B4-场景与购买旅程.md`
+
+## Execution Rules
+
+- Read local facts before writing conclusions.
+- Distinguish verified facts, design intent, assumptions, and missing evidence.
+- 默认使用简体中文展示工作流沟通和阶段产物；专有名词、产品名、品牌名、代码标识符、命令、文件路径、分支名、API、SDK、框架、协议、标准、错误信息和官方英文术语保留原文。
+- Do not claim tests, builds, screenshots, deployments, or reviews passed unless they were actually executed.
+- Local branch creation, commit, tag, and local merge may be executed by the agent for personal projects after scope and working-tree checks. Remote Git refresh, push, release, deployment, database write, and production config write require explicit user authorization.
+- This stage does not authorize business code changes unless the current command is an implementation command and all gates pass.
+- 若工作区存在 `business/{product}/` 商业化基线：需求价值必须能挂到 ICP 和使用场景（引用 B1/B3/B4 的具体条目）；需求主要服务负面画像时显式标记并请用户确认取舍；商业化基线缺失时不阻塞本阶段，但要记录缺口。
+- 触碰 `specs/` 已有行为的需求，必须显式写出"改变哪几条现有行为（编号）"，不得把存量行为当空白重新发明。
+- 无法当场确定的问题用 `[待澄清: 问题描述]` 就地标记，不要用含糊表述掩盖；标记多或分歧大时建议运行 `/澄清` 收敛。模糊词（快、流畅、稳定、好用等）出现时必须绑定数字或可观察行为，做不到就转成 `[待澄清]`。
+- 本阶段结论是 `/定义完成` 编译完成合同的直接输入：业务目标、边界、验收口径尽量写成可被 Oracle 化的陈述。
+
+
+
+## Required Outputs
+
+- Update or create the corresponding file under workspace-level `features/{feature}/`.
+- Update workspace-level `features/{feature}/00-工作流状态.md` when stage status changes.
+- Record unresolved questions and evidence gaps explicitly.

package/workflow/core/commands/02-/344/272/247/345/223/201/346/226/207/346/241/243.md

@@ -0,0 +1,35 @@
+# /02-产品文档
+
+## Goal
+
+产品文档: 输出 PRD、业务规则、高层 UI 方向、非功能需求和验收口径；详细 UI/UX 设计基线由后续 `/02B-UI设计` 阶段承接。
+
+## Required Inputs
+
+- `AGENTS.md`
+- `workflow/team-profile.yaml`
+- Previous stage documents under workspace-level `features/{feature}/`
+- Local code, local docs, and user-provided source materials listed in team-profile
+- 商业化基线（如存在）：workspace-level `business/{product}/B2-商业模式.md`、`B3-PMF与客户画像.md`、`B4-场景与购买旅程.md`
+
+## Execution Rules
+
+- Read local facts before writing conclusions.
+- Distinguish verified facts, design intent, assumptions, and missing evidence.
+- 默认使用简体中文展示工作流沟通和阶段产物；专有名词、产品名、品牌名、代码标识符、命令、文件路径、分支名、API、SDK、框架、协议、标准、错误信息和官方英文术语保留原文。
+- Do not claim tests, builds, screenshots, deployments, or reviews passed unless they were actually executed.
+- Local branch creation, commit, tag, and local merge may be executed by the agent for personal projects after scope and working-tree checks. Remote Git refresh, push, release, deployment, database write, and production config write require explicit user authorization.
+- This stage does not authorize business code changes unless the current command is an implementation command and all gates pass.
+- This stage should identify major UI surfaces and design risks, but should not replace `/02B-UI设计` when the feature has meaningful frontend or user-facing workflow.
+- 若工作区存在 `business/{product}/` 商业化基线：PRD 的目标用户直接引用 B3 的 ICP 与负面画像；涉及付费、定价或免费层边界的需求必须与 B2 商业模式口径一致，不一致时先对齐再定稿。
+- 验收口径必须**可度量且技术无关**（例：「新用户 2 分钟内完成首次创建」而非「体验流畅」）；关键行为建议用 EARS 或 Given/When/Then 句式，直接可作 `/定义完成` 的 Oracle 候选。
+- 未决口径用 `[待澄清: …]` 就地标记；禁止用模糊词代替决策，必要时运行 `/澄清`。
+- 非功能需求不再一句带过：性能、资源、成本、安全至少各给一条硬数字或显式"无约束+理由"，供完成合同的质量预算引用。
+
+
+
+## Required Outputs
+
+- Update or create the corresponding file under workspace-level `features/{feature}/`.
+- Update workspace-level `features/{feature}/00-工作流状态.md` when stage status changes.
+- Record unresolved questions and evidence gaps explicitly.

package/workflow/core/commands/02B-UI/350/256/276/350/256/241.md

@@ -0,0 +1,75 @@
+# /02B-UI设计
+
+## Goal
+
+UI 设计: 在 `/02-产品文档` 之后、`/03-技术架构` 之前，输出可被前端实现直接遵循的 UI/UX 设计基线、关键流程、页面清单、组件规范、平台适配、交互状态、可访问性和交付验收口径。
+
+## Required Inputs
+
+- `AGENTS.md`
+- `workflow/team-profile.yaml`
+- Workspace-level `features/{feature}/01-需求讨论.md`
+- Workspace-level `features/{feature}/02-产品文档.md`
+- Existing design references declared in `workflow/team-profile.yaml#source_materials.ui_specs`
+- Existing frontend rules declared in `workflow/team-profile.yaml#source_materials.frontend_rules`
+- Platform references relevant to the feature, such as Apple Human Interface Guidelines, Apple Design Resources, Figma handoff practices, and any project-specific Figma/GitHub design system references
+
+## Execution Rules
+
+- Read local facts before writing conclusions.
+- Distinguish verified facts, design intent, assumptions, and missing evidence.
+- 默认使用简体中文展示工作流沟通和阶段产物；专有名词、产品名、品牌名、代码标识符、命令、文件路径、分支名、API、SDK、框架、协议、标准、错误信息和官方英文术语保留原文。
+- Do not claim prototypes, screenshots, design reviews, usability tests, builds, or visual QA passed unless they were actually executed.
+- Local branch creation, commit, tag, and local merge may be executed by the agent for personal projects after scope and working-tree checks. Remote Git refresh, push, release, deployment, database write, production config write, and publishing a Figma file require explicit user authorization.
+- This stage does not authorize business code changes.
+- If no external visual reference exists, create a written UI baseline first; do not invent polished final visuals without marking them as draft design intent.
+- 默认只产出 `02B-UI设计.md` 设计文档。除非用户在本阶段明确要求生成 UI 设计图/视觉稿/原型图，否则不调用任何设计图生成工具（设计类 MCP、图像生成、Figma 文件生成、可视化/HTML 视觉稿导出等）去生成设计文件。
+- For iOS/macOS/watchOS/visionOS targets, default to Apple platform conventions before custom patterns.
+- For Web targets, record responsive breakpoints, keyboard behavior, accessibility rules, and component/token mapping explicitly.
+- If Figma is used, document the Figma file/page/frame, component names, variants, Auto Layout/constraints, prototype links, annotations, measurements, and readiness status.
+- If no Figma file is used, record wireframe descriptions, layout constraints, component inventory, state matrix, and screenshot/visual QA plan in enough detail for implementation.
+
+## 设计图生成边界
+
+- 默认文档优先：本阶段默认产物只有 `features/{feature}/02B-UI设计.md` 与 `features/{feature}/00-工作流状态.md` 的状态更新，用文字基线、线框描述、组件清单和状态矩阵把设计讲清楚。
+- 不主动出图：未经用户在本阶段明确要求，不得调用任何设计图/视觉稿生成工具生成设计文件，也不得把臆造的高保真视觉当成既定设计。
+- 显式触发才出图并留痕：仅当用户明确要求生成 UI 设计图/视觉稿/原型图时才调用相应工具；生成后在 `02B-UI设计.md` 记录使用的工具、产物清单和文件路径，并标注其为草稿设计意图还是已确认设计。
+- 不削弱 04A Gate：无论是否出图，`/04A-前端代码实现` 仍以 `02B-UI设计.md` 的设计基线为准。
+
+## Required Outputs
+
+- Create or update workspace-level `features/{feature}/02B-UI设计.md`.
+- Update workspace-level `features/{feature}/00-工作流状态.md` when stage status changes.
+- Record unresolved design questions and evidence gaps explicitly.
+- Record external references used and why they apply.
+- Produce an implementation handoff section that `/04A-前端代码实现` must follow.
+
+## Required Structure
+
+The `02B-UI设计.md` output should include:
+
+1. **设计目标与用户情境**：目标用户、核心任务、使用频率、设备情境和成功体验。
+2. **参考来源与适用性**：列出参考的 iOS、macOS、Web、Figma、GitHub design system 或其他资料；说明哪些规则会采用，哪些不采用。
+3. **信息架构**：导航结构、页面层级、主要入口、空状态、错误状态和设置入口。
+4. **关键用户流程**：首次进入、核心创建/编辑/订阅/搜索/支付/反馈等流程；每个流程写清进入条件、关键状态和退出路径。
+5. **页面清单**：页面名称、平台、主要组件、关键数据、状态、权限/合规提示、埋点候选。
+6. **设计系统基线**：颜色、字体、字号层级、间距、栅格、圆角、阴影/材质、图标、动效、图片/插画、design tokens 和命名规则。
+7. **组件规范**：按钮、输入、列表、卡片、导航、筛选、弹窗、权限说明、付费墙、反馈表单等组件的状态、尺寸、交互和错误处理。
+8. **平台适配**：iOS、iPadOS、macOS、Web 等差异；包括导航、窗口尺寸、键盘、鼠标/触控、系统组件和平台惯例。
+9. **多语言与可访问性**：文本扩展、动态字体、VoiceOver/屏幕阅读器、颜色对比、触控目标、键盘焦点、RTL 或 locale 差异。
+10. **响应式与视觉 QA**：需要验证的设备/视口、截图清单、状态清单、可接受偏差和阻塞条件。
+11. **体验预算**：可验收的体验质量线——感知性能（首屏骨架/进度反馈/乐观更新的具体要求）、三态完备（每个页面/组件的空态、错误态、加载态定义）、微文案（语气基线、错误信息必须可行动）、可访问性最低线（对比度、键盘可达、屏幕阅读器关键路径）、动效克制度（时长/缓动/可关闭）。每条写成可检查表述，供完成合同「体验质量线」直接引用，并至少提炼 1 条 manual 体验 Oracle 候选。
+12. **04A 实现交接规范**：前端实现必须读取的设计决策、组件映射、禁止偏离项、允许实现侧调整项、偏离记录格式。
+13. **待确认项**：只保留真实阻塞设计落地的问题。
+
+## Design Reference Baseline
+
+- Apple Human Interface Guidelines: 用作 iOS、iPadOS、macOS、watchOS、visionOS 平台交互、导航、控件、可访问性和系统一致性的基准。
+- Apple Design Resources: 使用 Apple 官方 iOS/iPadOS/macOS UI kits、Figma templates、SF Symbols、SF Pro、Icon Composer 等资源确认平台视觉和资产规格。
+- Figma Dev Mode / handoff practices: 使用 ready-for-dev、comments、annotations、measurements、component properties 和 prototype links 保持设计与实现同步。
+- GitHub Primer Design System: 参考 design tokens、component documentation、accessibility 和可维护设计系统文档方式，尤其适合 Web 或后台类产品。
+- IBM Carbon Design System: 参考开源 design system 的 foundations、Figma kit、代码组件、贡献机制和企业级可访问性文档方式。
+
+## 04A Gate
+
+`/04A-前端代码实现` 必须读取 `features/{feature}/02B-UI设计.md`。如果该文件缺失，或者关键页面没有 UI 设计基线，前端实现不得直接开始；只能先补齐 `/02B-UI设计`，或在 `04A` 文档中记录用户明确授权的设计豁免、影响范围和后续补齐计划。

package/workflow/core/commands/03-06-/347/240/224/345/217/221/345/207/206/345/244/207.md

@@ -0,0 +1,30 @@
+# /03-06-研发准备
+
+## Goal
+
+研发准备编排: 在已有 PRD 和必要的 02B UI 设计基线后串联生成 03 到 06 的研发准备文档；不授权代码实现。
+
+## Required Inputs
+
+- `AGENTS.md`
+- `workflow/team-profile.yaml`
+- Previous stage documents under workspace-level `features/{feature}/`
+- Local code, local docs, and user-provided source materials listed in team-profile
+
+## Execution Rules
+
+- Read local facts before writing conclusions.
+- Distinguish verified facts, design intent, assumptions, and missing evidence.
+- 默认使用简体中文展示工作流沟通和阶段产物；专有名词、产品名、品牌名、代码标识符、命令、文件路径、分支名、API、SDK、框架、协议、标准、错误信息和官方英文术语保留原文。
+- Do not claim tests, builds, screenshots, deployments, or reviews passed unless they were actually executed.
+- Local branch creation, commit, tag, and local merge may be executed by the agent for personal projects after scope and working-tree checks. Remote Git refresh, push, release, deployment, database write, and production config write require explicit user authorization.
+- This stage does not authorize business code changes unless the current command is an implementation command and all gates pass.
+- This orchestration command only prepares documents from 03 to 06; it does not authorize code implementation.
+- If the feature includes UI or frontend work, verify `features/{feature}/02B-UI设计.md` exists before generating frontend implementation or test-prep materials. If it is missing, create or request `/02B-UI设计` first.
+
+
+## Required Outputs
+
+- Update or create the corresponding file under workspace-level `features/{feature}/`.
+- Update workspace-level `features/{feature}/00-工作流状态.md` when stage status changes.
+- Record unresolved questions and evidence gaps explicitly.