Back to Details

roadmap

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Roadmap

路线图

Generate a comprehensive technical roadmap for building an entire application. Detailed enough that Claude Code can pick up any phase and execute it autonomously for hours.
This is not a high-level strategy doc. It's a delivery blueprint — every phase has concrete tasks, every task is actionable, and the whole thing is ordered so you can build from phase 1 through to launch without backtracking.
生成用于构建完整应用的全面技术路线图，详细程度需达到Claude Code可以接手任意阶段并自主执行数小时的标准。
这不是一份高层战略文档，而是一份交付蓝图——每个阶段都包含具体任务，每项任务都可执行，整体按顺序排列，让你可以从第一阶段逐步构建直至上线，无需返工。

When to Use

适用场景

  • Starting a major new product (after deep-research, or from a product brief)
  • Converting a vague idea into an executable plan
  • Planning a multi-week build that will span many Claude Code sessions
  • Before saying "build this" — the roadmap is what you hand Claude Code to execute
  • 启动重大新产品（完成深度研究后，或基于产品 brief）
  • 将模糊想法转化为可执行计划
  • 规划需要跨多个Claude Code会话的数周构建工作
  • 在说“构建这个”之前——路线图就是你交给Claude Code去执行的内容

Inputs

输入信息

The skill needs one of these:
InputWhere to find it
Deep research brief
.jez/artifacts/research-brief-{topic}.md
(from 
/deep-research
)
Product briefUser describes what they want to build
Existing partial appRead CLAUDE.md + codebase to understand what exists
Competitor to clone/improveURL or product name — skill analyses it
If the user just says "plan a note-taking app on Cloudflare", that's enough — ask clarifying questions as needed.
该技能需要以下其中一种输入：
输入内容获取位置
深度研究简报
.jez/artifacts/research-brief-{topic}.md
（来自
/deep-research
）
产品简报用户描述想要构建的内容
现有部分应用读取CLAUDE.md + 代码库以了解现有内容
要克隆/改进的竞品URL或产品名称——技能会对其进行分析
如果用户只说“在Cloudflare上规划一个笔记应用”，这也足够——必要时可提出澄清问题。

Workflow

工作流程

1. Establish the Vision

1. 确立愿景

Before any technical planning, nail down:
  • One sentence: What is this? ("A cloud-native markdown knowledge workspace for teams and AI agents")
  • Who: Primary users, secondary users, agents? ("Jez first, then Jezweb team, then clients")
  • Why: What existing tools fail at? What's the gap? ("Existing tools are headless — you can't browse them or stumble across things")
  • Constraint: Stack, budget, timeline, must-haves? ("Cloudflare, must have MCP, needs to be a PWA")
  • Not building: What's explicitly out of scope? ("No real-time CRDT collab, no plugin ecosystem")
在进行任何技术规划之前，先明确：
  • 一句话定位：这是什么？（例如：“面向团队和AI Agent的云原生Markdown知识协作空间”）
  • 目标用户：主要用户、次要用户、Agent？（例如：“首先是Jez，然后是Jezweb团队，最后是客户”）
  • 核心价值：现有工具存在哪些不足？填补了什么空白？（例如：“现有工具无可视化界面——无法浏览内容或偶然发现有用信息”）
  • 约束条件：技术栈、预算、时间线、必备功能？（例如：“基于Cloudflare，必须具备MCP，需为PWA应用”）
  • 明确不做的内容：哪些明确不属于范围？（例如：“不做实时CRDT协作，不做插件生态”）

2. Define the Stack

2. 确定技术栈

Based on the vision and constraints, lock in the technical stack:
markdown
| Layer | Choice | Why |
|-------|--------|-----|
| Frontend | [framework] | [reason] |
| Backend | [framework + runtime] | [reason] |
| Database | [engine + ORM] | [reason] |
| Auth | [provider] | [reason] |
| Storage | [service] | [reason] |
| Search | [method] | [reason] |
| Hosting | [platform] | [reason] |
If a deep-research brief exists, pull the recommendations from there. If not, make opinionated choices based on the user's existing stack (check 
~/Documents/
for patterns).
基于愿景和约束条件，确定技术栈：
markdown
| 层级 | 选择 | 原因 |
|-------|--------|-----|
| 前端 | [框架] | [理由] |
| 后端 | [框架 + 运行时] | [理由] |
| 数据库 | [引擎 + ORM] | [理由] |
| 认证 | [提供商] | [理由] |
| 存储 | [服务] | [理由] |
| 搜索 | [方式] | [理由] |
| 托管 | [平台] | [理由] |
如果存在深度研究简报，从中提取推荐方案；如果没有，则根据用户现有技术栈（检查
~/Documents/
中的模式）做出针对性选择。

3. Design the Data Model

3. 设计数据模型

Sketch all tables/collections the full product will need. Not just phase 1 — the complete model. This prevents schema redesigns mid-build.
markdown
undefined
勾勒产品所需的所有表/集合，不只是第一阶段——要设计完整模型，避免构建中途重新设计 schema。
markdown
undefined

Data Model

数据模型

[entity]

[实体]

id, [type] [field], [type], [constraints] ... created_at, updated_at
id, [类型] [字段], [类型], [约束] ... created_at, updated_at

[entity]

[实体]

...
...

Relationships

关系

  • [entity] has many [entity] via [field]
  • [entity] belongs to [entity] via [field]

Mark which tables are needed in which phase. Phase 1 might only need 3 of 8 tables, but designing them all upfront avoids migration pain.
  • [实体] 通过 [字段] 关联多个 [实体]
  • [实体] 通过 [字段] 属于 [实体]

标记哪些表在哪个阶段需要。第一阶段可能只需要8个表中的3个，但提前设计全部表可避免迁移麻烦。

4. Plan the Phases

4. 规划阶段

This is the core of the roadmap. Each phase must:
  • Have a clear goal — one sentence describing what's different when this phase is done
  • Be independently deployable — the app works (with reduced features) after each phase
  • Build on the previous phase — no phase requires ripping out what came before
  • Be completable in 1-3 Claude Code sessions — if a phase takes more than a day, split it
这是路线图的核心。每个阶段必须：
  • 目标清晰——用一句话描述完成该阶段后用户能做什么之前做不到的事
  • 可独立部署——每个阶段完成后应用都能正常运行（功能简化版）
  • 基于前序阶段——无需推翻之前的成果
  • 可在1-3个Claude Code会话内完成——如果一个阶段耗时超过一天，就拆分它

Phase Structure

阶段结构

For each phase:
markdown
undefined
每个阶段的格式：
markdown
undefined

Phase N — [Name]

第N阶段 — [名称]

Goal: [One sentence — what the user can do after this phase that they couldn't before] Depends on: Phase N-1 Estimated effort: [hours/sessions]
目标：[一句话描述——完成该阶段后用户新增的能力] 依赖：第N-1阶段 预计工作量：[小时/会话数]

What's New

新增内容

[Bullet list of user-visible features]
[用户可见功能的项目符号列表]

Database Changes

数据库变更

[New tables, new columns, migrations needed]
[新增表、新增列、所需迁移操作]

API Routes

API路由

[New endpoints this phase adds]
[本阶段新增的端点]

Frontend

前端

[New pages, components, UI changes]
[新增页面、组件、UI变更]

Infrastructure

基础设施

[New Cloudflare resources, secrets, config]
[新增Cloudflare资源、密钥、配置]

Task Checklist

任务清单

[Actionable tasks grouped by area — these are what Claude Code executes]
[按领域分组的可执行任务——Claude Code将执行这些任务]

Setup

环境搭建

  • [task]
  • [任务]

Data Layer

数据层

  • [task]
  • [task]
  • [任务]
  • [任务]

API

API

  • [task]
  • [任务]

Frontend

前端

  • [task]
  • [任务]

Testing & Polish

测试与优化

  • [task]
  • [task]
  • [任务]
  • [任务]

Definition of Done

完成标准

[How to verify this phase is complete — what to test, what to deploy]
undefined
[如何验证该阶段已完成——需要测试的内容、部署要求]
undefined

5. Phase Planning Patterns

5. 阶段规划模式

Phase 1 — Always the MVP

第一阶段——始终是最小可行产品（MVP）

The first phase must produce something usable by one person for one purpose. Not a demo, not a skeleton — a working tool that replaces whatever the user currently does (even if it's a spreadsheet or Apple Notes).
Phase 1 scope test: "Would you use this instead of what you use now?" If no, the MVP is too thin.
Typical Phase 1:
  • Auth (single user or invite-only)
  • Core data model (2-3 tables)
  • CRUD for the primary entity
  • Basic UI (list + detail + create/edit)
  • Deploy to production domain
  • Bare minimum styling (dark mode, responsive)
第一阶段必须产出可供一个人完成特定用途的可用工具，不是演示版，不是骨架——而是能替代用户当前所用工具的可用工具（即使是电子表格或Apple Notes）。
第一阶段范围测试：“你会用这个替代当前工具吗？”如果答案是否，说明MVP的功能太薄弱。
典型第一阶段内容：
  • 认证（单用户或邀请制）
  • 核心数据模型（2-3个表）
  • 核心实体的CRUD操作
  • 基础UI（列表 + 详情 + 创建/编辑）
  • 部署到生产域名
  • 基础样式（深色模式、响应式）

Phase 2 — Make It Real

第二阶段——让产品成型

The second phase turns the MVP into something you'd show to others:
  • Polish the UI
  • Add secondary features (search, filters, sort)
  • Better error handling and validation
  • Empty states and onboarding (use the 
    onboarding-ux
    skill)
  • Mobile responsiveness
  • Data export/import
第二阶段将MVP转变为可以展示给他人的产品：
  • 优化UI
  • 添加次要功能（搜索、筛选、排序）
  • 更好的错误处理和验证
  • 空状态和引导流程（使用
    onboarding-ux
    技能）
  • 移动端响应式适配
  • 数据导入/导出

Phase 3 — The Differentiator

第三阶段——打造差异化优势

What makes this product different from alternatives? Build that here:
  • AI features, MCP server, semantic search
  • The thing competitors don't have
  • The reason someone would choose this over the established player
产品与竞品的不同之处是什么？在此阶段构建：
  • AI功能、MCP服务器、语义搜索
  • 竞品没有的功能
  • 用户选择这款产品而非成熟竞品的理由

Phase 4+ — Growth Features

第四及以后阶段——增长功能

Each subsequent phase adds capabilities:
  • Multi-user / team features
  • Advanced views (graph, canvas, calendar, kanban)
  • Integrations (API, webhooks, third-party connections)
  • Admin / settings
  • Performance optimisation
  • Public-facing features (sharing, embedding, white-label)
后续每个阶段新增能力：
  • 多用户/团队功能
  • 高级视图（图谱、画布、日历、看板）
  • 集成（API、Webhook、第三方连接）
  • 管理/设置功能
  • 性能优化
  • 面向公众的功能（分享、嵌入、白标）

Final Phase — Platform

最终阶段——平台化

Only if the product is heading toward multi-tenant / SaaS:
  • Client workspaces
  • Billing / plans
  • White-label / custom domains
  • API tokens for third-party access
仅当产品向多租户/SaaS方向发展时需要：
  • 客户工作区
  • 计费/套餐
  • 白标/自定义域名
  • 供第三方访问的API令牌

6. Build Order

6. 构建顺序汇总

Summarise the phases in a table:
markdown
| Phase | Goal | New tables | New routes | Sessions |
|-------|------|-----------|-----------|----------|
| 1 | Personal MVP | 3 | 8 | 2-3 |
| 2 | Polish + search | +1 | +4 | 1-2 |
| 3 | AI + MCP | +1 (vectors) | +5 | 2-3 |
| 4 | Team features | +2 | +6 | 2-3 |
| 5 | Integrations | 0 | +4 | 1-2 |
| 6 | Platform | +2 | +8 | 3-4 |
用表格汇总各阶段：
markdown
| 阶段 | 目标 | 新增表 | 新增路由 | 会话数 |
|-------|------|-----------|-----------|----------|
| 1 | 个人MVP | 3 | 8 | 2-3 |
| 2 | 优化 + 搜索 | +1 | +4 | 1-2 |
| 3 | AI + MCP | +1（向量表） | +5 | 2-3 |
| 4 | 团队功能 | +2 | +6 | 2-3 |
| 5 | 集成功能 | 0 | +4 | 1-2 |
| 6 | 平台化 | +2 | +8 | 3-4 |

7. Deliberately Not Building

7. 明确不做的内容

List what's explicitly out of scope and why. This prevents scope creep during execution:
markdown
undefined
列出明确不属于范围的内容及原因，防止执行过程中范围蔓延：
markdown
undefined

Deliberately Not Building (v1)

V1版本明确不做的内容

  • Real-time collaborative editing (CRDTs) — too complex, Phase 5+ at earliest
  • Plugin ecosystem — too much surface area
  • Native mobile app — PWA is good enough
  • Offline-first with local storage — we're cloud-native
undefined
  • 实时协作编辑（CRDT）——复杂度太高，最早在第5阶段考虑
  • 插件生态——涉及面太广
  • 原生移动应用——PWA已足够
  • 本地存储优先的离线功能——我们是云原生应用
undefined

8. Schema Evolution Map

8. Schema演进图

Show how the database grows across phases:
markdown
| Table | Phase 1 | Phase 2 | Phase 3 | Phase 4 |
|-------|---------|---------|---------|---------|
| users | ✓ | | | |
| notes | ✓ | +tags col | +embeddings | |
| folders | ✓ | | | |
| note_links | | ✓ | | |
| workspaces | | | | ✓ |
| workspace_users | | | | ✓ |
展示数据库在各阶段的扩展情况：
markdown
| 表 | 阶段1 | 阶段2 | 阶段3 | 阶段4 |
|-------|---------|---------|---------|---------|
| users | ✓ | | | |
| notes | ✓ | +tags字段 | +embeddings字段 | |
| folders | ✓ | | | |
| note_links | | ✓ | | |
| workspaces | | | | ✓ |
| workspace_users | | | | ✓ |

9. API Surface Map

9. API接口演进图

Show how the API grows:
markdown
| Route | Phase | Auth | Purpose |
|-------|-------|------|---------|
| POST /api/auth/* | 1 | — | Authentication |
| GET/POST /api/notes | 1 | Yes | Note CRUD |
| GET /api/search | 2 | Yes | Full-text search |
| GET /api/search/semantic | 3 | Yes | Vector search |
| GET/POST /mcp/tools | 3 | Token | MCP interface |
| POST /api/workspaces | 4 | Yes | Team workspaces |
展示API在各阶段的扩展情况：
markdown
| 路由 | 阶段 | 认证要求 | 用途 |
|-------|-------|------|---------|
| POST /api/auth/* | 1 | — | 认证 |
| GET/POST /api/notes | 1 | 是 | 笔记CRUD |
| GET /api/search | 2 | 是 | 全文搜索 |
| GET /api/search/semantic | 3 | 是 | 向量搜索 |
| GET/POST /mcp/tools | 3 | Token | MCP接口 |
| POST /api/workspaces | 4 | 是 | 团队工作区 |

Output

输出结果

Write the roadmap to 
docs/ROADMAP.md
(or the project root if no 
docs/
exists).
The file should be a single markdown document that Claude Code can read at the start of any session and know exactly what to build next. It's the project's north star.
After generating, also update:
  • CLAUDE.md
    — add a reference to the roadmap
  • SESSION.md
    — set current phase
将路线图写入
docs/ROADMAP.md
（如果没有
docs/
目录则写入项目根目录）。
该文件应为单个Markdown文档，Claude Code在任何会话开始时读取它，就能准确知道下一步要构建什么。它是项目的北极星。
生成路线图后，还需更新：
  • CLAUDE.md
    ——添加路线图的引用
  • SESSION.md
    ——设置当前阶段

Quality Rules

质量规则

  1. Every task must be actionable — "Set up auth" is too vague. "Configure better-auth with email/password, create user and session tables, add auth middleware to Hono" is actionable.
  2. Phases must be deployable — after each phase the app works. No "infrastructure phase" that produces nothing usable.
  3. Phase 1 must be ruthlessly small — if it takes more than 2-3 sessions, cut scope.
  4. The data model must be complete upfront — schema redesigns mid-build are the #1 time waster.
  5. "Deliberately not building" is mandatory — without it, every phase grows.
  6. Tasks are grouped by layer (data, API, frontend, infra) — Claude Code works in layers, not features.
  7. Each phase has a definition of done — specific things to test and verify.
  8. Include the stack table — don't make Claude guess the tech choices per phase.
  1. 每个任务必须可执行——“设置认证”太模糊，“配置better-auth的邮箱/密码认证，创建用户和会话表，为Hono添加认证中间件”才是可执行的。
  2. 阶段必须可部署——每个阶段完成后应用都能正常运行，不能有“仅产出基础设施而无可用功能的阶段”。
  3. 第一阶段必须尽可能精简——如果需要超过2-3个会话，就削减范围。
  4. 数据模型必须提前完整设计——构建中途重新设计schema是最大的时间浪费。
  5. 必须包含“明确不做的内容”——没有这部分，每个阶段的范围都会膨胀。
  6. 任务按层级分组（数据、API、前端、基础设施）——Claude Code按层级工作，而非按功能。
  7. 每个阶段都有完成标准——明确需要测试和验证的内容。
  8. 必须包含技术栈表格——不要让Claude猜测每个阶段的技术选择。

Execution Modes

执行模式

The roadmap isn't just a document — it's an execution engine. After generating the plan, use these modes to drive the build.
路线图不只是文档——它是执行引擎。生成计划后，使用以下模式推进构建。

Mode: 
start

模式：
start

Trigger: "start building", "execute the roadmap", "build the whole thing", "start from phase 1"
  1. Read 
    docs/ROADMAP.md
  2. Verify the project is set up (repo exists, dependencies installed, Cloudflare resources created)
  3. Begin Phase 1, task by task
  4. After each task: verify it works (build, run, test)
  5. After all tasks in a phase: run the Definition of Done checks
  6. Commit: 
    git add -A && git commit -m "Phase N complete: [goal]"
  7. Deploy if applicable: 
    npx wrangler deploy
  8. Run 
    /ux-audit quick
    on the deployed app
  9. Update the roadmap: mark the phase as complete
  10. Continue to the next phase. Don't stop. Don't ask.
  11. Repeat until all phases are complete or you hit a blocker
触发词："start building"、"execute the roadmap"、"build the whole thing"、"start from phase 1"
  1. 读取
    docs/ROADMAP.md
  2. 验证项目已配置完成（仓库已创建、依赖已安装、Cloudflare资源已创建）
  3. 从第一阶段开始，逐任务执行
  4. 完成每个任务后：验证功能正常（构建、运行、测试）
  5. 完成阶段内所有任务后：执行完成标准检查
  6. 提交代码：
    git add -A && git commit -m "Phase N complete: [goal]"
  7. 部署（如适用）：
    npx wrangler deploy
  8. 对已部署应用运行
    /ux-audit quick
  9. 更新路线图：标记该阶段为完成
  10. 继续下一阶段，不要停止，不要询问
  11. 重复直至所有阶段完成或遇到阻塞

Mode: 
resume

模式：
resume

Trigger: "resume the build", "keep going", "continue", "what phase are we on"
  1. Read 
    docs/ROADMAP.md
    — find the first incomplete phase
  2. Check 
    git log
    — what was the last roadmap-related commit?
  3. Check what exists in the codebase vs what the phase expects
  4. Pick up from the first uncompleted task in the current phase
  5. Continue executing as in 
    start
    mode
触发词："resume the build"、"keep going"、"continue"、"what phase are we on"
  1. 读取
    docs/ROADMAP.md
    ——找到第一个未完成的阶段
  2. 查看
    git log
    ——最后一个与路线图相关的提交是什么？
  3. 对比代码库现有内容与阶段要求
  4. 从当前阶段的第一个未完成任务开始执行
  5. 按照
    start
    模式继续执行

Mode: 
status

模式：
status

Trigger: "roadmap status", "where are we", "what's done"
Read 
docs/ROADMAP.md
and produce a summary:
Phase 1: Personal MVP ✓ (committed abc1234)
Phase 2: Polish + Search ✓ (committed def5678)
Phase 3: AI + MCP ← IN PROGRESS (7/15 tasks done)
Phase 4: Team Features — not started
Phase 5: Integrations — not started
触发词："roadmap status"、"where are we"、"what's done"
读取
docs/ROADMAP.md
并生成摘要：
阶段1：个人MVP ✓（提交哈希abc1234）
阶段2：优化 + 搜索 ✓（提交哈希def5678）
阶段3：AI + MCP ← 进行中（15项任务已完成7项）
阶段4：团队功能 — 未开始
阶段5：集成功能 — 未开始

Execution Rules

执行规则

Keep going. The default is to continue to the next phase after completing one. Don't pause between phases to ask permission. The roadmap IS the permission.
Commit at phase boundaries. Every completed phase gets its own commit with a clear message. This creates natural restore points.
Deploy after every phase. If the project has a deployment target (wrangler.jsonc, vercel.json), deploy after each phase completes. Real deployment catches issues that local dev doesn't.
Quick audit between phases. Run a quick visual check on the deployed app between phases — catch layout issues, broken routes, obvious regressions before building on top of them.
Thorough audit at the end. After the final phase, run:
  1. /ux-audit thorough
    — comprehensive overnight test
  2. /onboarding-ux
    — generate empty states, welcome flow, help content
  3. /project-docs
    — update architecture documentation
Stop only when:
  • A task fails and you can't figure out why (error you haven't seen before)
  • You need a credential, API key, or account access you don't have
  • A design decision needs human input ("should this be a modal or a page?")
  • The build is complete
Don't stop for:
  • "Should I continue?" — yes, always
  • "Should I deploy?" — yes, if there's a deployment target
  • "Should I commit?" — yes, at phase boundaries
  • Minor issues that don't block the next task — log them as GitHub issues and keep going
持续推进：完成一个阶段后默认继续下一阶段，不要在阶段之间暂停询问许可。路线图就是许可。
在阶段边界提交代码：每个完成的阶段都要有单独的提交，提交信息清晰，这会形成天然的恢复点。
每个阶段完成后部署：如果项目有部署目标（wrangler.jsonc、vercel.json），每个阶段完成后都要部署，实际部署能发现本地开发中无法察觉的问题。
阶段间快速审计：在阶段之间对已部署应用进行快速视觉检查——在继续构建之前，发现布局问题、路由错误、明显的回归问题。
最终阶段全面审计：完成最后一个阶段后，执行：
  1. /ux-audit thorough
    ——全面的隔夜测试
  2. /onboarding-ux
    ——生成空状态、引导流程、帮助内容
  3. /project-docs
    ——更新架构文档
仅在以下情况停止：
  • 任务失败且无法找到原因（遇到从未见过的错误）
  • 需要没有的凭证、API密钥或账户权限
  • 需要人工输入的设计决策（“这应该是模态框还是新页面？”）
  • 构建已完成
以下情况不要停止：
  • “我应该继续吗？”——是的，始终继续
  • “我应该部署吗？”——是的，如果有部署目标
  • “我应该提交代码吗？”——是的，在阶段边界提交
  • 不阻塞下一个任务的小问题——将其记录为GitHub Issue并继续推进

Progress Tracking

进度跟踪

Mark completed phases directly in 
docs/ROADMAP.md
:
markdown
undefined
直接在
docs/ROADMAP.md
中标记已完成的阶段：
markdown
undefined

Phase 1 — Personal MVP ✅

阶段1 — 个人MVP ✅

Completed: 2026-03-19, commit abc1234 Goal: Replace Apple Notes for one user.

And for the current phase, mark completed tasks:

```markdown
完成时间：2026-03-19，提交哈希abc1234 目标：替代Apple Notes供单人使用。

对于当前阶段，标记已完成的任务：

```markdown

Task Checklist

任务清单

  • D1 schema — notes, folders tables
  • Hono API routes: CRUD for notes
  • CodeMirror 6 integration ← CURRENT
  • Quick switcher (Cmd+K)

This means `resume` can read the roadmap and know exactly where to pick up.
  • D1 schema — 笔记、文件夹表
  • Hono API路由：笔记CRUD
  • CodeMirror 6集成 ← 当前任务
  • 快速切换器（Cmd+K）

这意味着`resume`模式可以读取路线图并准确知道从哪里继续。

How This Replaces dev-session

如何替代dev-session

The old 
dev-session
skill managed SESSION.md files for cross-session handoff. The roadmap's progress tracking replaces that:
dev-session hadroadmap has
SESSION.md with "Current Position"Checked tasks in ROADMAP.md
"Resume Instructions"The next unchecked task IS the instruction
"What Works" sectionCompleted phases with commit hashes
Checkpoint commitsPhase boundary commits
Wrap sessionFinal phase + thorough audit
The roadmap is the session file. No separate tracking document needed.
旧的
dev-session
技能使用SESSION.md文件管理跨会话交接，路线图的进度跟踪功能替代了这一点：
dev-session的功能路线图的对应功能
SESSION.md中的“当前位置”ROADMAP.md中已勾选的任务
“恢复说明”下一个未勾选的任务就是执行说明
“可用功能”部分带有提交哈希的已完成阶段
检查点提交阶段边界提交
会话收尾最终阶段 + 全面审计
路线图就是会话文件，无需单独的跟踪文档。