当初为了赶演示，你们选了一个临时方案。半年后助手看到“项目采用这个方案”，把它当成永久架构原则继续扩展。选项留下来了，交付期限这个决定性前提却不见了。后来的人只能继承结论，没法重新判断。
一份简短的架构决策记录本来就能解决这件事。团队已有这样的记录时，继续维护即可。EasyNet 的作用可以是让不同助手在需要时找到这些材料，不必把成熟做法重新包装成另一套知识系统。
通过 Context 关联决定与出处时，值得保留的是当时约束、主要替代方案、选择理由和确认人。例如，“本次演示使用本地文件，因为时间不足以接入数据库；多人同时编辑前重新评估”。这一段比孤立的“使用本地文件”更能指导后续工作。
这些理由需要参与者确认。摘要可以从讨论中提取候选内容，但一次成功运行不能证明当时为什么作出选择。接手者还需要获得这个项目的决定记录与出处的读取权限，不能因分享一条引用就开放整段私人讨论。没有留下原因的旧决定，应找负责人核实，不由助手补写一个听起来合理的故事。
新任务使用旧决定时，先比较条件是否还成立。现在要支持多人编辑，正好触及原先约定的复查条件；助手应提出重新评估，而不是自行推翻，也不是无条件沿用。这种条件连接与提醒需要在任务入口补齐，单有资料引用不会自动触发。
拿一个已经遇到规模变化的项目检验这份记录：新同事能否看出哪些是硬约束、哪些只是当时的妥协，以及下一步该找谁决定。保留理由并非为了把所有讨论存下来，而是让过去的决定可以被理解、被继承，也能在条件变化后被有依据地改变。
- 01
记录当时约束
演示期限不等于永久架构原则。
- 02
保留决定出处
理由、替代方案与确认者。
- 03
触及条件后复查
多人编辑前找负责人重新决定。
一句结论补齐选择理由
简短的人工决策记录；review_when是提醒依据，不是自动触发器。
{
"decision": "local files for the demo",
"reason": "database integration would miss the demo deadline",
"alternative": "shared database",
"review_when": "more than one editor needs to write",
"confirmed_by": "<actual decision owner>"
}预期结果：后续多人编辑需求会指向复查，而不是盲目继承本地文件方案。
接入时的检查项
- 决定可回查其理由和确认者。
- 条件变化时能识别需要复查的记录。
- 过期决定与现行约束在交接中明确区分。