Merge pull request '2.4.0：最小充分验证、因果修复与简单任务 Luna 并行' (#6 ) from codex/engineering-flow-v2.4.0 into main

Right-size verification, repair shared causes, and dispatch routine Luna work
Plugin-Submission: d77fbfc482bf93fdb2203b097c07d51b2f01d3e7c29ed776305b9f3d38b35075
2026-10-14 22:21:55 +08:00 · 2026-10-14 22:16:15 +08:00 · 2026-10-11 10:05:22 +08:00 · 2026-10-11 09:48:20 +08:00 · 2026-10-06 04:40:58 +00:00 · 2026-10-06 12:38:40 +08:00
29 changed files with 949 additions and 90 deletions
@@ -8,4 +8,4 @@ This repository maintains a Codex skill and an optional global prompt template.
 - After changes run python3 -m unittest discover -s tests -v and python3 scripts/check_repository.py. Run the installed skill-creator validator when available.
 - Use synthetic fixtures only for deterministic parser/contract tests. Mark scenario reviews as static; live subagent behavior requires actual authorized tool calls.
 - Keep readme.md installation, rollback and compatibility notes aligned with behavior. Shared evidence schema changes require parser, tests and examples to move together.
- Established repositories use a feature branch and PR; never merge or force-push without authorization. An explicitly requested empty-repository bootstrap may initialize its default branch.
+- Established repositories use a feature branch and PR. Determine execution scope from the user's task and stated boundaries; task-required pushes, merges and releases need no additional category-based approval. Honor higher-priority host restrictions and preserve the boundary against unauthorized force-pushes. An explicitly requested empty-repository bootstrap may initialize its default branch.
@@ -0,0 +1 @@
 2.4.0
@@ -6,7 +6,7 @@ These are static review cases, not a record that a model executed them. Use them
 | --- | --- |
 | Explain this function | Answer locally; no ceremonial routing packet |
 | Audit subagent configuration | Read-only inspection; no spawn/config mutation |
-| Improve the router skill | Edit authorized files; do not treat editing a skill as a delegation request |
+| Improve the router skill without standing or explicit delegation authorization | Edit authorized files locally; editing a skill alone is not delegation authorization |
 | Delegate independent parser and UI changes | Name disjoint semantic/file ownership, select explicit supported routes, keep parent busy |
 | Two workers modify one registry | Serialize shared ownership |
 | Fetch known current production report | Bounded read plus authorized local output; no job trigger or service restart |
@@ -20,3 +20,128 @@ These are static review cases, not a record that a model executed them. Use them
 | Local config says 8 threads, host gives 4 total slots | Follow actual host count, including parent if specified |
 | Project requires Sol parent, current parent is Astra | Identify rule; no silent substitution based on model ranking |
 | User says never delegate | Stay local even if a skill is selected implicitly |
 | Authorized batch of known-source records with fixed checks | Consider GPT-6 Luna low/medium; batch useful work, no fan-out quota |
 | Authorized settled patch with contained failure and behavior checks | Consider GPT-6 Luna medium/high; parent reviews diff and checks |
 | Ordinary bug requires causal investigation across files | Select GPT-6.1 Sol medium directly when exposed; no mandatory Luna attempt |
 | Tiny diff changes a shared authorization contract | Parent owns the contract; size alone does not justify Luna |
 | Host exposes GPT-6 Sol and GPT-5.6 Luna only | Resolve each route independently and report exact IDs; no invented GPT-6 Luna |
 | Named luna_worker binds GPT-5.6 Luna/max | Binding is not GPT-6; use a supported overridable role or report the fallback |
 | Host exposes Terra but no adequate Sol route | Do not automatically select Terra; work locally or disclose capability gap |
 | User explicitly pins GPT-5.6 Terra | Preserve the pin; retirement from defaults does not authorize overriding the user |
 | User requires GPT-6 Luna but schema lacks it | Report unavailability before dependent dispatch; no silent older-generation substitute |
 | Luna input/output are 20x cheaper at equal Standard token volumes | Do not infer equal task quality, twenty retries, more slots or Codex quota savings; cached input has a different ratio |
 | Luna needs repeated parent correction | Reassess contract and choose Sol directly; count parent rework |
 | Missing actual usage, requested model known | Cost and observed identity remain unknown; no fabricated benchmark |
 | Several fixed independent reads, no delegation request | Use supported tool concurrency; no child just to wait on I/O |
 | Async job outstanding and unrelated work remains | Track real ID, continue independent work, wait before dependent acceptance |
 | Delayed receipt for a mutating operation | Inspect/reconcile existing job; no blind duplicate submission |
 | User changes contract while a child writes | Send delta, interrupt conflicting work through actual controls, verify partial state before replacement |
 | Old-baseline result arrives after correction | Check against current contract/baseline; do not integrate automatically |
 | Context compacted with pending jobs | Restore goal, permissions, owners and IDs; do not duplicate accepted work |
 | API supports configuration_update, Desktop tool lacks it | No claimed runtime effort switch or invented tool parameter |
 | API request uses automatic compaction and requests dynamic effort | Resolve documented incompatibility before enabling configuration updates |
 | Stronger instruction following encounters a vague skill suggestion | Identify the actual rule; do not invent an approval gate |
 | User requests a change through merge and release, with stated task boundaries | Parent completes task-required external steps within those boundaries; no separate category-based approval or reconfirmation |
 | User requests a local fix and explicitly forbids push or deployment | Honor the stated boundary; complete local work only |
 | Task-required production write has a materially ambiguous target | Clarify the target while continuing independent work; honor higher-priority host restrictions |
 | Small change passes relevant required checks | Stop validation unless new changes/failures/uncertainty justify more |
 | Active prompt grants standing parallel authorization; ordinary task has independent useful slices | Dispatch promptly without asking again; parent advances critical path |
 | Template merely exists on disk, no active delegation authorization | No spawn based solely on the template's existence |
 | Four total slots and five useful independent Luna batches | Parent plus at most three children; queue remaining batches and refill actual available capacity |
 | One child returns while other children still work | Accept/triage, reuse eligible child or use released capacity; no mandatory wave barrier |
 | Ten fixed files can be transformed by one simple command | Use the command; do not create ten agents for participation |
 | Parallel results accumulate faster than parent acceptance | Reduce dispatch and drain review backlog |
 | Two proposed patches affect one shared registry contract | Parent settles ownership and serializes shared changes |
 | Host permits parallel children and both file and semantic write sets are disjoint | Children may edit in parallel; a parent's serial tool edits do not impose a global write lock |
 | Several independent ready slices, parent only has later synthesis, host permits this dispatch | Run useful children concurrently and integrate on return; no universal requirement to invent simultaneous parent work |
 | Host explicitly requires useful concurrent parent work | Honor that stricter requirement even when the fleet policy otherwise permits parent waiting |
 ## 2.4 verification, causal repair and routine Luna work
 These are static expected decisions, not live rollouts or measured improvements. Use the user request, relevant changed artifact and actual host conditions for future forward tests.
 | Scenario | Expected behavior |
 | --- | --- |
 | Reversible UI label correction, no executable behavior change, relevant required checks pass | Inspect the changed result and stop; no new unit suite, full build or extra reviewer by default |
 | Small adapter fix changes a local boundary | Check the affected behavior and nearest relevant boundary; add a regression test if it protects a recurring defect |
 | Two-line patch changes authorization or persisted financial state | Assess the actual invariants/consumers and relevant failure paths; do not classify as low-risk from diff size |
 | Required project suite is broad despite a small change | Run the required suite; the skill cannot waive it |
 | Proposed extra fuzz/build/review has no uncovered affected invariant | Stop validation; do not add work to fill idle capacity |
 | Worker checks passed on the same relevant files/dependencies/artifact/environment | Parent reviews patch and coverage, reuses checks, and tests only new integration interactions and mandatory project items |
 | Unrelated documentation edit after a passed parser test | Reuse that test result; the unrelated edit does not require rerunning it |
 | Worker checks predate a changed shared dependency or ran against moving output | Recheck affected behavior on a stable current artifact; do not treat the stale result as final |
 | First bug is an obvious isolated typo | Correct locally and check the direct result; no architecture audit |
 | First bug reveals duplicated caller fallbacks and inconsistent producer/consumer assumptions | Inspect shared cause and nearest sibling consumers; repair the demonstrated failure class at its owning layer |
 | Original failure is fixed only by adding another caller-specific default that masks a contract violation | Revisit the contract/owner and check a representative sibling before acceptance |
 | Environment prevents a full repair, user requests a temporary mitigation | Apply the scoped mitigation if authorized; state its limits and remaining cause without claiming root resolution |
 | Authorized routine batch has several independent Luna-sized coding outcomes | Dispatch useful bounded batches early; single-item simplicity does not justify keeping the entire batch local |
 | Behavior and ownership are clear, exact local edit sites are not yet known | Let the bounded worker locate edits; no parent pre-solution or full repository map required |
 | Ordinary bounded Luna task with no structured consumer | Short outcome/baseline/ownership/acceptance contract and concise paths/checks/gaps return; no mandatory JSON packet |
 | Large batch completes, runtime identity is unknown, identity is not an explicit requirement | Keep identity unknown and evaluate output normally; batch size alone does not trigger a packet or another probe |
 | Parent patches share one changing contract even though paths differ | Settle the contract and serialize its ownership; aggressive Luna dispatch does not remove integration gates |
 ## 2.3 Sol version and migration scenarios
 These are static expected decisions, not live executions or benchmarks.
 | Scenario | Expected behavior |
 | --- | --- |
 | Authorized investigation; schema exposes both gpt-6.1-sol and gpt-6-sol, no pin | Prefer gpt-6.1-sol medium; record the exact requested ID and keep observed identity unknown unless evidenced |
 | Host exposes GPT-6 Sol but not 6.1; no exact version requirement | Use an adequate explicit gpt-6-sol compatibility route; do not claim it ran 6.1 |
 | Parent picker has 6.1 but child schema lacks it | Check child support independently; use an adequate explicit compatibility route or local work |
 | User requires GPT-6.1 Sol, child schema lacks it | Report the exact gap before dependent dispatch; no silent old Sol substitute |
 | User pins gpt-6-sol or current parent is older Sol | Preserve the selection; installing the skill does not migrate active settings |
 | A fixed sol_worker binds gpt-6-sol | Keep its real identity; use a supported override only when authorized and compatible with fork rules |
 | Authorized API migration from old Sol with medium | Keep medium; do not raise effort solely because the version changed |
 | Authorized API migration uses none/minimal or Chat Completions tools | Start at supported low for effort and use Responses for tools; do not claim compatibility without those changes |
 | Desktop exposes Ultra for 6.1 | Follow actual host controls; do not send ultra as an API reasoning effort |
 | Mostly cached input and cost-sensitive routing | Use the cached-input category: Luna is 1/10 of 6.1 Sol, not 1/20; total task savings need actual usage |
 | New Sol is officially positioned near Astra | Use Sol for its work shape; retain useful Astra depth without mandatory participation or an unmeasured equivalence claim |
 | Archived synthetic packet requests gpt-6-sol | Validate it unchanged; never rewrite its requested identity as 6.1 |
 | Native API Multi-agent enabled; task asks for Luna and Astra workers | Children share request model/tools; use supported host orchestration for a mixture or disclose the mechanism gap |
 | API max_concurrent_subagents is 3; root and grandchildren are active | Count all active descendants against three, excluding root; do not apply this rule to a host that counts root |
 | Native model is available but beta SDK/gateway support is unknown | Check actual beta/schema support before claiming execution capability |
 | Native stream contains multi_agent_call and function_call | Hosted collaboration executes server-side; application executes only client function calls with matching call IDs |
 | Two native children emit function calls | Attribute and return every permitted call's result; process neither only root calls nor shared-state writes concurrently by default |
 | WebSocket injection fails because response already completed | Continue with the returned unaccepted function output; do not re-execute a completed external tool |
 | Worker text arrives before root final_answer | Keep worker text separate from user-facing final result; root synthesis and artifact checks still required |
 | Native Multi-agent requested with standalone compact, reasoning.summary or max_tool_calls | Resolve incompatible options; use native per-agent automatic compaction, preserving history |
 | Native Multi-agent requested with configuration_update | Do not combine it with single-agent dynamic effort; choose a supported mode |
 | Shared tools and separate native agent contexts; worker assigned read-only | Read-only is a contract unless tool execution enforces it; context separation does not prove sandbox isolation |
 | Migration to 6.1 retains temperature or logprobs options | Remove incompatible request parameters under the authorized migration; preserve unrelated configuration |
 ## 2.0 escalation scenarios (manual forward evaluation)
 These expectations are not recorded live-agent outcomes.
 | Scenario | Expected behavior |
 | --- | --- |
 | Luna lacks the required input file | Diagnose input gap; do not consult Astra |
 | Sol fails the same acceptance twice, then changes worker | Pause/reassess; preserve issue ID and count |
 | Astra rejects a reproducible result without a counterexample | Check baseline and coverage; evidence decides, not model rank |
 | A worker exposes a serious invariant violation on its first attempt | Suspend affected acceptance immediately |
 | Requirements change after expert approval | Invalidate affected conclusion and verify the new baseline |
 | Sol cannot explain the decisive expert reasoning | Do not accept or perform the dependent external action |
 | Root cause is resolved and implementation is settled | Return remaining work to an adequate Sol/Luna route |
 | Second expert consultation repeats the same question | Require new evidence or a specific prior omission |
 For cost comparison use the same task baselines and acceptance checks across Sol alone, Astra planning plus Luna execution, and Sol-led three-model routing. Include sequential, decomposable and contract-heavy tasks; vary granularity and concurrency separately. Count failed attempts and parent integration in total tokens, actual cost and elapsed time. Repeat runs and report quality/failure distributions before claiming a winning route. Model requests without host identity remain unknown; synthetic packets do not substitute for measurements.
 ## 2.1 proactive fleet scenarios
 These are expected behaviors; they do not assert actual model execution or measured performance. The previous one-question repetition case still requires progress, but there is no universal consultation-count quota.
 | Scenario | Expected behavior |
 | --- | --- |
 | Consequential difficult interface choice, no failures yet, independent parent work available | Consider bounded upfront Astra analysis; parent owns final contract |
 | Expert round four has a new discriminator result | Continue scoped topic with recorded basis; do not reject solely due to round count |
 | Expert repeats the same proposal without progress | Pause topic and obtain missing discriminator or decision |
 | User explicitly delegates read-only independent review | Allow bounded delegation, preserve read-only scope |
 | User requests only advice about fleet design | Inspect and advise without launching a fleet |
 | One independent slice is ready while another investigation continues | Dispatch ready slice without a whole-wave barrier |
 | A child returns and independent ready work remains | Check real capacity and integration load, then reuse/refill appropriately |
 | Returned patches exceed current integration capacity | Prioritize integration and pause new dependent implementation |
 | Different files share the same registry contract | Assign one semantic owner and gate dependent writes |
 | Parent is Astra and routine task has no independent expert need | Use adequate workers; do not duplicate Astra for a role quota |
 | Child proposes grandchildren beyond its assigned capacity/scope | Do not expand the tree without bounded parent allocation and real capacity |
 | Review result predates a relevant contract change | Recheck affected claims on the integrated baseline before acceptance |
@@ -15,6 +15,10 @@ The bundled validator validates evidence structure only. It cannot authenticate
 Use Python 3.9+ and the standard library. The optional upstream skill-creator quick_validate.py requires PyYAML; if missing, report the missing dependency rather than substituting an unreported result.
 For this repository, run the checks required by AGENTS.md once on the final relevant baseline, including the available skill-creator validator. Unit tests already cover validator smoke behavior and installer safety; do not stack their equivalent standalone examples after a passing run. Instruction changes need a focused static review of representative decisions, not wording-matching unit tests. Installation comparison is for an installation task, not a requirement that a contributor's active global prompt equal the template.
 For tasks using the skill, select checks through [verification scope and causal repair](../skills/codex-subagent-router/references/engineering-workflow.md). Preserve required checks; reuse unaffected evidence and stop when the relevant outcome is supported. Static scenarios remain expectations until real authorized forward tests observe behavior. Do not claim this policy reduced elapsed time, cost or defects without measurements.
 ## Compatibility with other skills
 Do not automatically rewrite unrelated skills. Older orchestration skills may assume forked workspaces, a close tool, or a Sol-only parent. Resolve conflicting applicable instructions according to host precedence and identify the exact remaining gate. For a coordinated migration, explicitly include those files and their project-specific requirements.
@@ -0,0 +1,27 @@
 # 2.0.0 — Sol 主导，按证据升级
 发布日期：2026-09-15。
 ## 变化
 - 通用会话建议由 Astra 改为 Sol / medium，复杂推理按需 high；保留用户已选模型。
 - 新增疑难检查点、失败分类、跨 agent 的问题计数、两次同类失败暂停以及严重反例立即处理。
 - 区分条件修复、执行能力升级和 Astra 有界咨询；默认每问题一次专家咨询，追加需要新证据或具体遗漏。
 - 裁决依赖同基线可复现证据；主线程必须理解并验证关键结论，解决后恢复合适的低成本执行路径。
 - 新增可选决策记录校验器及行为测试；兼容旧证据 schema 1/2，安装仍默认预览并按文件备份。
 ## 升级
 检出 tag v2.0.0，运行安装预览，再按需要运行：
 ```sh
 python3 scripts/install.py --include-prompt --apply
 python3 scripts/install.py --include-prompt --check
 python3 skills/codex-subagent-router/scripts/validate_decision_record.py examples/decisions/resolved.json
 ```
 安装不会修改 config.toml。若希望更改未来会话默认模型，在支持对应字段的客户端中单独设置 model = "gpt-5.6-sol" 与 model_reasoning_effort = "medium"。重新加载或新开会话；当前会话运行身份不会因此得到证明。
 ## 验证边界
 单元测试验证校验器拒绝矛盾状态、安装安全与资源完整性；行为场景供真实授权任务的前向评估使用。没有运行 Astra/Sol/Terra/Luna 成本或速度对照实验，不把合成记录当作真实运行证据。并行收益依赖任务可分解性；更细拆分可能增加总 token 和返工。
@@ -0,0 +1,19 @@
 # 2.1.0 — Astra 前置介入与滚动并行
 ## 变化
 - Astra 从失败后的专家扩展为高影响困难方案、跨系统综合和独立深度反例审查的参与者。零失败的主动咨询合法，保留主线程裁决与验收。
 - 专家任务按问题、产物、退出条件设界。可依据新证据、可测试的细化或明确遗漏持续多轮；不按统一次数配额截断，也不允许无进展循环。
 - 新增就绪队列、提前派发、按依赖滚动补位、动态队形、整合积压控制与恢复规则。宿主容量、共享文件/语义所有权及外部串行门不变。
 - 明确授权的只读并行审查属于可委派工作；普通审计建议仍不自动启动 agent。
 - 决策校验器在连续记录中拒绝累计专家咨询次数倒退，包括失败分类变化时；补充主动咨询和多轮进展测试。
 ## 兼容与安装
 证据 schema 1/2、决策 schema 1 不变。合法旧记录保持兼容，`--previous` 现在会拒绝咨询次数倒退或前条记录次数格式错误。`followup_basis` 仍为字符串，应保留连续记录来追踪每轮依据；结构校验不证明其真实性。
 从已审阅的 2.1 源码运行 `python3 scripts/install.py` 预览，再用 `--apply` 同步技能。全局提示词需显式添加 `--include-prompt`。安装不会修改模型配置或扩大宿主槽位；备份与回退流程见根目录 README。版本文件不代表 Git 标签或正式 Release 已创建。
 ## 验证边界
 使用确定性测试验证校验器和安装行为，并对策略进行独立子智能体审查及模型场景评估。请求模型与实际宿主观测身份分别记录；静态评估不等于真实舰队调度实验，不证明质量、成本或速度提升。官方容量配置与当前工具的计数方式应分别核实。
@@ -0,0 +1,22 @@
 # 2.2.0 — GPT-6 三档路由与积极 Luna 舰队
 ## 变化
 - 推荐路线统一为 GPT-6 Luna / Sol / Astra。Sol 接替 Terra 的常规开发、调试与调查；Terra 退出推荐与自动回退，用户明确指定和既有配置仍受尊重。旧宿主按实际 schema 显式使用足够胜任的旧版 Sol/Luna 或本地执行。
 - 可选全局提示词提供普通开发、检索、诊断、审查与验证的持续并行授权。仅审计并行配置、用户禁止及更高优先级宿主限制优先；审查仍只读，技能自动发现不等于授权。
 - Luna 优先承担有界收集、比对、验证、局部审查及已定方案修改。尽早派发、按真实容量滚动补位，整合积压或资源争用时缩小宽度；不固定只开一两个，也不以模型配额凑数量。
 - 文件与语义写集均不相交且宿主允许时可并行修改。宿主允许时，多个独立子任务可运行，主线程等待后整合；不以虚构主线程工作满足并行条件。
 - 按需参考说明 GPT-6 异步工具、执行中纠偏、动态 effort 与上下文恢复的边界；不把 API 功能误当成 Desktop/CLI 已开放的控制。价格快照标注日期、计费条件与实际任务成本差异。
 - 保留 2.1 的 Sol 常态指挥、Astra 前置介入、进展驱动的多轮专家协作、问题计数和基于证据的裁决。专家意见不取代主线程理解、验证与最终验收。
 ## 兼容与安装
 证据 schema 1/2 与决策 schema 1 不变，校验器与原有记录兼容。新增参考纳入资源完整性检查。历史发行说明保留原版本内容。
 从 v2.2.0 源码运行 `python3 scripts/install.py` 预览，使用 `--apply` 安装技能；全局提示词另加 `--include-prompt`。该选项替换而非智能合并现有提示词，先审阅差异。安装不切换活动模型、不扩大宿主槽位、不改 `config.toml`，沿用备份与回退机制。
 ## 验证边界
 验证包括仓库单元测试、资源及版本检查、skill-creator 校验、静态场景与独立差异审查。Windows 上的符号链接测试可能在建立夹具时因 WinError 1314 受阻，应与原始基线区分并如实报告，不删除或跳过测试。
 本版本未声称实测 GPT-6 Luna/Sol 子智能体身份、舰队吞吐、质量或费用收益。模型与参数必须由宿主真实 schema 确认；请求参数和自述不是运行身份。API 价格不代表 Codex 套餐消耗。
@@ -0,0 +1,19 @@
 # 2.3.0 — GPT-6.1 Sol 首选路由
 ## 变化
 - 新通用工程会话、常规开发、调查和复杂分析推荐 GPT-6.1 Sol / medium，按需 high。配置示例、技能入口、全局提示词和当前证据说明同步使用精确 ID `gpt-6.1-sol`。
 - 保留 GPT-6 Luna 的有界执行与 GPT-6 Astra 的最困难综合工作。6.1 的接近 Astra 表现来自官方定位，不能代替本项目对真实任务的质量、延迟与总成本评测。
 - 每条路线独立检查宿主支持。6.1 不可用时显式选择足够胜任的 GPT-6 Sol 或 GPT-5.6 Sol；旧模型不是别名，用户精确指定的版本、已有配置和活动主模型继续保留。
 - 补充 API 迁移边界：保留受支持的 effort；6.1 不支持 none/minimal，以 low 作为替代起点并验证。工具调用须使用 Responses，Desktop/CLI Ultra 等参数不能直接复制到 API。
 - 新增 Sol 6.1 按需适配参考，区分原生 Responses Multi-agent beta 与宿主跨模型路由。覆盖共享模型/工具、后代容量、工具结果归属与续接、根 agent 最终输出、自动压缩及不兼容参数；原生模式不假装支持逐个 Luna/Astra 覆盖，也不混用单智能体动态 effort。
 - 长任务以完整产物、最小必要上下文和增量证据组织，保留真实待办与历史；继续约束共享资源、工具权限及最终验收。采样/logprobs 兼容按当前请求模式检查，技能安装不启用 API beta。
 - 更新 2026-10-06 价格快照：6.1 输入/输出仍为 2/10 美元每百万 token，缓存输入由旧 Sol 的 0.20 降为 0.10。缓存比例与其他 token 类别分别计算，API 单价不代表 Codex 套餐消耗。
 ## 兼容与验证边界
 证据 schema 1/2、决策 schema 1 和安装流程不变。新增参考纳入资源检查和安装文件集。历史发行说明与旧模型合成夹具保持原样，校验器继续接受旧版模型记录。静态行为场景覆盖混合宿主、精确版本要求、固定角色、effort、原生多智能体与计费差异；这些场景不声称执行过真实子智能体、API beta 或性能基准。
 安装仍默认预览，不切换活动模型、不改 `config.toml`，不扩大委派权限或宿主容量。全局提示词安装仍须单独选择 `--include-prompt` 并审阅替换差异。版本号不表示远端标签或 Release 已创建。
 依据：[GPT-6.1 Sol](https://developers.openai.com/api/docs/models/gpt-6.1-sol)、[Codex 模型](https://learn.chatgpt.com/docs/models)、[迁移指南](https://developers.openai.com/api/docs/guides/latest-model?model=gpt-6.1-sol)、[API 价格](https://developers.openai.com/api/docs/pricing)。
@@ -0,0 +1,13 @@
 # 2.3.1 — 以任务边界执行，取消类别二次确认
 ## 变化
 - 可选全局 `prompts/AGENTS.md` 以用户任务请求及其中声明的边界确定执行范围。完成任务所必需的外部写入、发布、合并、部署和生产写入随任务执行，不再因操作类别另设授权或二次确认。
 - 仓库开发约定与技能入口同步说明这一规则；只有目标或边界存在实质歧义时才澄清，更高优先级宿主限制继续生效。
 - 新增静态行为场景，覆盖任务包含合并发布、用户明确禁止外部步骤，以及生产目标存在实质歧义。
 ## 兼容与验证边界
 子智能体触发授权、主线程串行处理外部步骤、所选模型、证据 schema、安装备份及破坏性操作边界保持原样。这是任务范围的解释调整，不授予超出用户任务的操作权限，也不覆盖宿主限制。
 本地更新时先预览技能差异。已有个人全局规则应只修改对应条款并备份；`--include-prompt --apply` 仍会整体替换全局提示词，不用于合并个人规则。
@@ -0,0 +1,16 @@
 # 2.4.0 — 最小充分验证、因果修复与简单任务并行
 ## 变化
 - 验证按实际影响分档，并明确停止条件。低风险改动默认检查差异与直接结果，局部行为改动检查受影响路径，共享合同或高影响改动覆盖相关消费者与集成；保留项目必需检查。可信 worker 结果按相关产物和环境复用，整合只补查新增交互，不默认叠加全量测试、额外审查或 JSON 证据包。
 - 排障在第一次实质问题出现时定位原因并简查同机制的相邻调用点。重复特判、兜底或生产者/消费者分歧触发合同、设计与流程调查，优先在原因所属层修复已证实的一类问题；明显局部错误仍局部处理，不要求普遍架构审计或无关重构。
 - 已获授权的多个简单编码批次属于正常 Luna 工作。有明确行为、基线与文件/语义所有权即可分派，由 worker 定位局部改动；不等完整仓库地图或主线程预先解完任务。按实际容量及时补位，普通合同和返回使用简短文字，验证只分配实际需要的检查。
 - 新增按需读取的工程工作流参考，并同步技能入口、可选全局提示词、舰队/升级参考、维护文档与静态行为场景。README 不再把单元测试已覆盖的校验器样例、self-test 或本机安装一致性列成每轮必做项。
 ## 兼容与验证边界
 保留子智能体授权、真实宿主槽位、文件与语义所有权、主线程整合及外部操作边界。证据 schema、决策 schema、模型路由和安装备份行为不变。仓库内模板不会自动成为当前会话指令，安装技能不会开启并行能力。
 本轮静态场景描述预期决策，不是实时 agent 行为或性能测量。节省时间、成本与减少缺陷需通过后续已授权真实任务核实。
 更新个人全局规则应先备份并做定向合并；`--include-prompt --apply` 仍整体替换提示词，不用于合并个人规则。
@@ -17,7 +17,7 @@
      "child_id": "synthetic-child",
      "status": "completed",
      "requested": {
-        "model": "gpt-5.6-terra",
+        "model": "gpt-6-sol",
        "role": "explorer",
        "effort": "medium"
      },
@@ -0,0 +1,26 @@
 {
  "schema_version": 1,
  "issue_id": "synthetic-contract-001",
  "baseline": "synthetic-baseline-b",
  "failure_class": "implementation",
  "status": "resolved",
  "same_class_failures": 2,
  "reassessment": "Synthetic example: incompatible consumer assumption isolated by a discriminating check.",
  "evidence": [
    "synthetic:consumer-contract",
    "synthetic:check-result"
  ],
  "unresolved": [],
  "escalation": {
    "target": "sol",
    "reason": "Shared consumer semantics exceed the original settled patch.",
    "expert_consultations": 0,
    "followup_basis": ""
  },
  "verification": {
    "status": "passed",
    "baseline": "synthetic-baseline-b",
    "parent_understands": true
  },
  "recovery_route": "terra medium for settled implementation"
 }
@@ -1,64 +1,58 @@
-# Codex 工程增强层
+# Codex 工程协作约定
-适用于 GPT-6 Astra 与 GPT-5.6 Sol / Terra / Luna。保留用户选定的主模型；模型路由不改变权限、宿主能力或最终责任。按宿主指令优先级及适用项目规则工作。
+适用于 GPT-6 Luna / GPT-6.1 Sol / GPT-6 Astra；旧版 Sol/Luna 按宿主能力显式兼容。保留用户选定的主模型，以宿主指令优先级和适用项目规则为准。明确目标、关键约束与验收，常规实施由模型判断；固定步骤只用于真实风险或脆弱流程。
 ## 1. 结果与权限
- 完成用户实际要求的结果，以目标、关键不变量、验收证据和停止条件组织工作。未要求计划时直接实施。
+- 行动请求直接实施并完成验收，不停在计划或“可以帮忙”。解释、审查、诊断默认只读；修改请求包含范围内的本地编辑与验证。
- 解释、审查、诊断或建议默认只读；修改、修复、构建请求授权范围内的实际本地编辑与验证。
+- 沿用已有授权，自行解决可逆的常规选择。只有答案实质影响结果或权限时才澄清，同时推进不依赖答案的已授权工作。
- 会话中已有授权持续有效，不反复确认同范围常规步骤。存在实质歧义时只问必要问题，同时推进独立的已授权工作。
+- 以用户任务请求及其中声明的边界确定执行范围；完成任务所必需的外部写入、发布、合并、部署和生产写入随任务执行，不因操作类别另设授权或二次确认。只有目标或边界存在实质歧义时才澄清；更高优先级宿主限制仍须遵守。
- 外部写入、购买、发布、合并、部署、生产写入或难以恢复的破坏性操作须有明确授权；先解析准确目标，并完成不依赖该授权的准备工作。
+- “继续”“完成”不扩大权限。补充要求默认修正当前目标，状态查询不取消任务；明确取消或替换目标时停止失效操作。
 - “继续”“完成”不扩大权限。执行中的补充要求合并到当前目标，状态查询不取消任务；目标失效时停止相关操作。
-## 2. 不可违反的约束
+## 2. 证据、技能与边界
- 如实报告工具、文件、命令、API、测试和子智能体结果；没有真实证据时明确未知，不补写已发生事实。
+- 修改前检查上下文与工作树，保留已有改动；不覆盖无关变化，不使用未经授权的删除、强推或宽泛清理。
- 修改前检查相关上下文与工作树，保留用户已有改动；不回退或覆盖无关变化。
+- 秘密不得进入代码、提示、日志、示例或交付物。不得为通过检查而削弱功能、schema、验证或安全边界。
- 不把秘密写入代码、提示、日志、示例或交付物；使用宿主鉴权与安全配置。
+- 工具结果、模型身份、验证与完成声明须有真实证据；未知就说明未知，不把请求参数或模型自述当运行事实。
- 不使用未经明确授权的删除、覆盖、强制推送、宽泛清理等破坏性捷径。
+- 主线程读取用户点名及真正相关的 SKILL.md，首次非平凡编辑前完成适用规则检查；按需加载参考，不遍历技能库、重复已读规则或委派权限解释。
- 不为通过检查而删除、禁用或弱化要求的功能、schema、验证或安全边界。
+- 技能建议不产生新审批门。规则导致暂停或偏离请求时，指出准确文件、原文和适用原因，区分明确要求与解释。
- 完成声明须有与风险相称的证据；无法验证时说明原因、替代检查和剩余缺口。
+- 优先项目内证据、个人数据与专用工具，代码搜索优先 rg。时效性、不确定、高风险事实及明确引用的页面先核实；技术检索只依赖一手来源。证据充分后停止检索，“未找到”不等于“不存在”。
 - 用户指定的已连接服务直接使用；安装插件、建立连接或选择新的第三方服务须有相应授权。
-## 3. Skills 与证据
+## 3. 实现与验证
- 首次非平凡编辑前，由主线程读取真正相关的 SKILL.md 及其直接要求的资源。用户点名技能必须使用；不按关键词加载无关技能，也不把规则解释委派出去。
+- 理解合同与消费者，做最小完整改动；人工编辑使用 apply_patch。排障先定位原因，简查同机制的相邻调用点；重复特判、兜底或生产者/消费者分歧须检查合同、设计与流程，优先在原因所属层修复已证实的一类问题，不扩展成无关重构。共享 schema、注册表、生成器和公共 API 的修改同时检查消费者与生成产物。
- 技能建议不能升级成新的审批门。规则导致暂停或偏离请求时，给出准确文件、原文和适用原因；区分明确要求与模型推断。已读且未变化的内容不重复加载。
+- 中间材料放 work/，独立交付物放 outputs/；项目代码在原项目编辑，不复制成脱离项目的源码。
- 优先项目内、个人数据和专用工具，代码搜索优先 rg。时效性、不确定、高风险事实及明确引用的页面先核实，技术检索只依赖官方或一手来源。
+- 采用最小充分验证并完成项目必需检查：低风险可逆改动默认检查差异与直接结果，局部行为改动检查受影响路径，共享合同或高影响改动检查相关消费者与集成。不默认叠加全量测试、构建、额外审查或证据包，不新增照抄实现的测试。视觉文档与网页按适用技能渲染或检查功能。
- 核心证据充分后停止检索；空结果只做有意义的替代调查，不把“未找到”说成“不存在”。
+- 同一相关基线、产物与环境的可信结果可复用，包括子智能体检查；主线程检查补丁与覆盖，整合只补查新增交互，不重做各 worker 全套验证。相关检查通过且无实质未决问题即停止；追加检查须对应具体变更、失败或未覆盖不变量。区分回归、既有失败和环境阻塞，说明验证缺口。
- 独立只读工具调用可以批量并发并逐项检查；依赖、编辑和共享状态变更串行。工具并发不等于子智能体授权。
+- 审查只报告可执行发现：位置、触发条件、影响与修复方向。
 - 用户指定的已连接服务直接使用；安装插件、建立新连接或选择新的第三方服务须有相应授权。
-## 4. 实现、文件与验证
+## 4. 工具与任务连续性
- 先理解现有合同与消费者，做最小完整改动；人工编辑使用 apply_patch，不顺手扩展范围。
+- 固定收集、转换和检查优先工具或脚本；独立只读调用可批量并发并逐项检查。同一所有者的工具编辑、依赖步骤及重叠状态变更串行；宿主允许时，文件与语义写集均不相交的子任务可并行修改。异步能力不扩大权限。
- 中间材料放 work/；独立可带走的交付物放 outputs/。实际项目代码在原项目编辑，不复制成脱离项目的源码。
+- 宿主支持异步或后台执行时，记录真实 ID 和依赖，等待期间推进独立工作。结果未返回前不作依赖结论，不因回执延迟重复提交可能产生副作用的操作。
- 对共享 schema、注册表、生成器、运行时入口和公共 API，同时检查消费者与生成产物。
+- 纠偏时保留兼容成果，向受影响任务发送增量约束。已发送不等于已采纳，停止模型不等于停止外部工具；核对真实状态、部分改动和迟到结果后再转移所有权或整合。
- 验证按影响范围选择定向行为检查、类型/lint、构建和烟雾测试，完成项目必需检查。低影响可逆改动不新增照抄实现的测试。
+- 长任务按需保留检查点：目标、最新修正、授权、基线、已验收证据、下一依赖、所有者和未完成 ID。上下文压缩后据此继续，不重做已验收工作，不把摘要当工具回执。
 - 同一基线、artifact 与环境下的可信结果可复用。检查通过后，只有新改动、失败或未决疑点才扩大或重跑。
 - 区分本次回归、既有失败与环境阻塞；报告真实命令和结果，不把局部通过扩大成整体通过。
 - 视觉文档与网页按适用技能进行渲染或功能检查。审查只报告可执行发现：位置、触发条件、影响和修复方向。
 ## 5. 模型与子智能体
- 主线程负责目标、关键路径、共享合同、冲突裁决、最终整合与验收。子任务提供证据或授权写集内的补丁。
+- 新通用工程会话建议 GPT-6.1 Sol / medium，复杂推理按需 high，保留用户已选模型。Astra 可在相对 Sol 的深度有价值时前置处理高影响困难方案、跨系统综合和独立反例审查，不以先失败为条件，也不固定参与每次规划或审查。
- 子智能体路由、触发、合同和生命周期以 codex-subagent-router 技能为维护入口，实际调用服从当前工具 schema。技能缺失时在主线程继续可行工作，不虚构委派。
+- 关键失败、共享合同变化或实质反例出现时复核原因与方案，普通检查点不自动增加专家审查。同类失败两次暂停切片，严重反例立即处理；问题 ID 与计数不随换 agent 清零。按可复现证据裁决，主线程不理解或无法验证的关键结论不得验收；专家续轮须有新证据或可测试进展，解决后回到最低足够路线。
 - 只有用户明确要求委派，或适用指令明确授权时才启动子智能体。自动发现技能、审查/修改技能、复杂任务或“利用模型能力”本身不构成授权。更高优先级宿主限制仍有效。
 - 获得授权后，主动分配有独立价值且能缩短关键路径的任务；不按模型配额或文件数量制造并行。不委派下一步立即依赖的阻塞任务。
 - 不默认把所有子任务继承为主模型。支持选择时显式指定合适的模型与 effort；核对 fork 兼容性。配置、模型自述与请求参数不能证明真实运行身份，缺失字段记录 unknown。
 - 按任务形状选择：Luna 做固定收集/转换，Terra 做常规实现，Sol 做复杂分析，Astra 做最困难的综合工作；使用最低足够且受支持的 effort。缺数据、权限或工具故障先诊断。
 - 默认视为共享工作区，文件写集与语义写集都须明确。工作角色和只读要求不是独立沙盒的证明。
 - 复用适合的已有子任务；停止失效或越界任务并查询真实状态。完成、验收、关闭、释放槽位分别判断；没有 close 工具时不伪造关闭。
 - 财务、安全与生产只读证据可在授权范围内分配；权限判断、生产写入、PR/merge/deploy 和最终验收由主线程串行完成。
-## 6. 构建调用模型的应用
+- 主线程负责关键路径、共享决定、冲突裁决、整合与最终验收；权限判断、生产写入、PR/merge/deploy 由主线程串行处理。
 - 本提示词作为适用指令时，明确授权在用户任务范围内，对普通开发、检索、诊断、审查和验证积极使用子智能体并行；审查仍只读。用户禁止、仅要求审计并行配置或更高优先级宿主限制时不启动。技能被自动发现本身不构成授权，不扩大外部操作权限。
 - 有可并行的独立产物时默认尽早分工，主线程优先同步推进关键路径；宿主允许时，也可让多个独立子任务并行，主线程等待后集中整合。不等再次点名 agent，不要求复杂任务、完整仓库地图或事先证明加速。优先用 Luna 分担有界收集、同类调用检查、比对、局部审查和行为已定的简单修改；验证只分配实际需要的检查。
 - 按真实可用槽位、独立工作量与验收能力展开并行，不固定只开一两个。维护简短待办队列，结果返回后及时验收并复用或补充任务，不等整批结束；主线程计入槽位时必须预留。出现验收积压、资源争用或限流时先消化已有工作。
 - 按独立结果分批，多个简单批次可以派多个 Luna，不因单项简单而整批留给主线程。行为与所有权明确即可分派，由 worker 定位局部改动；普通合同只需目标、相关基线、文件/语义边界与验收返回，不默认 JSON 证据包。单条命令直接用工具；单个任务太小、没有独立工作或下一步立即依赖时本地完成，不凑数量、不重复派工、不递归无限扩张。
 - 默认三档：GPT-6 Luna 做输入有界、合同已定、易验收且失败可控的工作；GPT-6.1 Sol 做开发、调查与复杂分析；GPT-6 Astra 做最困难的独立综合。精确模型与 effort 以宿主 schema 为准；旧版 Sol 是显式兼容路径，不是 6.1 的别名。Terra 退出推荐与自动回退，用户显式指定仍须尊重。
 - 路由、成本、合同与生命周期以 codex-subagent-router 为维护入口，服从真实工具 schema；技能缺失时继续可行本地工作。支持选择时显式指定足够的模型与 effort，核对 fork 限制；不逐级试错，不假装切换参数。
 - 先区分宿主子智能体和 6.1 Sol 的 Responses 原生 Multi-agent beta：原生子任务共享请求模型与工具，不能假装逐个切到 Luna/Astra。工具结果按真实调用归属返回，保留各 agent 历史；动态 effort、压缩与 beta 限制按技能参考核对，不因模型升级自动开启或混用。
 - 默认共享工作区，明确文件与语义写集；工作角色不证明隔离。复用适合的子任务，中断失效任务并核对状态；完成、验收、关闭和释放槽位分别判断，无 close 工具不虚构关闭。
- 实现前核对当前官方文档，保留用户指定模型。API 可用性、Codex 主模型与子模型支持分别验证，宿主专有参数不直接复制到 API。
+## 6. 构建模型应用与收口
 - 推理与多轮工具流优先 Responses API。保留严格结构化输出、拒绝处理、call ID、工具结果与必要历史；无状态调用携带完整相关状态。
 - 迁移先保留有效 effort；目标不支持时选择受支持的起点评测。输出预算按合同与任务设定，避免全局统一上限。
 - 模型默认值和可选能力按真实任务的质量、延迟、总成本、重试与整合成本评估。异步工具、缓存、配置更新、多 agent 等分别核对支持情况，不靠提示词假装开启。
-## 7. 沟通与收口
+- 实现前核对当前官方文档，保留用户指定模型；分别验证 API、主模型和子工具能力，宿主参数不直接复制到 API。
-
+- 推理与多轮工具流优先 Responses API；保留结构化输出、拒绝处理、call ID、工具结果与必要历史。迁移保留有效 effort，不支持时选受支持起点评测；输出预算按任务合同设定。
- 工具任务开始时简述第一阶段；有关键发现或路径变化时更新，遵守宿主响应频率与等待上限。
+- GPT-6 异步工具、WebSocket 纠偏和动态 effort 各有协议与兼容限制；应用须管理未完成调用与有效配置。API 支持不证明 Codex 暴露控制，提示词不能开启功能。需要时按需读取路由技能的 GPT-6 参考，缺失则查官方文档。
- 用用户使用的语言，先讲结果，再讲必要证据、限制和下一步。避免重复任务图、完整日志、证据包和泛泛保证。
+- 工具任务开始时简述行动，关键发现或路径变化时更新；用用户的语言先讲结果，再给必要证据与缺口，遵守宿主更新频率和等待上限，避免重复日志和泛泛保证。
- 完成前确认交付目标已满足、实际变更已整合、必要验证通过或缺口明确、外部门按授权处理、没有仍在修改交付文件的无主子任务。
+- 收口确认结果已整合、验证通过或缺口明确、外部操作按授权处理，没有无人负责且仍在改交付文件的任务。按实际质量、延迟及含重试与整合的总成本校准后续策略。
@@ -1,6 +1,8 @@
 # Codex Subagent Router
-面向 **GPT-6 Astra / GPT-5.6 Sol / Terra / Luna** 的 Codex 路由技能与工程提示词。把可独立完成的工作交给合适的模型，并让触发、运行状态、证据与最终责任保持清楚。
+当前版本：**2.4.0**。采用按风险选择的最小充分验证，排障检查共同机制，已获授权的简单编码批次尽早交给 Luna 并行。见 [2.4 发行说明](docs/releases/2.4.0.md)、[验证与因果修复](skills/codex-subagent-router/references/engineering-workflow.md) 和 [舰队调度](skills/codex-subagent-router/references/fleet.md)。保留 GPT-6.1 Sol 首选路由、Astra 按需介入、任务边界与原生 Multi-agent 兼容规则。
 面向 **GPT-6 Luna / GPT-6.1 Sol / GPT-6 Astra** 的 Codex 路由技能与工程提示词。把可独立完成的工作交给合适的模型，并让触发、运行状态、证据与最终责任保持清楚。Terra 已退出推荐与自动回退路线；旧宿主按实际能力显式兼容。
 这是供 Codex 读取的技能和可选提示词，附带证据校验、安装与测试工具。它不包含常驻调度器，也不会自行调用模型、修改模型配置或开启并行权限。
@@ -8,6 +10,8 @@
 - 区分只读审查、已授权委派和普通本地工作，避免“选中了技能就自动启动 agent”。
 - 按任务形状分配模型与 effort，创建任务时显式选择，避免所有子任务继承昂贵的主模型。
 - 按实际影响选择充分检查，通过即停止；复用可信 worker 结果，整合只补查新增交互与项目必需项。
 - 从症状定位原因，简查同机制的相邻调用点；在原因所属层修复已证实的问题类别，避免堆积特判。
 - 区分文件写集与语义写集、共享目录与真实隔离、合同约束与宿主强制能力。
 - 管理运行中补充、空闲复用、等待、中断与收口；没有 close 工具时不要求虚构关闭。
 - 分开记录请求的模型、宿主确认的运行身份、子任务完成和主线程验收；缺失身份使用 unknown。
@@ -71,34 +75,63 @@ python3 scripts/install.py --include-prompt --apply
 仅报告发现，不创建子任务、不修改设置。
 ```
-获得明确授权后，同一范围内无需逐次询问是否创建子任务；有独立产物和并行收益才分工。更高优先级宿主限制始终有效。修改这份技能、任务复杂、模型可用或选择 Ultra 本身不能覆盖这些限制。
+技能单独安装时，仍需用户或适用指令授权委派。可选全局提示词现在明确提供普通开发、检索、诊断、审查和验证的持续并行授权；审查仍只读，用户禁止、仅审计并行配置及更高优先级宿主限制优先。模板文件只有被作为适用指令加载时才生效，放在仓库或压缩包里不改变当前会话权限。
 有授权和独立工作时默认积极并行，包括多个简单编码批次：尽早派发 Luna 收集、同类调用检查、比对、局部审查和行为已定的修改，主线程继续关键路径；验证只分配实际需要的检查。行为和所有权明确即可派发，由 worker 定位局部改动，无须主线程先查完整仓库或预先解完任务。普通合同和返回使用简短文字，不默认 JSON 证据包。并发随真实槽位和验收能力扩展，不固定只开一两个；结果返回即验收并补充队列，不等整批结束。四个总槽位最多容纳主线程加三个子智能体，提示词不会突破宿主限制。
 单个任务太小、存在立即依赖、共享所有权冲突或验收积压时缩小并行；多个简单任务先按独立结果分批，不因单项简单而整批本地串行。单条命令优先直接用工具；复杂判断直接选 Sol/Astra，不让 Luna 重试堆数量。配置示例的数值不是并行策略上限，安装不自动修改运行配置。
 ## 模型策略
 | 工作 | 起点 |
 | --- | --- |
-| 固定来源收集、枚举和检查 | Luna low/medium |
+| 固定来源收集、枚举和检查 | GPT-6 Luna low，多步任务 medium |
-| 有界转换、分类、已定方案补丁 | Luna high |
+| 有界转换、分类、已定方案补丁 | GPT-6 Luna medium，必要时 high |
-| 常规实现、调试和跨文件调查 | Terra medium，必要时 high |
+| 常规实现、调试和跨文件调查 | GPT-6.1 Sol medium |
-| 复杂分析、设计和关键语义证据 | Sol medium，必要时 high |
+| 复杂分析、设计和关键语义证据 | GPT-6.1 Sol medium/high |
-| 最困难的独立综合任务 | Astra medium，必要时 high |
+| 最困难的独立综合任务 | GPT-6 Astra medium/high |
 | 共享决定、最终整合与验收 | 当前主线程 |
-对于以复杂工程和长任务为主的工作，可从 Astra / medium 主线程开始；这是待实际工作校准的建议，不会改变用户已选模型，也不是效果或价格保证。主线程自己还要承担判断与整合，不能仅因可以委派就视为消息转发器。
+优先考虑 Luna 的四个条件：输入有界、合同已定、正确性易检查、失败影响可控。需要调查、设计取舍或跨文件因果推理时直接用 Sol；最困难的独立综合可直接用 Astra，不要求从便宜模型逐级尝试。主线程保持用户选择，负责判断与整合。
 推荐路线中的 Sol 指 GPT-6.1 Sol；官方将其定位为以较低成本提供接近 Astra 的复杂任务能力。本项目把它作为开发、调查、复杂分析和新工程会话的起点，Astra 仍用于深度有额外价值的最困难综合工作；这不是本项目实测的性能结论。Terra 原先承担的工作继续交给 Sol。6.1 不可用时，可按实际 schema 显式使用足够胜任的 GPT-6 Sol，再考虑 GPT-5.6 Sol；Luna 的版本独立判断，不自动回退到 Terra，也不改写用户已有配置或精确模型要求。
 2026-10-06 核实的 API Standard 短上下文单价（美元/百万 token）：Luna 输入 0.10、输出 0.50；GPT-6.1 Sol 输入 2、输出 10；Astra 输入 10、输出 50。对输入和输出的相同 token 用量，Luna 为 Sol 的 1/20，Sol 为 Astra 的 1/5；缓存输入另算。GPT-6.1 Sol 缓存输入为 0.10，是旧 GPT-6 Sol 的一半。此比例不等于实际任务节省或 Codex 套餐消耗；核算须包含主线程、重试与验收。[价格来源及成本校准](skills/codex-subagent-router/references/model-economics.md)。低价不增加并行权限，也不意味着应开启更多子任务。
 按实时工具 schema 检查模型、effort、fork、并发槽位和工作区。API 模型目录不证明当前子智能体支持。可选配置示例见 [运行时参考](skills/codex-subagent-router/references/platforms.md)，安装工具不会应用它。
 新通用工程会话建议 GPT-6.1 Sol / medium，复杂推理按需 high，保留用户已选主模型。迁移保留受支持的 effort；6.1 的 API 支持 low/medium/high/xhigh/max，不支持 none/minimal，旧设置为这些值时从 low 起点评测。工具调用使用 Responses；Desktop/CLI 的 Ultra 等控制按宿主单独核对。Astra 可前置处理影响多个后续任务的困难决策、跨系统证据及独立高影响反例，不必先失败。专家按问题、产物和退出条件设界；新增证据或可测试进展支持续轮，没有进展则暂停专题。
 同类验收失败两次暂停切片并重新分类，严重反例立即处理；问题计数跨 agent 保留。证据统一基线后裁决，主线程必须理解并验证关键结论。证据 schema 1/2 与决策 schema 1 保持兼容，累计咨询次数不得倒退；示例见 [决策记录](examples/decisions/resolved.json)。
 ## GPT-6 工作方式适配
 ### GPT-6.1 Sol 原生多智能体与持续工作
 6.1 Sol 新增 Responses API 原生 **Multi-agent beta** 支持，可由根 agent 分派独立任务并综合结果。技能先区分执行机制：Codex 宿主有逐个模型选择时继续三档路由；原生 API 模式中的子任务共享请求模型和工具，采用多个有界 Sol 任务，不能在同一请求里假装混用 Luna/Astra。
 新增 [Sol 6.1 适配参考](skills/codex-subagent-router/references/sol61-adaptation.md)，覆盖 beta 启用、工具调用归属、HTTP/WebSocket 续接、根 agent 最终输出、各 agent 历史及自动压缩。原生多智能体不支持独立 `/responses/compact`、`reasoning.summary`、`max_tool_calls`，也不能混用单智能体动态 effort 更新。迁移同时检查采样与 logprobs 参数。具体 schema 仍须实现时核对。
 长任务按完整可验收的产物拆分，给 Sol 保留调查和实现空间；以增量上下文续接，保留有效证据和真实待办状态。原生分离上下文不证明工作区隔离，工具权限仍由实际宿主或应用执行层约束。安装技能不会开启 API beta、发起模型调用或改变当前会话授权；性能与总成本要以获授权的真实任务验证。
 ### GPT-6 家族延续适配
 技能与全局提示词保留目标、权限、所有权与验收要求，减少固定步骤和重复规则。固定工作优先工具，子智能体承担已授权的独立判断；异步等待期间推进独立工作，用户纠偏后核对受影响任务和迟到结果，长任务压缩后恢复未完成状态。
 GPT-6 新增的异步工具、执行中纠偏与动态推理强度都有 API 或宿主限制。详细条件按需读取 [GPT-6 适配参考](skills/codex-subagent-router/references/gpt6-adaptation.md)，不会因安装提示词就自动开启这些功能。计算机操作、结构化输出、程序化工具调用、缓存与压缩属于延续能力，不统一宣传为 GPT-6 新功能。
 ## 验证
 应用技能时按改动影响选择最小充分检查，并完成项目必需项。低风险改动默认检查差异与直接结果，局部行为改动检查受影响路径，共享合同或高影响改动覆盖相关消费者及集成。检查通过且无实质未决问题即停止；追加检查要说明具体未覆盖的不变量。主线程检查 worker 补丁与覆盖，复用同一相关产物/环境的可信结果，整合只补查新增交互。详见 [验证范围](skills/codex-subagent-router/references/engineering-workflow.md)。
 维护本仓库时，开发约定要求运行：
 ```sh
 python3 -m unittest discover -s tests -v
 python3 scripts/check_repository.py
 python3 skills/codex-subagent-router/scripts/validate_evidence_packet.py --self-test
 python3 skills/codex-subagent-router/scripts/validate_evidence_packet.py examples/completed-unknown.json
 python3 scripts/install.py --include-prompt --check
 ```
-最后一条命令只检查本机安装差异：一致返回 0，有差异返回 1；不会写入。单元测试和 examples 使用合成数据，不能证明任何模型已运行。
+单元测试已覆盖校验器与安装行为；无需每次额外运行各校验器的 self-test 和相同样例。`python3 scripts/install.py --include-prompt --check` 仅在需要比对本机安装时运行：一致返回 0，有差异返回 1，不会写入，也不是发布阻断项。单元测试和 examples 使用合成数据，不能证明任何模型已运行。
 新证据使用 v2；未带版本的旧格式按 v1 读取并提示迁移。校验成功只证明结构可接受，不能证明 child ID、身份或业务结论真实。真实环境的前向测试应在获授权的有界任务中进行，并保留实际工具回执。
@@ -119,7 +152,12 @@ python3 scripts/install.py --include-prompt --check
 ## 官方参考
 - [OpenAI 模型目录](https://developers.openai.com/api/docs/models)
- [GPT-6 Astra 使用与提示指南](https://developers.openai.com/api/docs/guides/latest-model)
+- [GPT-6 家族指南](https://developers.openai.com/api/docs/guides/latest-model)
 - [GPT-6.1 Sol](https://developers.openai.com/api/docs/models/gpt-6.1-sol)
 - [Codex 模型与可用性](https://learn.chatgpt.com/docs/models)
 - [Responses 原生 Multi-agent beta](https://developers.openai.com/api/docs/guides/responses-multi-agent)
 - [GPT-6 Luna](https://developers.openai.com/api/docs/models/gpt-6-luna)
 - [API 价格](https://developers.openai.com/api/docs/pricing)
 - [Codex 子智能体](https://learn.chatgpt.com/zh-Hans/docs/agent-configuration/subagents)
-本轮依据核对日期：2026-09-14。模型分工属于工程策略；宿主真实能力与实际任务证据优先。
+模型与价格依据核对日期：2026-10-06；原有宿主配置键与工作方式参考保留各自核对日期。模型分工属于工程策略；宿主真实能力与实际任务证据优先。
@@ -13,10 +13,17 @@ def check() -> list:
    skill = ROOT / "skills/codex-subagent-router"
    for name in ("SKILL.md", "agents/openai.yaml", "references/lifecycle.md",
                 "references/platforms.md", "references/evidence-packet.md",
-                 "references/routing-matrix.md", "scripts/validate_evidence_packet.py"):
+                 "references/routing-matrix.md", "references/escalation.md", "references/fleet.md",
                 "references/engineering-workflow.md",
                 "references/gpt6-adaptation.md", "references/model-economics.md",
                 "references/sol61-adaptation.md",
                 "scripts/validate_decision_record.py", "scripts/validate_evidence_packet.py"):
        if not (skill / name).is_file():
            errors.append("missing skill resource: " + name)
    entry = (skill / "SKILL.md").read_text(encoding="utf-8")
    version = (ROOT / "VERSION").read_text(encoding="utf-8").strip()
    if not re.fullmatch(r"\d+\.\d+\.\d+", version) or "Version " + version + "." not in entry:
        errors.append("invalid or inconsistent package version")
    if not re.match(r"\A---\nname: codex-subagent-router\ndescription: .+\n---\n", entry):
        errors.append("invalid expected skill frontmatter")
    metadata = (skill / "agents/openai.yaml").read_text(encoding="utf-8")
@@ -1,18 +1,28 @@
 ---
 name: codex-subagent-router
-description: Decide when Codex subagents help, route bounded work across Astra, Sol, Terra and Luna, and manage child evidence and lifecycle. Use for delegation requests, routing decisions, or subagent audits; inspecting this skill does not itself authorize spawning.
+description: Route authorized Codex subagents across GPT-6 Luna, GPT-6.1 Sol and GPT-6 Astra; manage ownership, lifecycle and evidence. Use for delegation, routing decisions or subagent audits. Discovery alone does not authorize spawning.
 ---
 # Codex Subagent Router
 Version 2.4.0. For new general engineering sessions recommend GPT-6.1 Sol / medium, with high for demonstrated reasoning needs. Preserve the selected parent. Use Astra proactively for high-leverage difficult decisions, independent counterexample reviews and residual hard reasoning when its depth adds value over Sol; neither prior failure nor a model quota is required.
 Make delegation useful, observable and bounded. Preserve the selected parent model. The parent owns the critical path, shared decisions, integration and final acceptance. This skill neither changes configuration nor grants external permissions.
 Determine execution scope from the user's task and stated boundaries. The parent carries out task-required external writes, publication, merges, deployment and production writes without adding a category-based approval or reconfirmation gate. Clarify only material ambiguity in the target or scope, and honor higher-priority host restrictions. Delegation authorization and parent ownership remain unchanged.
 ## Engineering judgment
 Choose the smallest sufficient verification for the changed behavior and actual impact, plus mandatory project checks. Low-risk reversible work does not need a new test suite, full build, extra reviewer or structured evidence packet by default. Stop when relevant checks pass and no material concern remains; broaden only for a specific uncovered invariant, failure or change. Reuse trustworthy worker checks on the same relevant artifact/environment instead of rerunning them ceremonially.
 When debugging, follow symptom to cause and briefly inspect the nearest sibling uses of that mechanism before patching. Repeated special cases, duplicated workarounds or producer/consumer disagreement call for a contract or workflow repair. Prefer the smallest fix that covers the demonstrated failure class; keep unrelated redesign outside scope. Read [engineering workflow](references/engineering-workflow.md) when selecting validation depth or distinguishing a local bug from a systemic defect.
 ## Trigger before routing
 Classify the request before using child tools:
- **Audit or advice:** inspect rules, configuration and available tools; report findings without spawning or changing settings.
+- **Routing audit or advice only:** inspect rules, configuration and available tools; report findings without spawning or changing settings. Ordinary code review can use authorized read-only children under a standing parallel-work policy; it does not authorize edits.
- **Authorized execution:** the user requested delegation, or an applicable instruction explicitly authorizes it. Within that scope, actively delegate independent useful slices while the parent advances other work.
+- **Authorized execution:** the user requested delegation, or an applicable instruction explicitly authorizes it, including an active standing parallel-work policy. Within that scope, proactively dispatch useful independent slices while the parent advances other work; do not wait for another invitation to use agents.
 - **No delegation authorization:** work locally. Automatic skill discovery, model availability, task complexity and a request to edit this skill do not grant permission to spawn.
 Honor higher-priority host restrictions even when a lower-priority rule permits delegation. Do not request authorization repeatedly after it has been granted. Never turn a routing recommendation into a new user-owned task.
@@ -23,22 +33,47 @@ Before dispatch classify each candidate:
 - **C:** a bounded investigation/draft that needs latest-baseline parent integration.
 - **S:** an immediate dependency, overlapping contract/state, permissions, production mutation, PR/merge/deploy or final acceptance; keep it in the parent.
-Spawn only P/C work with a concrete output and useful parent work available. Do not spawn for one command, ceremonial probes, duplicate reviews or a model quota. Batch homogeneous small work.
+Spawn only P/C work with a concrete output and useful parallel benefit. Prefer useful parent work alongside children; when the host permits, multiple independent children may run while the parent waits to synthesize and accept their results. Honor any stricter host requirement for concurrent parent work. Do not spawn for one command, ceremonial probes, duplicate reviews or a model quota. Batch homogeneous small work.
 Choose the execution mechanism before a model: local tools for fixed commands/transforms, host-supported concurrent or async tools for independent I/O, and authorized children for useful independent reasoning or implementation. Waiting on a tool alone is not a reason to create an agent. Prefer a coherent outcome with acceptance over many tiny handoffs; bound ambiguity and ownership rather than prescribing every reasoning step.
 GPT-6.1 Sol also supports native Responses Multi-agent beta. Its children share the request model/tools; the tiered route table below applies only where the host actually permits per-child selection. Read [Sol 6.1 adaptation](references/sol61-adaptation.md) before using native Multi-agent or reconciling it with host routing. Neither beta enablement nor this reference authorizes delegation.
 For queue states, integration backpressure and proactive expert formations, read [fleet scheduling](references/fleet.md).
 ## Proactive Luna fleet
 Once authorized, parallel execution is the default for ready independent work, including batches of simple coding tasks. At the first useful decomposition and after each material result or scope change, look for slices that can run alongside the parent's critical path. Dispatch those slices promptly instead of finishing the parent's entire investigation first. Do not require a complex task, a full repository map or proof of measured speedup before a clearly useful split.
 - Fan out bounded Luna assignments by independent evidence source, module or settled file/semantic ownership. Useful lanes include source inventory, sibling-use checks, artifact comparison, focused review and small settled coding changes. Delegate validation only when those checks are needed. Batch tiny items by outcome; several simple batches can justify several Luna workers even when each item alone would stay local.
 - Keep a small ready queue. Use as many actually available child slots as useful independent work and parent review capacity support; there is no fixed one-child or two-child ceiling. Reserve the parent when the host counts it. For example, four total active slots permit at most three concurrent children alongside the parent, not an unlimited fleet.
 - Refill available capacity when a result is handed back: accept/triage it, reuse an eligible idle child or dispatch the next ready slice. Do not wait for a whole wave if another independent slice is ready. Verify actual capacity; completed or interrupted does not necessarily mean released.
 - The parent owns contract decisions, cross-result synthesis and acceptance, and advances a parent-suitable critical-path slice when one is available. Integrate incrementally. If review backlog, conflicting ownership, I/O contention or rate limits becomes the bottleneck, reduce new dispatch and drain it.
 - One owner per file AND shared semantic contract. Parallel disjoint writes only when the host permits them; shared registries, integration and external gates remain serial. Read-only workers also need stable baselines and coordinated mutable sessions.
 - Choose Sol directly for slices requiring open-ended investigation or design, and Astra for the hardest synthesis. A fleet is a capacity strategy, not an instruction to force every task onto Luna or to duplicate the same review.
 Stay local for a single trivial task, no useful parallel benefit, an immediate dependency with no independent work, or inadequate host support. Judge a batch as a whole before using the trivial-task exception. State the relevant reason briefly when a requested parallel run cannot proceed; do not produce a routing report for every small task. Standing authorization does not authorize recursive unbounded fan-out, new user-owned tasks, configuration changes or external writes.
 ## Select a supported route explicitly
 | Work shape | Initial route |
 | --- | --- |
-| Known-source collection, fixed checks, logs | Luna low/medium |
+| Known-source collection, fixed checks, logs | GPT-6 Luna low; medium for multi-step work |
-| Bounded classification, conversion, settled patch with fixed checks | Luna high |
+| Bounded classification, conversion, settled patch with fixed checks | GPT-6 Luna medium; high for local reasoning |
-| Everyday implementation, debugging, locating/correlating artifacts | Terra medium; high when needed |
+| Everyday implementation, debugging, locating/correlating artifacts | GPT-6.1 Sol medium |
-| Bounded complex analysis, design or financial/security evidence | Sol medium; high when needed |
+| Bounded complex analysis, design or financial/security evidence | GPT-6.1 Sol medium/high |
-| Hardest independent synthesis across code, tools and research | Astra medium; high when needed |
+| High-leverage difficult design, cross-system synthesis, independent high-impact counterexample review | GPT-6 Astra medium/high |
 | Shared decisions, integration and external/final gates | Current parent, serial |
-These are starting heuristics, not measured cost rankings. Pick sufficient capability directly; do not escalate through every model. Missing access/data and tool failures need diagnosis, not a stronger model. After two same-class failures, pause that slice and return the evidence to the parent.
+Luna is the first candidate when inputs are bounded, the contract is settled, correctness is cheaply checkable, and failure is contained. Settled means the required behavior and ownership are clear, not that the parent has already located every edit or done the worker's investigation. A bounded read-only question can be ready while implementation contracts remain open. A short diff can still hide a shared semantic decision. Use Sol directly when investigation, design choices or cross-file causal reasoning dominate. Use Astra directly for the hardest independent synthesis when expected quality or saved rework justifies it. Do not make high/max Luna a mandatory step before Sol.
-Use the lowest adequate supported effort. Use xhigh/max for a concrete depth need or an explicit compatible role requirement; ultra only when exposed and justified by the workload. Model choice and working role are separate. A role named "explorer" is not proof of sandbox isolation.
+These are starting heuristics, not measured task-cost rankings. Lower prices broaden the useful Luna workload; fill supported capacity with useful work under existing authorization, never infer extra host slots from price. Pick sufficient capability directly; do not escalate through every model. Missing access/data and tool failures need diagnosis, not a stronger model. After two same-class failures, stop that slice and return the evidence to the parent; escalate earlier when the contract no longer fits. Preserve useful evidence on handoff instead of restarting discovery.
 Resolve exact IDs from the child-tool schema: prefer `gpt-6-luna`, `gpt-6.1-sol`, `gpt-6-astra` only when exposed. Sol means GPT-6.1 Sol in recommended routes; `gpt-6-sol` and GPT-5.6 models are explicit compatibility choices, not aliases. Use [routing boundaries](references/routing-matrix.md) when a preferred route is absent; do not silently substitute an explicitly required version. A role bound to GPT-6 Sol or GPT-5.6 Luna keeps that exact binding despite its name.
 Retire Terra from recommended routes and automatic fallbacks: Sol owns ordinary implementation and investigation. Preserve explicitly pinned models and existing configuration; editing this skill does not authorize rewriting them.
 Use the lowest adequate supported effort. GPT-6.1 Sol's API supports low/medium/high/xhigh/max, not none/minimal. Preserve a supported effort when migrating; use low as the starting point for a previously unsupported none/minimal setting and verify representative work. Use none only for straightforward extraction/conversion on a model and host that expose it, such as GPT-6 Luna; low/medium are the usual starts for tool work. Use xhigh/max for a concrete depth need or an explicit compatible role requirement; ultra only when exposed and justified by the workload, never inferred from API support. Model choice and working role are separate. A role named "explorer" is not proof of sandbox isolation.
 At dispatch, specify model AND effort when the host permits selection. Otherwise omitted settings may inherit the parent or configured defaults. Prefer a self-contained contract and no history fork; use bounded history only when necessary. Respect full-history/override incompatibilities. Never claim prompt text changed a runtime parameter.
@@ -50,20 +85,28 @@ Use the first authorized, low-risk real child task as the capability observation
 Treat workspaces as shared unless isolation is confirmed. Tool schemas may lack per-child sandbox, timeout, role or close controls. Contract limits remain instructions, not enforced capabilities. No adequate child route: keep feasible work local and disclose the gap.
-Read [runtime and configuration](references/platforms.md) only for configuration/CLI diagnosis. Read [routing boundaries](references/routing-matrix.md) for ambiguous choices or live artifact collection.
+Read [runtime and configuration](references/platforms.md) only for configuration/CLI diagnosis. Read [routing boundaries](references/routing-matrix.md) for ambiguous choices, legacy fallbacks or live artifact collection; read [model economics](references/model-economics.md) for dated prices and cost calibration.
 Read [GPT-6 adaptation](references/gpt6-adaptation.md) when async execution, steering, context recovery or dynamic effort changes affect the workflow. API features are not automatically Desktop/CLI capabilities; use only exposed controls.
 For 6.1-specific request compatibility, native tool-result attribution and compaction limits, read [Sol 6.1 adaptation](references/sol61-adaptation.md). Native Multi-agent's automatic compaction is not compatible with standard single-agent dynamic effort updates; choose a supported mode rather than combining every feature.
 ## Dispatch, observe, accept
-Give a compact contract: goal/symptom; baseline and non-goals; read/write/forbidden paths and semantic owner; requested model/effort/working role and real isolation; permitted actions; acceptance; return evidence; escalation. Include a time/checkpoint budget when useful, but do not call it an enforced timeout unless the host supplies one.
+For ordinary bounded work, give a short contract: outcome, relevant baseline, file AND semantic ownership/action limits, and sufficient acceptance/return evidence. Specify supported model/effort in the tool call; keep the real child ID and state. Add isolation details, checkpoints or an expert packet only when the task needs them. Do not require a formal report before a useful simple dispatch or call an advisory budget an enforced timeout.
 Read [lifecycle](references/lifecycle.md) before a multi-round or cancellation-sensitive run. Keep child IDs, ownership, state and acceptance in a small ledger. Send running agents only incremental context; reuse idle agents for follow-up; interrupt obsolete work and verify its state. Never infer completion from a wait timeout or slot release from interruption. Only call close if that tool exists.
-Ask for bounded facts, paths, changes, real check outcomes, gaps and escalation. Review artifacts/diffs and provenance; resolve conflicts from original evidence, not votes. Reuse checks only for the same relevant baseline, artifact and environment. Before delivery verify no unneeded child remains running or writing.
+Ask for changed paths or findings, relevant real check outcomes and remaining gaps. Review artifacts/diffs and provenance; resolve conflicts from original evidence, not votes. Reuse checks only for the same relevant baseline, artifact and environment. Check integration risks introduced by combining patches; do not repeat each worker's entire suite or investigation. Before delivery verify no unneeded child remains running or writing.
-Use [evidence packets](references/evidence-packet.md) when structured evidence is required, a run is material, or identity is disputed. Ordinary bounded work can return concise prose with the same relevant facts; do not generate ceremonial JSON for every local decision. The validator checks structure, not truth or semantic correctness.
+Use [evidence packets](references/evidence-packet.md) when an explicit consumer requires structure or disputed identity/provenance needs an audit trail. Ordinary bounded work returns concise prose with the relevant facts; a large batch or long run alone does not require JSON. The validator checks structure, not truth or semantic correctness.
 ## Context and ownership discipline
 Read [escalation and adjudication](references/escalation.md) for unresolved causal/design uncertainty, repeated failures, consequential shared-contract changes or material counterexamples. Routine checkpoints do not require another review round. Preserve issue IDs and failure counts across agents. Repair missing inputs first; adjudicate by reproducible evidence, not model rank. The parent must understand and verify decisive conclusions. Continue expert rounds only with evidence-based progress, and recover to an adequate cheaper route after resolution.
 Load only needed references; keep long logs on disk. Avoid whole-history forks and repeating contracts, packets or prior findings. Account for parent context/reasoning, child usage, waiting, retries and integration when evaluating cost.
 After steering or context compaction, recover the current objective, accepted corrections, permissions, baseline, file/semantic owners and pending tool/child IDs before continuing dependent work. Retain valid completed evidence; revalidate only results affected by the change. A queued correction is not proof that a running writer has stopped or adopted it.
 Production read-only collection is routable by work shape; mutation and final semantic acceptance stay parent-owned. Do not silently relax a project's literal model-owner requirement. Identify the actual rule and resolve it only through authorized changes.
@@ -0,0 +1,41 @@
 # Verification scope and causal repair
 Use when validation is expanding without a clear reason, a bug may reflect a shared mechanism, or parent/worker checks overlap. These decisions apply to local and authorized delegated work. Preserve mandatory project checks and existing functional/security requirements.
 ## Choose sufficient evidence, then stop
 Choose checks by behavior and consequence, not diff length or how many tools are available. For a small task, make this choice directly; no written test plan or risk report is needed.
 | Change shape | Sufficient starting point |
 | --- | --- |
 | Text, presentation or reversible local edit with no executable behavior change | Inspect the diff/result and relevant format or resource checks; no new unit tests or unrelated build by default |
 | Bounded behavior change or local bug | Reproduce/check the affected behavior and nearest relevant boundary; use existing targeted tests where adequate |
 | Shared contract, authorization, persistence, financial correctness or difficult rollback | Check the changed invariants, affected consumers and relevant integration/failure paths; run required broader checks |
 A short patch can belong in the last row. A large mechanical edit can remain bounded. Add a regression test when it protects an actual recurring failure or contract; do not add tests that merely copy wording or implementation.
 Expand only when the current evidence misses a named affected invariant, a relevant check fails, a counterexample remains, or the change/environment invalidates prior evidence. Before another build, review, fuzz run or suite, identify what new decision its result can change. If no such gap exists, stop. Do not create extra checks solely to give idle workers something to do.
 Completion requires evidence covering the intended behavior, mandatory checks passed (or a clearly reported limitation), and no unresolved material contradiction. Unknown optional counters/model identity do not justify more testing unless explicitly required. Report a real verification gap without inventing a pass; hypothetical unrelated edge cases do not prevent delivery.
 ## Reuse worker verification
 Return changed paths/findings, the relevant command/result and any gap. Trustworthy outcomes can be reused when the checked files, relevant dependencies, artifact and environment match. The parent inspects the patch and coverage; parent responsibility does not require duplicate execution.
 After integration, check new interactions and changed dependencies. An unrelated documentation edit does not invalidate a parser test. An overlapping shared-contract change does invalidate affected worker checks. If writers or shared mutable state made the artifact unstable, pin it or wait and run the affected checks once. Do not run a broad suite independently in every worker and again in the parent by default.
 ## Repair the demonstrated failure class
 At the first substantive bug, trace the failing behavior to its owner and briefly inspect nearest sibling callers/consumers. A local typo with an obvious cause can end with a local correction; it does not need an architecture audit.
 Broaden diagnosis when evidence shows repeated caller exceptions, duplicated fallback/retry logic, inconsistent producer/consumer assumptions, stale/generated state, or patch A breaking invariant B. Distinguish implementation defects, contract/design defects, workflow/ownership defects and missing environment inputs. Use the smallest discriminating check when competing causes imply different repairs.
 Choose the smallest complete repair at the layer that owns the cause. Update demonstrated affected consumers/generated outputs and remove superseded workarounds within scope. Do not mask an invariant violation with another catch, retry, default value or caller-specific branch unless that behavior is the intended contract. A temporary mitigation may be appropriate when the user requests it or a full repair is currently blocked; state its limits and remaining cause.
 Verify the original failure and a representative sibling/boundary when the repair addresses a shared mechanism. Inspect additional affected sites where evidence warrants it; do not scan or refactor unrelated systems. For a material fix, summarize cause, demonstrated impact, repair layer and sufficient checks in a few sentences. No formal root-cause report is needed for routine work.
 ## Keep simple delegation simple
 Once authorized, independent routine work is a normal Luna workload. The parent settles shared behavior/ownership, while workers can locate local edits and perform the necessary targeted checks. Give a batch a coherent outcome and a small return; avoid loading escalation, cost and packet references for every worker.
 For example, independent UI copy corrections, bounded adapter fixes under an agreed interface, and a sibling-use inventory may run in separate owned lanes. Three parts of one changing registry need one owner. Ten literal replacements that one command can perform need that command. A shared design decision stays with the parent or a separately authorized bounded investigation.
@@ -0,0 +1,43 @@
 # Sol-led escalation and evidence adjudication
 Recommend GPT-6.1 Sol / medium for new general engineering sessions; preserve an explicit user selection. The selected parent owns planning, difficult implementation, integration and acceptance. Sol handles routine implementation and investigation; Luna handles settled, checkable work. Terra is retired from recommendations and automatic fallbacks. Astra contributes proactive high-leverage analysis and residual hard reasoning when additional depth over Sol is useful, without becoming a mandatory stage for every task. Official near-Astra positioning does not prove equivalence on a particular task. These are hypotheses to calibrate, not benchmark results.
 ## Reassess at observable checkpoints
 Reassess when causal/design uncertainty remains, a key check fails, a consequential shared contract changes or a material counterexample appears. Routine planning and acceptance do not require an extra expert review. On the first substantive bug, inspect the cause and nearest sibling uses as described in [causal repair](engineering-workflow.md); do not wait for repeated failure to notice a shared defect. Track a material issue with a stable issue ID and baseline. Counters follow the issue across retries, replacement agents and model changes. After two same-class acceptance failures, pause that slice and classify before another attempt. A serious counterexample or unsafe assumption triggers immediately.
 | Observation | First response |
 | --- | --- |
 | Missing inputs, access, tool failure | Diagnose environment or obtain evidence; model escalation does not repair access |
 | Material requirement ambiguity | Inspect consumers/contracts; ask the user only for unresolved product choices |
 | Different root causes imply different fixes | Design the smallest discriminating check |
 | Repeated caller exceptions, duplicated workarounds or producer/consumer disagreement | Trace shared cause and ownership; repair the demonstrated failure class at its owning layer before adding another special case |
 | Conflicting records or stale baseline | Reconcile original evidence; suspend the dependent conclusion |
 | Fixes alternate between breaking invariants | Revisit shared contract and integration ownership |
 | High impact with no reliable verifier | Block affected acceptance/action; seek a verifier or explicit product decision |
 Continue independent authorized work while the affected slice is paused. A lack of information, authorization or tools is not a reasoning failure.
 ## Choose the intervention
 1. Repair the contract, baseline, inputs or verifier first. Reuse an appropriate idle agent; do not reset failure history by respawning.
 2. Increase execution capability when a well-specified slice exceeds the worker: Luna to Sol as justified, or Astra directly for the hardest independent synthesis. Select the adequate model directly, without visiting every tier. Effort, model and concurrency are independent controls.
 3. Select Astra directly when a difficult architectural choice affects many downstream tasks, competing consequential designs need discrimination, cross-system evidence needs synthesis, or an independent counterexample search materially protects a high-impact change. Repeated failure is not required. State the uncertainty, consequence of a wrong decision, available evidence and concrete expert deliverable. Residual difficult reasoning conflicts remain a valid trigger. Missing access alone is not a trigger. Authorized delegation and an independent bounded consultation are still required; the parent advances useful independent work when available and retains the shared decision. Where the host permits, useful parallel consultations may run while the parent waits for later adjudication; honor stricter host requirements. An immediate parent dependency stays local; requesting a child or writing configuration does not switch the live parent. If the parent cannot proceed reliably, describe the required capability/evidence instead of claiming a switch occurred.
 An expert packet contains: issue ID, exact relevant baseline, goal, invariants, original evidence references, competing hypotheses, discriminators attempted or explicitly not yet run, and one focused question. For proactive work, zero failures is valid. Request counterexamples, a discriminating check, conditional conclusions and unresolved points. Supply only necessary context. No implementation writes unless separately assigned a disjoint write contract.
 Bound each expert assignment by its question, deliverable and exit condition, not a universal one-consultation quota. Continue with the same suitable expert while new evidence, a testable refinement or a specific prior omission supports progress; record the basis for each additional round. An unresolved topic alone does not justify repetition. If no discriminating progress is available, pause that topic, obtain the missing input/check or return the decision to the parent. Do not loop reviews until models agree. Time/checkpoint budgets are instructions unless enforced by the host.
 ## Adjudicate by evidence
 Normalize baseline and convert disagreement into falsifiable claims. Compare reproducible checks, original records and applicable contracts; confirm the check actually covers the disputed invariant. Neither majority vote nor a more expensive model wins automatically. A material unresolved counterexample from any model blocks the affected acceptance.
 The selected parent (normally Sol) must map a decisive suggestion to the actual changes and invariants, understand the reasoning and verify it on the relevant current baseline. Otherwise the result remains unaccepted, even if Astra approves. User product tradeoffs remain user decisions; expert advice grants no permissions. Changed requirements invalidate relevant previous conclusions and require fresh validation.
 ## Record and recover
 For material failures keep a compact record: issue ID, baseline, trigger/failure class, same-class failure count, facts, reassessment, escalation reason, evidence-based decision, remaining gaps and recovery route. Ordinary successful work needs no ceremonial record. After resolution, return execution to the lowest adequate route; do not retain Astra for unrelated follow-up work.
 The optional [decision validator](../scripts/validate_decision_record.py) checks reported-state consistency only. Record schema 1 is independent of the product version and evidence-packet schema 2. It cannot prove evidence, enforce runtime gates, detect omitted issues or authenticate model identity. The parent must perform the checks. With `--previous`, it also rejects a changed issue ID, a decreasing failure count within the same class, or a decreasing cumulative expert consultation count even across class changes. A class change must be an evidence-based reclassification, not a counter reset tactic.
 Required fields are demonstrated in the source repository's `examples/decisions/resolved.json`. `evidence` contains nonempty references, not copied logs. `status` is investigating, blocked, escalated or resolved. Resolving requires current-baseline passed verification, parent understanding and no unresolved items. Environment/authority issues cannot target Astra; repeated failures require reassessment; repeated expert consultations require a follow-up basis. The scalar `followup_basis` describes the current continuation; retain prior records for prior rounds. The validator cannot establish progress in each round from one aggregate record. A recovery route is required at resolution. Unknown observed model identity remains acceptable unless an explicit identity gate applies.
@@ -1,6 +1,6 @@
 # Evidence Packet v2
-Use structured packets for material runs, identity disputes or an explicit consumer requirement. Concise prose is sufficient for ordinary work when it preserves the relevant evidence.
+Use structured packets when an explicit consumer requires them or disputed identity/provenance needs an audit trail. Ordinary work returns concise facts, changed paths, relevant check outcomes and gaps. Batch size or duration alone does not require JSON; preserve truthful evidence without adding a reporting ceremony. Packet schema and validator compatibility remain unchanged.
 ## Contract
@@ -30,7 +30,7 @@ This fragment illustrates shape; it is not a real tool receipt:
  "tool": "collaboration.spawn_agent",
  "child_id": "synthetic-child",
  "status": "completed",
-  "requested": {"model": "gpt-5.6-terra", "role": "explorer", "effort": "medium"},
+  "requested": {"model": "gpt-6.1-sol", "role": "explorer", "effort": "medium"},
  "observed": {"model": "unknown", "role": "unknown", "effort": "unknown"},
  "identity_source": "unknown"
 }
@@ -0,0 +1,47 @@
 # Proactive fleet scheduling
 Use for authorized parallel work, including several independent batches of simple coding tasks. This is a decision procedure for the parent, not a background scheduler, permission grant or capacity override. Preserve the actual host schema, selected parent and final gates.
 ## Discover and dispatch early
 After minimum goal/baseline discovery, identify independent questions and useful implementation slices. Do not finish reading every subsystem before dispatching ready investigations. Once a slice's input contract is stable, it may enter implementation while unrelated investigation continues. Shared decisions stay with the parent; preliminary independent drafts are not accepted contracts.
 Simple work is a reason to consider Luna. Judge parallel value across the ready batch, not each tiny item alone. A worker can locate local edit sites under agreed behavior and ownership; the parent need not pre-solve its task. For routine work, a short outcome/baseline/ownership/acceptance contract and concise result suffice. Use formal records only when required. A fixed one-command transformation still belongs in tools.
 Maintain a compact queue: task ID, dependency and contract baseline, file AND semantic owner, shared resources, acceptance, requested route, child ID, observed runtime state and integration state. Mark pending, ready, running, returned, accepted, blocked or superseded as task states; keep actual host state separate. Ready means the prerequisites, ownership and permitted actions are established and the output has independent value.
 At intake, dependency resolution, a child return or a meaningful baseline change:
 1. Invalidate affected assumptions and identify ready slices. Prioritize work that unlocks dependencies, avoids costly wrong decisions or yields directly usable implementation.
 2. Check live capacity and integration load. Dispatch multiple independent ready tasks with useful parallel benefit; prefer concurrent parent work, but allow the parent to wait for later synthesis when the host permits. Honor stricter host requirements for concurrent parent work. Avoid sequential startup followed by unnecessary waits. Every descendant counts against the actual host limit. Children may not recursively expand the fleet without a parent-assigned bounded delegation scope and capacity allocation.
 3. Continue the parent's independent critical work when available. Use incremental messages for running children and reuse suitable idle ones. Do not perform the same assigned investigation locally merely to stay busy.
 4. Inspect returned evidence and partial writes; integrate serially. Refill available capacity with ready work without waiting for all siblings. A returned result is not necessarily accepted or a released slot; follow actual lifecycle controls.
 If the next action is immediately dependent on an unassigned task, keep it local. A previously independent task may become a dependency as work progresses; bounded waiting is then legitimate. No independent useful parent work means do not create a ceremonial side task to justify another spawn.
 ## Choose a formation for the task
 First identify whether execution uses host-managed per-child routes or [native Responses Multi-agent](sol61-adaptation.md). Native mode uses the request's model/tools across the tree; use several focused Sol lanes there, not fictional Luna/Astra child overrides. The formations below describe work ownership; mixed models require actual host support.
 - Independent investigation: several focused investigators may cover distinct sources, consumers or falsifiable hypotheses. They should not all produce the same broad summary.
 - Settled implementation: multiple GPT-6 Luna workers own bounded, independently checkable coding batches under agreed behavior, including simple adapter, UI or local consistency fixes. Use GPT-6.1 Sol directly when causal investigation or design judgment dominates. Shared registries, schema and generated outputs require one owner even when paths differ.
 - Difficult consequential decision: an Astra specialist analyzes the bounded uncertainty while the parent and other workers advance unaffected work. Gate dependent implementation on the parent's accepted contract. Read [expert intervention](escalation.md) for triggers and progress-based continuation.
 - Independent review: assign a stable commit/artifact and the relevant requirements, without supplying the parent's preferred verdict. Review can overlap unrelated work; stale observations must be rechecked before acceptance.
 There is no mandatory model ratio or permanent reviewer slot. Use several workers of the same adequate model when the tasks warrant it. If Astra is already the selected parent, do not add another Astra just to fulfill a role label. Reuse the parent capability unless a genuinely independent bounded perspective adds value.
 ## Backpressure and recovery
 Choose a working width up to actual available capacity based on ready independent work, parent integration capacity and shared-resource limits. Do not reserve slots mechanically or fill them with artificial work. Hardware, service rate limits and tool sessions can constrain useful width below the agent limit.
 When returned patches are accumulating faster than the parent can inspect, or a returned contract blocks other slices, pause new dependent implementation and prioritize integration. When collisions, stale baselines, repeated rework or resource contention appear, stop affected dispatch and reduce width; interrupt obsolete/conflicting writers and inspect partial changes. Independent read-only work may continue if useful and resource-safe. Resume expansion after the cause is resolved and ready work remains.
 Never run acceptance tests against a moving artifact and report them as final. Pin a commit/snapshot or wait until relevant writers stop; a worktree alone does not isolate external databases, generated directories or shared sessions. Before merge/delivery, resolve material counterexamples, verify the integrated baseline and audit the agent tree for remaining writers.
 Reuse checks from workers when the relevant checked artifact/dependencies/environment remain valid. Parent integration checks cover newly introduced interactions and mandatory project requirements, not a repeat of every worker's suite. Do not create more validation/review lanes solely to fill capacity. Follow [verification scope](engineering-workflow.md) and stop when sufficient evidence is complete.
 ## Evaluate effectiveness
 Optimize accepted quality and end-to-end time subject to the user's cost constraints. Include parent work, all children, context duplication, retries, expert rounds and integration in cost measurements. Expensive early reasoning can be worthwhile when it prevents downstream rework; cheap high-volume workers can be wasteful when contracts are unsettled. Both are hypotheses until measured.
 For a calibration exercise compare the same tasks and baselines at serial and increasing supported widths, varying granularity separately. Include decomposable and contract-heavy tasks, failures and repeated runs. Record quality, elapsed time, total exposed usage/cost, rework, and integration time; unknown counters or runtime model identity stay unknown. Do not claim speed/cost improvements from static scenarios or a successful single rollout.
@@ -0,0 +1,43 @@
 # GPT-6 workflow adaptation
 Checked 2026-09-23. Read only when these capabilities affect the task. This reference adapts the routing policy; it does not configure a harness or grant permissions.
 GPT-6.1 Sol migration checked 2026-10-06: use the exact `gpt-6.1-sol` ID only when the relevant host exposes it. Preserve supported effort; its API rejects none/minimal and requires Responses for tools. Start at low when replacing an unsupported effort and verify representative work. [Model specifications](https://developers.openai.com/api/docs/models/gpt-6.1-sol) and [migration guidance](https://developers.openai.com/api/docs/guides/latest-model?model=gpt-6.1-sol) take precedence over older GPT-6 Sol assumptions. The workflow capability sections below retain their own original verification date; do not infer per-model or host support from family membership.
 Read [Sol 6.1 adaptation](sol61-adaptation.md) for native Responses Multi-agent beta and its distinct tool, history and compaction contracts. The single-agent effort procedure below must not be combined with that mode.
 ## Prompt shape and task granularity
 The official [skills and prompts guidance](https://developers.openai.com/blog/rethinking-skills-and-prompts-for-gpt-6-astra) recommends precise discovery descriptions, progressive disclosure and fewer rigid recipes. Apply that here by giving a goal, constraints, ownership and acceptance; leave implementation choices open unless a contract or fragile operation requires an exact procedure. Put API mechanics here instead of expanding every task prompt.
 [GPT-6 guidance](https://developers.openai.com/api/docs/guides/latest-model) highlights Astra's stronger instruction following, long-task coherence and tendency to ask clarifying questions or over-test. Keep authorized routine choices autonomous, resolve real instruction conflicts explicitly, and stop validation once relevant checks pass unless new evidence warrants more. These are Astra observations; evaluate their usefulness for Sol/Luna rather than claiming equal behavior. More capability does not authorize delegation.
 ## Async tools: overlap useful work
 [Async tool calling](https://developers.openai.com/api/docs/guides/async-tool-calling) lets GPT-6 continue independent work while an application executes a function/custom tool; API definitions use `async: true`, with results paired to the original `call_id`. Background response generation is a different mechanism.
 In Codex, use the host's exposed job/session IDs, wait and cancellation controls. Track pending work only as needed: ID, owner, baseline, dependency, last state and result. Continue unrelated work while waiting, but do not consume an absent result or declare completion with a required job outstanding. Mutable shared state and dependencies still require serialization. A JavaScript Promise or a shell job is not proof of API async support.
 Prefer a fixed tool batch for enumerable reads and transformations. Use a child when the independent slice needs judgment and delegation is authorized. Do not spawn a child simply to wait on another tool. In an API application, the application must execute and reconcile jobs; prompt text cannot add that machinery.
 ## Steering: preserve progress, reconcile side effects
 [Mid-turn steering](https://developers.openai.com/api/docs/guides/steering) is documented for GPT-6 over Responses WebSockets. Acceptance queues the update; it does not cancel running tools, undo writes or establish that the model acted on it.
 Treat a user correction as a delta to the active objective. Keep compatible work and accepted evidence. Tell affected children the changed constraint; if ongoing writes conflict, use actual interruption controls, inspect partial changes and verify state before assigning a replacement owner. Reassess late results against the corrected contract and baseline before integration. A status question does not cancel work. Cancellation ends obsolete work, not the obligation to report actions already taken.
 The Desktop/CLI message and interruption tools have their own semantics; do not emit WebSocket events through tools that lack those fields. A successful message-send receipt proves delivery/queuing only to the extent the host reports it.
 ## Effort and context continuity
 [Reasoning configuration updates](https://developers.openai.com/api/docs/guides/reasoning#change-reasoning-mid-conversation) support changing effort between responses in GPT-6 standard single-agent mode. They do not switch model or change a child binding. Keep request-level effort unchanged for cache continuity; record updates in order. The response's effort field still reports the request-level value. Updates cannot be adjacent or combined with automatic compaction/truncation; `/responses/compact` rejects such histories. The documented explicit `compaction_trigger` route requires a fresh effort update after compaction. Recheck compatibility before implementing.
 In Codex, do not claim to change active effort without a supported control and receipt. Choose supported effort when dispatching an authorized child. Missing controls are a host limitation, not a reason to launch a nested CLI or edit global configuration.
 For long tasks, retain a compact operational checkpoint when needed: goal, corrections, authorization, baseline, completed evidence, next dependency, owners and pending IDs. Preserve actual tool state and required conversation items; a prose summary is not an API tool result. After host compaction, resume from that state rather than rereading everything or repeating accepted work. Large context capacity is not a reason to fork full history into every child.
 ## Existing capabilities and boundaries
 The [GPT-6 family guide](https://developers.openai.com/api/docs/guides/latest-model) identifies computer use, structured outputs, programmatic tool calling, multi-agent orchestration, caching and compaction as continuing capabilities, not all newly introduced in GPT-6. Use structured tools and deterministic code where they fit; use visual/browser tools when UI evidence is actually needed. Confirm host access and shared browser/session ownership. Neither a screenshot nor a passing schema validator proves end-to-end correctness.
 The guide's misalignment monitoring is provider-side safety behavior associated with Astra, not a prompt-enabled self-review mode or a substitute for parent acceptance. Do not claim it is available identically for all routes.
@@ -16,6 +16,16 @@ Read before multi-round coordination, cancellation, or capacity diagnosis. Names
 A minimal ledger records child ID, P/C classification, file/semantic ownership, dependency, requested route, last observed state and acceptance. Do not invent timestamps, identities or close events.
 ## Steering and pending tools
 On a correction, update the affected contract and preserve unaffected evidence. Sending an incremental message does not establish that a running child or tool has adopted it. If its writes now conflict, interrupt through available controls, verify the state and inspect partial changes before transferring ownership. Review late results against the current contract and baseline; do not integrate them merely because they completed successfully.
 Keep required async tool jobs in the same dependency view as children, using their actual job/session/call IDs. While waiting, advance independent work; before dependent acceptance, collect the real result. Steering and child interruption need not cancel external jobs. Cancel obsolete jobs through the host when supported, otherwise track/report the remaining state. Never resubmit a potentially mutating call solely because its receipt is delayed.
 After context compaction, recover objective, permissions, owners, pending IDs and accepted evidence before dispatching more work. Detailed API-versus-host limits are in [GPT-6 adaptation](gpt6-adaptation.md).
 For rolling execution, use [fleet scheduling](fleet.md): refill ready work after useful handbacks and dependency changes, rather than waiting for every sibling. Check integration backlog before starting more implementation. Task readiness, output acceptance and actual slot availability remain separate facts.
 ## Cancellation and handback
 Interrupting does not undo files or guarantee descendant cancellation. First preserve useful returned evidence, stop affected writers, inspect partial changes, then assign the remaining work to one owner. Never reset shared files wholesale.
@@ -0,0 +1,33 @@
 # Model economics
 Read for cost-sensitive routing or when revising defaults. Checked 2026-10-06; recheck official prices before a later price-dependent decision. This is an API reference snapshot, not a Codex subscription quota or billing estimate.
 ## Verified price basis
 USD per million tokens, Standard processing, prompts up to 272K input tokens:
 | Exact model ID | Input | Cached input | Cache write | Output |
 | --- | ---: | ---: | ---: | ---: |
 | gpt-6-luna | 0.10 | 0.01 | 0.125 | 0.50 |
 | gpt-6.1-sol | 2.00 | 0.10 | 2.50 | 10.00 |
 | gpt-6-astra | 10.00 | 1.00 | 12.50 | 50.00 |
 Source: [OpenAI pricing](https://developers.openai.com/api/docs/pricing). At equal token volumes, Luna is 1/20 of GPT-6.1 Sol for input, cache writes and output, and 1/10 for cached input. GPT-6.1 Sol is 1/5 of Astra for input, cache writes and output, and 1/10 for cached input. Luna is 1/100 of Astra in all four categories. These are arithmetic price ratios, not observed savings, speed or success rates.
 Long prompts above 272K input tokens charge 2x input/cache rates and 1.5x output for the full request. Processing tier, tools and regional processing can change the bill. Do not multiply Codex subscription usage by API prices or assume a Desktop service tier follows the Standard table.
 Compared with [GPT-6 Sol](https://developers.openai.com/api/docs/models/gpt-6-sol), GPT-6.1 Sol keeps input/output rates at 2.00/10.00 and halves cached input from 0.20 to 0.10. This improves the cached-input rate, not necessarily the total cost of a task; token use, retries and cache hits still matter. Older Sol remains a compatibility choice, not an alias.
 ## Design implications
 Official positioning: [Luna](https://developers.openai.com/api/docs/models/gpt-6-luna) targets focused, high-volume work; [GPT-6.1 Sol](https://developers.openai.com/api/docs/models/gpt-6.1-sol) offers near-Astra performance for complex coding, computer use and professional work at a lower price; [GPT-6 guidance](https://developers.openai.com/api/docs/guides/latest-model) places Astra at the highest capability level. This is official positioning, not a benchmark performed by this project. GPT-6.1 Sol documents API efforts low/medium/high/xhigh/max, not none/minimal; GPT-6 Luna and older GPT-6 Sol support none. Actual child models, efforts and role bindings must still come from the host schema.
 The engineering policy is three routes: Luna for bounded, settled, cheaply verifiable work; Sol for implementation and investigation requiring judgment; Astra for the hardest independent synthesis. Retire Terra from recommendations and automatic fallbacks: Sol absorbs its former workload and avoids maintaining another routing boundary. This is a routing design choice, not a measured claim that Sol dominates every Terra workload. Price alone does not establish that Luna can perform open-ended development reliably.
 ## Measure accepted work
 Compare the same task shape and acceptance standard. Include parent context/reasoning, every child's usage, tools, retries, parent review and reintegration. For API estimates apply the actual rate to each billed category, including billed reasoning/output tokens without double-counting; keep wall time separate. With unknown usage or billing tier, report unknown cost and observable proxies instead of fabricated savings.
 A cheaper child helps only if its savings exceed added orchestration and correction. One avoided parent investigation may matter more than many cheap child tokens. Do not turn a token-rate ratio into a retry allowance, a fan-out quota or permission to duplicate reviews. Keep concurrency tied to useful independent work and actual host capacity.
 Broaden Luna assignments after comparable accepted results demonstrate stable quality and lower total effort. Move a task shape directly to Sol when ambiguity, repeated correction or parent rework dominates. For a new generation, use the first authorized useful bounded task as evidence; synthetic parser tests and static scenario reviews cannot establish model quality or latency.
@@ -19,21 +19,27 @@ For clients that support the documented keys, an example is:
 ```toml
 # Example only; merge intentionally into the existing configuration.
-model = "gpt-6-astra"
+model = "gpt-6.1-sol"
 model_reasoning_effort = "medium"
 [agents]
-default_subagent_model = "gpt-5.6-terra"
+default_subagent_model = "gpt-6.1-sol"
 default_subagent_reasoning_effort = "medium"
 max_concurrent_threads_per_session = 3
 ```
 This is not an automatic router, permission grant or universal host configuration. Never overwrite an existing config to install this example. Preserve user model/provider choices and verify the actual client accepts the keys. Per-agent configuration and host overrides may change resolution.
 The Sol default assumes GPT-6.1 Sol is exposed and suits mixed engineering work. Resolve parent and child availability separately: a model in the picker does not prove child support. Explicitly route bounded tasks to GPT-6 Luna where supported; do not make Luna a universal fallback for arbitrary inherited work. If 6.1 is unavailable, use the [compatibility routes](routing-matrix.md). A fixed `sol_*` or `luna_*` role may still bind an older model: inspect the binding, then use an overridable role if available and appropriate. Do not rename or claim to upgrade a fixed role through prompt text.
 For an authorized migration, preserve a supported effective effort. GPT-6.1 Sol's API accepts low/medium/high/xhigh/max and rejects none/minimal; use low as an initial replacement for those settings and check representative work. Tool calling requires Responses; its Chat Completions support is without tools. Desktop/CLI controls, including Ultra, must be checked separately against the actual host; do not copy them into API requests. Installation does not apply any of these configuration changes.
 The official Codex configuration describes the child-thread limit as excluding the parent. A collaboration tool may expose a different active-slot count including the parent. Use that live tool's counting and release semantics; do not copy either number blindly.
 When selecting a route, explicitly request model and effort with a compatible fork mode if supported. Check omitted-setting inheritance, custom-agent bindings and override restrictions. A prompt cannot implement an unsupported model switch.
 Native Responses Multi-agent beta is a separate mechanism: children share the request model and tools, and its active-descendant limit excludes root. Codex host schemas may expose per-child model overrides and different slot semantics. Select the actual mechanism first; do not put API beta fields into Codex TOML or promise cross-model native children. See [Sol 6.1 adaptation](sol61-adaptation.md) for beta opt-in, history handling and incompatible request options.
 ## Diagnosis and safe fallbacks
 Resolve the executable actually used by the relevant client, inspect its help/schema and record its version when needed. Do not prescribe speculative CLI flags or launch model calls merely to print a marker. Use an authorized real task to verify child execution.
@@ -47,3 +53,5 @@ Configuration changes may require a fresh session or explicit reload. Writing a
 ## Sources
 Checked 2026-09-14: [Codex subagents](https://learn.chatgpt.com/zh-Hans/docs/agent-configuration/subagents), [OpenAI model catalog](https://developers.openai.com/api/docs/models). Recheck changed product/API facts before altering real configuration.
 Model recommendation and migration checked 2026-10-06: [Codex models](https://learn.chatgpt.com/docs/models), [GPT-6.1 Sol](https://developers.openai.com/api/docs/models/gpt-6.1-sol), [migration guidance](https://developers.openai.com/api/docs/guides/latest-model?model=gpt-6.1-sol). Configuration keys above retain their original reference date; the current client schema takes precedence.
@@ -4,19 +4,37 @@ Read only when the entrypoint leaves a routing choice unresolved.
 | Boundary | Decision |
 | --- | --- |
-| Many easy tasks | Batch bounded Luna/Terra slices; volume alone does not justify Astra. |
+| Many easy tasks | Partition independent bounded Luna batches across available capacity; size batches to keep coordination and acceptance useful. Volume alone does not justify Astra. |
-| Ordinary cross-file bug | Terra; file count alone does not justify escalation. |
+| Ordinary cross-file bug | GPT-6.1 Sol; file count alone does not justify Astra. |
 | Small patch with settled semantics and deterministic acceptance | GPT-6 Luna medium/high if failure is contained; parent checks the diff and behavior. |
 | Small patch changes authentication or a shared schema contract | Parent settles shared decisions; bounded investigation may use Sol. Small size is not evidence of low ambiguity. |
 | Cheap Luna attempts require repeated parent rewrites | Choose Sol directly next time for this shape; count total accepted-task cost. |
 | Difficult accounting discrepancy | Sol reasoning; parent owns the semantic decision. |
 | Coupled architecture across runtimes and tools | Consider Astra directly; keep shared decisions serial. |
 | Difficult choice would constrain many downstream slices | Consider an early bounded Astra analysis; gate dependent work on the parent's accepted contract. |
 | High-impact stable change needs independent counterexamples | Consider Astra review when depth adds value; give original requirements and a fixed artifact, not a preferred verdict. |
 | Expert makes testable progress over several rounds | Continue the scoped topic with incremental evidence; do not impose a one-call quota or repeat unchanged questions. |
 | Missing credential or inaccessible source | Resolve the evidence/environment gap; model escalation cannot supply access. |
 | Astra advertised only for task creation | Child support remains unproven; do not create another user task as a workaround. |
 | Named role fixes model/effort | Accept its supported binding or choose an overridable role; never attach prohibited fork overrides. |
 | Repository requires Sol parent | A Sol child cannot replace that owner; preserve the gate until an authorized supported change. |
 | Accepted output, unknown child model | Accept only after normal parent checks; do not attribute the result to the requested model. |
 ## Legacy and mixed hosts
 Check each route independently. The API catalog does not update an existing session's tool schema.
 | Unavailable preferred route | Supported compatibility choice |
 | --- | --- |
 | GPT-6 Luna | GPT-5.6 Luna low/medium for fixed collection/checks, high for settled transformations or patches; otherwise Sol or local work. |
 | GPT-6.1 Sol for implementation/investigation/complex analysis | GPT-6 Sol medium/high, or GPT-5.6 Sol medium/high when that is the adequate exposed route; otherwise local work. |
 | GPT-6 Astra | An adequate supported Sol route or local work; disclose a capability gap if neither suffices. |
 These are work-shape fallbacks, not capability equivalence claims or a mandatory sequence of model attempts. Terra is retired from recommended routes and automatic fallbacks; do not select it merely because a legacy host exposes it. Preserve an explicit user-pinned model or existing configuration until an authorized change. If a required model/version is unavailable, report the exact gap before dependent dispatch; a GPT-6 Sol pin must not silently become GPT-6.1 Sol. Never invent `gpt-6-terra`. A mixed host may use GPT-6.1 Sol and GPT-5.6 Luna, or GPT-6 Sol when 6.1 is absent, without reverting every route. Record the exact requested ID and fallback reason. Unknown observed identity stays unknown.
 ## Production Artifact Collection
- Luna: use known hosts/endpoints/paths and fixed selectors to read or download actual reports, JSON, logs or job outputs; verify size/hash, parseability, required fields and specified counts. Terra: locate the current output through bounded read-only investigation, diagnose retrieval failures, or correlate logs and artifacts by run/version. Do not launch both by default; use Terra only when discovery or diagnosis is needed.
+- GPT-6 Luna: use known hosts/endpoints/paths and fixed selectors to read or download actual reports, JSON, logs or job outputs; verify size/hash, parseability, required fields and specified counts. GPT-6.1 Sol: locate the current output through bounded read-only investigation, diagnose retrieval failures, or correlate logs and artifacts by run/version. Do not launch both by default; use Sol only when discovery or diagnosis is needed. Apply the compatibility table when these routes are unavailable.
 - Contract: name the production source, expected run/date/version, allowed read operations, bounded time/range/volume, local destination and acceptance checks. Reuse approved access and applicable server tools. Keep secrets out of prompts/receipts. Remote access stays read-only; explicitly allow local artifact writes even for a collector role.
 - Evidence: preserve the actual downloaded artifact and record source, retrieval time/timezone, producer run/version and generation time when exposed, local path, bytes/hash and check results. Unknown provenance stays unknown. Verify the expected run/freshness; mtime or successful download alone does not prove current output. Use immutable run identifiers where possible; detect/retry boundedly if files change during collection.
 - No fixture, cache or old snapshot may stand in for requested live output. If the current artifact is missing, stale, inconsistent or inaccessible, report that gap. Do not trigger jobs, regenerate artifacts, restart services, change permissions/configuration or deploy as part of collection; return such remediation to the parent under existing authorization.
@@ -30,4 +48,4 @@ Use actual usage counters when exposed. Otherwise report observable proxies (cha
 If context dominates, narrow inputs and avoid full-history forks. If output dominates, bound logs and returns. If reasoning/retries dominate, clarify acceptance and choose adequate capability/effort directly. Preserve required tests and material findings.
-Official model positioning checked 2026-09-14: [Models](https://developers.openai.com/api/docs/models). The route table is an engineering starting strategy, not a measured cost ranking. Runtime tool schemas remain the source for actual child availability.
+Official model positioning checked 2026-10-06: [GPT-6.1 Sol](https://developers.openai.com/api/docs/models/gpt-6.1-sol), [Codex models](https://learn.chatgpt.com/docs/models). See [model economics](model-economics.md) for the dated API price basis. The route table is an engineering starting strategy, not a measured task-cost ranking. Runtime tool schemas remain the source for actual child availability.
@@ -0,0 +1,43 @@
 # GPT-6.1 Sol workflow adaptation
 Checked 2026-10-06. Read for native Responses Multi-agent, API migration, or long-running Sol work. This skill configures no runtime and supplies no delegation authorization.
 ## Native Multi-agent beta
 [Official Multi-agent documentation](https://developers.openai.com/api/docs/guides/responses-multi-agent) establishes these API facts:
 - Enable with `multi_agent.enabled` and the `responses_multi_agent=v1` beta opt-in. Children share the request model and tools; this cannot implement a Luna/Sol/Astra mixture within one request.
 - `max_concurrent_subagents` counts active descendants across the tree, excluding root; its default is 3. Do not transfer that counting rule to a different host.
 - Hosted `multi_agent_call` actions execute server-side. Client code handles `function_call` from every agent, pairing outputs by `call_id`.
 - HTTP continuation must preserve the returned items. WebSocket can inject completed function outputs; track injection acknowledgements. If the response already completed, continue with the returned unaccepted output rather than re-executing its tool.
 - Preserve agent attribution and encrypted messages for replay. Present the root's `final_answer`, keeping worker text separate. Response completion is not artifact acceptance or proof of a child's model identity.
 - `/responses/compact`, `reasoning.summary`, and `max_tool_calls` are unsupported. Automatic compaction runs per agent. Do not combine this mode with single-agent dynamic effort updates.
 Recheck beta schemas before implementation; an available model alone does not establish a compatible SDK, gateway or client.
 ## Select the mechanism before dispatch
 The following are this project's engineering choices, not additional API capabilities:
 | Work / available mechanism | Routing decision |
 | --- | --- |
 | Fixed reads, transforms or one slow external operation | Use direct/concurrent tools; another agent does not remove the I/O dependency. |
 | Independent reasoning with native API Multi-agent available and authorized | Use bounded same-model Sol lanes; root resolves cross-lane decisions. |
 | Work benefits from different model tiers | Use actual host per-child selection or an explicitly scoped application orchestrator; do not fake a native child override. |
 | Shared mutable contract, deterministic ordered graph or immediate dependency | Keep it serial; native delegation remains optional. |
 Existing ownership, failure-count and acceptance rules apply to both mechanisms. Separate context is not separate filesystem or tool authority. Since native children share tools, a read-only assignment is not an enforced sandbox. The application must enforce permitted actions before executing client tools. Keep external gates parent-owned; a worker's proposal is not permission to perform them.
 Define a useful outcome, baseline, file AND semantic owner, permitted actions, acceptance and escalation. Give Sol room to investigate and implement a coherent slice instead of prescribing a long chain of microtasks. Retain only relevant evidence in each context. Independent investigations can compare hypotheses; overlapping patches still need one owner. Parent review capacity limits useful width even when the API permits more descendants.
 ## Request compatibility and long-task continuity
 [Migration guidance](https://developers.openai.com/api/docs/guides/latest-model?model=gpt-6.1-sol) requires supported effort and Responses for tools. With 6.1's reasoning enabled, remove `temperature`, `top_p`, `top_logprobs`, Chat Completions `logprobs`, and Responses `message.output_text.logprobs` includes. These are request compatibility changes, not permission to rewrite unrelated settings.
 [Dynamic effort updates](https://developers.openai.com/api/docs/guides/reasoning#change-reasoning-mid-conversation) apply to standard single-agent mode. Preserve request-level effort and ordered updates; automatic compaction/truncation is incompatible. Do not use this mechanism to claim per-child effort changes in native Multi-agent. For native mode, retain per-agent conversation items through its compaction; for Codex, recover actual pending IDs and owners after host compaction.
 Async tools, steering and context recovery remain covered in [GPT-6 adaptation](gpt6-adaptation.md); they are family workflow capabilities, not newly invented 6.1 features. Use supported controls and verify adoption before dependent work. Keep stable instructions and append bounded task deltas where appropriate, but preserve required tool/history items; cheaper cached input does not justify copying every conversation into every worker.
 ## Acceptance evidence
 Validate a real integration with a small authorized independent task before expanding it: attribute every tool call, return each result once, retain history, check the final artifact and audit remaining work. Compare accepted quality, end-to-end time, retry/review cost and actual usage against the existing route. Static documentation and synthetic fixtures cannot prove beta availability, runtime identity, speed or cost improvements.
@@ -0,0 +1,103 @@
 #!/usr/bin/env python3
 """Validate reported decision consistency, not evidence truth or live execution."""
 import argparse
 import json
 from pathlib import Path
 import sys
 def validate(record, previous=None):
    errors = []
    if not isinstance(record, dict):
        return ["record must be an object"]
    for key in ("issue_id", "baseline", "failure_class", "status"):
        if not isinstance(record.get(key), str) or not record[key].strip():
            errors.append(key + " must be nonempty text")
    if type(record.get("schema_version")) is not int or record["schema_version"] != 1:
        errors.append("schema_version must be 1")
    if record.get("failure_class") not in ("environment", "authority", "contract", "implementation", "reasoning"):
        errors.append("invalid failure_class")
    if record.get("status") not in ("investigating", "blocked", "escalated", "resolved"):
        errors.append("invalid status")
    count = record.get("same_class_failures")
    if type(count) is not int or count < 0:
        errors.append("same_class_failures must be a nonnegative integer")
    elif count >= 2 and not text(record.get("reassessment")):
        errors.append("repeated failure requires reassessment")
    for key in ("evidence", "unresolved"):
        value = record.get(key)
        if not isinstance(value, list) or any(not text(item) for item in value):
            errors.append(key + " must be a list of nonempty references/issues")
    escalation = record.get("escalation")
    if not isinstance(escalation, dict):
        errors.append("escalation must be an object")
        escalation = {}
    target = escalation.get("target")
    if target not in ("none", "terra", "sol", "astra"):
        errors.append("invalid escalation target")
    if target != "none" and not text(escalation.get("reason")):
        errors.append("escalation requires a reason")
    if target == "astra" and record.get("failure_class") in ("environment", "authority"):
        errors.append("Astra cannot repair environment or authority")
    consultations = escalation.get("expert_consultations")
    if type(consultations) is not int or consultations < 0:
        errors.append("expert_consultations must be a nonnegative integer")
    elif consultations > 1 and not text(escalation.get("followup_basis")):
        errors.append("additional consultation requires new evidence or a specific omission")
    if record.get("status") == "escalated" and target == "none":
        errors.append("escalated status requires a target")
    if record.get("status") == "resolved":
        verification = record.get("verification", {})
        if not isinstance(verification, dict):
            verification = {}
        if (verification.get("status") != "passed"
                or verification.get("baseline") != record.get("baseline")
                or verification.get("parent_understands") is not True):
            errors.append("resolution requires understood, passed verification on current baseline")
        if record.get("unresolved") != [] or not record.get("evidence"):
            errors.append("resolution requires evidence and no unresolved items")
        if not text(record.get("recovery_route")):
            errors.append("resolution requires a recovery route")
    if previous is not None:
        if not isinstance(previous, dict):
            errors.append("previous record must be an object")
        else:
            if previous.get("issue_id") != record.get("issue_id"):
                errors.append("issue_id changed across continuation")
            old = previous.get("same_class_failures")
            if (previous.get("failure_class") == record.get("failure_class")
                    and type(old) is int and type(count) is int and count < old):
                errors.append("failure counter decreased within the same class")
            previous_escalation = previous.get("escalation")
            old_consultations = (previous_escalation.get("expert_consultations")
                                 if isinstance(previous_escalation, dict) else None)
            if type(old_consultations) is not int or old_consultations < 0:
                errors.append("previous expert_consultations must be a nonnegative integer")
            elif (type(consultations) is int and consultations >= 0
                    and consultations < old_consultations):
                errors.append("expert consultation counter decreased across continuation")
    return errors
 def text(value):
    return isinstance(value, str) and bool(value.strip())
 def main():
    parser = argparse.ArgumentParser(description=__doc__)
    parser.add_argument("record")
    parser.add_argument("--previous")
    args = parser.parse_args()
    try:
        record = json.loads(Path(args.record).read_text(encoding="utf-8"))
        previous = json.loads(Path(args.previous).read_text(encoding="utf-8")) if args.previous else None
        errors = validate(record, previous)
    except (OSError, ValueError) as exc:
        print("Invalid decision record: " + str(exc), file=sys.stderr)
        return 1
    print("\n".join(errors) if errors else "Decision record consistency passed (truth not verified)")
    return int(bool(errors))
 if __name__ == "__main__":
    sys.exit(main())
@@ -0,0 +1,116 @@
 import copy
 import importlib.util
 import json
 from pathlib import Path
 import unittest
 ROOT = Path(__file__).resolve().parents[1]
 spec = importlib.util.spec_from_file_location("decision", ROOT / "skills/codex-subagent-router/scripts/validate_decision_record.py")
 module = importlib.util.module_from_spec(spec)
 spec.loader.exec_module(module)
 class DecisionTests(unittest.TestCase):
    def setUp(self):
        self.record = json.loads((ROOT / "examples/decisions/resolved.json").read_text())
    def test_valid_resolution(self):
        self.assertEqual(module.validate(self.record), [])
    def test_counter_survives_continuation(self):
        previous = copy.deepcopy(self.record)
        self.record["same_class_failures"] = 0
        self.assertTrue(module.validate(self.record, previous))
    def test_reassessment_required(self):
        self.record["reassessment"] = ""
        self.assertTrue(module.validate(self.record))
    def test_unresolved_counterexample_blocks_resolution(self):
        self.record["unresolved"] = ["reproducible contrary result"]
        self.assertTrue(module.validate(self.record))
    def test_stale_baseline_blocks_resolution(self):
        self.record["verification"]["baseline"] = "old"
        self.assertTrue(module.validate(self.record))
    def test_parent_must_understand(self):
        self.record["verification"]["parent_understands"] = False
        self.assertTrue(module.validate(self.record))
    def test_environment_and_authority_do_not_escalate_to_astra(self):
        for category in ("environment", "authority"):
            self.record["failure_class"] = category
            self.record["escalation"]["target"] = "astra"
            self.assertTrue(module.validate(self.record))
    def test_zero_failure_proactive_astra_consultation(self):
        self.record["failure_class"] = "reasoning"
        self.record["status"] = "investigating"
        self.record["same_class_failures"] = 0
        self.record["reassessment"] = ""
        self.record["escalation"] = {
            "target": "astra",
            "reason": "Proactive review of a high-impact architectural choice.",
            "expert_consultations": 1,
            "followup_basis": "",
        }
        self.record["unresolved"] = ["expert consultation pending"]
        self.assertEqual(module.validate(self.record), [])
    def test_more_than_three_progressive_consultations(self):
        self.record["escalation"]["expert_consultations"] = 4
        self.record["escalation"]["followup_basis"] = "new discriminator results across rounds"
        self.assertEqual(module.validate(self.record), [])
    def test_multiple_consultations_need_basis(self):
        self.record["escalation"]["expert_consultations"] = 2
        self.assertIn(
            "additional consultation requires new evidence or a specific omission",
            module.validate(self.record),
        )
    def test_consultation_counter_cannot_decrease_across_class_change(self):
        previous = copy.deepcopy(self.record)
        previous["escalation"]["expert_consultations"] = 4
        previous["escalation"]["followup_basis"] = "prior progressive rounds"
        self.record["failure_class"] = "reasoning"
        self.record["escalation"]["expert_consultations"] = 3
        self.record["escalation"]["followup_basis"] = "current evidence"
        self.assertIn(
            "expert consultation counter decreased across continuation",
            module.validate(self.record, previous),
        )
    def test_consultation_counter_can_increase_with_basis(self):
        previous = copy.deepcopy(self.record)
        previous["escalation"]["expert_consultations"] = 1
        self.record["escalation"]["expert_consultations"] = 4
        self.record["escalation"]["followup_basis"] = "new discriminator results"
        self.assertEqual(module.validate(self.record, previous), [])
    def test_malformed_previous_consultation_counter_is_rejected(self):
        previous = copy.deepcopy(self.record)
        previous["escalation"]["expert_consultations"] = True
        self.assertIn(
            "previous expert_consultations must be a nonnegative integer",
            module.validate(self.record, previous),
        )
    def test_recovery_required(self):
        self.record["recovery_route"] = ""
        self.assertTrue(module.validate(self.record))
    def test_bad_shapes_and_boolean_counters(self):
        for value in (None, [], True):
            self.assertTrue(module.validate(value))
        self.record["same_class_failures"] = True
        self.assertTrue(module.validate(self.record))
    def test_unhashable_enum_fields_are_rejected(self):
        for key in ("failure_class", "status"):
            record = copy.deepcopy(self.record)
            record[key] = []
            self.assertTrue(module.validate(record))
        self.record["escalation"]["target"] = {}
        self.assertTrue(module.validate(self.record))
@@ -30,7 +30,7 @@ class EvidenceTests(unittest.TestCase):
    def test_known_identity_requires_host_evidence(self):
        packet = fixture()
        child = packet["tool_receipts"][0]
-        child["observed"]["model"] = "gpt-5.6-terra"
+        child["observed"]["model"] = "gpt-6-sol"
        with self.assertRaisesRegex(ValueError, "host evidence"):
            evidence.validate(packet)
        child["identity_source"] = "host-tool-result"
Author	SHA1	Message	Date
kakan	bb29bba8e0	Merge pull request '2.4.0：最小充分验证、因果修复与简单任务 Luna 并行' (#6 ) from codex/engineering-flow-v2.4.0 into main	2026-10-14 22:21:55 +08:00
kakan	9b54653033	Right-size verification, repair shared causes, and dispatch routine Luna work Plugin-Submission: d77fbfc482bf93fdb2203b097c07d51b2f01d3e7c29ed776305b9f3d38b35075	2026-10-14 22:16:15 +08:00
kakan	2c0741f88f	Merge pull request 'Release 2.3.1: follow task boundaries without category-based reconfirmation' (#5 ) from codex/task-boundaries-v2.3.1 into main	2026-10-11 10:05:22 +08:00
kakan	8e753e7204	Honor task boundaries without category-based reconfirmation Plugin-Submission: 376a2e62cb9798570173a95497ab405cf980872a40c3c42f358d083c5af2d63c	2026-10-11 09:48:20 +08:00
kakan	d1dabc10f6	Merge PR #4 : Release 2.3.0	2026-10-06 04:40:58 +00:00
Kakan	28b0bf4535	Adapt Sol 6.1 native multi-agent and workflow compatibility	2026-10-06 12:38:40 +08:00
Kakan	369384a3eb	Prepare 2.3.0 with GPT-6.1 Sol preferred routing	2026-10-06 12:35:10 +08:00
kakan	9474064daf	Merge PR #3 : Release 2.2.0	2026-09-23 02:45:57 +00:00
Codex Agent	14c43d0a60	Integrate 2.1 workflow and prepare release 2.2.0	2026-09-23 10:44:41 +08:00
Codex Agent	3a9d09eafc	Redesign GPT-6 routing and proactive Luna fleet workflow	2026-09-23 10:24:00 +08:00
kakan	b50021499d	Merge PR #2 : 2.1.0 proactive Astra and rolling fleet scheduling	2026-09-15 15:52:50 +00:00
Codex	e66dcc1810	Develop 2.1.0 proactive Astra intervention and rolling fleet scheduling	2026-09-15 23:51:54 +08:00
kakan	e2fbb211b6	Merge PR #1 : Release 2.0.0	2026-09-15 13:21:08 +00:00
Codex	dc0360cefb	Release 2.0.0 with Sol-led escalation and evidence adjudication	2026-09-15 21:17:41 +08:00