Development
增量式实现
以增量方式交付变更。当实现任何涉及多个文件的功能或改动时使用。
以纵向薄切片的方式构建——实现一小块，对其进行测试、验证，然后再扩展。
┌──────────────────────────────────────┐
│ │
│ Implement ──→ Test ──→ Verify ──┐ │
│ ▲ │ │
│ └───── Commit ◄─────────────┘ │
│ │ │
│ ▼ │
│ Next slice │
│ │
└──────────────────────────────────────┘
对于每个切片：
构建一条贯穿整个技术栈的完整路径：
Slice 1: Create a task (DB + API + basic UI)
→ Tests pass, user can create a task via the UI
Slice 2: List tasks (query + API + UI)
→ Tests pass, user can see their tasks
Slice 3: Edit a task (update + API + UI)
→ Tests pass, user can modify tasks
Slice 4: Delete a task (delete + API + UI + confirmation)
→ Tests pass, full CRUD complete
先攻克风险最高的部分：
Slice 1: Prove the WebSocket connection works (highest risk)
Slice 2: Build real-time task updates on the proven connection
Slice 3: Add offline support and reconnection
在编写任何代码之前，先问：“能行得通的最简单做法是什么？”
SIMPLICITY CHECK:
✗ Generic EventBus with middleware pipeline for one notification
✓ Simple function call
✗ Abstract factory pattern for two similar components
✓ Two straightforward components with shared utilities
✗ Config-driven form builder for three forms
✓ Three form components
只改动任务所需的部分。不要“顺手整理”相邻的代码。
每个增量只改动一件逻辑上的事情。不要混淆关注点。
每次增量之后，项目必须能够构建，且现有测试必须通过。
const ENABLE_TASK_SHARING = process.env.FEATURE_TASK_SHARING === 'true';
if (ENABLE_TASK_SHARING) {
// New sharing UI
}
新代码应默认采用安全、保守的行为：
export function createTask(data: TaskInput, options?: { notify?: boolean }) {
const shouldNotify = options?.notify ?? false;
// ...
}
每个增量都应能够独立回退。
每次增量之后：
npm test）npm run build）npx tsc --noEmit）npm run lint）完成一个任务的所有增量之后：