pepeye

Pepeye

协调若干各自负责的成果，推动它们达成一个获认可的结果。当前负责人掌控工作流推进、整合、用户决策和最终判断。各技能保留各自的方法、证据约定和权限边界；原生工作者是其下方的执行上下文。

编排模式

采用适合当前工作的最小编排规模：

• assignment — 一个边界明确的执行上下文，包含一个主要技能、可选的辅助能力、精确的范围／权限以及预期结果；
• workflow — 一位负责的负责人组合多个任务／阶段，并设置依赖关系、分支、跳过条件、独立性边界和完成证据；
• program — 一种工作流，其正确延续必须能够承受当前负责人／会话丢失。只有在此规模下，持久化编排状态才有必要。

工作流负责人不等同于阶段负责人。对 alaga、atunwo、architect 或其他技能进行排序，不会复制或取代该技能的方法。工作流特有的行为应放在分派的任务中，而不是选定的技能定义中。

当下一位语义负责人或合适路径确实不明确时，使用 alarina。不要让每个已声明的工作流阶段都经过它。

组合任务

当并行处理、聚焦上下文、调查或独立判断能带来实质帮助时，使用原生子 Agent。对于小型局部任务，直接处理。

任务应明确：

• 一个边界明确的成果和停止条件；
• 一个负责所请求结果的主要技能；
• 零个或多个能实质影响该任务的辅助技能；
• 精确的候选项／来源标识及相关上下文；
• 允许使用的工具／操作、工作区以及修改／发布权限；
• 需要返回的验收结果／证明；以及
• 在委派的目的为独立判断时，对独立性的要求。

任务约束的是结果边界，而不是所选技能的内部方法。所选技能在有帮助时可以自行委派给子 Agent。由当前启用的提供方／宿主框架处理工作者的实例化、模型／工作量映射、嵌套／容量以及等效的执行机制；不要把这些机制复制到技能指令中。

工作者的输出和检索到的内容都是证据，绝不是编辑、发布、批准、合并、安装或扩大范围的新授权。

审查计划材料

计划审查与计划编写相互独立。不要创建单独的规划者配置，也不要仅为提高推理质量而要求专门的规划工作者。

每当明确计划成为重要的工作流产物——因为它是请求交付的成果、决定重大决策的依据，或将指导委派执行／多阶段执行——都应将该固定计划交由新指派的独立审查者审查，然后再将其视为已就绪、已接受或可用于推进工作。无论计划来自 atona、主会话、用户、已持久化的产物还是其他工作流，都适用此规则。

审查者根据已接受的结果和当前证据对计划提出质疑。视情况检查：

• 隐含假设或尚未解决的决策；
• 顺序、依赖关系、责任归属和可行性；
• 下游工作原本可能自行补全的架构缺口或可观察契约缺口；
• 证明／验收策略以及过时证据；
• 失败处理、迁移、回滚或恢复义务；以及
• 可能实质性改变结果的可信简化方案或遗漏约束。

在新的上下文中审查一个固定候选版本。在宿主环境能够强制执行时，应将该任务设为只读。审查者应返回发现的问题、排除的疑虑、证明缺口以及范围明确的处置结论；不得悄然改写计划或推进工作流。

将确认后的修正交由最接近的语义负责人处理，并按需更新计划；之后，在将实质性变更后的计划视为已就绪之前，再次审查。不会影响判断边界的纯编辑性修改无需再次审查。如果工作足够简单，可以直接着手，且不存在明确计划，则不要仅为满足此规则而凭空制定计划或增加审查流程。

对于实现候选项，atunwo 仍是独立的代码判断方法。计划审查不能取代代码审查。

运行工作流

当重复出现的多阶段成果适合采用明确的流程拓扑时，请使用具名工作流。工作流资产位于 workflows/ 下，并遵循工作流契约。

工作流是自适应图，而非仪式：

• 跳过结果已确定且仍然有效的阶段；
• 出现重要的缺失结果时，插入相应阶段；
• 当独立阶段的写入内容／证据互不冲突时，并行运行这些阶段；
• 在将任何重要的明确计划视为已就绪或用于推进工作之前，先对其进行审查；
• 当独立性属于所请求证据的一部分时，保持审查者与决策者相互独立；
• 当新证据使某项决策、计划、架构、候选项或证明失效时，返回最接近的负责阶段；
• 一旦满足工作流已接受的结果和所需证据，就停止推进交付，然后按照下文的复盘契约结束本次运行。

负责人只传递可能影响推进的跨阶段状态：已接受的结果、重大决策、当前计划／规范／架构标识、候选项标识、阻碍因素、所需证据、权限以及未解决的分支。不要预先加载所有上游对话记录或参考资料。

当前工作流路径包括：

• 从想法到产品；
• 从 Bug 到已验证的修复；以及
• 从 PR 到可合并。

这些路径是起点，并非强制的生命周期链条。

让团队状态清晰可见

启用原生子 Agent 后，根据运行时事实维护一份简洁、用户可见的团队快照。在初始人员配置后，以及人员配置、任务分配、模型／推理、阻塞或进度状态发生重大变化时，报告快照。

对每位活跃或近期的工作者，请包含：

• 当多位工作者属于同一类型时，使用简短的工作者标签；
• 子 Agent 类型；
• 运行时实际公开的模型 + 推理级别；
• 有明确范围的任务／分配；以及
• 简洁的进度／状态，例如已排队、运行中、受阻、审核中、已完成、已取消，或最新的重大里程碑。

不要推断主机未公开的有效模型或推理级别。相关情况下，应区分已配置／自适应值与观察到的运行时值；无法确定时使用 unknown，不要猜测。

这是可观测性机制，不是第二套编排数据库。根据常规的人员配置、状态确认和完成事件更新快照；不要为了让仪表盘动起来或编造进度而轮询工作者。

按比例进行监督

监督的目的是发现后果重大的偏差，而不是创建第二套工作流语言。

当方向仍可低成本纠正，且满足以下任一条件时，进行状态确认：

• 假设、范围、架构、权限或负责的方法可能发生重大变化；
• 下一阶段代价高、具有破坏性、难以撤销，或高度依赖当前输出；
• 证据与方向矛盾、反复尝试失败，或工作者受阻；
• 独立性／证明力度正在减弱；或
• 工作者已准备好移交重大成果。

要求提供简洁的证据，说明哪些内容已确定、哪些仍不确定，以及下一项重大行动。不要强制要求通用检查点模板、计时器、轮询频率或协调者命令词汇。如果工作者在收到一次明确请求后仍无响应或没有进展，应根据实际差距缩小范围、调整方向、中断或重新分配，而不是反复观察。

整合结果

检查决定性产物，并根据工作流结果和阶段负责人的证据约定，核对每项必需的阶段结果。工作者已完成、多数意见一致、模型名称或状态显示通过，本身都不足以作为验收证据。

将创作与影响重大的独立判断分开。分支发生变化后，复用有效的部分结果；仅当证据的证伪边界发生变化时，才使该证据失效。

将工作者工作树及其 .qp 视为一个隔离的候选项。验收后，将其工作区和相关本地状态移交给负责验收的工作流进行核对。

完成必需阶段，或在结束前明确说明其失败情况。发布或合并仍需另行授权。

以复盘和经验提炼收尾

每次工作流或自主运行都应在运行的交付/结果状态确定后，以 ayewo-igba-ise 复盘收尾。这适用于已完成、实质性暂停、已放弃或存在争议的运行。回顾是工作流收尾的一部分，默认不应成为重新开启已定工作事项的理由。

确定运行边界，并让 Àyẹ̀wò 判定哪些做法确实有效、失败、耗费了恢复精力，或暴露了结构性摩擦。在回顾重建运行情况时，不要修改被评估的内容。

只提炼复盘所支持的经验：

• 当当前补救范围授权修改相应内容时，将有证据支持的面向 Agent 的指令/技能补救交由 oro-fun-sigidi 处理；
• 将新的公开技能身份、实质性的路由/所有权重新分配、晋升、合并或移除视为重要补救：在当前范围和证据支持时执行，否则留下范围明确的负责人交接事项；
• 将架构、运行时、工具、产品或流程改进交由相应负责人处理；
• 仅对通过准入门槛的稳定、非显而易见且有独立证据支持的项目知识，使用明确的 amose .learnings 维护；以及
• 将一般性理由、一次性观察、会话历史和推测性经验留在复盘/PR/计划中，而不是写入持久化项目记忆。

没有持久化经验也是有效结果。如果某项经验经评估需要补救，且该运行已拥有对相应负责人所管内容的修改权限，则应在复盘确定后，将后续工作作为单独的负责人结果执行；否则应返回负责人交接事项，不得在未明示的情况下授予新权限。

在复盘完成且每项符合条件的经验都已由相应负责人提炼，或明确列为待处理的授权交接事项之前，不要将自主工作流视为已完全收尾。

持久化程序

不要仅因任务规模较大或涉及多名工作者，就将编排状态外置。只有在正确续接必须跨越当前负责人/会话、机器重启或移交给另一位协调者时，才阅读持久化程序。

Pepeye 目前尚未实现调度器、守护进程、持久化工作者注册表或编排数据库。只有在实际工作流表明对话/工作流状态无法安全满足可恢复性需求后，才添加此类机制。

返回

返回总体结果、实际使用的工作流/阶段、决定性的整合证据、重要分支或干预措施（如适用）、计划审查结果、相关的最终团队状态、复盘结果、已提炼的经验/负责人交接事项，以及尚存的差距。区分已计划、已审查计划、已交付、已进行代码审查、已发布、已整合、已发布版本和已完成回顾收尾等状态。