Back to Details

parallel-orchestration

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Parallel Orchestration

并行编排

Layer: Operating Model + Skill
非自明な実装をdependency graphへ分解し、Readyまたはstack-readyなnodeをresource/WIP制約内で安全に並行実行する。
Constitutional requirementは「1 worker = 1 particular sandbox」ではなく Mutable Ownership Safety / Identity Integrity / Organizational Continuity である。current modelはisolated mutable runtime + immutable snapshot/result + fencing identity（現在はgeneration-based fencing）でこれを実現する。
より強いagent/runtimeが同等以上のguaranteeを別mechanismで提供する場合は、ADR-0017のrefinement contractに従って置換できる。Worker / Supervisor のlogical roleと observational / mutable / durable attempt の分類は 
organization/execution-roles.md
と ADR-0019 をcanonical sourceとする。Herdrをselected runtime Practiceとして使う場合は 
herdr-runtime
Skillを適用するが、Herdr lifecycle stateをcanonical task/result stateにしない。
层级：Operating Model + Skill
将非平凡实现分解到 dependency graph 中，并在 resource/WIP 约束内安全地并行执行 Ready 或 stack-ready 的 node。
Constitutional requirement 并非「1 worker = 1 particular sandbox」，而是 Mutable Ownership Safety / Identity Integrity / Organizational Continuity。current model 通过 isolated mutable runtime + immutable snapshot/result + fencing identity（目前为 generation-based fencing）来实现这一点。
如果更强的 agent/runtime 通过其他 mechanism 提供同等或更强的 guarantee，则可以依据 ADR-0017 的 refinement contract 予以替换。Worker / Supervisor 的 logical role 与 observational / mutable / durable attempt 分类，以 
organization/execution-roles.md
和 ADR-0019 为 canonical source。将 Herdr 用作 selected runtime Practice 时，应应用 
herdr-runtime
Skill，但不得将 Herdr lifecycle state 作为 canonical task/result state。

Attempt-class routing

Attempt-class 路由

spawn前にroleだけでなくexecution attempt classを決める。
  • observational: research / exploration / independent review / read-only diagnostics。source/runtimeのmutable ownershipを持たない限りbranch / Draft PR / sandbox / fencing / durable checkpointを要求しない。
  • mutable: independent implementationやstateful execution。明示的mutable-ownership boundary、base/result identity、stale result rejectionを要求する。
  • durable: Issue-level / long-running / background / remote execution。mutable要件に加えてdurable discoverability、checkpoint/recovery、fencingを要求する。
観測用subagentがsourceを変更し始めた場合はmutableへ、session/provider lossを越えて継続すべきworkになった場合はdurableへpromotionする。
spawn 前不仅确定 role，还要确定 execution attempt class。
  • observational：research / exploration / independent review / read-only diagnostics。除非拥有 source/runtime 的 mutable ownership，否则不要求 branch / Draft PR / sandbox / fencing / durable checkpoint。
  • mutable：independent implementation 或 stateful execution。要求具备明确的 mutable-ownership boundary、base/result identity 和 stale result rejection。
  • durable：Issue-level / long-running / background / remote execution。除 mutable 要求外，还需要 durable discoverability、checkpoint/recovery 和 fencing。
如果 observational subagent 开始修改 source，应将其提升为 mutable；如果任务需要跨越 session/provider loss 继续执行，则应提升为 durable。

Current operating guarantees

当前运行保障

  • concurrent mutable implementation workerごとにisolated runtime、serialization、transaction等の明示的mutable-ownership boundaryを持つ。current defaultは1 worker = 1 isolated mutable runtime。
  • shared working tree / Git index / integration branchを複数workerが直接更新しない。
  • parent -> child はimmutable snapshot。
  • child -> parent はimmutable commit/ref/diff + validation result。
  • sandbox lifecycleはworker外のSupervisorが管理する。
  • worktree単体をexecution isolationとみなさない。
  • WSL/LinuxでSupervisorがlocal branchをworktreeへmaterializeする場合は
    worktree-workflow
    Skillに従ってWorktrunkを使用できるが、各workerのruntime isolationとimmutable result contractは別に維持する。
  • durable planning unitはGitHub Issue、短命な内部subtaskはSupervisor taskとしてよい。
  • Issue dependency graphがdurable dependency SoTであり、Git branch topologyだけでdependencyを管理しない。
  • child lifecycleはparent model processではなくSupervisorが所有する。
  • durable worker task/resultはstale attemptを排除できるfencing identityを持つ。current implementationでは 
    execution_generation
    を使用し、初期generationは 
    1
    、recovery/reassignment時にSupervisorが原子的に進める。
  • result統合前にapplicableなcurrent fencing identityとの一致を検証し、stale identityを統合しない。
  • validation resultはvalidated SHA/snapshotにpinし、stack rebase/update後の別SHAへ流用しない。
  • long-running task / context limit / sandbox recreationでは 
    agent-recovery
    Skillを適用する。
  • security-audit
    のcandidate validationではhunterとverifierを同一agentにせず、fresh verifierへimmutable candidate/evidenceを渡す。final record verificationが必要なprofileでも同じseparationを維持する。
  • spawn前に 
    policy-evaluation
    Skillのexecution profileを判定し、mechanical / localized taskへ不要なfan-outを導入しない。
  • 每个并发 mutable implementation worker 都必须具有 isolated runtime，以及 serialization、transaction 等明确的 mutable-ownership boundary。current default 是 1 worker = 1 isolated mutable runtime。
  • 多个 worker 不得直接更新 shared working tree / Git index / integration branch。
  • parent -> child 使用 immutable snapshot。
  • child -> parent 使用 immutable commit/ref/diff + validation result。
  • sandbox lifecycle 由 worker 之外的 Supervisor 管理。
  • 不将单个 worktree 视为 execution isolation。
  • 在 WSL/Linux 中，当 Supervisor 将 local branch materialize 到 worktree 时，可以依照 
    worktree-workflow
    Skill 使用 Worktrunk，但仍须分别维持每个 worker 的 runtime isolation 和 immutable result contract。
  • durable planning unit 是 GitHub Issue，短生命周期的内部 subtask 可以是 Supervisor task。
  • Issue dependency graph 是 durable dependency 的 SoT，不能仅通过 Git branch topology 管理 dependency。
  • child lifecycle 由 Supervisor 拥有，而不是 parent model process。
  • durable worker 的 task/result 必须带有能够排除 stale attempt 的 fencing identity。当前实现使用 
    execution_generation
    ，初始 generation 为 
    1
    ，在 recovery/reassignment 时由 Supervisor 原子推进。
  • 在集成 result 前，验证其与 applicable 的 current fencing identity 一致；不得集成 stale identity。
  • validation result 必须固定到 validated SHA/snapshot；stack rebase/update 后不得将其复用于其他 SHA。
  • 遇到 long-running task / context limit / sandbox recreation 时，应用 
    agent-recovery
    Skill。
  • 在 
    security-audit
    的 candidate validation 中，hunter 与 verifier 不得由同一 agent 承担；应向 fresh verifier 传递 immutable candidate/evidence。即使 profile 要求 final record verification，也应维持相同的职责分离。
  • spawn 前根据 
    policy-evaluation
    Skill 判定 execution profile，避免为 mechanical / localized task 引入不必要的 fan-out。

Execution profile routing

Execution profile 路由

orchestration strengthはtask sizeの印象ではなくexecution profileから決める。
  • mechanical
    : solo executionをdefaultとし、deterministic tooling / focused validationを優先する。
  • localized
    : bounded scopeをsoloで進め、必要なvalidationと、policy/user-visible riskがある場合のcold final reviewを追加する。
  • cross-boundary
    : dependency graphへ分解し、安全なnodeのみparallelizeする。candidate artifact完了後はbuilderと分離したindependent cold reviewを必須とする。
  • judgment-heavy
    : evidence / reference / acceptance rubricを先に固定し、candidate artifact完了後はbuilderと分離したindependent cold reviewを必須とする。
複数profileに該当する場合はsafeguardを合成する。特に 
cross-boundary
かつ 
judgment-heavy
のtaskはdependency decomposition / safe parallelismとevidence/rubric-first executionの両方を適用し、combined routingをorchestration前に記録する。
execution profileは 
quality-gate
のverification risk taxonomyを置換しない。orchestration/review強度とtest levelを別々に決定する。
orchestration 强度应根据 execution profile 决定，而不是根据对 task size 的主观印象。
  • mechanical
    ：默认采用 solo execution，并优先使用 deterministic tooling / focused validation。
  • localized
    ：以 solo 推进 bounded scope，补充必要的 validation，并在存在 policy/user-visible risk 时增加 cold final review。
  • cross-boundary
    ：分解到 dependency graph 中，仅并行化安全的 node。candidate artifact 完成后，必须进行与 builder 分离的 independent cold review。
  • judgment-heavy
    ：先固定 evidence / reference / acceptance rubric。candidate artifact 完成后，必须进行与 builder 分离的 independent cold review。
如果一个 task 同时符合多个 profile，应组合相应的 safeguard。尤其是同时属于 
cross-boundary
和 
judgment-heavy
的 task，必须同时采用 dependency decomposition / safe parallelism 与 evidence/rubric-first execution，并在 orchestration 前记录 combined routing。
execution profile 不会替换 
quality-gate
的 verification risk taxonomy。orchestration/review 强度与 test level 必须分别决定。

Adaptive fan-out / fan-in

自适应 fan-out / fan-in

fan-outはagent数ではなくadmitted progressを最適化する。まず smallest useful fan-out（独立して価値を出せる最小数）で開始し、各fan-in boundaryで再評価する。
mode:
  • independent decomposition: Ready / stack-readyな独立nodeを並行実行する。
  • competitive exploration: uncertain problemへ複数のobservational candidateを独立に作らせる。多数決ではなくevidence / measurement / validationで比較する。
  • specialist separation: builder / reviewer / benchmark / security等を責務分離する。
  • speculative execution: reviewable immutable predecessor snapshotへexact pinできる場合だけ先行する。predecessor変更時はstaleとしてreconcileする。
competitive mutable implementationは、各attemptが独立mutable ownership boundary、同一base/input identity、immutable result contractを持つ場合だけ許可する。満たせなければobservational explorationまたは直列implementationへ縮退する。
追加spawnはReady work、uncertainty、WIP、provider/host resource、human review、CI/external wait、retry/stale率、回収costを見て判断する。idle capacityだけを理由にworkを分割しない。追加Workerのmarginal valueよりorchestration/integration bottleneckが大きい場合はfan-outを止める。
短命でparent内部に閉じるhelperはnative subagentを優先する。independent lifecycle / mutable ownership / background continuity / provider separation / human attachが必要ならtop-level Workerへ昇格する。Herdrを使う場合の具体mappingは 
herdr-runtime
に従う。
fan-in時はtask/attempt/base/fencing/result identityとapplicable evidenceを確認する。複数agentの同意だけをcorrectness evidenceにしない。
fan-out 的目标是优化 admitted progress，而不是 agent 数量。首先采用 smallest useful fan-out，即能够独立产生价值的最小数量，并在每个 fan-in boundary 重新评估。
模式：
  • independent decomposition：并行执行 Ready / stack-ready 的独立 node。
  • competitive exploration：针对不确定的问题，让多个 observational candidate 独立产出；通过 evidence / measurement / validation 进行比较，而不是采用多数决。
  • specialist separation：分离 builder / reviewer / benchmark / security 等职责。
  • speculative execution：仅当能够 exact pin 到可审查的 immutable predecessor snapshot 时才可先行。predecessor 发生变更时，将结果作为 stale 进行 reconcile。
competitive mutable implementation 仅在每个 attempt 都具有独立的 mutable ownership boundary、相同的 base/input identity 和 immutable result contract 时才允许。否则，应退回到 observational exploration 或串行 implementation。
是否增加 spawn，应结合 Ready work、uncertainty、WIP、provider/host resource、human review、CI/external wait、retry/stale 率和回收成本判断。不得仅因为存在空闲 capacity 就拆分 work。如果新增 Worker 的边际价值低于 orchestration/integration bottleneck，则应停止 fan-out。
对于生命周期短且封闭在 parent 内部的 helper，优先使用 native subagent。如果需要 independent lifecycle / mutable ownership / background continuity / provider separation / human attach，则提升为 top-level Worker。使用 Herdr 时的具体 mapping 应遵循 
herdr-runtime
。
fan-in 时，检查 task/attempt/base/fencing/result identity 与 applicable evidence。多个 agent 达成一致不能作为 correctness evidence。

Capacity / delivery-estimation coupling

容量与 delivery-estimation 联动

scheduleやroadmapを理由にWIP / spawn数 / agent数を増減する場合は、
agent-delivery-estimation
Skillを参照する。
orchestration側から少なくとも次の観測可能情報を提供する。
  • active agent count / WIP
  • Ready / blocked / stack-ready node数
  • task type / risk / Work Unit when calibrated
  • retry / reassignment / generation change
  • blocked duration
  • human-review queue
  • CI / integration wait
  • usage-limit / provider resource constraint
agent数増加を線形speedupとみなさない。task mixやhuman/CI bottleneckが異なる期間のthroughput差をagent数の因果効果と断定しない。
estimate達成のためにisolation、snapshot/result、fencing identity、WIP/resource safetyを弱めてはならない。安全なorchestration invariantはforecastより優先する。
如果因 schedule/roadmap 原因需要调整 WIP / spawn 数 / agent 数，应参考 
agent-delivery-estimation
Skill。
orchestration 侧至少应提供以下可观测信息：
  • 活跃 agent 数 / WIP
  • Ready / blocked / stack-ready node 数
  • task type / risk / 已校准时的 Work Unit
  • retry / reassignment / generation change
  • blocked 时长
  • human-review 队列
  • CI / integration 等待时间
  • usage-limit / provider resource constraint
不要将 agent 数增加视为线性 speedup。不同周期的 throughput 差异可能源于 task mix 或 human/CI bottleneck 不同，不能将其断定为 agent 数带来的因果效果。
不能为了满足 estimate 而削弱 isolation、snapshot/result、fencing identity、WIP/resource safety。安全的 orchestration invariant 优先于 forecast。

Dependency readiness

依赖就绪状态

nodeは次のどちらかを満たす場合にspawn可能:
  1. unfinished prerequisiteがない
  2. hard predecessorが未mergeでも、reviewable immutable predecessor snapshotがあり 
    stack-ready
    と判定できる
stack-ready
で開始する場合、worker inputへpredecessor Issue/PR identityとexact commit SHA / immutable snapshotを記録する。
predecessorが後から変更された場合はaffected downstream task/branchをstaleとして扱い、base reconciliationとrequired revalidationを行う。
node 满足以下任一条件时即可 spawn：
  1. 不存在未完成的 prerequisite。
  2. 即使 hard predecessor 尚未 merge，也存在可审查的 immutable predecessor snapshot，并被判定为 
    stack-ready
    。
以 
stack-ready
状态启动时，必须在 worker input 中记录 predecessor Issue/PR identity 以及 exact commit SHA / immutable snapshot。
如果 predecessor 后续发生变更，应将受影响的下游 task/branch 视为 stale，并执行 base reconciliation 与必要的 revalidation。

Flow

流程

  1. Issueのobjective / acceptance criteria / dependency / target releaseを読む。
  2. policy-evaluation
    に従ってexecution profileを判定し、fan-out / reviewer強度を決める。
  3. canonical Issue dependency graphからtask graphを作る。
  4. linear hard dependency segmentでstacked PRが適切かを判断する。
  5. 各nodeのinput snapshot / predecessor snapshot / output contract / recovery boundaryを決める。
  6. Supervisorがdurable taskへcurrent fencing identity（current defaultでは 
    execution_generation
    ）と実行policyを割り当ててspawnする。
  7. Readyまたはstack-readyなnodeをWIP/resource制約内でspawnする。
  8. durable ticket branchをworker/subagentが作る場合、first meaningful commitをcanonical remoteへpublishし、remote head SHA一致を確認した直後にPRを作成する。active/incompleteならDraft、readiness条件を満たしていればReady for reviewとし、published commit + PRなしでactive implementationを継続しない。
  9. meaningful boundaryでcheckpointする。
  10. worker resultをinspectし、applicableなcurrent fencing identityとbase snapshotがcurrent expected stateに一致することを確認する。
  11. Coordinator/Supervisorだけがshared durable integration stateへ順序立てて統合する。
  12. integration checkpointごとにrequired validationを行う。
  13. predecessor変更でupstack/downstream branchが更新された場合、affected validationを再実行する。
  14. Reviewerをclean candidate snapshotから起動する。cross-boundary / judgment-heavy workではbuilderのprivate reasoningではなくobjective / rubric / artifact / validation evidenceを渡すindependent cold reviewを必須とする。
  15. GitHub Issue / Project / PR metadataを実行状態と同期する。
  1. 阅读 Issue 的 objective / acceptance criteria / dependency / target release。
  2. 按照 
    policy-evaluation
    判定 execution profile，并确定 fan-out / reviewer 强度。
  3. 从 canonical Issue dependency graph 构建 task graph。
  4. 判断 stacked PR 是否适合 linear hard dependency segment。
  5. 确定每个 node 的 input snapshot / predecessor snapshot / output contract / recovery boundary。
  6. Supervisor 为 durable task 分配 current fencing identity（current default 为 
    execution_generation
    ）和执行 policy，然后 spawn。
  7. 在 WIP/resource 约束内 spawn Ready 或 stack-ready 的 node。
  8. 如果 worker/subagent 创建 durable ticket branch，应在 first meaningful commit 后将其 publish 到 canonical remote；确认 remote head SHA 与该 commit 一致后，立即创建 PR。处于 active/incomplete 状态时设为 Draft，满足 readiness 条件时设为 Ready for review。没有 published commit + PR 时，不得继续 active implementation。
  9. 在 meaningful boundary 执行 checkpoint。
  10. 检查 worker result，确认 applicable 的 current fencing identity 和 base snapshot 与 current expected state 一致。
  11. 仅由 Coordinator/Supervisor 按顺序集成到 shared durable integration state。
  12. 在每个 integration checkpoint 执行 required validation。
  13. 如果 predecessor 变更导致 upstack/downstream branch 更新，则重新执行受影响的 validation。
  14. 从 clean candidate snapshot 启动 Reviewer。对于 cross-boundary / judgment-heavy work，必须提供 objective / rubric / artifact / validation evidence，以进行与 builder 分离的 independent cold review，而不是提供 builder 的 private reasoning。
  15. 同步 GitHub Issue / Project / PR metadata 与执行状态。

Spawn contract

Spawn 契约

observational workerはobjective / scope / authority / expected evidenceの最小contractでよい。mutable workerでは次を基準とし、durable workerではfencing / recovery fieldsを必須化する。
mutable workerの最低限input:
text
issue_or_task_id
objective
acceptance_criteria
target_release
base_snapshot
predecessor_issue_or_pr
predecessor_snapshot
immediate_pr_base
branch_identity
expected_pr_identity_and_state
assignee_expectation
reviewer_expectation
label_expectation
fencing_identity_or_execution_generation
role
attempt_class
allowed_tools
filesystem_policy
network_policy
budget
expected_result
durable workerでは上記に加えて、
recovery_boundary
、durable checkpoint/evidence reference、durable discoverability metadataを必須とする。resume/recovery時は
checkpoint_sha_or_snapshot
も必須とする。
dependency / durable GitHub deliveryを使わない短命taskでは該当しないfieldはnull/omittedでよい。
budget
にはresource / cost / timeoutに加えて、childがさらにspawnできる深さと数の上限を含める。上限のないrecursive spawn（fork bomb）やunbounded costを作らない。
filesystem_policy
/ 
network_policy
はSupervisorが実際にenforceする境界を表す。policy enforcementが別のruntime/provider設定で行われる場合も、spawn contractにはそのpolicy IDまたは解決済みpolicyを記録し、worker inputと実際のsandbox制約が追跡可能でなければならない。
observational worker 可以只采用包含 objective / scope / authority / expected evidence 的最小 contract。mutable worker 应遵循以下基准，durable worker 则必须强化 fencing / recovery fields。
mutable worker 的最低 input：
text
issue_or_task_id
objective
acceptance_criteria
target_release
base_snapshot
predecessor_issue_or_pr
predecessor_snapshot
immediate_pr_base
branch_identity
expected_pr_identity_and_state
assignee_expectation
reviewer_expectation
label_expectation
fencing_identity_or_execution_generation
role
attempt_class
allowed_tools
filesystem_policy
network_policy
budget
expected_result
durable worker 除上述内容外，还必须包含 
recovery_boundary
、durable checkpoint/evidence reference 和 durable discoverability metadata。在 resume/recovery 时，还必须提供 
checkpoint_sha_or_snapshot
。
对于不使用 dependency / durable GitHub delivery 的短生命周期 task，不适用的 field 可以为 null/省略。
budget
除 resource / cost / timeout 外，还应包含 child 可继续 spawn 的深度与数量上限。不得形成无上限的 recursive spawn（fork bomb）或 unbounded cost。
filesystem_policy
/ 
network_policy
表示 Supervisor 实际 enforce 的边界。即使 policy enforcement 由另一 runtime/provider 配置执行，spawn contract 仍必须记录相应 policy ID 或 resolved policy，且 worker input 与实际 sandbox 约束必须保持可追踪。

Durable branch contract

Durable branch 契约

worker/subagentへdurable branch作成権限を与える場合、その権限はremote publication + PR state lifecycleとセットで扱う。
canonical sequence:
  1. branch作成
  2. first meaningful commit
  3. canonical remoteへcommitをpublish
  4. remote branch head SHAがfirst meaningful commit SHAと一致することを確認
  5. immediate PR creation with state matching actual work
  6. Issue linkage / assignee / reviewer / labels / target release / stack contextを設定
  7. implementation継続
GitHub上のPRはremoteでheadを解決でき、head/baseに差分がある必要があるため、branch作成・first commit・remote publication・remote head検証・PR creation/state設定を1つのoperational start procedureとして扱う。
workerがremote publishまたはPR mutation権限を持たない場合、first meaningful commit後ただちにSupervisor/Coordinatorへcontrolを返す。Supervisor/Coordinatorがcommitをpublishし、remote head SHA一致を確認し、PR作成/state設定を完了するまでそのdurable branchでの追加implementationを進めない。
Ephemeral immutable ref/resultはこのcontractの対象外。
向 worker/subagent 授予 durable branch 创建权限时，该权限必须与 remote publication + PR state lifecycle 成套处理。
canonical sequence：
  1. 创建 branch。
  2. 创建 first meaningful commit。
  3. 将 commit publish 到 canonical remote。
  4. 确认 remote branch head SHA 与 first meaningful commit SHA 一致。
  5. 立即创建 PR，并使 state 与实际工作状态一致。
  6. 设置 Issue linkage / assignee / reviewer / labels / target release / stack context。
  7. 继续 implementation。
GitHub 上的 PR 必须能够通过 remote 解析 head，且 head/base 之间必须存在差异。因此，应将 branch 创建、first commit、remote publication、remote head 验证、PR creation/state 设置视为一个 operational start procedure。
如果 worker 没有 remote publish 或 PR mutation 权限，则在 first meaningful commit 后立即将控制权交回 Supervisor/Coordinator。在 Supervisor/Coordinator 完成 commit publish、remote head SHA 验证以及 PR 创建/state 设置之前，不得在该 durable branch 上继续 implementation。
Ephemeral immutable ref/result 不受此 contract 约束。

Result contract

结果契约

observational resultはsource mutationを含まず、evidence provenanceと対象artifact identityを返す。mutable/durable workerは次を基準とする。
mutable workerの最低限output:
text
agent_id
issue_or_task_id
target_release
base_snapshot
predecessor_snapshot
fencing_identity_or_execution_generation
attempt_class
result_commit_or_ref
pr_identity (PR設定完了後は必須。それ以前の権限不足handoffではnull/omitted)
pr_state (PR設定完了後は必須。それ以前の権限不足handoffではnull/omitted)
summary
validation_results
known_issues
durable workerでは上記に加えて、
checkpoint_sha_or_snapshot
、
status
、
completed_steps
、
next_steps
、
pending_validation
、
external_side_effects
、
artifact_refs
、
updated_at
を含むrecovery handoffを必須とする。GitHub/branch deliveryの場合はpublished remote head、PR identityと実際のstate（Draft / Ready）、Issue/branch metadataも必須とする。
applicableなcurrent fencing identity（current implementationでは 
execution_generation
）と一致しないresultは自動統合しない。
recorded predecessor/base snapshotとcurrent expected baseが異なるresultはstale candidateとしてreconcileし、盲目的に統合しない。
observational result 不包含 source mutation，并返回 evidence provenance 和目标 artifact identity。mutable/durable worker 应遵循以下基准。
mutable worker 的最低 output：
text
agent_id
issue_or_task_id
target_release
base_snapshot
predecessor_snapshot
fencing_identity_or_execution_generation
attempt_class
result_commit_or_ref
pr_identity (PR設定完了後は必須。それ以前の権限不足handoffではnull/omitted)
pr_state (PR設定完了後は必須。それ以前の権限不足handoffではnull/omitted)
summary
validation_results
known_issues
durable worker 除上述内容外，还必须提供包含 
checkpoint_sha_or_snapshot
、
status
、
completed_steps
、
next_steps
、
pending_validation
、
external_side_effects
、
artifact_refs
、
updated_at
的 recovery handoff。在 GitHub/branch delivery 场景中，还必须包含 published remote head、PR identity 与实际 state（Draft / Ready），以及 Issue/branch metadata。
与 applicable 的 current fencing identity（当前实现为 
execution_generation
）不匹配的 result 不得自动集成。
如果记录的 predecessor/base snapshot 与 current expected base 不同，则将 result 视为 stale candidate 并执行 reconcile，不得盲目集成。

Landing handoff boundary

Landing 交接边界

worker / subagent の shared durable integration state への ordered landing（
release-x-y-z
への ticket landing、
release-x-y-z -> main
release PR merge、
main
への直接反映等）は Coordinator / Supervisor だけが実行する。
  • worker / subagent は target release trunk / 
    main
    への merge / landing 操作を実行せず、PR creation/state・remote publication・branch head verify・validationまで完了したcandidateをimmutable handoffする。
  • ticket-class candidateはreadiness/quality gateを満たせば追加のuser merge authorizationなしでCoordinator / Supervisorがdependency順にlandingする。
  • release-class 
    release-* -> main
    candidateはexplicit user authorizationが必要で、authorization scopeをhandoff artifactへ含める。
  • Coordinator / Supervisorはlanding直前にactual head/base/current SHAを再取得し、ticket/release classificationとrequired gateを再検証する。
この境界を越えて worker / subagent が landing 操作を実行した場合:
  • 直近 landing は stale candidate として扱う。
  • 自動rollback は前提としない。integration state への影響と reconciliation 必要性を Supervisor が reassess し、必要なら new landing 候補で再実行する。
standaloneでticket PRを扱うAgentはreadiness/quality gate通過後に自律landingできる。standaloneでrelease PRを扱うAgentはexplicit release authorizationがある場合に限り直接landingできる。
worker / subagent 对 shared durable integration state 的 ordered landing（例如将 ticket landing 到 
release-x-y-z
、merge 
release-x-y-z -> main
的 release PR、直接反映到 
main
等）仅由 Coordinator / Supervisor 执行。
  • worker / subagent 不得对 target release trunk / 
    main
    执行 merge / landing 操作；必须在完成 PR creation/state、remote publication、branch head verify 和 validation 后，以 immutable handoff 交付 candidate。
  • ticket-class candidate 如果满足 readiness/quality gate，Coordinator / Supervisor 无需额外的 user merge authorization，即可按照 dependency 顺序 landing。
  • release-class 
    release-* -> main
    candidate 需要 explicit user authorization，并且 handoff artifact 必须包含 authorization scope。
  • Coordinator / Supervisor 在 landing 前必须重新获取 actual head/base/current SHA，并再次验证 ticket/release classification 与 required gate。
如果 worker / subagent 越过此边界执行了 landing 操作：
  • 将最近一次 landing 视为 stale candidate。
  • 不预设自动 rollback。由 Supervisor 重新评估其对 integration state 的影响以及 reconciliation 的必要性，必要时使用新的 landing candidate 重新执行。
standalone 处理 ticket PR 的 Agent 在通过 readiness/quality gate 后可以自主 landing。standalone 处理 release PR 的 Agent 仅在获得 explicit release authorization 时才能直接 landing。

Review handoff

审查交接

Reviewer inputはclean candidate snapshotへpinする。
Reviewerが見るのは、requested scopeの網羅、decision precedenceとの整合、correctness / architecture consistency、regression risk、required verification levelに対するtest adequacy、validation evidenceがcurrent SHAのものか、hidden coupling、sandbox / runtimeでの再現性、target release / stack predecessorとの整合、PR metadataとIssue linkageの整合、関係する場合はrecovery / checkpointとの整合である。
PR review contextには最低限:
  • linked Issue / acceptance criteria
  • target release
  • immediate stack predecessor if any
  • current head SHA
  • validation evidence for that SHA
  • known blockers
  • expected reviewer/CODEOWNERS context
review後にhead SHAが変わった場合、古いapproval/validationがcurrent policy上有効かを再評価する。
将 Reviewer input 固定（pin）到 clean candidate snapshot。
Reviewer 应检查：requested scope 的覆盖情况、与 decision precedence 的一致性、correctness / architecture consistency、regression risk、相对于 required verification level 的 test adequacy、validation evidence 是否属于 current SHA、hidden coupling、sandbox / runtime 中的可复现性、与 target release / stack predecessor 的一致性、PR metadata 与 Issue linkage 的一致性，以及相关时与 recovery / checkpoint 的一致性。
PR review context 至少包括：
  • linked Issue / acceptance criteria
  • target release
  • immediate stack predecessor（如有）
  • current head SHA
  • validation evidence for that SHA
  • known blockers
  • expected reviewer/CODEOWNERS context
如果 review 后 head SHA 发生变化，应重新评估旧 approval/validation 在 current policy 下是否仍然有效。

Parent failure

父级失败

parent agentが停止してもsafeなchildを自動破棄しない。
recovered CoordinatorはSupervisorからchildを再発見し、running/completed/failed/orphanedをreconcileする。completed resultはimmutable snapshot/result relationship、predecessor/base identity、applicableなcurrent fencing identityを確認してから統合する。
GitHub上のIssue/PR/branch metadataはdurable recovery evidenceであり、active durable ticket branchにpublished remote head + PRがない状態を正常状態として扱わない。PRが存在する場合もactive/incompleteならDraft、readiness条件を満たしていればReady for reviewであることをreconcileする。Ready ticket PRの未landing、land済みopen Issue、merged/landed後のstale ticket branchもdriftとしてrepairする。zero-diff release branchはDraft release PR invariantの例外だが、first meaningful integrated difference後はDraft release PRを必須とし、release PRをautonomous ticket landingへ含めない。
parent agent 停止时，不自动销毁仍处于安全状态的 child。
恢复后的 Coordinator 应从 Supervisor 重新发现 child，并对 running/completed/failed/orphaned 状态进行 reconcile。集成 completed result 前，必须确认 immutable snapshot/result relationship、predecessor/base identity，以及 applicable 的 current fencing identity。
GitHub 上的 Issue/PR/branch metadata 是 durable recovery evidence。active durable ticket branch 缺少 published remote head + PR 的状态不能视为正常。即使 PR 已存在，active/incomplete 时也应为 Draft，满足 readiness 条件时则应为 Ready for review，应对这些状态进行 reconcile。
将 Ready ticket PR 未 landing、landed 后 Issue 仍 open，以及 merged/landed 后的 stale ticket branch 都视为 drift 并修复。zero-diff release branch 是 Draft release PR invariant 的例外；但在首次产生 meaningful integrated difference 后，必须创建 Draft release PR，并且 release PR 不得纳入 autonomous ticket landing。

Fallback

回退方案

isolated sandbox同士なら同じfileを触ること自体は直列化の理由にならない。直列化やdependencyが必要なのは、same interfaceの非互換変更、same generated artifact、same external mutable resourceを扱う場合である。
true isolationが使えない場合、shared mutable workspaceで並列実装しない。read-only researchの並列化または安全な直列実装へ縮退する。
stacked PRを安全に維持できない場合もdependency SoTを壊さず、predecessor merge後に通常ticketとして開始する直列workflowへ縮退する。
即使 isolated sandbox 之间会触及相同文件，这本身也不是串行化的理由。只有在处理同一 interface 的不兼容变更、同一 generated artifact 或同一 external mutable resource 时，才需要串行化或 dependency。
如果无法使用 true isolation，则不得在 shared mutable workspace 中并行实现。应退回到 read-only research 的并行化或安全的串行 implementation。
如果无法安全维护 stacked PR，也不得破坏 dependency SoT；应在 predecessor merge 后，退回到以普通 ticket 开始的串行 workflow。

Organizational outcome checks

组织成果检查

orchestrationのqualityはfan-out数や特定Supervisor APIではなく、次のoutcomeで確認する。
  • concurrent workersが互いのmutable stateを無調停に破壊しない
  • task / attempt / result identityをretry/recovery後も取り違えない
  • completed resultのevidenceがcurrent artifactへbindされる
  • parent/worker loss後もdurable stateからreconcileできる
  • dependency/authorityを無視して速さだけを最大化しない
  • orchestration overheadがtask価値を上回る場合はsolo executionへ縮退できる
current Supervisor / execution_generation / Worktrunk shapeはこれらを満たす現在のimplementationであり、永続的なAPI contractではない。
orchestration 的 quality 应根据以下 outcome 判断，而不是根据 fan-out 数量或特定 Supervisor API：
  • 并发 workers 不会无协调地互相破坏 mutable state。
  • 在 retry/recovery 后不会混淆 task / attempt / result identity。
  • completed result 的 evidence 绑定到 current artifact。
  • parent/worker loss 后仍可从 durable state 进行 reconcile。
  • 不会为了单纯最大化速度而忽略 dependency/authority。
  • 如果 orchestration overhead 超过 task 价值，可以退化为 solo execution。
当前 Supervisor / execution_generation / Worktrunk shape 满足上述要求；它是当前 implementation，而不是永久性的 API contract。