ch3sh-lc/myworkflow/project-init

阶段0 判定文件夹类型 ─[常规]→ 阶段1 只建 CLAUDE.md → 报告
                     ─[项目]→ 阶段2 收集信息+确认 GOAL → 阶段3 生成文件 → 阶段4 两个 index.json → 阶段5 验证与报告

# [项目名称] 工作区指令
## 每次工作的强制步骤
**每次新会话开始时，先调用「myworkflow-project-maintain」skill。** 它引导你：
1.读本文件（规则）→ 2. 读 `docs/STATE.md`（现在在哪）→ 3. 读 `docs/PROGRESS.md` 条目区（最近做了什么）
4.读 `docs/GOAL.md` 与 `docs/design/index.json`（要做什么、做到哪）→ 5. 工作完成后回到该 skill 的完成时流程，强制同步文档
> 不要跳过。文档体系的价值取决于每一次工作都留下记录。
## 当前项目
正在开发 **[项目名称]**（一句话定位）。为什么做见 `docs/GOAL.md`。
## 工作规则
1.**先设计后开发**：改动只做 `docs/design/` 中已写明的点；新增功能 / 行为变更 / 新模块必须先生成 design，没有 design 不动手。bug 修复 / 重构 / 配置 / 文档 / 格式化允许豁免，但须在 PROGRESS 条目标注「本次无 design（小场景豁免）」；判断不清时默认按"需要 design"处理。
2.**验收口径**：只有用户明确说"确认没问题 / 可以了 / 通过了 / 我验收通过"才能把点置「完成」；**用户没说话 = 还没验收**，只能停在「待验收」。
3.**文档同步**：每次变更后同步 `docs/PROGRESS.md`、`docs/STATE.md`、`docs/design/index.json`，必要时 `STRUCTURE.md`。
4.**不许搬运**：`docs/` 只放本项目开发过程产生的文档；项目里既有的资料、素材、参考文档原地不动。
## 工作区目录结构
[实际目录树，逐行注释用途；细节见 STRUCTURE.md]
## 目录结构更新规则
仅当根目录（顶层）新增 / 删除 / 重命名目录或文件、新增子项目、核心规则变化时更新本文件目录树；子目录内文件增删由 STRUCTURE.md 管理。

# [项目名称] 项目结构
> 最后更新：YYYY-MM-DD　新增、删除、重命名文件或目录时必须同步更新本文件。
---
## 顶层结构
[项目根]/
├── CLAUDE.md              # 工作区入口指令（怎么工作）
├── STRUCTURE.md           # 本文件（东西在哪）
├── src/                   # 源代码
└── docs/                  # 开发文档区：GOAL.md 为什么做（仅用户批准可改）｜STATE.md 现在在哪（刷新式）｜
                           #   PROGRESS.md 做了什么（条目区 + 版本记录区）｜design/ 做什么（含 index.json）｜
                           #   information/ 学到了什么（含 index.json）｜research/ 外部世界怎么说｜other/ 兜底
## [每个主要子目录的结构]
src/  →  index.ts 入口 ／ components/ UI 组件 ／ utils/ 工具函数
## 当前核心事实
-运行时：Node.js 22；包管理器：pnpm；测试框架：Vitest；默认端口：3000

# [项目名称] 目标
> 更新：YYYY-MM-DD。**本文件仅用户批准可改**——agent 只能提议，不得自行写入或改写。
## 最终验收
-[可量化判据 1：数字 / 阈值 / 分母]
-[可量化判据 2]
-什么不算达标：[明确写出"看起来好但不合格"的情形]
## 为什么做（开发本意）
[2–4 句：解决谁的什么问题，做完之后有什么不同]
## 边界与约束
-不做什么：
-已知硬约束（数据 / 环境 / 时间）：
-验收与成本冲突时的优先级：

# [项目名称] 开发进度
> **版本：0.0.0**（初始值，按 3.4 定稿：空体系 `0.0.0` / 已有可运行产物 `0.1.0` / 有代码清单 `version` 以清单为准；无清单时本行为权威源，有清单时本行只引用清单；下方 v0.1.0 为首个功能版本示例）
> 双层结构：**条目区**（做了什么，最新在最上，每条一行，带版本号）+ **版本记录区**（每版本一段：问题/根因/修改/验证）
> 版本号是两层的 join key。归档：条目区触顶后最老内容移入 `docs/other/progress-archive-YYYY.md`。
---
## 条目
## YYYY-MM-DD
-[New Feature][v0.1.0] 一句话做了什么（严格一行，不写"为什么"）
-[Debug][v0.1.0] ……
---
## 版本记录
### v0.1.0 — YYYY-MM-DD
**问题 / 动机**：（背景与意图）
**根因**：（仅 bug 修复需要：为什么发生、为什么之前没发现、为什么这样修）
**修改**：`路径/文件` — 改了什么；对应 design 点号 `design-01-P1`
**验证**：命令 + exitCode/退出码（或产物路径 / sha256），不写"已测试"

# [项目名称] 当前状态
> 最后刷新：YYYY-MM-DD。**刷新式**——只回答"现在在哪"，历史一律进 PROGRESS.md。
> 自检：本文件出现 3 条以上上周的内容 → 你把 PROGRESS 的历史抄进来了，删掉。
## 位置
-当前版本：v0.1.0（与 `docs/PROGRESS.md` 头部一致；若代码清单有 version，以它为准并在此列出差异）
-正在做：design-01 的 P2（开发中不进 index）／无
-卡住的：（阻塞点号 + 具体原因；没有就写"无"）
## 下一步（≤5 条，按优先级）
1.…
## 等用户验收
-design-01-P1「…」— 已完成并验证，等用户确认
## 当前生效的约束与环境
-运行时 / 包管理器 / 测试命令 / 默认端口 / 不能碰的东西

# design-01：<主题>
> 状态：进行中 / 已完成 / 已废弃　创建：YYYY-MM-DD　最后更新：YYYY-MM-DD
> 上游：`docs/GOAL.md`　本文件只管"做什么"，不管"怎么写"。
## 背景
[为什么做这一块：对应 GOAL 的哪条判据、当前缺口是什么]
## 需求
-需求 1：…
## 验收标准
-[可验证判据：什么算做成、怎么验、什么条件下算不达标]
## 点清单
| 点号 | 内容 | 状态 | 证据 | 备注 |
|------|------|------|------|------|
| design-01-P1 | … | 未开发 | | |
| design-01-P2 | … | 未开发 | | |
> 状态为四态封闭枚举：`未开发` / `阻塞` / `待验收` / `完成`。**"开发中"不写进本表**，它由 `docs/STATE.md` 承载。
> 权威索引是 `docs/design/index.json`；本表的点号与状态必须与 index 完全一致，冲突时按 index 修正本表。
## 不做的事
-[明确排除项，防止范围漂移]

# information-01：<主题>
> 创建：YYYY-MM-DD　最后更新：YYYY-MM-DD　索引：`docs/information/index.json`
## 条目
### info-001 — YYYY-MM-DD　一句话结论
-场景：（在什么情况下遇到的）
-结论 / 做法：（以后遇到就该这么做）
-反例 / 坑：（曾经怎么错的、代价是什么）
-来源：（用户原话 / 实测输出 / 文件路径）

{
  "schema_version": 1, "project": "CoCo", "updated": "2026-09-15",
  "status_enum": ["未开发", "阻塞", "待验收", "完成"],
  "designs": [
    { "id": "design-01", "file": "design-01-用户登录.md", "title": "用户登录", "created": "2026-09-15", "updated": "2026-09-15", "goal_check": "GOAL 回望：本 design 与 GOAL 的「登录流程可用」一致" }
  ],
  "points": [
    { "id": "design-01-P1", "design": "design-01", "file": "design-01-用户登录.md", "title": "支持手机号 + 验证码登录", "status": "待验收", "evidence": "pnpm vitest run tests/login.test.ts → exit 0（8 passed）；手工走通验证码登录进入首页", "updated": "2026-09-15", "note": "" },
    { "id": "design-01-P2", "design": "design-01", "file": "design-01-用户登录.md", "title": "记住登录状态 7 天", "status": "未开发", "evidence": "", "updated": "2026-09-15", "note": "" }
  ]
}

{
  "schema_version": 1, "project": "CoCo", "updated": "2026-09-15",
  "entries": [
    { "id": "info-001", "file": "information-01-构建与测试.md", "title": "构建前必须先跑代码生成，否则 TS 类型缺失", "tags": ["构建", "测试"], "summary": "直接 pnpm build 会因缺失生成代码报类型错误；正确顺序是先 pnpm gen 再 pnpm build。", "created": "2026-09-15", "updated": "2026-09-15" }
  ]
}

□ 1. CLAUDE.md / STRUCTURE.md / docs/{GOAL,STATE,PROGRESS}.md 均存在且非空
□ 2. docs/ 下 design、information、research、other 四个目录已建
□ 3. 两个 index.json 可被 json.load 解析，字段齐全，status_enum 与示例枚举一致
□ 4. PROGRESS.md 头部有版本号一行；STATE.md 有"最后刷新"日期；STRUCTURE.md 与实际文件系统一致（抽查关键目录）
□ 5. 白名单自查：本轮所有写入都在 CLAUDE.md / STRUCTURE.md / docs/** 之内
□ 6. 无搬迁自查：本轮没有移动、重命名或删除任何既有文件

📋 文档体系初始化完成：✓ CLAUDE.md（已写入对「myworkflow-project-maintain」的强制引用）✓ STRUCTURE.md（[N] 个目录）✓ docs/GOAL.md（用户已确认）✓ docs/PROGRESS.md（双层）✓ docs/STATE.md（刷新式）✓ 两个 index.json（可解析）