cs-roadmap
cs-roadmap
启动必读
开始任何判断或动作前,先读取 .codestable/attention.md;缺失则视为骨架不完整,提示先补齐或运行 cs-onboard,不要回退到外部 AI 入口文件。
.codestable/roadmap/ 是项目的"规划层"——每个子目录承载一块大需求,主文档由三块构成:
- 概设:这块大需求要怎么搭、拆成哪几个模块 / 组件、各自职责
- 架构层详设:模块之间的接口契约、共享数据结构、跨 feature 的协议
- 子 feature 拆解:把方案分解成一串带依赖关系的子 feature 种子,feature 流程一次消费一条
三块一起作为这块大需求所有子 feature 的共同约束——每条子 feature 进 cs-feat-design 时,roadmap 第 2 块的接口契约就是它的硬约束输入(不能违反,要改先回 roadmap update)。
为什么 roadmap 承载架构方案不放进 architecture/:cs-arch 守"只记现状不记计划"。前瞻性架构方案属于"还没落地、可能还会变"的事前规划,放进 architecture 会污染那份系统地图。等子 feature 真正落地,对应接口由 cs-feat-accept 提炼回 architecture/——roadmap 完成过渡使命后归档。
为什么单独一层:requirements 记"要什么"(愿景)、architecture 记"怎么搭"(结构)、roadmap 记"怎么分步实现"(执行)。把执行规划塞进愿景或结构文档会把"要什么"和"打算怎么实现"混起来——查不到系统真实能力,计划改一下又得改两份文档。
为什么文件夹不是单文件:拆解过程会产生草稿 / 调研 / 方案对比 / 白板转述,塞一份 md 会乱又舍不得删。每个 roadmap 一个子目录,主文档对外口径,旁边 drafts/ 随便堆。
More from liuzhengdongfortest/codestable
cs-feat-design
feature 流程阶段 1——为新功能起草 {slug}-design.md 作为后续实现和验收的唯一输入,拍板后抽出 checklist。触发:用户说"开始设计方案"、"写 design doc"、"准备实现 XX",前提是已知道做什么、为谁、怎么算成功。
652cs-brainstorm
想法还模糊时的讨论入口,做分诊后路由到 feature-design / feature-brainstorm / roadmap。AI 是思考伙伴不是记录员。触发:用户说"有个想法还没想清楚"、"先 brainstorm 一下"、"聊一聊这块"、"方向还在摇摆"。不处理 bug 和重构。
651cs-feat-accept
feature 流程阶段 3——验收闭环:对照 design 核实现 + 回写 architecture / requirement / roadmap,最后产出 {slug}-acceptance.md。触发:用户说"功能写完了验收一下"、"做最后检查"、"准备 merge"、"出验收报告"。前置依赖 cs-feat-impl 完成。
651cs-feat-impl
feature 流程阶段 2——按 {slug}-checklist.yaml 里 design 切好的 paradigm 维度 steps 推进,每步具体改哪个文件由 implement 自决,写完用统一格式汇报。触发:用户说"方案确认了开始实现"、"按方案写代码"、"开工"。前提是 design 已 approved 且有 checklist。遇到方案外情况要回方案谈不要硬冲。
650cs-onboard
把新仓库或有零散文档的仓库接入 CodeStable 体系,两条路径自动判断:空仓库从零搭骨架,已有文档走审计 + 迁移映射。触发:用户说"在这个项目里用 CodeStable"、"搭 CodeStable 结构"、"初始化 CodeStable"、"迁移到 CodeStable"。
649cs-feat
新功能开发的子流程入口,把"加个 X 能力"从想法走到验收闭环。触发:用户说"做新功能"、"加个 X"、"实现 XX"。只做路由,根据已有产物决定走 brainstorm / design / fastforward / implement / acceptance。不处理 bug。
648