Intent
Intent 是 shipyard 的内部需求入口：支持/运营人员最先看到产品问题，却无法编写工程规格。intent 技能把他们的对话转换成一份目标级的 YAML+Markdown 产物，由负责人审阅并签署，从而让工程团队收到一份没有迷雾的任务。它建立在可验证性边界之上——智能体负责提问、记录与起草；人类负责提交、核实与签署。
设计来源：这里的每个决策都由一张 wayfinder 图（7 张工单）固定，并在实现前于一个演示仓库中端到端走通。
角色契约
贡献者（例如支持人员）粘贴原始反馈或聊天记录。智能体绝不编造事实；未知内容成为明确的“待确认”项。
决策属于人类：贡献者确认措辞，主管提交，产品负责人核实事实并签署接受/拒绝。智能体绝不签署、绝不替任何人拒绝，也绝不代替评审者。
停止门是完成门，而非模糊度评分——不借用 deep-interview 中的数学计算；只复用其 Goal 与 Constraint 清晰度判断作为质量门槛。
对话（编号批量提问）
开场清点：用一句话重述问题，然后展示五部分清点（每部分已知/缺失）。
编号批量提问：把每个缺口作为编号问题一次性列出。贡献者按编号回答（1 是；2 不确定）。未知答案记为“待确认”并推入未决问题——绝不追问到让人猜测为止。
重新清点：应用答案；如果仍有缺口，发出下一批编号问题。一轮 = 一批。
停止门（五个部分必须全部通过）：
问题：可观察现象，不嵌入解决方案
目标：一句话，无限定词，点明实体与关系（deep-interview Goal Clarity 门槛）
用户和系统：用户与系统使用真实名称；未知写作“待确认”并计为未决问题
约束：边界、限制和非目标明确（deep-interview Constraint Clarity 门槛）
未决问题：列表非空，或明确写“无”
软限制：第 6 轮软提示（“以当前清晰度起草？”），硬上限第 12 轮。提前退出从不被阻止——单薄的部分会表现为更长的未决问题，而评审才是拒绝它们的关口。
起草：智能体起草 docs/intents/<slug>/intent.md（模板见下），状态为 draft；贡献者在任何提交前确认措辞。
intent.md 模板
intent: <slug> title: <one-line title> author: <name (role)> date: <YYYY-MM-DD> status: draft | in-review | accepted | rejected round: <tracker review round>
问题
<observable phenomena, no solution>
目标
one sentence, no qualifiers
用户和系统
<who the users are, which systems, real names; unknowns as 待确认>
约束
<boundaries, non-goals; cite Rules pillar files when a constraint comes from them>
未决问题
- [阻塞|非阻塞] <question> ← agent suggests, product owner finalizes
未决问题分级
“阻塞”的检验标准是：“不回答它，规格还能被批准吗？”不能 → 阻塞；能 → 非阻塞（被追踪，可以带入开发）。起草智能体给出分级建议；产品负责人在规格批准时最终确定。
评审交接（harbor 四类记录）
评审在仓库的 tracker 上运行——tracker 是唯一的记录来源；intent.md 的 frontmatter 仅镜像状态。每个 Intent 一个记录文件，轮次在其中累积。每条记录必填字段：签署人、日期、裁决、指向 intent.md 的链接、轮次、拒绝原因（拒绝时必填）。
proposal = 主管提交 Intent（intent.md → status: in-review）
verification = 产品负责人在决定前对照仓库证据核实事实；智能体可以起草事实核查表，但签名属于评审者——没有仓库证据可查？那么 verification 记录为何不需要。
decision = 接受或拒绝；拒绝需要原因，这是重新提交的关键输入
execution result = 该 Intent 的规格生成已完成
被拒绝 → 修订 → 在同一文件下以下一轮编号重新提交。历史保持可追溯。
移交给 launch
一个被接受的 intent（status: accepted）是有效的任务简报。launch 的规格综合随后遵循四步契约：
读取 docs/intents/<slug>/intent.md（必须为 accepted、最新轮次）
结合现有代码库
遵循 Rules pillar（CLAUDE.md + docs/standards/ + docs/business/）
列出每个疑点与规则冲突——分级放入规格的待确认部分
Intent 未决问题逐字带入规格，保持其待确认状态。
修订
接受后的新信息（通常由第一份规格浮出）构成修订：任何人都可发起，提交者签署，且总是作为新一轮重新进入完整评审——没有小改动豁免。intent 变更会标记生成的规格为陈旧；规格从新 intent 重新生成并重新批准。没有单独的修订记录类型：轮次承载它。
冲突沉淀
规格待确认部分中的冲突结论遵循基于先例的路由：个案本地答案留在规格中；将约束后续 Intent 的结论沉淀进 Rules pillar（业务规则进 docs/business/，行为规则进 docs/standards/）；难以逆转的技术权衡成为 ADR。绝不重复写入；绝不推迟归档。产品负责人决定某结论是否具有先例性；技术负责人建议落点。