Specs（功能规格）¶

介于 raw（原始想法） 和 wiki（已实现的沉淀） 之间的工程契约层。这是多人协作的核心交付物 — 后端/前端打开就知道做什么。

子目录¶

路径	含义
`active/`	正在开发的 spec — status: approved / in-progress
`done/`	已实现的 spec — status: done（保留作历史，连同 wiki 更新一起看）
`parked/`	评估后暂缓的 spec — status: parked，含暂缓理由

命名约定¶

SPEC-<3位数序号>-<中文短标题>.md

例： - SPEC-001-knowledge-base-refactor.md - SPEC-002-定时导出Excel.md - SPEC-003-多账号管理.md

序号全局唯一、永不重用。状态变化时只动 status frontmatter，不动文件名。

当前 spec¶

🚀 Active¶

ID	标题	状态	负责人	目标版本
—	—	—	—	—

✅ Done¶

ID	标题	完成版本	链接
001	知识库改造（raw+specs+frontmatter）	v0.10.22	SPEC-001
002	Watchdog 核弹重启后自动恢复	v0.10.23	SPEC-002

💤 Parked¶

ID	标题	暂缓理由
—	—	—

状态流转¶

                  ┌──> parked（评估后暂缓 / 优先级低）
                  │
draft ─> approved ─> in-progress ─> done
  ↑          ↑
来源 raw   团队评审

状态	含义	谁能改
`draft`	起草中，待评审	作者
`approved`	评审通过，准备开干	团队
`in-progress`	正在实现	实施者
`done`	已完成 + wiki 已更	实施者
`parked`	暂缓（标明理由）	作者 / 团队

多人协作工作流¶

1. 需求来源 → docs/raw/inbox/ 或 docs/raw/feedback/
2. 评估通过 → 用 _template.md 起手写 SPEC-XXX，存到 active/
   - 后端关注：数据模型 / API 接口 / 后端任务
   - 前端关注：UI 设计 / 前端任务
3. 实施 → 按任务拆分推进，frontmatter 改 in-progress
4. 完成 → 移 done/ + 更新 wiki/ + 关联 issues 中遇到的 bug

与 issues / wiki 的边界¶

层	时间维度	关注
specs	要做什么（未来 / 进行中）	数据模型 + API + 任务拆分
issues	修过什么（过去）	根因 + 修法 + 教训
wiki	是什么（当前事实）	架构 + 字段语义 + 组件用法

一个新功能的全生命周期：

raw/feedback/  →  specs/active/  →  实现  →  specs/done/
                                            ↘ wiki/  更新架构
                                            ↘ issues/ 实施中的 bug

全部 specs（按 status）¶

approved¶

ID	标题	目标版本	链接
SPEC-004-Phase3-API	SPEC-004 Phase 3 — 云端 API 契约（客户端先就绪 / 服务端待实现）	v0.10.95 (client) / TBD (server)	打开

done¶

ID	标题	目标版本	链接
—	SPEC-004 — 网站采集多阶段优化 + 云端协同 + 贡献度	v0.10.87+	打开
SPEC-000	SPEC-000 — v2 UI 改版说明（v0.8.58 → v0.9.x → v0.10.x）	v0.10.0	打开
SPEC-001	知识库改造 — 借鉴卡帕西的四层漏斗	v0.10.22	打开
SPEC-002	Watchdog 核弹重启后自动恢复（带上限保护）	v0.10.23	打开
SPEC-003	文档治理自动化（docs:check + docs:rebuild + _overview）	v0.10.25	打开
SPEC-006	SPEC-006 — task delete 时二选一 confirm 商家数据去留	v0.10.102	打开

parked¶

ID	标题	目标版本	链接
SPEC-005	SPEC-005 — React 前端 lifecycle 系统性扫描 + 修复	TBD	打开