用途：这是 Spec Forge 工作流中的 journeys 阶段，用于逐步细化每个主要用户旅程的行为，回答“按步骤发生什么、有哪些状态与备选路径、适用哪些规则、涉及哪些代码触点”。
主要能力：按小批次评审旅程，逐个旅程创建或更新 .spec-forge/specs/<spec-id>/journeys/<journey-id>.yaml，内容涵盖触发条件、参与者与前置条件、主流程、备选流程、加载/空/错误/成功状态、业务规则与边界情况、关联组件、代码触点与公共契约、可观测性预期；同时维护 journeys/batches.yaml 的评审状态。
使用方式：仅在 Plan 模式下运行，非 Plan 模式须先让用户切换。开始前先确认聊天语言与文件语言，并读取 ../spec-forge/assets/contracts/ux-contracts.yaml。先执行 spec-forge-cli resolve --target <target-dir> --skill spec-forge-journeys --stage journeys --write，再逐步收集缺失参数，用 spec-forge-cli apply 记录。用 spec-forge-cli focus --target <target-dir> --spec-id <spec-id> --stage journeys --max-items 1 --write 选择批次；用 artifact get 查看、artifact merge 增量更新或 artifact put 整体替换。每轮最多 3 个紧密相关问题、最多一个主旅程。在聊天中给出摘要并请求明确批准，再用 spec-forge-cli approve 记录，最后执行 gate check 与 stage advance。
适用场景：需要把已批准架构转化为可评审、可验收的旅程规格时。
限制：入口要求架构产物已存在且已批准；不得跳过看似明显的旅程，不得深入组件内部（仅识别触点），不得一次评审过多流程，不得把高风险问题留在散文中，不得一次性收集全部缺失参数，不得让用户直接查看 YAML。输出为 journeys/batches.yaml、journeys/<journey-id>.yaml 与 gates/journeys.yaml。