intent

意图

意图是船厂的内部接单入口：支持/运维人员最先看到产品问题，却写不出工程规格。意图技能把他们的对话转换为目标级的 YAML+markdown 产物，由负责人审阅并签署，从而让工程团队收到一份没有迷雾的任务。它立足于可验证性边界——Agent 负责提问、记录和起草；人类负责提交、验证和签署。

设计溯源：这里的每一项决策都由一张 wayfinder 地图（7 张工单）钉定，并在实现前于一个演示仓库中端到端走通。

角色契约

• 贡献者（例如支持人员）粘贴原始反馈或聊天记录。Agent 绝不臆造事实；未知项一律成为显式的 待确认 条目。
• 决策属于人类：贡献者确认措辞，主管提交，产品负责人核实事实并签署接受/拒绝。Agent 绝不签署，绝不代任何人拒绝，也绝不代替评审人。
• 停止门是完成门，不是含糊度评分——不从 deep-interview 借用任何数学计算；只复用其目标清晰度与约束清晰度的判断作为质量门槛。

对话（编号批量提问）

1. 开场盘点：用一句话复述问题，然后展示五段式盘点（每段已知 / 缺失）。
2. 编号批量提问：把所有缺口作为编号问题一次性列出。贡献者按编号回答（1 是; 2 不确定）。未知的回答记录为 待确认 并推入未决问题——绝不追问到逼人猜测。
3. 重新盘点：应用这些回答；若仍有缺口，发出下一批编号问题。一轮 = 一批。
4. 停止门（五段必须全部通过）：
   • 问题：可观察的现象，不夹带解决方案
   • 目标：一句话，无修饰语，点明实体与关系（deep-interview 目标清晰度门槛）
   • 用户和系统：用户与系统使用真实名称；未知者写为 待确认 并计入未决问题
   • 约束：边界、限制和非目标均明确（deep-interview 约束清晰度门槛）
   • 未决问题：列表非空，或显式写 无
5. 软限制：第 6 轮给出软提示（“以当前清晰度起草？”），第 12 轮硬性封顶。绝不阻止提前退出——信息稀薄会表现为更长的未决问题，而评审才是拒绝它们的关卡。
6. 起草：Agent 以 status: draft 起草 docs/intents/<slug>/intent.md（模板见下）；贡献者在任何提交前确认措辞。

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

未决问题分级

对 阻塞 的检验是：“不回答它，规格还能被批准吗？” 不能 → 阻塞；能 → 非阻塞（被跟踪，可带入开发）。起草 Agent 给出建议分级；产品负责人在规格批准时最终确定。

评审交接（harbor 四记录）

评审在仓库的 tracker 上进行——tracker 是唯一的记录来源；intent.md 的 frontmatter 仅镜像状态。每个意图一个记录文件，各轮次在其中累积。每条记录的必填字段：签署人、日期、裁定、指向 intent.md 的链接、轮次、拒绝原因（拒绝时必填）。

• proposal = 主管提交意图（intent.md → status: in-review）
• verification = 产品负责人在裁定前对照仓库证据核实事实；Agent 可以起草事实核查表，但签名属于评审人——没有仓库证据可查？那么 verification 要记录为何不需要
• decision = 接受或拒绝；拒绝需要给出原因，而该原因是重新提交的关键输入
• execution result = 该意图的规格生成已完成

被拒绝 → 修订 → 在同一文件中以下一轮次编号重新提交。历史保持可追溯。

交接至 launch

一个被接受的意图（status: accepted）是一份有效的任务简报。随后，launch 的规格综合遵循四步契约：

1. 读取 docs/intents/<slug>/intent.md（必须已被接受，且为最新轮次）
2. 与现有代码库结合
3. 遵循 Rules 支柱（CLAUDE.md + docs/standards/ + docs/business/）
4. 列出每一处疑问和规则冲突 —— 分级归入规格的待确认部分

意图中的开放问题原样带入规格，保持其待定状态。

修订

接受之后出现的新信息（通常由第一份规格浮现）即构成一项修订：任何人都可发起，提交者签署，并且它始终作为新一轮重新进入完整评审 —— 无轻微变更豁免。意图变更会将被生成的规格标记为过时；规格根据新意图重新生成并重新获批。不存在单独的修订记录类型：由轮次承载。

冲突沉淀

规格待定部分中的冲突结论遵循基于先例的路由：个案局部答案留在规格中；将约束后续 Intent 的结论沉淀进 Rules 支柱（业务规则进入 docs/business/，行为规则进入 docs/standards/）；难以逆转的技术权衡成为 ADR。绝不双写；绝不延迟归档。由产品负责人决定某项结论是否构成先例；技术负责人就归档位置提供建议。