| name | loom-story |
| description | Turn product context, vision, roadmap, host issues, notes, or discussion summaries into a Loom-consumable User Story, Story Readiness, and business semantic confirmation point before formal spec / plan work. |
Loom Story
loom-story 承接 story-to-delivery intake 场景。
它把产品上下文收束为 User Story、Story Readiness 与 Story Business Confirmation，但不替代 Work Item、spec.md、plan.md、review、merge-ready 或 closeout。
1. 使用时机
当任务满足以下任一条件时，进入 loom-story：
- 将 vision、roadmap、notes、host issue 或讨论内容整理成 User Story
- 判断 story 是否足够进入 formal spec / plan
- 需要用户轻量确认 story 的业务语义，或根据用户修订意见回到 story shaping
- 需要把 story acceptance scenarios 映射到后续
spec.md / plan.md
- 需要检查 actor specificity 或 scenario coverage
如果用户要求把 story、roadmap 或治理目标拆成 Phase / FR / Work Item / PR，或要求规划 issue tree、依赖关系、blocked-by/blocks，应回到 loom-init 的 delivery planning 路由。loom-story 只负责 story shaping，不输出 issue-tree plan。
如果任务已经是实现当前 Work Item，应进入 loom-build。如果任务已经要求 formal spec review，应进入 loom-spec-review。
2. 固定入口
统一入口固定为：
loom story --target <repo> [--item <id>] --json
该入口只读取全局 loom CLI 可用性，输出 agent-safe story intake contract summary。实际 story shaping 由执行者根据输入上下文写入用户指定载体或后续 spec / plan，不由 runtime 自动裁决产品目标。
3. 输出职责
执行者必须在实际 shaping 输出中保持四类分离结果：
- User Story
- actor
- capability
- outcome
- business value
- acceptance scenarios
- out of scope
- provenance / context locators
- Story Readiness
- decision:
confirmed | pending | revision-requested | not_applicable
- rationale
- missing inputs
- spec / plan entry expectation
- Story Business Confirmation
- decision:
pending | confirmed | revision-requested | not_applicable
- confirmation scope: actor、capability、outcome、business value、acceptance scenarios、out of scope
- revision request 或 bypass rationale
- confirmation source
User Story 主体不得包含 delivery handoff、spec locator、plan locator、recovery state、review findings、PR summary、merge-ready 或 closeout state。
4. Shaping Checklist
至少检查：
- actor 是否具体，避免在已有具体角色时写成模糊
User
- outcome 是否可观察
- business value 是否说明进入交付链的理由
- out of scope 是否足够清楚，避免后续 spec / plan 默认扩大范围
- happy path 是否存在
- negative path、edge case、alternative path、security/permission、environment/interruption 是否按风险覆盖或标记
not_applicable
- story 是否过大，需要拆成多个 Work Item 或 FR
- 若需要拆分，交给
loom-init 的 delivery planning 路由输出 issue-tree plan；不要在 story 主体里直接写执行树
- 若 story readiness 为
pending，说明缺少哪些输入或业务确认，并停在 story shaping
- 若用户给出修订意见，记录
revision-requested，必须回到 story shaping，不得直接进入 spec / plan
- 若 story 涉及业务语义，是否已经请求用户确认；用户直接说「确认」即可记录
confirmed
- 若 story 不适用，记录
not_applicable 和 bypass rationale，不得只省略 story 结果
5. Delivery Boundary
loom-story 只把 story 准备成后续 delivery 输入：
spec.md 消费 story scenarios 形成 behavior contractplan.md 将 scenarios 映射到 tests、checks、manual validation 或 not_applicable evidence- Story Readiness 与 Story Business Confirmation 都必须是
confirmed 或明确 not_applicable，formal spec / plan 才能消费 story 语义
pending 或 revision-requested 必须 fail closed：停止 formal spec shaping，回到 story shaping 或等待用户业务语义确认not_applicable 必须说明纯治理、维护、格式或链接类 bypass rationale，后续 spec / plan 只能消费该 rationale，不得制造空确认Work Item 仍是唯一执行入口- issue tree、Phase / FR / Work Item / PR 切分、blocked-by/blocks 与 host carrier mapping 由
loom-init 的 delivery planning 路由承接
6. Full / Minimal Suite Path 边界
loom-story 不选择或重定义 full/minimal suite path；它只产出可被
spec-suite 消费的 story readiness 与 business confirmation 输入。
- full path：若 formal spec path 消费 story，必须输出 Story Readiness 与 Story
Business Confirmation locator，且 decision 为
confirmed 或明确
not_applicable。pending / revision-requested 必须 fail closed，回到 story
shaping 或等待业务语义确认。
- minimal path：纯治理、维护、格式、链接修复或载体整理可以输出
not_applicable，但必须包含 bypass rationale、consumer boundary 和 recheck
condition，供 spec.md、plan.md、evidence-map 与后续 gate 消费。
loom-story 不把 not_applicable 升级成产品确认，不生成 evidence-map、
consistency-analysis、review、merge-ready 或 GitHub closeout truth。
输入信号与输出合同见：
