Parent-Child Process

定義

Parent-Child Process

Parent-Child Process とは、ある parent process frame が、
自らの goal、scope、governance、responsibility topology の一部を局所化して、
一つまたは複数の child process frame を生成し、
それぞれに bounded autonomy を与えたうえで、
その結果を Process Delta、evidence、unresolved issues、recommendations として回収・統合する
階層的な process 構造 である。

それは単なる subtask 分解ではなく、
goal slice、retained authority、delegated responsibility、inherited constraints、return contract、lifecycle coupling、incident / recovery propagation を持つ。

より短く言えば、Parent-Child Process とは
「大きな仕事を局所 frame に切り出しつつ、親が global goal と主要 authority を保持し、子が bounded な work を進め、その結果を親へ返す」構造 である。

PCE 2.0 において長い仕事を一つの平坦な frame で扱うと、

• context が肥大化し
• authority が曖昧になり
• handoff が雑になり
• recovery が難しくなり
• incident の blast radius が不必要に大きくなりやすい

そのため、仕事はしばしば親子の frame に分解される。
ただしその分解は、単なる工程分割ではなく、責任と統治を伴う構造分解 でなければならない。
それを表すのが Parent-Child Process である。

---

なぜ Parent-Child Process が必要なのか

PCE 2.0 が parent-child 構造を独立に扱うのは、
長時間・多主体・多段の仕事を、そのまま一つの frame に押し込むと process integrity が損なわれやすいからである。

少なくとも、次の理由がある。

1. Goal は局所化しないと扱えない

大きな feature、incident、research loop、release process などは、
そのままでは一つの actor や一つの local context に載せにくい。
子 frame に goal slice を切り出すことで、局所的に扱える。

2. Capability と visibility を狭められる

read-only analysis と write-enabled implementation、
artifact evaluation と memory writing、
incident analysis と normal execution は、同じ capability surface に置くべきではない。
child frame を切ることで bounded execution が可能になる。

3. Parent が retain すべき authority がある

親はしばしば次を保持する。

• global goal ownership
• final approval
• final merge / memory promotion path
• final incident sink
• global close authority

子に仕事を任せても、これらを無条件に渡すべきではない。

4. Failure を局所化できる

ある child frame が失敗しても、親全体を直ちに abandon する必要はない。
child の rollback、replan、retry を局所的に扱える。

5. Handoff と recovery を強くできる

parent→child、child→parent の return contract があることで、

• handoff loss を減らせる
• pending gate を保てる
• checkpoint を child 単位で設計できる
• recovery の blast radius を狭められる

6. Durable learning を分離して得られる

子 frame は artifact を返すだけではなく、

• failure lesson
• decision rationale
• operational memory candidate
• recovery note

などを返しうる。
これにより、部分的失敗でも productive failure に変換しやすい。

だから Parent-Child Process は、
大きい仕事を小さくするため ではなく、
大きい仕事を責任と統治を保ったまま継続可能にするため に必要なのである。

---

Parent-Child Process は何ではないか

輪郭をはっきりさせるために、まず何ではないかを書いておく。

1. 単なる task breakdown ではない

TODO を小さく分けただけでは child frame にはならない。
goal slice、return contract、authority retention、lifecycle が必要である。

2. 単なる function call ではない

ある actor が tool を呼ぶことは local execution かもしれないが、
それが独自 frame、独自 gate、独自 return contract を持たないなら child process とは限らない。

3. 単なる subagent call ではない

subagent が使われていても、

• parent-child の明示的 relation
• delegated / retained responsibility
• return contract
• lifecycle coupling

がなければ、PCE 2.0 の意味での child frame とは言いにくい。

4. 単なる Handoff ではない

Handoff は transition である。
Parent-Child Process は構造であり、handoff はその中で起こる出来事である。

5. 単なる Branch and Join ではない

parallel child を持つことはあるが、親子構造の本質は parallelism ではない。
それは authority retention と delta return の階層にある。
parallel topology については Branch and Join を参照する。

6. 単なる組織階層ではない

親と子は manager と subordinate を意味しない。
frame の関係であって、人事上の上下関係とは別である。

---

Parent-Child Relation の中心命題

PCE 2.0 における親子関係は、概念的には次のように書ける。

parent_child(parent, child) iff
  child.parent_frame_id = parent.frame_id
  and child.goal is a bounded goal slice
      or an explicit adjunct needed for parent continuation
  and retained_authorities(parent, child) are explicit
  and return_contract(parent, child) exists

ここで重要なのは二つある。

1. Child は親の goal の局所断面、または continuation-support frame である

多くの child は parent goal の局所断面を扱う。
ただし incident-analysis、evaluation、recovery など、親の continuation を成立させる adjunct frame も child としてありうる。

2. 親の authority retention が必須である

child を切るとは、全部を委ねることではない。
何を retain し、何を delegate するかが parent-child semantics の中心である。

---

Parent が保持しやすいもの

PCE 2.0 では、親 frame はしばしば次を保持する。

1. Global Goal Ownership

子に goal slice を渡しても、親が global goal を保持することが多い。
child が親 goal を黙って reframe してはならない。

2. Final Completion Acceptance

child が completed しても、parent が completed するとは限らない。
最終 close は親の goal owner または close authority が持つ。

3. Final Approval / Merge Authority

子が local approval を持つことはありうるが、
最終 merge / release / canonical write は親か、親が retain した authority が持つことが多い。

4. Incident Sink

child 内で local incident handling をしても、
global incident sink は parent に残ることが多い。

5. Cross-child Integration Responsibility

複数 child の結果をどう統合し、どの conflicts をどう解くかは親が持つ。

この retained set が明示されていなければ、
子の autonomy は容易に overreach する。

---

Child に渡されやすいもの

一方、child frame には次のような bounded responsibility が渡されやすい。

1. Local Goal Slice

親の goal の局所断面。
たとえば

• spec analysis
• implementation
• review preparation
• incident analysis
• memory candidate triage

などである。

2. Local Execution

child が scope 内で実際に work を進める責任。

3. Bounded Evaluation

親が要求する criteria の一部について、局所的判断を行う責任。
ただし final ratification を持つとは限らない。

4. Scoped Capability

必要な tools / data / write scope を child に限って与える。
親より広げるのではなく、通常は狭める。

5. Local Recovery Strategy

child 単位の checkpoint / recover / rollback anchor を持つことがある。

6. Return Obligation

何を親へ返すか、どの format で返すかを child が引き受ける。
これが return contract である。

---

Goal Slice と Adjunct Child

親子関係の中心には goal slice があるが、すべての child が純粋な goal slice frame とは限らない。
PCE 2.0 では、少なくとも二種類の child を区別するとよい。

1. Goal-Slice Child

親 goal の局所断面を直接進める child。

例:

• spec-analysis
• implementation
• review
• documentation update

2. Adjunct Child

親 goal を直接達成するのではなく、親の継続・判断・回復を支える child。

例:

• incident-analysis child
• evaluation-only child
• recovery-validation child
• migration impact child

この区別があると、
「子は必ず親の deliverable の断片を返すべきだ」という誤解を避けられる。
Adjunct child は、decision, evaluation, failure lesson, recovery readiness を返すこともある。

---

Parent-Child Process と Handoff の関係

親子構造は静的な関係だが、実際の進行は handoff を通して行われる。

Parent → Child Handoff

親から子へは、少なくとも次が渡る。

• goal slice
• inherited constraints
• retained authorities の明示
• relevant evidence refs
• expected outputs
• return contract
• stop / escalate conditions

Child → Parent Return Handoff

子から親へは、少なくとも次が返る。

• process delta
• evidence refs
• unresolved issues
• recommendation
• residual risk
• completion signal

ここで重要なのは、child の raw local context をそのまま返さないことだ。
親が消費するのは、child の return contract に従って package 化された continuity である。

したがって Parent-Child Process は、
structural relation + directed handoff pair
として理解すると分かりやすい。

---

Parent-Child Process と Lifecycle の関係

child は親の一部だが、親と同じ lifecycle を取るわけではない。
ここに Parent-Child Process の重要な複雑さがある。

Child lifecycle

child 自身の active / pending / blocked / completed などを持つ。

Parent lifecycle

親自身の open / waiting / integrating / completion_ready などを持つ。

関係としての lifecycle coupling

child の状態が parent の次の legal transition をどう変えるかを定める。

たとえば、

• child active → parent は open のまま waiting_on_child かもしれない
• child blocked → parent も blocked_on_child になるかもしれない
• child completed → parent は integrating_child_return へ進むかもしれない
• child abandoned → parent は replan_pending になるかもしれない

つまり parent-child relation には、
frame 間の lifecycle coupling がある。

---

Lifecycle coupling の代表パターン

1. Strict Dependency

child が終わらないと parent が次へ進めない。

例:

• spec-analysis child が終わらないと spec approval に入れない

2. Advisory Dependency

child の結果があるとよいが、親は必要に応じて別ルートを取れる。

例:

• supplementary analysis child
• optional optimization child

3. Parallel Integration Dependency

複数 child のうち必要集合が揃うと parent が integrating に入る。

4. Incident Override Dependency

child incident が parent の normal progression を停止させる。

5. Recovery Dependency

ある child の recovery が終わらないと parent が legal next transition を持てない。

この coupling を曖昧にすると、
child が completed したのに parent がどう進めばよいか分からなくなる。

---

Parent-Child Process と Governance Surface の関係

親と子は governance 的にも同じではない。
親の governance がそのまま child にコピーされるわけではない。

継承されやすいもの

• global policy constraints
• out-of-scope rules
• required approval topology の上位部分
• incident sink
• target release constraints

局所化されるもの

• child-specific capability scope
• local evaluator set
• local approval point
• child-specific checkpoint policy
• local stop conditions

原則

• child は親の governance を silent に弱めてはならない
• child は通常、親より狭い capability / visibility を持つ
• child-specific gate は parent gate と別に定義されうる
• child return が親 gate を automatically 解くとは限らない

このため Parent-Child Process は、
governance inheritance + bounded specialization
として理解できる。

---

Parent-Child Process と Process Delta の関係

child は通常、親の durable state を直接書き換えるべきではない。
child が返す中心は Process Delta である。

Child が返しうるもの

• artifact delta
• decision delta
• failure delta
• evaluation delta
• operational memory candidate
• recovery note
• unresolved issue set
• recommendation

親がすること

• delta を受け取る
• 必要なら additional evaluation をかける
• approval point を通す
• promote / merge / archive / reject を決める

ここで重要なのは、
child completion ≠ parent durable mutation
だという点である。

子は変化候補を返し、
親または親が retain した authority がそれを採用する。

---

Child が durable state を直接書いてよい場合

通常は親経由が安全だが、例外もありうる。

直接 write がありうる条件

• child に明示的な memory_write_authority が delegate されている
• target collection が strictly bounded である
• parent が provisional write のみ許している
• runtime / recovery collection のように narrow surface である
• governance rules がそれを許している

原則

それでも次を失ってはならない。

• provenance
• authority trace
• parent relation
• return note or coordination delta

つまり direct child write は可能だが、
例外的で traceable な bounded authority
として扱うべきである。

---

Parent-Child Process と Recovery の関係

親子構造は recovery を強くする一方で、複雑にもする。

子ごとの recovery

各 child は独自の Recovery Point を持ちうる。
これにより child 単位で resume / rollback / replan が可能になる。

親の recovery

親は

• 自身の state
• child return state
• child pending state
• child recovery refs

を見て recover する必要がある。

重要な点

• child が recover 中でも parent は別の child を進められることがある
• child failure が親全体の recover / replan を要求することもある
• parent cancellation が child recovery を invalid にすることもある

つまり Parent-Child Process は、
recovery semantics を階層化する構造 である。

---

Parent-Child Process と Incident Ownership の関係

異常時には、parent-child relation のどこに incident sink があるかが重要になる。

典型パターン

1. Local child incident

child 内で containment できる。
親には delta と status だけ返す。

2. Escalated incident

child が local bundle では処理不能として親の incident owner へ返す。

3. Parent-wide incident

一つの child の failure が親全体の progression を止める。

4. Dedicated incident child

親が incident handling のための別 child frame を spawn する。

このとき Parent-Child Process は、
「大きい仕事を分ける構造」であると同時に、
「異常時の責任を routing する構造」でもある。

---

Parent-Child Process の代表パターン

1. Analysis Child

goal: parent のための調査・整理
return: summary + evidence + unresolved issues

2. Execution Child

goal: bounded implementation / transformation
return: artifact delta + evidence + rollback note

3. Evaluation Child

goal: bounded evaluation / grading
return: evaluation delta + recommendation

4. Memory Child

goal: memory candidate triage / durable form construction
return: candidate set + provenance + write recommendation

5. Incident Child

goal: failure analysis / blast radius clarification / recovery recommendation
return: failure delta + recovery recommendation

6. Integration Child

goal: multiple outputs の整合確認・統合準備
return: integrated delta proposal

この pattern は taxonomy というより、
「どの kind の bounded autonomy を child に切り出すか」を考える補助になる。

---

いつ child frame を切るべきか

次の条件があるなら、同一 frame 内の transition だけで済ませず、child frame を切る価値が高い。

1. Goal Slice が意味的に独立しているとき

親の goal の一部を、局所成功条件つきで切り出せる場合。

2. Capability Boundary が大きく違うとき

read-only analysis と write-enabled implementation は別 child にしやすい。

3. Eval / Approval Topology が違うとき

子で独自の evaluators や local approval を持ちたい場合。

4. Recovery Policy を独立させたいとき

長い作業や risky local work を、親全体と切り離して recoverable にしたい場合。

5. Incident Blast Radius を局所化したいとき

failure を一箇所に閉じ込めたい場合。

6. Return Contract を明示したいとき

親が子から何を受け取るべきかを明確にしたい場合。

短く言えば、
goal、capability、evaluation、recovery、incident、return contract のいずれかが独立性を要するなら child frame を切る
のが基本である。

---

いつ child frame を切らない方がよいか

逆に、次のような場合は child frame を切ると過剰設計になりやすい。

1. 同じ actor が同じ capability で短く連続して進める局所手順

同一 bundle / 同一 gate / 同一 output なら local sequencing で十分なことが多い。

2. 独立した return contract がない

単に途中の micro-step を分けたいだけなら child にする理由は弱い。

3. Lifecycle を分ける価値がない

checkpoint や incident isolation の必要がない極小作業。

4. Parent authority をほぼ全部子に渡すことになってしまう

その場合は child ではなく、frame transfer や reframe を検討した方が自然なことがある。

---

Parent-Child Relation の最小スキーマ

PCE 2.0 における最小スキーマは、次のように置ける。

parent_child_relation:
  relation_id:
  parent_frame_ref:
  child_frame_ref:
  relation_kind:
    # goal_slice | adjunct_evaluation | adjunct_incident | adjunct_recovery | integration
  goal_slice:
  retained_authorities:
  delegated_responsibilities:
  inherited_constraints:
  inherited_governance:
  child_capability_boundary:
  child_visibility_boundary:
  completion_dependency:
  return_contract:
    required_deltas:
    required_evidence:
    unresolved_issue_format:
    recommendation_format:
    completion_signal:
  escalation_path:
  cancellation_policy:
  recovery_coupling:
  provenance:

もう少し process 指向に書くなら、次のようにも置ける。

child_frame_binding:
  parent_frame:
  child_frame:
  purpose:
  local_goal:
  success_binding:
  parent_retains:
  child_controls:
  local_evaluators:
  local_approvals:
  return_path:
  failure_propagation:
  recovery_strategy:
  supersession_policy:

このスキーマで重要なのは、次の点である。

1. relation kind がある
2. retained と delegated を分ける
3. return contract がある
4. governance / capability inheritance がある
5. failure / recovery / cancellation を持てる

つまり parent-child relation は、
単なる parent_frame_id だけでは足りず、
authority と continuity の契約 を持つべきである。

---

小さな例

feature.checkout.coupon-combination parent frame から、spec-analysis child を切る例を書く。

parent_child_relation:
  relation_id: rel.feature.checkout.coupon-combination.spec-analysis
  parent_frame_ref: feature.checkout.coupon-combination
  child_frame_ref: feature.checkout.coupon-combination.spec-analysis
  relation_kind: goal_slice
  goal_slice: >
    仕様案を整理し、影響範囲と未解決論点を parent frame に返す
  retained_authorities:
    - global_goal_ownership_by_product_owner
    - final_spec_approval_by_product_owner
    - final_incident_sink_by_product_owner
  delegated_responsibilities:
    - local_analysis_execution_to_analyst_agent
    - local_goal_clarification_within_scope
  inherited_constraints:
    - payment_gateway_changes_are_out_of_scope
    - coupon_precedence_rule_is_baseline_constraint
  inherited_governance:
    - spec_must_return_with_unresolved_issue_list
    - child_cannot_reframe_parent_scope
  child_capability_boundary:
    tools:
      - repository_search
      - document_search
    permissions:
      - read_only
  child_visibility_boundary:
    visible:
      - checkout_spec_refs
      - precedence_adr
      - current_validation_logic
    hidden:
      - production_credentials
      - unrelated_module_notes
  completion_dependency: strict_dependency
  return_contract:
    required_deltas:
      - spec_summary_candidate
      - decision_candidates
      - unresolved_issues
    required_evidence:
      - source_refs
    unresolved_issue_format:
      - issue
      - why_unresolved
      - recommended_next_owner
    recommendation_format:
      - spec_approval_ready | replan_needed
    completion_signal: child_return_handoff_completed
  escalation_path:
    - product_owner
  cancellation_policy:
    child_cancelled_if_parent_superseded: true
  recovery_coupling:
    child_has_own_checkpoint_policy: true
    parent_may_resume_without_child_only_if_replanned: true
  provenance:
    created_by: feature.checkout.coupon-combination

この relation により、analyst agent は

• read-only で調査できる
• local ambiguity を整理できる
• しかし parent の global goal は変えられない
• return contract を満たす形でしか結果を返せない

という bounded autonomy を持つ。

---

Parent-Child Process の不変条件

PCE 2.0 では、少なくとも次の不変条件を置く。

1. Every child has an explicit parent relation

単に parent_frame_id があるだけでは足りない。
retained / delegated / return contract が必要である。

2. Child must have a bounded goal or explicit adjunct purpose

子は親の goal slice か、明示的な continuation-support purpose を持たなければならない。

3. No silent inheritance of parent authority

child は親の approval / merge / incident / close authority を黙って継承してはならない。

4. Every child has a return contract

子から親へ何を返すのか不明な child は不完全である。

5. Child completion does not imply parent completion

completed child は親の進行条件を変えるが、親 close を自動化しない。

6. Parent retention must remain traceable

親が retain している authority は明示されていなければならない。

7. Child failure propagation must be defined

child が blocked / abandoned / incident_open になったとき、親へどう波及するか定義されるべきである。

8. Child recovery must not violate parent governance

recover により child が古い authority や stale context を使ってはならない。

9. Child delta must not become parent durable truth automatically

返された delta は、親または retained authority による integration を要する。

10. Cancellation and supersession semantics must be explicit

親の reframe / supersede によって child がどうなるかを明示すべきである。

---

最低限の自己点検

ある process 設計が parent-child-aware かどうかは、次で点検できる。

1. なぜ child frame を切るのか説明できるか
2. child が goal slice か adjunct purpose を持っているか
3. 親が retain している authority を言えるか
4. child が delegated された責任を言えるか
5. child の capability / visibility が bounded か
6. return contract があるか
7. child completion と parent completion を混同していないか
8. child failure / incident / recovery が親へどう波及するか言えるか
9. child が parent durable state を黙って更新しないようになっているか
10. parent-child relation が handoff と lifecycle の両方に反映されているか

このどれかが欠けるなら、その分解はまだ PCE 2.0 の意味で親子 process になっていない。

---

関連する概念

Parent-Child Process は、PCE 2.0 の階層的 process semantics の中心として、次の概念と強く結びつく。

• Process Frame
• Goal Ownership
• Execution
• Approval
• Evaluation
• Memory Writing
• Incident Ownership
• Asymmetry
• Transitions
• Handoff
• Lifecycle
• Approval Points
• Checkpoint and Recovery
• Process Delta
• Recovery Point
• Governance Surface
• Branch and Join
• Escalation
• Rollback

---

暫定的なまとめ

Parent-Child Process が言っていることは、最終的には次の一文に集約できる。

大きな仕事を小さく分けることは、単なる分業ではない。
親が何を保持し、子に何を委ね、子が何を返し、失敗や回復がどう波及するかを明示したうえで、bounded autonomy と return contract を持つ階層的 process として設計してはじめて、長い仕事は壊れずに進められる。

PCE 2.0 において parent-child 関係は、単なる subtask tree ではない。
それは goal、authority、governance、delta、recovery を階層化して継続可能にする構造である。

だから Parent-Child Process は、単なる decomposition ではない。
それは、PCE 2.0 において 大きな仕事を bounded autonomy と explicit integration によって成立させる階層的 process topology である。