SDD 规格驱动开发
Nexus 原生面向 AI 编程设计。它采用 SDD（Spec Driven Development，规格驱动开发）：让 Coding Agent 先定义规格、再按规格实施与验收，从需求规划到部署上线全程可追溯、可验收。
核心原则
所有规划与实施决策必须遵守（源自项目顶层规格 .oms/SPEC.md）：
- 人类主导决策：AI 提供建议和方案，关键决策必须由人类确认后才能执行。
- 规格先行：任何实施前必须先产生规格文档，经人类确认后再执行。
- 测试先行：编写实现代码前必须先定义并确认测试规格。
- 层级推进：产品顶层规格 → Sprint 目标 → 功能规格 → 实施，不可跳层。
- 聚焦范围：每个 Sprint / 阶段只做当前必需的，不提前实现「未来可能需要」的功能。
三条铁律
- 铁律 I · 路径管理：操作
.oms/前必须先定位项目根目录。 - 铁律 II · 无规格不实施：收到实施请求必须先确认规格就位。
- 铁律 III · 无测试不实现：先写测试（红）→ 再写代码（绿）→ 全量通过才能归档。
.oms/ 规格体系
SDD 的所有产物沉淀在 .oms/ 目录（项目根），它是 Agent 与人类的「单一事实来源」：
text
.oms/
├── SPEC.md ← 项目顶层规格（产品边界与核心价值）
├── CONTEXT.md ← 项目状态中转站（Sprint / 阶段 / 任务项）
├── ISSUES.md ← 待处理问题列表
├── TEST.md ← 测试命令配置
├── BUILD.md ← 构建型 Sprint 规范
├── MEMO.md ← 决策备忘录
├── AGENT_CONTEXT_PROTOCOL.md ← Agent 上下文协议
├── sprints/ ← Sprint 级别规格文档
├── plans/ ← 功能规划文档（spec.md + dod.md + design.md）
├── feats/ ← 已归档功能文档
├── infra/ ← 基础设施文档
├── research/ ← 技术调研文档
├── done/ ← 已完成归档
└── design-system/ ← 设计系统约定- SPEC.md：产品定位、目标用户、核心价值、关键特性、边界约定、核心假设。任何重大决策都回溯它。
- CONTEXT.md：当前 Sprint / 阶段 / 任务的状态中转；📋 链接行是唯一的「已规划」标志（有 📋 = 已规划，无 📋 = 未规划）。
- plans/
<feature>/：单个功能规划，包含spec.md（做什么）、design.md（怎么做）、dod.md（Definition of Done，测试规格）。
为什么适合 AI 原生
- 可追溯：每一步都有文档产物，人类随时 review、Agent 随时回溯。
- 可验收：DoD（测试规格）是「完成」的客观标准，避免「感觉做完了」。
- 防跑偏：层级推进 + 聚焦范围，阻止 Agent 擅自扩大实现范围。
- 可沉淀：Sprint / Feature 归档形成团队知识库，新成员或新 Agent 可快速接手。
规格文档是 AI 实施的唯一基准。人类确认规格的那一刻，才赋予 Agent 实施许可。