arojinle

Àròjinlẹ̀

明确表达的机制不一定代表已确定的需求。仅在需求、受益者、可观察的成功标准和重要权衡尚未明确时，才进一步澄清。复用完整的简报和已接受的约束；不要凭空制造备选方案，也不要重新询问已确定的选择。单个已理解的有限选择可以留给发起者决定。

如果尚未解决的项目特定含义——术语、身份、边界、关系、所有权或不变量——可能实质性地改变决策树，请使用 amose。

持续访谈用户，直到双方达成共识，且没有重要分支仍被默默假定。将其绘制为一棵决策树：每项决策都应分支到依赖它的决策。

按轮次推进这棵树。前沿是所有前置条件都已确定的决策。每轮一次性询问整个可回答的前沿，然后等待用户回答，再开始下一轮。

使用这张问题卡，并以 Markdown 呈现，不要显示模板围栏。各轮的问题编号保持稳定；在能让回答更加明确时，为选项标注标签。

❓ **Q1** — **<question title>**: <question and choices, as needed>

💡 <brief context, evidence, trade-off or example, only when it makes the decision clearer>

➡️ <recommended answer and why>

每轮都会重塑决策树。在提出下一轮问题前，根据已确认的回答重新计算重要前沿；回答可能创建、移除、合并、拆分或重新界定依赖分支。不要只是沿着先前设想的决策树继续推进。

如果用户无法判断抽象选项，就用一个简短示例让选择具体化，或使用 adanwo 获取直接体验，然后根据用户的反馈继续。反复提问无法替代用户尚未拥有的体验。在确认之前，提出的解释都应保持试探性。

不要在同一轮提出依赖其他未决问题答案的问题。

查找事实是你的工作，绝不是用户的工作。直接查明范围有限的事实。在调查前置条件期间，询问独立的前沿问题；只有依赖该证据的问题才等待。若某个重要前沿确实受第三方提供且无法查证的信息控制，应指出缺失的信息，并继续询问独立的问题。如果收集这类信息属于工作范围，可直接返回可回答的问题；若 oro 可用且对面向接收者的草拟工作有实质帮助，也可使用 oro。起草不等于授权发送，也不会让回复自动成为批准。

只有在不同的专业知识或上下文所带来的收益足以抵消协调成本时，才委派范围明确的分析、研究或专家工作；返回简洁的结论和证据链接。

使用 iwadi 开展实质性的前置条件研究，并使用适用的项目或宿主能力获取源材料。继续同一场访谈；证据不完整并不意味着依赖的前置条件已确定。

当某个前沿选择有多个可信的备选方案，且至少两个独立标准可能实质性地改变推荐结果时，使用精简、针对该决策的评分标准。先应用硬性门槛；仅推导对此决策真正重要的标准；说明决定性因素、最有力的可信备选方案以及重要的反面证据。不要为琐碎或已确定的选择凭空打分，也不要让平均分掩盖硬性门槛。评分标准用于支持推荐；决策仍由用户作出。

当所需结果是探索主动机会或塑造方向时，在探索模式下使用 atona。如果可丢弃的原型能帮助澄清具体选择，则使用 adanwo。

决策仍由用户作出。不要默默地将推荐、生成的选项、比较评分或原型观察转化为确认。

让共同理解一目了然

对于计划或提议的方向，应从第一个有意义的提议开始使用 html-artifact。通过该计划的负责人复用其持续更新的视图；否则，为交接维护一个视图。将问题留在对话中。其他有明确边界的决策可按需借助可视化支持。

发生重大变更后，应先在同一份 HTML 计划中更新决策及其呈现，再提出依赖这些决策的问题；不要创建内容等同的 Markdown 副本。保留备选方案、硬性门槛、不确定性和反面证据。在最终确认前展示整合后的视图。如果该视图不可用，报告这一缺口并继续独立核实事实。

在宣布没有未解决的重要事项之前，应审视当前决策树，检查其中是否存在影响重大的假设、缺失分支、相互矛盾的决策，以及从未明确说明的依赖关系。

只有在审视后已无未解决的重要分支、任何必需视图均为最新状态，且用户确认双方理解一致时，才可结束。向同一调用方返回已确认的决策、重要假设／证据、对选择构成约束且可能改变决策的备选方案／标准、明确的延期事项／重新进入条件，以及下一个结果边界。同时提供计划的 HTML 定位信息和修订版本。返回新发现的领域、事实或技术缺口，但不要启动相互竞争的工作流。不要在 arojinle 内执行交付工作。