用途：从已完成的 {base_directory}/implementation/milestones.yaml（/implementation-planner 的输出）生成交付时间线。用法：/delivery-timeline [base-directory]。未提供目录时，会先查找当前目录下的 implementation/milestones.yaml，找不到则询问规划产物所在位置并等待用户提供路径，存入 base_directory。
主要流程：读取 milestones.yaml 中各里程碑的 id、name、dependencies、estimated_duration 及 meta.ordering_strategy（缺省为 foundation-first）。随后一次性询问三个问题：生产部署日期（YYYY-MM-DD）、QA 轮数、每轮 QA 天数；若部署日期落在周六或周日会提示改用上一周五或下一周一，需用户确认。之后按内置换算表把 estimated_duration 转为整数工作日，并在 milestones.yaml 中为每个里程碑添加 estimated_days，其他字段保持不变（示例：1 week 对应 estimated_days: 5）。
时间线构建：汇总 estimated_days 得 total_development_days；当总开发天数大于 30 或里程碑数大于 5 视为大型项目（仅记录于摘要，QA 轮数仍以用户输入为准）。按依赖顺序从 Day 0 起为每个里程碑分配 start_day 与 completion_day（无依赖 start_day=0，有依赖为最后依赖 completion_day 的下一工作日）。multi-pr 策略会在每个里程碑后插入 pr-creation、pr-review、review-feedback、merge 四个阶段，其余策略使用项目末尾的单次 PR 流程。随后追加部署、按轮次重复的 QA 阶段（QA Deadline 使用 qa_days_per_round）以及固定 Signoff 阶段。
输出：写入 {base_directory}/delivery/timeline.yaml（必要时先 mkdir -p {base_directory}/delivery），文档含 version、project、generated、milestones_file、summary（总天数、项目规模、QA 轮数、交付模型）、timeline 与 workback。workback 以 post-signoff 的 completion_day 对应 production_deploy_date，倒推真实日历日期并跳过周六周日，生成 project_start_date 与全部条目日期，最后附 production-deploy 条目。之后执行内联的 Gap Analysis 检查（里程碑覆盖、依赖顺序、时长换算、项目规模、QA 轮数、交付模型、时间线完整性、workback 正确性），报告问题并询问是立即修复、按现状继续还是先手动调整估算。
限制：需已存在符合格式的 milestones.yaml；依赖时间按工作日计算，不处理节假日；输出规范与完整示例见 references/output-spec.md 和 references/example.yaml，这些文件内容暂未提供。