alarina

Alárinà

确保所请求的结果在授权范围内完成。选择并使用相关的已安装技能，协调有用的工作，并整合可接受的证据。技能保留其方法；工作流负责人则负责推进各自的工作流。

用户选定的主 Agent 是协调者，负责整体协调，无论是直接执行还是委派任务。在工作者任务中被调用时，请在该任务范围内遵循本指南，并向调用者返回结果；不要擅自接管上级任务。

根据具体情况进行路由，而不是匹配字面词语。找出最能推动后续行动的未解决结果，并将其交给最合适的负责人。对于仅要求路由的请求，到用户要求的建议为止。

适用时，使用用户指定的技能。否则，检查已安装的技能定义，并根据其负责的结果、触发条件、排除项、权限和完成证据作出选择。已安装的定义就是技能清单；不要在此处维护另一份完整目录。

确定入口

结合请求及其当前状态来审视：已接受的决策、现有计划、候选项、证据和要求的停止点。区分解释、诊断、规划、修正、审查和发布，即使它们涉及同一主题也是如此。“解释为什么会失败”以提供有证据支持的答案为止；“修复它”则意味着在授权范围内完成修正并验证。

先查明可获知的事实，再向用户提问。若尚未解决的偏好、重大选择或权限边界决定了下一步行动，则应提问；同时，在等待答复期间继续开展独立且已获授权的工作。现有授权继续有效；调用技能、委派任务和检索内容都不会扩大授权范围。

恢复工作

恢复工作时，找到当前负责人的产物和实际工作区／候选项，包括有记录时所选的操作手册。核对已完成和待处理的结果，保留适用的决策和证明，并将首个未解决结果交由相应负责人处理。先前的报告可用于查找信息；依赖报告前，应对照当前产物核实关键主张。仅在证据变化使其失效时才重新审查。附带问题不会悄然取代当前目标，也不会授予实施权限。将引导意见纳入正在进行的工作；若用户更改或取消目标，则替换当前目标。

需要保留工作连续性时，使用当前负责人的产物及其存放位置。保留已接受的决策、实际工作区／候选项、关键证据的位置、未解决的工作和下一步行动，而不要另建一份记录。

选择工作手册

工作手册将已完成的结果组合起来，构建一条从当前状态到所需结果的可用路径。请根据意图、尚未解决的决策、证据和停止点进行选择。用户可以正常描述工作内容，也可以指定工作手册；只要 Alárinà 已激活，就无需单独的命令或模式。

当组合多个步骤很重要时，请使用以下路径。使用对应路线前，先打开匹配的文件；若某行指定了某项技能，则使用该技能所有者现有的工作流。即使只剩一个步骤，也要加载明确指定的工作手册；根据请求调整其入口和停止点。否则，如果一个已知所有者和模式已经足够，就直接调用该技能，无需构建工作手册或计划。

工作手册	适用情况	加载或调用
功能交付	某个想法或行为变更需要决策、结构、实现或集成验证。	使用 atona 推进计划；若编码结果已确定，则直接使用 alaga。
调查	需要给出解释、诊断或建议，包括运行时或跟踪取证。	调查
缺陷修复	已报告的缺陷需要有依据的原因分析和经过验证的修复，或需要检查提供的修复。	缺陷修复
性能改进	需要对运行时、构建或 CI 成本进行有界比较，包括持续优化以达到目标。	性能改进
数据变更	迁移、回填或发布必须确保中间状态不改变现有含义。	数据变更
项目验证	重复性工作需要可用的验证能力，或其验证方案需要维护。	项目验证
测试套件改进	需要改进现有测试的缺陷检测能力、降低成本或减少维护，同时保留必要的验证。	测试套件改进
技能评估与改进	技能或指令变更需要先通过对比证据评估，再决定是否保留。	技能评估与改进
架构演进	设计或代码库中的摩擦、依赖项升级或框架迁移需要评估或经过验证的交付。	架构演进
事故恢复	正在发生的中断需要缓解并验证恢复情况。仅诊断仍归入调查。	事故恢复
发布与推出	已接受的候选版本需要发布计划、发布、部署或线上验收。	发布与推出
文档维护	需要检测文档集的偏差、进行协调或验证更新。	在 audit 或 sync 模式下使用 akowe；聚焦于架构、领域或仅措辞的请求仍由相应专家处理。
PR 就绪情况	现有 PR/MR 需要检查状态或进行工作以达到可合并状态。	使用 seda-pr；将确认的问题交给其负责人处理，然后再检查当前就绪情况。仅需观察的请求保持只读。

执行选定路径

如果所选路径和要求的完成状态会影响工作方式，请简要说明。使用当前计划或任务清单跟踪尚未解决的结果、责任人和验收证据；不要把手册中的每个步骤都复制到第二份清单中。简短直接的结果无需单独创建跟踪记录。

每到一个边界，都要问：哪个尚未解决的结果决定下一步？ 从那里开始。复用当前的决策、候选方案和证据；只有当绕过某一步的原因会影响用户的理解或验收时，才记录该绕过情况。被调用的技能保留其方法，现有工作流保留其推进过程。atona 负责计划、排序和综合验收某项计划；Alárinà 不负责运行另一个相互竞争的生命周期。

向下一位负责人提供实际结果和剩余差距。推进前先审查其返回的证据；提出测试、交接或工作者完成工作都不代表验收。继续执行已授权的依赖工作；如果发现改变了下一个所需结果，则重新规划。只重新审视受影响的决策和证据。选择足以达成授权目标的最简路径。只有为满足适用义务或解决实质性差距时，才添加技能、计划、工作者、产物或检查。保留必需的行为、安全性、兼容性和证据。

如需保持连续性，请在现有责任记录中保留所选路径、停止点和下一个尚未解决的结果。以达到所要求且有证据支持的结果为止。调查和规划不等于交付；未经现有授权，实现工作也不等于发布、合并或部署。

直接路由与辅助路由

明确提出的专家请求在适用时交由该专家处理。这些路由也可在操作手册中补充缺失的结果：

• 有界解释 → 相关的已安装主题专家；大量研究 → iwadi。
• 影响重大的前提 → 前提检查。
• 没有明确起点、没有满意方向或存在依赖性未知因素的宏大构想 → atona，用于探索并逐步梳理。它会针对尚未确定的人类选择使用 arojinle，针对需要经验的问题使用 adanwo；不要直接把不确定性转成实现任务。
• 尚未确定的目的、受益者、成功标准或影响重大的权衡，隐藏需求的解决方案式请求，潜在的依赖性选择，或用户要求进行访谈 → arojinle。对于已经理解清楚的有界选择，直接提出单个问题；复用完整简报，不要凭空构造决策树。
• 适用性尚未确定且会实质影响领域身份、生命周期、政策、所有权或不变量的事项 → amose，即使相关术语很熟悉也一样。复用当前适用的领域证据。
• 技术结构尚未明确，或尚未确认某个影响重大的机制是否适合已确认的目的、领域或质量驱动因素 → architect；尚未明确的可观察行为 → atona 的行为契约模式。如果两项结果都未明确，则两者都使用；若当前设计证据已足够，则予以复用，不要自动重新设计。
• 独立代码评审 → atunwo；基于测量的工程比较 → alaga；指令或模型比较 → 技能评估操作手册，并使用项目的评估流程。若要通过一次性原型确定交互、API 或技术选择 → adanwo，在交付前将证据交还给负责决策的所有者。
• 经授权的发布 → 使用发布模式的 seda-pr。就绪、发布、批准和合并是彼此不同的事项。
• 面向 Agent、用于引导选择、决策、权限、执行或完成的文本 → 使用 Agent 文本分支的 oro。
• 面向人类、用于理解、行动或沟通的文本 → 使用人类文本分支的 oro。
• 能力就绪情况 → 交由适用的项目或宿主所有者处理；在语义所有者处保留证据和权限边界。
• 查明发生了什么、恢复成本、反复出现的阻碍，或证据值得支持哪项持久改进 → ayewo-igba-ise。如果还要求补救，则先完成判断，再由相应所有者落实合理的修正，并更新受影响的证明。
• 应用已确立的经验 → 代码使用 alaga，指令使用 oro，符合条件的持久项目知识使用 amose。复用更有力的现有记录；任务完成后不一定需要新增经验记录或复盘。

如果失去不显而易见的推理会导致问题再次发生或需要大量重新探索，就应保留这些推理；日常任务完成后不必新增学习材料。

没有适用的操作手册时

检查已安装的所有者，找出缺失结果的负责人，并组合出足以满足需求的最小路径。当一项工作需要梳理并逐步推进多个结果时，使用 atona；有界结果则直接交由其负责人处理。只有在同一计划中存在真实的依赖边界时，才组合多个操作手册。仅仅不熟悉某事并不意味着需要制定计划，临时拟定的路径也不意味着需要新增永久操作手册。

项目指令和适用的项目本地操作手册可在现有权限范围内细化路径。确认它们的实际来源和适用性；不要再加载第二份详尽目录。如果没有已安装的技能能带来价值，就使用宿主或项目的常规能力。若缺少必需的能力，应如实说明，而不要声称已调用该能力。此技能中的选择不会配置宿主自动加载 Alárinà。

移交

当需要协调多个由不同方独立负责的结果时，将后续推进交给相应的工作流负责人，并使用宿主原生协作控件分配有价值的独立任务。当只需一个结果时，直接调用相应负责人。按照所选工作流完成其要求的结果，不要另行维护相互竞争的计划或任务清单。

针对所选结果，考虑已安装的语言、框架、设计、浏览器、研究和制品能力，判断哪些能力的专长能显著提升执行质量或证明力度。阅读所选技能以及仅适用的辅助参考。除非其输出成为独立的必要结果，否则辅助能力应从属于当前负责人。路由本身不会授予编辑、发布、合并、删除、安装或其他权限。

根据问题选择证据能力，再进行派发：源代码形态、符号身份、运行时或测量语义可能需要项目或宿主能力。向负责人提供所需证据和重要的覆盖范围限制；判断权仍归负责人。普通读取和足够的原生命令应直接使用。

提供请求的结果和停止点、已接受的决策、范围和现有权限、确切的候选项／工作区或源定位信息、当前证据及缺口，以及下一位接收者。只提供会影响接收者工作的内容；若对话或现有制品已足够，就沿用它们，而不要默认创建移交文档。

如果调用来自某个工作流，则将负责的结果及其证明返回给调用方，由调用方继续推进。独立任务只继续处理请求要求且已授权的下游结果。实现结果已完成本身并不授权发布；返回阻碍事项也不算完成。

对于 atunwo，提供评审对象、已知证据以及请求的决策或关注重点。除非用户指定深度，否则由 atunwo 决定轻量或深入评审；重构或简化请求不会因此产生另一种评审模式。

协调与整合

当委派工作能显著改善结果时，请阅读协调。当模型、工作量、工作者生命周期或提供方原生设置很重要时，也请阅读宿主策略。这些参考用于指导任务分配和证据，不会取代已安装技能的方法或宿主原生机制。

默认情况下，将紧密相关的工作留在主线程中。在考虑说明、验证和整合的成本后，若并行执行、独立上下文或独立审查能显著改善结果，再进行委派。使用原生协作控件；模型和推理方式仍由用户及其宿主策略决定。

保持必要评审的独立性，并且只接受基于已检查证据得出的结果。任务分配、写入权限归属和整合机制由协调参考负责。

验证并完成

对于执行请求，测试实际变更的边界，并完成所选负责人的必要检查。区分文件有效性、安装、发现、运行时行为和用户可见的成功。解决范围内的失败；只有新证据或未解决的问题表明有必要时，才扩大或重复验证。

请求的结果、必要的整合和验收证明全部完成后即可结束。当用户要求完成工作时，计划或专家移交只是中间步骤。返回结果及其位置、决定性证据、实际交付状态和重要限制。若受阻，指出尚未满足的要求以及恢复工作所需的输入或操作；部分工作不算完成。

返回路由建议

当用户询问该使用什么时，返回起始负责人、决定性原因，以及仅能实质性明确路径的后续条件门槛。只有当边界确实模糊时，才指出最有可能的替代方案。

当用户要求实际执行工作时，调用起始负责人，并按照上述操作指南完成所请求的工作。