pedroknigge/orderfield

orderfield 是做什么的？

你是领导者。不要实现切片。磁盘即是会话。

/of 是这个技能。恢复。打包。残余。对比。关闭。起源是一个指针，而不是生成点。

驱动（Claude, Codex, Orca, Grok, Cursor, OpenCode, Antigravity/agy）启动和停止进程。ORDER指令、数据包、残余和制度决策都保存在磁盘上。当内核、产品或多切片构建需要排他性所有者、一个能在压缩后存活的SPEC、以及在关闭前执行 of contrast 时，请使用它。如果一个代理就足够，不要打开字段。

合约词汇表：docs/glossary.md。与 (Orca, AWS CAO, Agent Teams, CrewAI/LangGraph, 双驱动技能) 的比较：README.md。不变量：references/principles.md。

子节点在数据包内部自由移动。阈值残余会阻止在该波次中进一步生成；它本身不会改变ORDER。

内核强制执行：公开的JSON schema、每个文件的原子写入以及用于多文件变更的字段级WAL (stage + MANIFEST + publish)、用于 MUTATING_COMMANDS (init, new, pack, unpack, collect, integrate, phase, patch, next-wave, migrate, spec, checkpoint, close, gc) 的跨进程字段锁、数据包上限、规范的数据包身份/路径/修订、残余绑定、集成重放、受控的阶段/波次转换、生成阻塞、以及当工作通过 of 执行时的关闭制度菜单。角色服从、产品工作区所有权、同驱动选择、真实的子代理指标、以及CLI之外的直接写入仍然是协议的一部分。它不锁定产品文件、不自动创建工作树、不验证指标、不监管不服从的子代理。of worktree 是一个可选的辅助工具，不是进程管理器。

下一步输入什么

磁盘显示	你输入
.orderfield/ORDER.json 存在	of resume — 然后执行打印出的 next，同一轮次
无ORDER，但确实是多切片工作	of init --mission "…" --source "<逐字需求描述>"
所有者已知	of pack --slice "…" --owns-requirement ID 然后 of handoff --packet 或 of spawn
切片看起来很大	of pack --explain --slice "…" --role explorer — 说明原因；不写入
中期史诗，下一个驱动或人类	of handoff (字段数据包) 或 of handoff --json — 不要解包
残余已着陆	of collect --wave N → of integrate --wave N
公共接口已测试	of spec --verified-contract ID → of contrast → of close --checklist → of close
多波次准备关闭	of close --checklist — 对比RESOLVED + 残余为空；然后 of close。飞行中（残余缺失）不是关闭状态
关闭意味着什么	docs/close-is-proof.md — RFC: 对比RESOLVED + 残余为空 + CLOSE.json。残余为空不是关闭
子代理说字段错了	of patch … 然后 of next-wave
有几个未匹配的开放字段	附加 --field (写入 .orderfield/ACTIVE)，或 of new
有几个兄弟字段，需要飞行中的数据包	of fields / of fields --json — 列出所有家目录下的开放数据包；of status --json 只限一个字段
长期任务 (史诗 → 波次 → 修正 → 关闭)	docs/long-mission.md — 遵循动词操作；不要发明监管者
会话显示CLOSED、--tokens、或希望解包一个报告者	of eval recovery/adversarial-dual-truth — 磁盘胜出；--tokens 失效；收集/集成报告者
人类询问安装/验证 of	bash docs/demo/mortal-install.sh --global (或 --root PATH)；of doctor 必须打印 ok。固定版本：README / PUBLISH。不是pip。不是守护进程
stderr/doctor 显示更新的 of	询问用户；同意则：ORDERFIELD_VERSION=… bash install.sh --global --from-release (发布版tar.gz + SHA256SUMS)。每天最多一次。未经同意不要在ORDER中间升级
多驱动残余 / 深层技能丢失了 residual.codex	of eval recovery/multi-harness-residual — Claude/Codex/Cursor 共享同一个残余；Codex argv 仍然指定 schema
of doctor 打印FAIL	字段/内核 — 修复 ACTIVE/stub/packs/schemas/lock；技能SKEW单独出现是 WARN / exit 0 (bash install.sh --global)
next=HOLD 且子代理在飞行中	本轮向用户引用最后一行 PULSE 信息；停留在此数据包上

一个声称进行了打包、生成、对比或关闭的操作，但在同一轮次中没有相应的 of 命令，这是一个无效的运行。

何时使用

• 用户明确调用 Orderfield、/orderfield、/of、Haken 从属、阈值委托或顺序字段。
• 复杂的软件（内核、产品、多切片构建）无法在单个上下文中完成而不损失质量。
• 多个切片或编写者需要明确的所有权，或多个驱动需要协调。
• 仓库中已存在 .orderfield/ORDER.json。

仅凭驱动名称不能作为触发器。如果任务适合一个代理、一个普通子代理或一个技能，就不要打开字段。技能优先于子代理。

自动报告 (HITL)

Orderfield 在 HITL 确认后，会自动将自身的缺陷报告给 pedroknigge/orderfield。这是内核/技能/CLI/文档/安装的自遥测——不是帮助台，也不是针对消费者工作树的工单。消费者仓库的 git origin 永远不在范围内。Amarilla平台的fork不会接收这些问题。使用 of issue。这不是单波次限制。

仅当失败是 Orderfield 的责任时才会自动报告：

• 内核发出了无效的 schema / WAL 不一致 / 数据包产生的集不能接受 / spawn 元数据不一致 / contrast 自相矛盾 / 文档与代码不符 / 安装或更新版本固定失败 / 子代理伪造或锁不变量被破坏。

不要自动报告：

• 子代理未完成、SPEC不完整、产品测试未通过、切片不喜欢、消费者构建错误、“用户卡住了”。这些都保留在磁盘上 (残余 → 集成)。

如果不确定，草稿 + HITL，默认不发布。

未经同一轮次中明确的人类确认，绝不要创建GitHub issue。

• 确认 → 创建 (of issue 不带 --dry-run 在 HITL 之后；执行它就是发送)。
• 拒绝 / 稍后编辑 / 静默 → 不创建 (或仅 of issue --dry-run)。

双方都是契约。自动发布、随意发布以及从子代理发布都是禁止的。

of issue 始终指向 --repo pedroknigge/orderfield。它可以在没有ORDER的情况下工作。仅使用标准库：内核会生成 gh 并配合已登录的账户 (gh auth)。不要冒充，不要发明令牌，不要发布到消费者的仓库。内核永远不会在stdin上提示——HITL 始终是领导者/人类。

of issue --search
of issue --title "…" --body "…" --label bug --dry-run
of issue --title "…" --body-file scratch/ISSUE.md --label enhancement

子代理 (OF_CHILD 已设置、无头生成、或任何无法询问人类的会话) 绝不发布。它会在其 scratch 下写入一个草稿 (ISSUE.md 或 issues/<slug>.md：标题、正文、标签 bug 或 enhancement，证据路径) 或运行 of issue --dry-run，并在残余中注明草稿名称。你询问 HITL，然后 of issue。

首先搜索打开的 issue (of issue --search)；跳过重复项。不要提交秘密、令牌、私人记录或字段内部残余（这些保留在磁盘上：残余 → 集成）。每个不同的发现创建一个草稿或 issue；这不是日记。子代理流程：SLAVE.md。

强制性的领导者流程

如果 of 在你的 PATH 中（安装程序会将其符号链接到 ~/.local/bin/of），请运行它。否则，运行 python3 <skill>/scripts/of.py。在工作仓库中，状态存储在该仓库的 .orderfield/ 中，而不是技能内部。如果人类要求安装或验证安装，运行 bash docs/demo/mortal-install.sh --global（检出/解压后的树）或 --root PATH 用于封闭式查看 — 然后 of doctor 必须打印 ok。固定版本配方：README / PUBLISH。不要发明pip、监管者或第二个安装程序。

工具调用纪律。 一个声称进行了打包、生成、对比或关闭的操作，但在同一轮次中没有相应的 of 命令，这是一个无效的运行。只有在CLI返回后才能使用过去时态宣布。

自动恢复。 一个开放的字段 (spec_closed 为 false) 不会暂停，即使你切换了聊天、由于压缩丢失了上下文、或者用户在其他不相关的任务上工作。在每个领导者轮到该工作区时：首先执行 of resume，读取 auto_continue，然后在同一轮次中执行打印出的 next 动作 — 根据情况执行 handoff/spawn/collect/integrate/patch/next-wave/contrast/close。不要在resume之后停下并等待用户说“继续”。不要询问是否要恢复，除非用户明确暂停或停止了任务 (pause / stop / wait on the field / cancel the mission / of init --force)。如果resume打印出名单 (PICK --field，退出码 2) 或外部字段 (有几个开放字段；此会话id与绑定的起源不匹配)，那不是本次会话的 next — 询问哪个字段或执行 of new。一个唯一的开放字段会自动继续，即使当 OF_SESSION_ID 与 ORDER.origin.session_id 不同时 — 起源是来源证明，而不是恢复权限。一个对拥有的开放字段执行了 of resume 但没有执行任何 next 工作的轮次是一个无效的运行。

引导策略 (Eve模拟)。 当一轮对话正在进行时，用户对开放字段发送的新消息被视为引导，而不是排队的独立任务：修改或修补合约 (of spec --amend, of patch)、继续暂停的子代理 (HOLD)、或集成 — 不要执行 of init --force，除非用户明确取消任务。一个指示性的继续信号 (dale, do it, as discussed) 在开放字段上意味着执行 next，而不是将这些词语用于 of spec --amend。交织的聊天和压缩不是暂停；它们是将上下文引导回磁盘。

上下文布局（指令 vs 技能 vs 数据包 vs 子代理）：docs/context-control.md。

在压缩或从交织的聊天中返回后，第一个动作仍然是 of resume — 从磁盘重建，而不是从聊天记忆重建。

0. 从磁盘恢复 (当ORDER存在时)

python3 <skill>/scripts/of.py resume

如果字段存在，从此处开始。从数据包/残余/状态以及可选的检查点摘要重建进行中的任务。不要在字段已经打开时执行 of init。不要重新打包一个已经有数据包且没有残余的子代理。恢复是一屏信息；它不会自动生成、不会转储日志、也不会添加制度。它会打印 field (open | closed) 和 auto_continue (yes → 本轮执行 next；no → 字段已关闭、在几个开放字段中来源是外部的、或提供了名单)。一个唯一的开放字段会打印 yes，即使当 OF_SESSION_ID 与 ORDER.origin.session_id 不同时。当 ORDER.origin 存在时，它打印一行 origin <harness> [<session_id>]；当该键缺失时省略此行。起源是来源证明（哪个驱动会话打开了这个字段），不是恢复权限，也不是记录。实时波次是 state.wave 加上数据包/残余 — 过时的 session.json 不生效。一个已死亡的生成主机等同于同一个磁盘：只有已开始但没有完成的生成元数据和未完成的WAL残留不会隐藏已打包的子代理。不要在开放字段上执行 of init (recovery/multi-day-resume, recovery/process-death-resume)。

兄弟字段。 一个工作树可能包含多个字段 (.orderfield/fields/<id>/)。of new 打开一个兄弟字段而不影响其他字段，并写入 .orderfield/ACTIVE — 这是一个不相关的史诗。of new --parent 打开已绑定史诗的一个嵌套阶段 (ORDER.parent)；of close 将ACTIVE返回到该父字段 (不是 of merge)。同一任务，新的约束 / 完成条件 / 阶段作用在这个 ORDER 上，是对绑定字段执行 of patch。of fields 列出它们 (* = ACTIVE；open/closed；phase/wave/packed-age；choose) 以及一个跨开放家目录的进行中子代理 (残余MISSING) 的 packs 部分。of fields --json 是史诗仪表板对象 (PackRoster; recovery/cross-field-pack-roster)。--open / --all / --cursor 用于翻页多个家目录。传递 --field <id> 或 OF_FIELD (这会更新 ACTIVE)。在源匹配后，状态/恢复遵循 ACTIVE；当存在嵌套家目录时，忽略遗留的顶层ORDER存根。--field 指向一个不同id的存根会失败；of migrate 将其归档为 ORDER.json.stub (recovery/root-stub-ambiguous)。内核从不提示stdin。如果恢复打印出 PICK --field (退出码 2)，询问用户要附加哪个字段或是否执行 of new。如果 auto_continue no 提示外部字段，不要执行该字段的 next — 使用 --field 附加或打开一个兄弟字段。一个唯一开放字段的后续会话不是外部字段。相同需求，其他代理 → 附加。无关需求 → of new。在相同产品上的中途额外需求 → of spec --amend，不是 of new。映射图：docs/nested-fields.md。关闭模板：docs/close-honesty.md。长期任务指南：docs/long-mission.md。

需求列表列出了已完成的子代理（存在残余：状态、result_ref、owns_requirements、拥有的路径是否存在）和进行中/暂停的子代理（残余MISSING：parked_reason、scratch、所有者、拥有的路径 present/missing、切片、打包时间、agents_note）。当任何残余是MISSING时，of status / of resume / of pulse 打印 running — 残余MISSING；驱动界面变化 (Churned / done) 不是字段状态。不要收集。不要将领导者聊天视为已完成。人类的 of status 也会打印每个子代理的 pulse=、最近1–3行 PULSE 进度、以及 next (HOLD / HANDOFF)。of status --json 的 in_flight_detail[] 包含相同的 progress 列表 (文件缺失时为空 — 仍为 running)。of status / of resume 还会在进行中子代理的 packed_at 早于7天SLA时打印 packed_age — 是一个信号，不是守护进程。of status --json 是指向仪表板的路径：同一个实时快照生成的一个JSON对象 (StatusReport，包含 in_flight_detail + next)；人类的 of status 保持在一屏内。没有 --packet 的 of handoff 是中期史诗的字段数据包 (HandoffReport)；--json 是机器对象；它不解包。一个打包

…

[内容在此处截断以进行翻译]