bain-riper-cli 0.1.1

package/templates/qoder/rules/openspec_reverse_sync.md

@@ -0,0 +1,97 @@
+---
+trigger: model_decision
+description: OpenSpec apply 阶段的 Reverse Sync（反向同步）硬规则。在 openspec-apply-change 执行过程中，一旦发现 spec/design/tasks 与代码实现存在偏差，必须立即执行五步法（停止→诊断→回写文档→等确认→继续），禁止反向修改代码适配错误文档。触发 openspec-apply-change skill 时必须加载本文件。
+---
+
+# OpenSpec Reverse Sync（反向同步硬规则）
+
+> ⚖️ **上级规则**：本文件受 `.qoder/rules/project_constitution.md`（项目宪法，always_on）约束。
+> 宪法 §1「Spec is Truth」即本文件的理论根基——代码、文档冲突时**先改文档，再改代码**。
+
+**本文件是 项目在 apply 阶段处理 spec 偏差的唯一标准流程。**
+目的：确保 Spec 始终是业务行为的唯一真相源，杜绝「代码写完、文档烂尾」的腐败。
+
+---
+
+## §一、触发条件（以下任一情况出现即必须启动）
+
+在整个 `openspec-apply-change` 执行过程中，一旦发现：
+
+1. 按 `tasks.md` 实现时，发现 `spec.md` / `design.md` 中的描述与实际代码结构无法对齐
+2. `reference-code` 中同类型实现与 spec 存在冲突
+3. 实现过程中发现 spec 遗漏了关键字段 / 接口 / 校验规则
+4. 实现过程中发现 `tasks.md` 的步骤顺序或依赖关系存在错误
+
+**必须立即执行下方五步法，禁止以下行为**：
+- ❌ 先改代码以适配错误的 spec
+- ❌ 在代码中埋 TODO 占位绕过 spec 偏差
+- ❌ 口头说"后面再修文档"然后继续写代码
+
+---
+
+## §二、Reverse Sync 五步法
+
+### 第 1 步：停止
+**立即停止**当前任务的代码实现。在回复中显式声明：
+> ⚠️ 检测到 spec/deviation，暂停代码实现，启动 Reverse Sync。
+
+### 第 2 步：诊断
+在回复中**明示偏差点**，格式：
+```
+偏差点：<具体描述>
+位置：
+  - spec.md §X 行 Y：「原文」
+  - design.md §Z：「原文」
+  - 实际代码/结构：「现状」
+建议修订方向：<一句话>
+```
+每个偏差点必须引用具体文件、章节、行号或原文片段，禁止模糊描述。
+
+### 第 3 步：回写文档（核心）
+**先修改文档，而非代码**。使用 `search_replace` 工具提交 `spec.md` /
+`design.md` / `tasks.md` 的修订。修订范围应限于：
+- 补充遗漏字段 / 接口 / 校验规则
+- 修正错误的步骤顺序或依赖关系
+- 修正与实际代码结构不符的描述
+
+**严禁在回写文档的同时修改代码**。第 3 步**只改文档**。
+
+### 第 4 步：等待确认
+回写完成后，**必须等待用户明确确认**（"OK / 同意 / 继续"等）。
+未确认前禁止进入第 5 步，禁止恢复代码实现。
+
+若用户拒绝修订方向，回到第 2 步重新诊断。
+
+### 第 5 步：继续
+用户确认后，回到原任务的代码实现，**基于修正后的文档**继续工作。
+
+---
+
+## §三、档位差异
+
+| 档位 | Reverse Sync 执行力度 |
+|---|---|
+| **zero** | 不适用（无代码变更） |
+| **fast** | 偏差暴露时仍须执行五步法，但因改动小（单字段/单枚举），诊断应 ≤2 个偏差点 |
+| **standard** | 严格遵守五步法，诊断可含 3-5 个偏差点 |
+| **deep** | **零容忍**——任何偏差必须立即触发五步法；诊断不设上限；回写完成后须**逐条核验**修正是否闭环；禁止以"后续 change 再修"为理由推迟 |
+
+---
+
+## §四、与其他文件的关系
+
+| 文件 | 关系 |
+|---|---|
+| `.qoder/rules/project_constitution.md` | 宪法 §1「Spec is Truth」为本文件的理论根基 |
+| `.qoder/rules/openspec_preflight.md` | apply 阶段 Preflight 完成后，本文件在实施中持续生效；§零.4 Core Goal Loop Anchor 检测到目标偏移时触发本文件的五步法 |
+| `.qoder/rules/openspec_output_specs.md` | §五 tasks.md 末尾记录本文件的硬约束摘要 |
+| `.qoder/skills/openspec-apply-change/SKILL.md` | 本文件替代原 SKILL.md 中 Step 0 Reverse Sync 块与 Guardrails 中的硬规则；apply skill 触发时由 Qoder model_decision 加载本文件 |
+
+---
+
+## §五、自检清单（apply 阶段 Preflight 中必须验证）
+
+- [ ] 已加载本文件并理解五步法
+- [ ] 若当前任务档位为 `deep`：已确认零容忍策略
+- [ ] 已知偏差触发条件（§一 4 条）
+- [ ] 已约定偏差点诊断格式（文件 + 章节 + 原文引用）

package/templates/qoder/rules/openspec_specifications.md

@@ -0,0 +1,84 @@
+---
+trigger: glob
+glob: openspec/**/*.md
+---
+# OpenSpec 项目规则索引
+
+> ⚖️ **上级规则**：本文件受 `.qoder/rules/project_constitution.md`（项目宪法，always_on）约束。宪法 §7 目录约束即本文件 §三 的源头，冲突以宪法为准。
+
+适用范围：在 `openspec/changes/**` 与 `openspec/specs/**` 下创建或修改
+`proposal.md` / `design.md` / `spec.md` / `tasks.md` 时生效。
+
+本文件作为 OpenSpec 项目规则的**索引层**，按职责将完整规则拆分为三份独立文件。
+任何 artifact 的写作都必须依次满足这三层约束。
+
+## 零、项目宪法（最高优先级）
+
+**单一真相源**：⚖️ `.qoder/rules/project_constitution.md`（trigger: always_on）
+
+定义 10 条跨场景绝不可违反的底线（Spec is Truth / Restate First / 多租户 /
+SHALL-MUST / 禁重复造轮子 / 禁猜 API / 标准分层 / 参考代码对齐 /
+禁独立编译任务 / Preflight 自检物理可见）。
+本索引仅列条目，条款正文以宪法文件为准。
+
+## 一、Preflight（写作前）
+
+**单一真相源**：📋 `.qoder/rules/openspec_preflight.md`
+
+定义写作前的 Restate First、前置阅读、Preflight 自检清单。
+未完成 Preflight 前禁止生成任何 artifact。
+
+## 二、Output Specs（写作中 / 落盘前）
+
+**单一真相源**：📋 `.qoder/rules/openspec_output_specs.md`
+
+定义 proposal / design / spec / tasks 四类 artifact 的章节硬性要求、
+通用输出约定、Artifact 输出自检清单。
+未通过自检禁止落盘。
+
+## 二点五、Task Tiers（任务深度分级）
+
+**单一真相源**：📋 `.qoder/rules/openspec_task_tiers.md`
+
+定义 `zero` / `fast` / `standard` / `deep` 四档及其流程裁剪：
+fast 档跳过 design.md 与 Clarify；standard 默认全套；deep 追加
+codemap.md 与 ≥5 个 Clarify 点。Restate 末尾必须声明档位。
+
+## 二点六、Reverse Sync（反向同步硬规则）
+
+**单一真相源**：📋 `.qoder/rules/openspec_reverse_sync.md`
+
+定义 apply 阶段发现 spec/design/tasks 偏差时的五步处理流程
+（停止→诊断→回写文档→等确认→继续）。apply 阶段必须加载。
+
+## 二点七、CodeGraph 代码知识图谱（工具增强）
+
+**单一真相源**：📋 `.qoder/rules/openspec_codegraph.md`
+
+定义 CodeGraph（v0.9.4）MCP 工具在代码探索中的分层与优先级：
+`codegraph_query / callers / callees / impact / context / files / status / sync`。
+对宪法 §5（禁重复造轮子）、§6（禁猜测 API）、§1（Spec is Truth）提供
+工具级增强，减少 Grep/Glob 手工扫描 token 消耗。可选启用，失败降级。
+
+## 三、目录与命名约束
+
+> 完整目录树与所有路径约定见 `openspec/project-profile.md` §2 / §3。
+> 以下为速记摘要，冲突以 profile 为准。
+
+```
+<base-package>/
+├── controller/           # REST API endpoints
+├── service/              # Business logic layer
+│   └── impl/             # Service implementations
+├── mapper/               # MyBatis mapper interfaces
+├── constant/             # Enums and constants
+├── config/               # Spring config & utility classes
+└── domain/               # JPA/MyBatis entities
+    ├── params/           # param objects
+    └── vo/               # view objects
+```
+
+- 新增实体、Mapper、Service、Controller 必须落在上述目录
+- 常量/枚举统一 `constant/`
+- 工具类与 Spring 配置统一 `config/`
+- 基础包路径、Mapper XML 路径、建表 SQL 路径等具体值见 profile

package/templates/qoder/rules/openspec_task_tiers.md

@@ -0,0 +1,109 @@
+---
+trigger: model_decision
+description: OpenSpec 四档任务深度分级（zero / fast / standard / deep）。在 Restate First 完成后，必须据此判定本次任务档位并向用户声明，再按档位裁剪 Clarify / 前置阅读 / 四件套 / Reverse Sync 的执行力度。触发 openspec-propose / openspec-continue-change / openspec-explore / openspec-apply-change 四个 skill 时必须加载本文件。
+---
+
+# OpenSpec 任务深度分级（Task Tiers）
+
+> ⚖️ **上级规则**：本文件受 `.qoder/rules/project_constitution.md`（项目宪法，always_on）约束。
+> 宪法 §2 Restate First 在本文件扩展为「复述 + 声明档位」两步。档位无论高低，均不得绕开宪法 10 条底线。
+
+**本文件是 项目对任务规模的唯一分级标准。**
+目的：让小任务轻量、大任务扎实。避免"改一个字段也要跑完四件套"的体验负担。
+
+---
+
+## §一、四档定义（按"范围 + 风险 + 交付物"三维判定）
+
+| 档位 | 适用范围 | 风险 | 交付物 | 典型用时 |
+|---|---|---|---|---|
+| **zero** | 纯问答 / 解读 / 代码走读 / 规则答疑 | 无代码变更 | 仅对话回复，不生成任何 artifact，不启动 openspec CLI | 秒级 |
+| **fast** | 单字段新增 / 单枚举补录 / 错别字 / 日志文案 / 常量修订 | 低 | 直接走 `openspec-apply-change` 风格的轻量 change：**仅 spec delta + 1 个 task**，**跳过 design.md**、**跳过 Clarify**（显式声明） | 5-15 分钟 |
+| **standard** | 单领域常规 CRUD / 导入导出 / 权限校验 / 单表字段扩展（≤3 字段） | 中 | 完整四件套（proposal + design + spec + tasks），Clarify 必做 | 30-90 分钟 |
+| **deep** | 跨领域 / 架构级调整 / 多模块影响 / 涉及数据迁移 / 新增领域实体（≥5 字段） | 高 | 四件套 + 追加 `codemap.md`（关键调用链 / 入口清单），Clarify 至少 5 个歧义点，Reverse Sync 零容忍 | 半天~若干轮对话 |
+
+---
+
+## §二、判定决策树（Restate 完成后立即执行）
+
+```
+Restate 通过
+  ↓
+是否需要改代码或文档？
+  ├── 否 → [zero]（直接回复）
+  └── 是
+       ↓
+     改动是否同时满足：① ≤1 个字段/枚举/文案；② 不涉及接口签名；③ 不涉及权限/租户逻辑？
+       ├── 是 → [fast]
+       └── 否
+            ↓
+          是否满足任一条：① 跨 ≥2 个业务模块；② 动数据库 ≥2 张表；③ 改架构/中间件/通用基类；④ 新增领域实体 ≥5 字段？
+            ├── 是 → [deep]
+            └── 否 → [standard]（默认档）
+```
+
+**判定结果必须在 Restate 末尾显式声明**，格式：
+
+```
+档位：<zero|fast|standard|deep>
+理由：一句话说明为什么是这个档
+```
+
+**用户有权覆盖 AI 的判定**（"这个按 standard 跑"）。用户未反对 = 采纳 AI 判定。
+
+---
+
+## §三、各档流程裁剪
+
+### zero
+- ❌ 不走 openspec 任何 skill
+- ❌ 不生成 artifact
+- ✅ 允许直接基于已加载上下文回答；涉及代码示例时必须真实引用文件路径
+
+### fast
+- ✅ 必做：Restate + 档位声明 + Preflight 自检物理化展示（§二）
+- ❌ 可跳过：Clarify（显式声明"fast 档无需 Clarify"即可）
+- ❌ 可跳过：design.md（直接 proposal + spec delta + tasks，tasks 通常只有 1-3 条）
+- ✅ repowiki 按需：最多 **0-1 个** 主章节
+- ✅ 归档：走 `openspec-archive-change` 正常流程
+
+### standard（默认档）
+- ✅ 全套流程，严格遵守前几轮已落地的所有硬规则
+- ✅ Clarify 3-5 个歧义点
+- ✅ repowiki 最多 2 个主章节
+- ✅ 四件套齐备
+
+### deep
+- ✅ 在 standard 基础上叠加：
+  - Clarify **≥5** 个歧义点，必须覆盖架构 / 数据一致性 / 租户 / 性能 4 个维度
+  - 追加 `openspec/changes/<name>/codemap.md`（关键类 / 入口 / 调用链 / 风险点）
+  - Reverse Sync 零容忍：任何偏差必须立即触发五步法
+  - repowiki 最多 3 个主章节（仍遵守"先 list_dir 再 read_file"）
+
+---
+
+## §四、升档与降档
+
+- **升档**：实施过程中发现复杂度超出预期 → 立即停止，向用户声明升档理由（如 "fast → standard：发现需要新建 Mapper 接口"），**等用户确认后**按新档位补齐前置流程（如补 Clarify / 补 design.md）。
+- **降档**：禁止 AI 主动降档。只有用户显式要求"按 fast 跑" / "直接做" 时才允许降档，且必须保留 Restate + 档位声明两项底线。
+
+---
+
+## §五、与其他规则文件的关系
+
+| 文件 | 关系 |
+|---|---|
+| `.qoder/rules/project_constitution.md` | 宪法 §2 的"声明档位"落地于本文件 §二 |
+| `.qoder/rules/openspec_preflight.md` | §零 Restate 末尾追加档位声明；§零点五 Clarify 对 fast/zero 放行；§二 自检新增"档位项" |
+| `.qoder/rules/openspec_output_specs.md` | fast 档允许省略 design.md；其他 artifact 章节硬性要求在 standard/deep 档仍完整生效 |
+| `openspec/config.yaml` | context 新增 `Task Tiers` 段，rules.proposal 追加"档位声明"硬约束 |
+
+---
+
+## §六、档位判定自检清单（Restate 阶段必须通过）
+
+- [ ] 已在 Restate 末尾显式声明档位（`档位：<...>`）
+- [ ] 已给出判定理由（一句话）
+- [ ] 若声明为 fast：已显式写"本任务无需 Clarify"
+- [ ] 若声明为 deep：已规划 codemap.md 并预告至少 5 个 Clarify 点
+- [ ] 若用户覆盖 AI 判定：已采纳用户档位，不再争论

package/templates/qoder/rules/project_constitution.md

@@ -0,0 +1,90 @@
+---
+trigger: always_on
+---
+# 项目宪法（Constitution）
+
+**本文件是 AI 在本项目中进行任何对话、生成任何 artifact、修改任何代码时
+必须遵守的最高优先级底线清单**。无论是否进入 OpenSpec 流程、无论当前
+处于哪个 skill，以下十条条款始终生效。
+
+> 等级说明：
+> - 本宪法 **高于** `.qoder/rules/` 下的所有其他规则文件。
+> - 其他规则文件定义「怎么做」，宪法定义「**绝对不可为**」。
+> - 违反宪法 = 立即停止并向用户报错，不允许以"更好的方案"为由绕开。
+
+---
+
+## §1 Spec is Truth（真相源优先）
+OpenSpec 的 `spec.md` / `design.md` / `tasks.md` 是业务行为的**唯一真相源**。
+代码、文档、口头约定与 spec 冲突时，**先改 spec，再改其他**。
+Reverse Sync 五步法见 `.qoder/rules/openspec_reverse_sync.md`。
+
+## §2 Restate First
+在生成任何 artifact（proposal / design / spec / tasks）或开始实施任何任务前，
+必须先用 ≤8 行复述「目标 / 边界 / Done Contract / 风险」并等待用户明确确认。
+未确认禁止进入后续步骤。详见 `.qoder/rules/openspec_preflight.md` §零。
+
+## §3 多租户字段完整性
+所有业务实体、数据表、DTO、Mapper 查询必须包含多租户字段并正确过滤，
+除非该实体被知识库明确列为全局共享表（如字典、系统配置）。新增业务表
+缺失多租户字段即视为违宪。
+> 具体字段名、基类及知识库路径见 `openspec/project-profile.md` §4 / §2。
+
+## §4 SHALL / MUST 关键字
+`spec.md` 的每条 Requirement 必须以 `SHALL` 或 `MUST` 开头，否则
+`openspec archive` 会直接失败。禁止使用 should / may / will 等弱动词。
+
+## §5 禁止重复造轮子
+新增任何功能前必须：
+1. 检索仓库现有实现（同名 / 同语义的类、工具方法、Service）
+2. 核对 `pom.xml` 与 `admin/pom.xml` 已有依赖
+3. 只有现有代码与依赖均不能满足时，才允许新增
+
+禁止引入功能重复的依赖或重复实现已有工具类。
+
+## §6 禁止猜测第三方 API
+若在 `docs/reference-code/` 与仓库现有实现中未找到同类型用法，
+必须先阅读该包的源码或官方 README 确认 API 存在且版本兼容，
+再在 artifact 或代码中引用具体类名 / 方法名。严禁"假设 API 存在"式编码。
+
+## §7 标准分层目录
+所有 Java 类必须落在标准分层目录内，不得放在其他包。
+> 完整目录树与路径约定见 `openspec/project-profile.md` §3；
+> 附加资源路径（Mapper XML、建表 SQL）见 `openspec/project-profile.md` §2。
+
+## §8 参考代码优先对齐
+新增同类型功能（CRUD / 导入导出 / 权限 / 分页）必须以参考模板的
+继承结构、注解写法、分页约定、多租户处理方式为准，不得自创风格。
+> 参考模板完整文件清单见 `openspec/project-profile.md` §5。
+
+## §9 禁止独立编译验证任务
+`tasks.md` 禁止独立列出 `mvn clean compile` / `mvn compile` 等整体
+编译验证步骤。单任务内「编译无错误」作为证据可保留，但不得单独用作
+任务条目。
+
+## §10 Preflight 自检物理可见
+在执行 OpenSpec 任一 skill（propose / continue / explore / apply）的
+Step 1 之前，必须按 `.qoder/rules/openspec_preflight.md` §二 完成自检，
+并在主回复开头以可见形式展示已勾选项。未展示自检结果即视为未执行。
+
+---
+
+## 附：违宪处置流程
+1. 立即**停止**当前动作
+2. 在回复中**明示**违反条款编号
+3. **回滚**已做改动（如有）
+4. **等待用户**决定：调整需求 / 修订宪法 / 放弃任务
+
+---
+
+## 与其他规则文件的关系
+
+| 文件 | 关系 |
+|---|---|
+| `.qoder/rules/openspec_preflight.md` | 本宪法的**执行手册**，定义写作前流程 |
+| `.qoder/rules/openspec_output_specs.md` | 本宪法 §4 / §9 的**输出格式落地** |
+| `.qoder/rules/openspec_specifications.md` | 本宪法 §7 的**目录约束索引层** |
+| `openspec/config.yaml` | 向 openspec CLI 注入时提供 context / rules 双保险 |
+| `openspec/project-profile.md` | 本宪法 §3 / §5 / §7 / §8 的具体值存放处；**移植项目时唯一需大改的文件** |
+
+修改本宪法条款 = 变更项目底线，需团队讨论后谨慎执行。

package/templates/qoder/skills/requirement-breakdown/SKILL.md

@@ -0,0 +1,126 @@
+---
+name: requirement-breakdown
+description: Parse large requirement documents (.docx/.doc), clarify functionality through multi-round Q&A with user, break down into independent OpenSpec change steps, and create inputs/requirement.md for each step. Use when the user provides a requirement document and wants to split it into incremental OpenSpec changes.
+---
+
+# 需求文档拆分（Requirement Breakdown）
+
+将大需求文档（`.docx` / `.doc`）解析、澄清并拆分为多个独立的 OpenSpec change，每个 change 可单独 `/opsx:propose` 渐进实现。
+
+## 前置条件
+
+开始前确认：
+- 用户已提供需求文档路径（`.docx` 或 `.doc`）
+- `.qoder/repowiki/zh/content/` 知识库可访问
+- `openspec/changes/` 目录存在
+
+## 执行流程
+
+### Step 1：读取知识库建立项目上下文
+
+从 `.qoder/repowiki/zh/content/` 读取项目背景知识（最多 3 个主章节）：
+
+1. **系统架构设计/** — 了解技术栈、分层目录、核心依赖
+2. **核心功能模块/** — 了解现有功能模块，判断新需求归属
+3. **数据模型设计/** 或 **安全与权限/** — 按需求类型补充（数据密集型→数据模型，涉及权限→安全与权限）
+
+> 读取策略：先 `list_dir` 查看章节目录，再 `read_file` 只读 3-4 个最相关的 .md。
+> 同 session 内已读章节不重复读取。
+
+### Step 2：解析需求文档
+
+读取用户提供的 `.docx` 或 `.doc` 文件，提取核心内容：
+
+- 功能模块划分
+- 数据实体及字段
+- 业务流程与交互
+- 接口列表
+- 非功能性需求
+
+> 如果文档格式为 `.doc`（旧格式），先尝试直接解析；若失败则提示用户转换为 `.docx` 后重试。
+
+### Step 3：多轮对话澄清（必须用 AskUserQuestion）
+
+基于文档内容与业务复杂度，**不设固定轮次上限**，持续对话直到以下条件全部满足：
+- 所有功能模块的边界已明确（包含 / 不包含什么）
+- 所有数据实体字段、关联关系、多租户策略已确认
+- 各模块的实现优先级和依赖关系已排序
+- 文中模糊表述（如「支持多种方式」「后续扩展」）已逐一澄清为具体方案
+- 拆分后的每个 change 均已确认为独立可交付
+
+**每轮必须用 `AskUserQuestion` 提交选择题**（二选一或三选一），禁止开放式文本问题。
+
+**澄清维度 checklist**（逐项覆盖，未澄清不进入 Step 4）：
+- [ ] 功能边界：各模块的包含/不包含范围
+- [ ] 数据模型：实体字段、关联关系、多租户策略
+- [ ] 实现优先级：哪些模块先做、哪些可后置
+- [ ] 技术细节：是否涉及新依赖、新中间件、数据迁移
+- [ ] 拆分粒度：确认拆分后的每个 change 是否独立可交付
+- [ ] 模糊表述消歧：文档中所有不确定描述均已确认
+
+**结束条件**：用户显式回复「澄清完毕 / 没有更多问题 / 可以开始拆分」或 checklist 全部通过且用户确认，方可进入 Step 4。
+
+### Step 4：拆分并落盘
+
+澄清完成后，将需求拆分为多个独立实现步骤。每个步骤：
+
+1. **确定 `<name>`**：英文短横线命名（如 `add-employee-training-crud`）
+2. **创建目录**：`openspec/changes/<name>/`
+3. **创建 inputs 子目录**：`openspec/changes/<name>/inputs/`
+4. **写入需求文件**：`openspec/changes/<name>/inputs/requirement.md`
+
+`requirement.md` 尽可能包含：
+
+```markdown
+# [步骤中文标题]
+
+## 关联模块
+- 所属功能模块：XXX
+- 依赖的上游 change：<name>（无则填「无」）
+
+## 功能描述
+[该步骤要实现的核心功能，详细描述]
+
+## 数据范围
+- 涉及实体/表：XXX
+- 新增字段：[列出或填「无」]
+
+## 接口清单
+| 方法 | 路径 | 说明 |
+|------|------|------|
+| GET | /xxx | 分页查询 |
+| POST | /xxx | 新增 |
+
+## 不包含
+[不包含的功能]
+
+## 代码结构
+
+## 验收标准
+- [ ] XXX
+- [ ] XXX
+```
+
+### Step 5：输出拆分总览
+
+#### 5.1 输出拆分全貌表格
+
+```
+| 序号 | Change Name | 标题 | 依赖 | 启动命令 |
+|------|-------------|------|------|----------|
+| 1    | xxx         | XXX  | 无   | `/opsx:propose openspec/changes/xxx/inputs/requirement.md` |
+| 2    | yyy         | YYY  | xxx  | `/opsx:propose openspec/changes/yyy/inputs/requirement.md` |
+```
+
+#### 5.2 输出执行指引
+
+提示用户：
+> 按依赖顺序逐个执行。在**新对话**中直接复制启动命令即可开始实现，Change Name 是唯一标识，不会因序号混淆出错。
+
+## 约束
+
+- 每个 change 必须是**独立可交付**的功能增量
+- 拆分后的 change 数量建议 ≤ 5 个（超过时与用户二次确认）
+- 所有实体默认含多租户字段，除非确认为全局共享表
+- 技术判断以 `.qoder/repowiki/` 和 `openspec/project-profile.md` 为准，不猜测
+- 命名遵循 OpenSpec 规范：英文、短横线、小写