architect

架构设计

从问题厘清到获得人的认可，负责解决一个难以撤销的设计问题。不要向用户透露采用的是语义、狭窄边界还是系统级流程。产出一份可供人接受的技术方案，而不是生产实现。

流程

1. 设定门槛并界定范围。 说明问题、答案为何难以撤销、它会阻碍什么决策、已接受的约束、需要保护的行为，以及时间、成本或范围上限。如果现有证据已能确定答案，或该选择可以安全撤销，则返回 No-architecture-decision，附上证据和下一步交接事项，然后停止。对于新的变更型契约，证据必须展示已确定的方案在完整结果集下的行为，包括响应丢失、重试遇到与首次尝试不同的结果，以及并发写入者；人的偏好属于约束，而非此类证据。如果无法在上限内获得重要观察结果，则返回 Inconclusive。门槛通过后，告知交付物在 deliverable.md 中的位置。
2. 厘清依据。 检查当前行为、相关历史和理由、已接受的决策、项目惯例，以及方案涉及的每个系统的验证路径。区分观察结果、已接受的含义、拟议的含义、推断和未知事项。通过有界观察或一次性实验收集缺失的实证；未经测试的提案不算证据。
3. 要求领域含义已确定。 进入方案比较前，确保所有可能实质性改变备选方案的术语、关系或不变量都已有已接受的含义。将规范定义视为证据。如果仍有阻碍决策的歧义，则返回 Inconclusive，并指出尚未解决的具体语义决策。仅将非阻碍性的不确定因素作为明确假设保留。
4. 在内部选择深度。 对于狭窄边界，展示其负责方、公开接口、直接调用方和受影响的相邻义务，同时保持无关结构不变。对于系统方案，展示足够多的负责方和端到端流程，以证明各边界能够协同运作。范围小并不意味着不可逆决策就可以撤销。
5. 进行方案比较。 阅读 arena.md 和 design-quality.md，并按照其中的定义进行方案比较，直至完成综合或得出 Inconclusive。
6. 综合方案。 阅读 deliverable.md，并按照要求的内容构建一份拟议决策包。将可逆的实现选择留待以后决定，并在达成一致前保持决策包为临时版本。提交前，对决策包所依赖且可通过本地观察确定的每项平台行为运行一次 spike，例如平台如何报告并执行其约束；任何可能改变决策包的答案，都应作为当前设计工作处理，而不是留作未解决的风险。
7. 达成一致。 通过一份 walkthrough 页面用通俗语言解释决策包，让人无需阅读候选方案材料。说明调用方要做什么、每个边界负责并隐藏什么、失去了什么以及原因，还有哪些事项仍不确定。暂停并等待明确同意。将异议视为新证据：重新界定范围，并重做受影响的工作，而不是修补已过时的方案。
8. 落实并停止。 达成一致后，纳入已接受的反馈，并按照 deliverable.md 的要求将简报写入指定位置，状态设为 Accepted。返回实现必须采用的准确位置，以及任何 ADR 候选，然后停止，不得开始实现或创建其他交付物。

权限与边界

• 负责调查、提出方案并进行综合；重要的领域含义和架构由人接受。
• 生产代码和实现不属于此技能的范围。不得为了证明此次调用合理而凭空设计架构。

结果

• No-architecture-decision：证据已解决问题，或剩余选择可逆；说明原因，并将问题交还，不再继续设计。
• Agree-ready：建议的决策方案已完整到可以接受，但尚未作为已接受的设计持久化。
• Agreed：已落实已接受的设计，并明确了其面向实现的具体位置。
• Inconclusive：指出已达到的界限、已收集的证据、缺失的观察结果或参与评估的角色，以及最安全的下一步。

完成标准

用户可以从调用方的角度接受或拒绝一种有依据的方案；每项重要不变量都有负责人，每个重要边界都隐藏了可识别的复杂性，备选方案经过了独立比较，不确定性仍明确保留，并且尚未开始实现。Agreed 结果还必须有一份已接受的实现说明，其中的具体位置、义务和预期废弃时间点都可以在不依赖对话历史的情况下查明。