kata-complete-milestone

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
<objective> Mark milestone {{version}} complete, archive to milestones/, and update ROADMAP.md and REQUIREMENTS.md.
Purpose: Create historical record of shipped version, archive milestone artifacts (roadmap + requirements), and prepare for next milestone. Output: Milestone archived (roadmap + requirements), PROJECT.md evolved, git tagged. </objective>
<execution_context> Load these files NOW (before proceeding):
  • @./references/milestone-complete.md (main workflow)
  • @./references/milestone-archive-template.md (archive template)
  • @./references/version-detector.md (version detection functions)
  • @./references/changelog-generator.md (changelog generation functions) </execution_context>
<context> **Project files:** - `.planning/ROADMAP.md` - `.planning/REQUIREMENTS.md` - `.planning/STATE.md` - `.planning/PROJECT.md`
User input:
  • Version: {{version}} (e.g., "1.0", "1.1", "2.0") </context>
<process>
Follow milestone-complete.md workflow:
  1. CRITICAL: Branch setup (if pr_workflow=true)
    Check pr_workflow config FIRST before any other work:
    bash
    PR_WORKFLOW=$(cat .planning/config.json 2>/dev/null | grep -o '"pr_workflow"[[:space:]]*:[[:space:]]*[^,}]*' | grep -o 'true\|false' || echo "false")
    CURRENT_BRANCH=$(git branch --show-current)
    If
    PR_WORKFLOW=true
    AND on
    main
    :
    You MUST create a release branch BEFORE proceeding. All milestone completion work goes on that branch.
    bash
    # Determine version from user input or detect from project files
    # (version-detector.md handles detection across project types)
    VERSION="X.Y.Z"  # Set from user input or detection
    
    # Create release branch
    git checkout -b release/v$VERSION
    
    echo "Created release branch: release/v$VERSION"
    echo "All milestone completion work will be committed here."
    Display:
    ⚠ pr_workflow is enabled — creating release branch first.
    
    Branch: release/v$VERSION
    
    All milestone completion commits will go to this branch.
    After completion, a PR will be created to merge to main.
    If
    PR_WORKFLOW=false
    OR already on a non-main branch:
    Proceed with current branch (commits go to main or current branch).
    GATE: Do NOT proceed until branch is correct:
    • If pr_workflow=true, you must be on release/vX.Y.Z branch
    • If pr_workflow=false, main branch is OK
0.1. Generate release artifacts:
Proactively generate changelog and version bump. Follow the release_workflow step in milestone-complete.md (loads version-detector.md and changelog-generator.md) to:
  1. Detect version bump type from conventional commits
  2. Calculate next version
  3. Generate changelog entry
  4. Bump version in all project version files detected by version-detector.md
  5. Insert changelog entry into CHANGELOG.md
Present all proposed changes for review:
## Release Preview

**Current version:** $CURRENT_VERSION
**Bump type:** $BUMP_TYPE
**Next version:** $NEXT_VERSION

**Changelog entry:**
## [$NEXT_VERSION] - $DATE

### Added
[feat commits formatted]

### Fixed
[fix commits formatted]

### Changed
[docs/refactor/perf commits formatted]

**Files updated:**
[list each version file detected and updated]
- CHANGELOG.md → new entry prepended
Use AskUserQuestion:
  • header: "Release Changes"
  • question: "Review the release changes above. Approve?"
  • options:
    • "Approve" — Keep changes and proceed to verify readiness
    • "Edit changelog first" — Pause for user edits, then confirm
    • "Revert and skip release" — Undo release file changes, proceed to verify readiness without release artifacts
  1. Check for audit:
    • Look for
      .planning/v{{version}}-MILESTONE-AUDIT.md
    • If missing or stale: recommend
      /kata-audit-milestone
      first
    • If audit status is
      gaps_found
      : recommend
      /kata-plan-milestone-gaps
      first
    • If audit status is
      passed
      : proceed to step 1
    markdown
    ## Pre-flight Check
    
    {If no v{{version}}-MILESTONE-AUDIT.md:}
    ⚠ No milestone audit found. Run `/kata-audit-milestone` first to verify
    requirements coverage, cross-phase integration, and E2E flows.
    
    {If audit has gaps:}
    ⚠ Milestone audit found gaps. Run `/kata-plan-milestone-gaps` to create
    phases that close the gaps, or proceed anyway to accept as tech debt.
    
    {If audit passed:}
    ✓ Milestone audit passed. Proceeding with completion.
  2. Verify readiness:
    • Check all phases in milestone have completed plans (SUMMARY.md exists)
    • Present milestone scope and stats
    • Wait for confirmation
  3. Gather stats:
    • Count phases, plans, tasks
    • Calculate git range, file changes, LOC
    • Extract timeline from git log
    • Present summary, confirm
  4. Extract accomplishments:
    • Read all phase SUMMARY.md files in milestone range
    • Extract 4-6 key accomplishments
    • Present for approval
  5. Archive milestone:
    • Create
      .planning/milestones/v{{version}}-ROADMAP.md
    • Extract full phase details from ROADMAP.md
    • Fill milestone-archive.md template
    • Update ROADMAP.md to one-line summary with link
  6. Archive requirements:
    • Create
      .planning/milestones/v{{version}}-REQUIREMENTS.md
    • Mark all v1 requirements as complete (checkboxes checked)
    • Note requirement outcomes (validated, adjusted, dropped)
    • Delete
      .planning/REQUIREMENTS.md
      (fresh one created for next milestone)
  7. Update PROJECT.md:
    • Add "Current State" section with shipped version
    • Add "Next Milestone Goals" section
    • Archive previous content in
      <details>
      (if v1.1+)
6.5. Review Documentation (Non-blocking):
Before committing, offer final README review:
Use AskUserQuestion:
  • header: "Final README Review"
  • question: "Revise README before completing milestone v{{version}}?"
  • options:
    • "Yes, draft an update for my review" — Revise README and present to the user for approval
    • "No, I'll make the edits myself" — Pause for user review, wait for "continue"
    • "Skip for now" — Proceed directly to commit
If "Yes, I'll review now":
Review README.md for the complete v{{version}} milestone.
Ensure all shipped features are documented.
Say "continue" when ready to proceed.
If "Show README": Display README.md, then use AskUserQuestion:
  • header: "README Accuracy"
  • question: "Does this look accurate for v{{version}}?"
  • options:
    • "Yes, looks good" — Proceed to Step 7
    • "Needs updates" — Pause for user edits, wait for "continue"
If "Skip" or review complete: Proceed to Step 7.
Non-blocking: milestone completion continues regardless of choice.
6.7. Close GitHub Milestone:
If github.enabled, close the GitHub Milestone for this version. See milestone-complete.md
close_github_milestone
step for details.
  1. Commit and finalize:
    • Stage: MILESTONES.md, PROJECT.md, ROADMAP.md, STATE.md, archive files
    • Commit:
      chore: complete v{{version}} milestone
    PR workflow handling (branch was created in step 0):
    bash
    PR_WORKFLOW=$(cat .planning/config.json 2>/dev/null | grep -o '"pr_workflow"[[:space:]]*:[[:space:]]*[^,}]*' | grep -o 'true\|false' || echo "false")
    CURRENT_BRANCH=$(git branch --show-current)
    If
    PR_WORKFLOW=true
    (on release/vX.Y.Z branch):
    Push branch and create PR:
    bash
    # Push branch
    git push -u origin "$CURRENT_BRANCH"
    
    # Collect all phase issues for this milestone
    GITHUB_ENABLED=$(cat .planning/config.json 2>/dev/null | grep -o '"enabled"[[:space:]]*:[[:space:]]*[^,}]*' | head -1 | grep -o 'true\|false' || echo "false")
    ISSUE_MODE=$(cat .planning/config.json 2>/dev/null | grep -o '"issueMode"[[:space:]]*:[[:space:]]*"[^"]*"' | grep -o '"[^"]*"$' | tr -d '"' || echo "never")
    
    CLOSES_LINES=""
    if [ "$GITHUB_ENABLED" = "true" ] && [ "$ISSUE_MODE" != "never" ]; then
      # Get all phase issue numbers for this milestone
      # --state all includes already-closed issues (GitHub ignores redundant Closes #X,
      # but including them ensures PR body reflects all related work)
      PHASE_ISSUES=$(gh issue list --label phase --milestone "v{{version}}" \
        --state all --json number --jq '.[].number' 2>/dev/null)
    
      if [ -z "$PHASE_ISSUES" ]; then
        echo "Note: No phase issues found for milestone v{{version}}. This is expected for milestones without GitHub issues."
      fi
    
      # Build multi-line closes section
      for num in ${PHASE_ISSUES}; do
        CLOSES_LINES="${CLOSES_LINES}Closes #${num}
    "
      done
    fi
    
    # Create PR
    gh pr create \
      --title "v{{version}}: [Milestone Name]" \
      --body "$(cat <<EOF
    ## Summary
    
    Completes milestone v{{version}}.
    
    **Key accomplishments:**
    - [accomplishment 1]
    - [accomplishment 2]
    - [accomplishment 3]
    
    ## Release Files
    
    [list version files that were updated]
    - `CHANGELOG.md` — v{{version}} entry added
    
    ## After Merge
    
    Create GitHub Release with tag `v{{version}}`.
    
    ## Closes
    
    ${CLOSES_LINES}
    EOF
    )"
    Display:
    ✓ PR created: [PR URL]
    
    After merge:
    → Create GitHub Release with tag v{{version}}
    If
    PR_WORKFLOW=false
    (on main):
    Create tag locally:
    • Tag:
      git tag -a v{{version}} -m "[milestone summary]"
    • Ask about pushing tag
  2. Post-release verification:
    After the release PR is merged (or tag is pushed), prompt for verification:
    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
     POST-RELEASE CHECKLIST
    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
    
    Before moving on, verify the release:
    
    ☐ CI/CD pipeline passed (if configured)
    ☐ Release artifacts published successfully
    ☐ Quick smoke test confirms basic functionality
    
    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
    Use AskUserQuestion:
    • header: "Verification"
    • question: "Release verification complete?"
    • options:
      • "Yes, verified" — Continue to completion
      • "Something failed" — Stop and investigate
      • "Skip" — Continue without verifying
    If "Something failed": Stop and help debug the issue. If "Yes" or "Skip": Continue to step 9.
  3. Offer next steps:
    • /kata-add-milestone
      — start next milestone (questioning → research → requirements → roadmap)
</process>
<success_criteria>
  • Milestone archived to
    .planning/milestones/v{{version}}-ROADMAP.md
  • Requirements archived to
    .planning/milestones/v{{version}}-REQUIREMENTS.md
  • .planning/REQUIREMENTS.md
    deleted (fresh for next milestone)
  • ROADMAP.md collapsed to one-line entry
  • PROJECT.md updated with current state
  • Git tag v{{version}} created (if pr_workflow=false) OR PR created/instructions given (if pr_workflow=true)
  • GitHub Milestone v{{version}} closed (if github.enabled)
  • Commit successful
  • User knows next steps (including need for fresh requirements)
If release workflow was run:
  • CHANGELOG.md updated with v{{version}} entry (reviewed and approved)
  • Version bumped in all detected project version files
  • GitHub Release created (if pr_workflow=false) OR instructions provided (if pr_workflow=true) </success_criteria>
<critical_rules>
  • Load workflow first: Read milestone-complete.md before executing
  • Verify completion: All phases must have SUMMARY.md files
  • User confirmation: Wait for approval at verification gates
  • Archive before deleting: Always create archive files before updating/deleting originals
  • One-line summary: Collapsed milestone in ROADMAP.md should be single line with link
  • Context efficiency: Archive keeps ROADMAP.md and REQUIREMENTS.md constant size per milestone
  • Fresh requirements: Next milestone starts with
    /kata-add-milestone
    which includes requirements definition </critical_rules>
<objective> 标记里程碑{{version}}为完成状态,归档至milestones/目录,并更新ROADMAP.md和REQUIREMENTS.md。
目的:创建已发布版本的历史记录,归档里程碑相关文件(路线图+需求文档),为下一个里程碑做准备。 输出:里程碑已归档(路线图+需求文档),PROJECT.md已更新,已创建git标签。 </objective>
<execution_context> 立即加载以下文件(在执行前):
  • @./references/milestone-complete.md(主工作流)
  • @./references/milestone-archive-template.md(归档模板)
  • @./references/version-detector.md(版本检测功能)
  • @./references/changelog-generator.md(变更日志生成功能) </execution_context>
<context> **项目文件:** - `.planning/ROADMAP.md` - `.planning/REQUIREMENTS.md` - `.planning/STATE.md` - `.planning/PROJECT.md`
用户输入:
  • 版本:{{version}}(例如:"1.0"、"1.1"、"2.0") </context>
<process>
遵循milestone-complete.md工作流:
  1. 关键:分支设置(若pr_workflow=true)
    在进行任何其他工作前,先检查pr_workflow配置:
    bash
    PR_WORKFLOW=$(cat .planning/config.json 2>/dev/null | grep -o '"pr_workflow"[[:space:]]*:[[:space:]]*[^,}]*' | grep -o 'true\|false' || echo "false")
    CURRENT_BRANCH=$(git branch --show-current)
    如果
    PR_WORKFLOW=true
    且当前在
    main
    分支:
    你必须先创建一个发布分支,之后才能继续。所有里程碑完成相关的工作都将在该分支上进行。
    bash
    # 从用户输入或项目文件中检测版本
    # (version-detector.md负责处理不同项目类型的版本检测)
    VERSION="X.Y.Z"  # 从用户输入或检测结果中设置
    
    # 创建发布分支
    git checkout -b release/v$VERSION
    
    echo "Created release branch: release/v$VERSION"
    echo "All milestone completion work will be committed here."
    显示:
    ⚠ pr_workflow已启用 — 正在创建发布分支。
    
    分支:release/v$VERSION
    
    所有里程碑完成相关的提交都将提交到该分支。
    完成后,将创建PR合并到main分支。
    如果
    PR_WORKFLOW=false
    或当前已在非main分支:
    继续使用当前分支(提交将进入main分支或当前分支)。
    检查点:分支正确后才能继续:
    • 若pr_workflow=true,必须处于release/vX.Y.Z分支
    • 若pr_workflow=false,main分支是允许的
0.1. 生成发布相关文件:
主动生成变更日志并更新版本号。遵循milestone-complete.md中的release_workflow步骤(加载version-detector.md和changelog-generator.md)来:
  1. 根据约定式提交检测版本更新类型
  2. 计算下一版本号
  3. 生成变更日志条目
  4. 在所有被version-detector.md检测到的项目版本文件中更新版本号
  5. 将变更日志条目插入到CHANGELOG.md中
展示所有拟议的变更供审核:
## 发布预览

**当前版本:** $CURRENT_VERSION
**更新类型:** $BUMP_TYPE
**下一版本:** $NEXT_VERSION

**变更日志条目:**
## [$NEXT_VERSION] - $DATE

### 新增
[feat提交格式化内容]

### 修复
[fix提交格式化内容]

### 变更
[docs/refactor/perf提交格式化内容]

**更新的文件:**
[列出所有被检测到并更新的版本文件]
- CHANGELOG.md → 新增条目已前置
使用AskUserQuestion:
  • 标题:"Release Changes"
  • 问题:"审核以上发布变更。是否批准?"
  • 选项:
    • "Approve" — 保留变更并继续验证准备情况
    • "Edit changelog first" — 暂停以等待用户编辑,然后确认
    • "Revert and skip release" — 撤销发布文件的变更,不生成发布相关文件直接继续验证准备情况
  1. 检查审计情况:
    • 查找
      .planning/v{{version}}-MILESTONE-AUDIT.md
      文件
    • 若文件缺失或已过期:建议先运行
      /kata-audit-milestone
    • 若审计状态为
      gaps_found
      :建议先运行
      /kata-plan-milestone-gaps
    • 若审计状态为
      passed
      :继续执行步骤1
    markdown
    ## 飞行前检查
    
    {如果没有v{{version}}-MILESTONE-AUDIT.md文件:}
    ⚠ 未找到里程碑审计文件。请先运行`/kata-audit-milestone`来验证需求覆盖情况、跨阶段集成和端到端流程。
    
    {如果审计发现问题:}
    ⚠ 里程碑审计发现问题。请运行`/kata-plan-milestone-gaps`来创建解决问题的阶段,或选择继续并将其视为技术债务。
    
    {如果审计通过:}
    ✓ 里程碑审计通过。继续执行完成流程。
  2. 验证准备情况:
    • 检查里程碑中的所有阶段是否都有已完成的计划(存在SUMMARY.md文件)
    • 展示里程碑范围和统计数据
    • 等待确认
  3. 收集统计数据:
    • 统计阶段、计划、任务的数量
    • 计算git范围、文件变更、代码行数(LOC)
    • 从git日志中提取时间线
    • 展示摘要,等待确认
  4. 提取成果:
    • 读取里程碑范围内所有阶段的SUMMARY.md文件
    • 提取4-6项关键成果
    • 展示供批准
  5. 归档里程碑:
    • 创建
      .planning/milestones/v{{version}}-ROADMAP.md
      文件
    • 从ROADMAP.md中提取完整的阶段详情
    • 填充milestone-archive.md模板
    • 将ROADMAP.md更新为带链接的单行摘要
  6. 归档需求文档:
    • 创建
      .planning/milestones/v{{version}}-REQUIREMENTS.md
      文件
    • 将所有v1需求标记为完成(勾选复选框)
    • 记录需求结果(已验证、已调整、已丢弃)
    • 删除
      .planning/REQUIREMENTS.md
      文件(为下一个里程碑创建新的需求文档)
  7. 更新PROJECT.md:
    • 添加“当前状态”部分,记录已发布的版本
    • 添加“下一个里程碑目标”部分
    • 将之前的内容归档到
      <details>
      标签中(若版本为v1.1及以上)
6.5. 文档审核(非阻塞):
提交前,提供最终的README审核选项:
使用AskUserQuestion:
  • 标题:"Final README Review"
  • 问题:"在完成里程碑v{{version}}前,是否修订README?"
  • 选项:
    • "Yes, draft an update for my review" — 修订README并展示给用户审核
    • "No, I'll make the edits myself" — 暂停等待用户审核,等待用户发送"continue"指令
    • "Skip for now" — 直接进入提交步骤
如果选择"Yes, I'll review now":
针对已完成的v{{version}}里程碑审核README.md。
确保所有已发布的功能都已文档化。
准备就绪后请发送"continue"。
如果选择"Show README": 展示README.md,然后使用AskUserQuestion:
  • 标题:"README Accuracy"
  • 问题:"这是否符合v{{version}}的实际情况?"
  • 选项:
    • "Yes, looks good" — 继续执行步骤7
    • "Needs updates" — 暂停等待用户编辑,等待用户发送"continue"指令
如果选择"Skip"或审核完成: 继续执行步骤7。
非阻塞:无论选择如何,里程碑完成流程都会继续。
6.7. 关闭GitHub里程碑:
若github.enabled为true,关闭该版本对应的GitHub里程碑。 详情请查看milestone-complete.md中的
close_github_milestone
步骤。
  1. 提交并完成:
    • 暂存:MILESTONES.md、PROJECT.md、ROADMAP.md、STATE.md、归档文件
    • 提交:
      chore: complete v{{version}} milestone
    PR工作流处理(步骤0中已创建分支):
    bash
    PR_WORKFLOW=$(cat .planning/config.json 2>/dev/null | grep -o '"pr_workflow"[[:space:]]*:[[:space:]]*[^,}]*' | grep -o 'true\|false' || echo "false")
    CURRENT_BRANCH=$(git branch --show-current)
    如果
    PR_WORKFLOW=true
    (当前在release/vX.Y.Z分支):
    推送分支并创建PR:
    bash
    # 推送分支
    git push -u origin "$CURRENT_BRANCH"
    
    # 收集该里程碑的所有阶段议题
    GITHUB_ENABLED=$(cat .planning/config.json 2>/dev/null | grep -o '"enabled"[[:space:]]*:[[:space:]]*[^,}]*' | head -1 | grep -o 'true\|false' || echo "false")
    ISSUE_MODE=$(cat .planning/config.json 2>/dev/null | grep -o '"issueMode"[[:space:]]*:[[:space:]]*"[^"]*"' | grep -o '"[^"]*"$' | tr -d '"' || echo "never")
    
    CLOSES_LINES=""
    if [ "$GITHUB_ENABLED" = "true" ] && [ "$ISSUE_MODE" != "never" ]; then
      # 获取该里程碑的所有阶段议题编号
      # --state all包含已关闭的议题(GitHub会忽略重复的Closes #X,
      # 但包含它们能确保PR正文反映所有相关工作)
      PHASE_ISSUES=$(gh issue list --label phase --milestone "v{{version}}" \
        --state all --json number --jq '.[].number' 2>/dev/null)
    
      if [ -z "$PHASE_ISSUES" ]; then
        echo "Note: No phase issues found for milestone v{{version}}. This is expected for milestones without GitHub issues."
      fi
    
      # 构建多行Closes部分
      for num in ${PHASE_ISSUES}; do
        CLOSES_LINES="${CLOSES_LINES}Closes #${num}
    "
      done
    fi
    
    # 创建PR
    gh pr create \
      --title "v{{version}}: [Milestone Name]" \
      --body "$(cat <<EOF
    ## Summary
    
    Completes milestone v{{version}}.
    
    **Key accomplishments:**
    - [accomplishment 1]
    - [accomplishment 2]
    - [accomplishment 3]
    
    ## Release Files
    
    [list version files that were updated]
    - `CHANGELOG.md` — v{{version}} entry added
    
    ## After Merge
    
    Create GitHub Release with tag `v{{version}}`.
    
    ## Closes
    
    ${CLOSES_LINES}
    EOF
    )"
    显示:
    ✓ PR created: [PR URL]
    
    After merge:
    → Create GitHub Release with tag v{{version}}
    如果
    PR_WORKFLOW=false
    (当前在main分支):
    在本地创建标签:
    • 标签:
      git tag -a v{{version}} -m "[milestone summary]"
    • 询问是否推送标签
  2. 发布后验证:
    发布PR合并后(或标签推送后),提示进行验证:
    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
     POST-RELEASE CHECKLIST
    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
    
    Before moving on, verify the release:
    
    ☐ CI/CD pipeline passed (if configured)
    ☐ Release artifacts published successfully
    ☐ Quick smoke test confirms basic functionality
    
    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
    使用AskUserQuestion:
    • 标题:"Verification"
    • 问题:"Release verification complete?"
    • 选项:
      • "Yes, verified" — 继续完成流程
      • "Something failed" — 停止并协助调试问题
      • "Skip" — 不进行验证直接继续
    如果选择"Something failed": 停止并协助调试问题。 如果选择"Yes"或"Skip": 继续执行步骤9。
  3. 提供下一步建议:
    • /kata-add-milestone
      — 启动下一个里程碑(包含问题调研→需求定义→路线图规划)
</process>
<success_criteria>
  • 里程碑已归档至
    .planning/milestones/v{{version}}-ROADMAP.md
  • 需求文档已归档至
    .planning/milestones/v{{version}}-REQUIREMENTS.md
  • .planning/REQUIREMENTS.md
    已删除(为下一个里程碑准备新的需求文档)
  • ROADMAP.md已折叠为单行条目
  • PROJECT.md已更新当前状态
  • 已创建git标签v{{version}}(若pr_workflow=false)或已创建PR/提供相关说明(若pr_workflow=true)
  • GitHub里程碑v{{version}}已关闭(若github.enabled为true)
  • 提交成功
  • 用户了解下一步操作(包括需要创建新的需求文档)
若已执行发布工作流:
  • CHANGELOG.md已更新v{{version}}条目(已审核并批准)
  • 所有被检测到的项目版本文件已更新版本号
  • 已创建GitHub Release(若pr_workflow=false)或已提供相关说明(若pr_workflow=true) </success_criteria>
<critical_rules>
  • 先加载工作流: 执行前先阅读milestone-complete.md
  • 验证完成情况: 所有阶段必须有SUMMARY.md文件
  • 用户确认: 在验证检查点等待用户批准
  • 先归档再删除: 在更新/删除原始文件前,必须先创建归档文件
  • 单行摘要: ROADMAP.md中折叠的里程碑应为带链接的单行内容
  • 上下文效率: 归档操作确保每个里程碑对应的ROADMAP.md和REQUIREMENTS.md文件大小保持稳定
  • 新需求文档: 下一个里程碑通过
    /kata-add-milestone
    启动,该命令包含需求定义环节 </critical_rules>