用途：fmway-po 位于开发流程上游，目标是在启动 fmway-dev 或 fmway-bugs 之前，把尚未成形的需求转化为一个或多个可直接进入开发的工单。它面向产品负责人场景，强调先澄清问题、再确认范围，最后才撰写文档。
主要能力：
- 需求梳理：以产品语言记录要解决的问题、受影响的人、期望结果、已知限制与非目标、成功衡量方式，并阅读已有的 PRD.md、docs/、历史工单与 PRD 等上下文。
- 仓库识别：向用户确认涉及哪些仓库，或读取中央仓库 CLAUDE.md 中的 repos: 列表；多仓库产品需先列出所有可能涉及的仓库。
- 只读可行性评估：逐仓库以只读方式调研当前行为、可能受影响的模块、入口、集成与需保留的既有模式，并把结论追溯到 repo:ruta:línea；无法从代码确认的内容必须登记为开放问题而非假设。同时记录跨仓库的 API、事件、模式、共享包等契约变更及顺序约束。
- 范围与拆分门（Gate 1）：在写工单前提出范围草案，包括一行式需求重述、范围内外、工单拆分（按仓库、增量或功能与缺陷区分）、依赖顺序、可行性摘要，以及需用户立即回答和仍可自行调研的问题，等待用户确认。
- 隔离配置：Gate 1 之后询问用户是在当前检出中新建分支，还是创建独立 git worktree；若当前有未提交改动则先暂停询问。分支方式为 git switch develop && git pull --ff-only && git switch -c po/{slug}；worktree 方式仅在 .worktrees/ 下创建：git fetch origin develop && mkdir -p .worktrees && git worktree add .worktrees/po-{slug} -b po/{slug} origin/develop。工单写入拥有 docs/ 的中央仓库，不直接写入 develop 或 main。
- 工单撰写：为每个已确认的工单生成 docs/requirements/{ticket-slug}/TICKET.md，slug 格式为 {带零填充的编号}-{kebab-case 名称}，编号在 docs/requirements/ 与 docs/prds/ 之间连续；文档包含状态、问题/结果、范围、可行性备注、受影响仓库与模块表、跨仓库依赖、可验证的验收标准、风险与假设、开放问题、建议流程等章节。写作规则要求可追溯、可验证、不臆造需求。
- 就绪评审门（Gate 2）：逐工单展示就绪定义清单，包括问题与结果、范围与非目标、代码级可行性、仓库与契约映射、可验证验收标准、开放问题已解决或经用户明确同意延期；开放问题未清空的工单不能标记为就绪，需迭代直至用户确认。
- 交付：用户通过 Gate 2 后把工单状态更新为就绪；仅在用户明确要求时才与 Jira 等工单系统同步并记录问题键；随后建议调用 fmway-pr 推送 po/{slug} 并开 PR，PR 标题为 po({slug}): {名称}，正文包含需求、工单列表与状态、拆分依据、开放问题处理情况，合并需用户批准。
使用方式：按门控顺序推进，Gate 1 确认范围与拆分，Gate 2 评审就绪清单，Gate 3 建议 PR 流程；每个门控处暂停等待用户确认。
适用场景：单仓库小改动只需简短可行性与一个工单；多仓库产品（如 Web 应用加 API 加 worker）需分别调研并显式记录契约与顺序约束。
限制：流程只分析不编码，不写 PRD 或开发计划，不维护 .ways/state.json；调研期间对被调研仓库只读；未经用户明确请求不得创建、更新或流转工单系统问题；未确认范围前不得撰写工单，未解决开放问题不得标记就绪，无代码依据不得作可行性断言。