Branch and Join

定義

Branch and Join

Branch and Join とは、ある parent process frame が、
自らの goal、scope、constraints、governance の一部を局所化して
複数の child process frame または bounded execution path を同時または準同時に走らせ、
その結果を join contract に従って
再統合・比較・選別・縮約・昇格準備する process topology である。

それは単なる parallel execution ではなく、
branch purpose、retained authorities、delegated responsibilities、return contracts、join conditions、conflict resolution、failure propagation、recovery coupling を持つ。

より短く言えば、Branch and Join とは
「親の仕事を bounded な複数の子経路へ分け、その結果を条件付きで再び一つの continuation に戻す構造」
である。

PCE 2.0 において branch は、ただ仕事を細かく分けることではない。
join は、ただ結果を集めることでもない。
branch-and-join は、bounded autonomy を複数走らせ、その成果を governed に統合する ための構造である。

この意味で Branch and Join は、
Parent-Child Process を sibling topology の側から具体化した概念である。

---

なぜ Branch and Join が必要なのか

PCE 2.0 が branch-and-join を独立に扱うのは、長い仕事では「一つの frame を順番に進める」だけでは十分でないことが多いからである。

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

1. 異なる局所仕事を同時に進めたい

たとえば feature delivery では、

• implementation
• edge-case test design
• rollback readiness analysis
• policy impact review

を同時に進めた方がよいことがある。
これを一列に並べると、不必要に遅くなる。

2. alternative を比較したい

一つの答えを探すのではなく、

• design option A
• design option B
• risk-minimizing option C

のように複数案を並行に検討し、後で比較して選びたいことがある。

3. risk を局所化したい

高リスクな探索や migration analysis を別 branch に閉じ込めれば、
本線の execution や governance を汚さずに済む。

4. capability と visibility を分けたい

read-only analysis branch と write-enabled implementation branch を分けることで、
bundle と surface をより狭く設計できる。

5. 評価や review を並行化したい

artifact production と evaluation preparation、
memory candidate 抽出と failure analysis を別 branch にした方がよい場合がある。

6. 親が retain する authority を保ったまま部分自律を与えたい

branch を切ることで子は bounded autonomy を持てる。
しかし final approval、final merge、global goal ownership は親に retain できる。

つまり Branch and Join は、
複雑な仕事を平坦にせず、しかし完全分離もせず、統治可能な複数経路へ広げて再統合するため に必要である。

---

Branch and Join は何ではないか

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

1. 単なる task breakdown ではない

TODO を複数に分けるだけでは branch ではない。
親の retain する authority、各 branch の bounded scope、return contract、join 条件が必要である。

2. 単なる parallel execution ではない

並列に走ることはあるが、本質は並列性ではない。
本質は 分岐の意味 と 再統合の規律 にある。

3. 単なる Handoff ではない

Handoff は continuity transfer の遷移である。
branch-and-join は複数 path を持つ構造であり、handoff はその中で起こる。

4. 単なる Parent-Child Process ではない

親子関係は前提だが、それだけでは sibling 間の調整や join 条件は表現できない。
Branch and Join は、複数 child を同時に束ねる topology である。

5. 単なる merge ではない

join は process-level な再統合である。
merge は durable state への反映である。
join 後にさらに eval / approval / promotion / merge が必要なことが多い。

6. 単なる compare-and-pick ではない

alternative branch を比較する join は一形態にすぎない。
all-of join や quorum join もある。

7. 単なる organizational hierarchy ではない

親子や branch は人事上の上下関係を意味しない。
frame の構造であって、組織図とは別である。

---

Branch と Join を分けて考える

この二つは密接だが、同じではない。

Branch

親の continuity を複数の bounded path に分けること。
ここで重要なのは、

• 何を局所化するか
• 何を retain するか
• 各 child に何を返させるか

である。

Join

branch から返ってきた continuity を、
比較・統合・選別・縮約して、親の次の progression を決めること。
ここで重要なのは、

• どの child が join に必要か
• 何を evidence として受け取るか
• conflict をどう解くか
• join の結果が何を unlock するか

である。

概念的には、次のように書ける。

branch(parent_frame) -> {child_frame_1, child_frame_2, ...}
join({child_returns}, join_contract) -> integrated_continuation

ここで重要なのは、join の出力はしばしば integrated continuation であって、
まだ durable truth ではないことだ。

---

Branch Set という考え方

PCE 2.0 では、branch をばらばらの child の集合としてではなく、
branch set として扱うと分かりやすい。

Branch Set

同じ親 frame の同じ branch decision から生まれ、
共通の目的・shared constraints・retained authorities・join contract を持つ child 群。

branch set を導入すると、次が明確になる。

• この child 群は何のために一緒に切られたのか
• どの child が必須で、どの child が任意か
• join は all-of なのか select-one なのか
• 一つの child failure が branch set 全体を止めるのか
• 部分 join が可能か

つまり branch set は、
分岐を sibling topology として把握するための単位 である。

---

Branch の主な型

PCE 2.0 では、少なくとも次の型を区別するとよい。

1. Partitioned Branch

親 goal の異なる局所断面を、scope を分けて並行に進める。

例:

• implementation branch
• tests branch
• docs branch

これは最も分かりやすい branch である。
各 child は比較的 disjoint な local goal を持つ。

2. Alternative / Speculative Branch

複数案・複数仮説・複数設計を並行に検討する。

例:

• design option A
• design option B
• fallback option C

join では比較・選択・却下 rationale が重要になる。

3. Validation Branch

main branch とは別に、評価や検証だけを独立して進める。

例:

• implementation branch
• regression analysis branch
• rollback readiness branch

ここでは child が artifact を作らず、evaluation delta や risk note を返すことがある。

4. Redundant / Consensus Branch

同じ問いに対して複数 branch が独立に答え、
一致や quorum を見たい場合である。

例:

• independent verification
• dual review branch
• redundant research branch

5. Incident Isolation Branch

通常フローと incident analysis / containment を分離する branch である。

例:

• main feature execution
• incident investigation child

この branch は adjunct child 的な性格が強い。

6. Synthesis Support Branch

親の統合判断を助けるための補助 branch。

例:

• blast radius estimation
• migration impact scan
• policy compatibility analysis

これらは parent goal の直接実装ではなく、join quality を上げるために切られる。

---

Join の主な型

join も一種類ではない。
PCE 2.0 では、少なくとも次の型を区別できる。

1. All-of Join

required branch すべての return が揃って初めて join が開く。

例:

• implementation
• tests
• rollback note

の全部が必要なケース。

2. Any-of / First-success Join

複数 branch のうち一つが sufficient な結果を返せばよい。

例:

• 複数設計案のうち一つを採用する
• 複数 retrieval branch のうち一つで十分な evidence が得られる

3. Quorum Join

一定数または一定条件の branch return が揃えばよい。

例:

• 3つの independent review branch のうち2つ一致
• 複数 evaluator の合意

4. Comparative Join

branch を比較し、最も妥当な path を選ぶ。

例:

• option A vs B
• lower risk vs lower cost

この join では、選ばれなかった branch の rationale も価値を持つ。

5. Reducer / Synthesis Join

複数 branch の return を合成して、より高次の integrated output を作る。

例:

• code change + test additions + rollback assessment
• multiple research notes → integrated recommendation

6. Approval-gated Join

join 自体はできても、親の次の progression は別の approval を要する。

例:

• child return をまとめた review package はできた
• しかし parent は product owner approval 待ち

7. Partial Join

branch set 全体ではなく、一部だけ先に統合して進める。

例:

• docs branch は遅れていても implementation + tests だけ先に review へ進める

8. Abort / Cancel Join

ある branch の失敗や supersession により、branch set 自体を閉じる。

例:

• alternative branch A が選ばれたので B / C を abandon する
• policy incident により branch set を停止する

---

Join は merge ではない

これは非常に重要である。

Join

複数 child の continuity を、親の次の合法状態へ統合する process-level operation。

Merge

ある delta item を durable project state に反映する durable-state mutation。

つまり、

• join は process の再統合
• merge は durable state の更新

である。

たとえば implementation branch と tests branch の all-of join によって
「review-ready package」ができたとしても、
それはまだ canonical merge ではない。
その後に approval、promotion、merge が必要なことがある。

PCE 2.0 では、この差を明確に保つ。

---

Branch and Join と Parent-Child Process の関係

Parent-Child Process が
一つの parent と一つの child の関係を定義するのに対し、
Branch and Join は 複数 child の sibling coordination を扱う。

親子ページが強いのは、

• retained authority
• delegated responsibility
• return contract
• parent-child lifecycle coupling

である。

Branch-and-join ページが強いのは、それに加えて

• sibling set の目的
• required branches
• join kind
• inter-branch conflicts
• partial joins
• cancellation / supersession semantics

を扱う点である。

したがって branch-and-join は、
parent-child process の上に乗る multi-child topology semantics と言える。

---

Branch and Join と Handoff の関係

branching はしばしば parent→child handoff を伴い、
joining は child→parent return handoff を伴う。

Parent → Child branch handoff

親は child に対して次を渡す。

• local goal
• constraints
• retained authority の明示
• capability boundary
• expected return

Child → Parent join return handoff

child は親に対して次を返す。

• delta
• evidence
• unresolved issues
• recommendation
• completion / blocked / abandoned signal

ここで重要なのは、join は handoff そのものではないということだ。
join は、複数 return handoff を受けて
何が parent の次の legal continuation になるかを決める構造 である。

---

Branch and Join と Lifecycle の関係

branch set には、親 frame の lifecycle とは別に、branch-set の sublifecycle があると考えると分かりやすい。

Branch-set sublifecycle の代表状態

• defined
• branching_active
• waiting_on_branches
• partial_join_ready
• integrating
• joined
• join_blocked
• abandoned
• superseded

たとえば parent frame は open のままでも、
その内部で branch set は waiting_on_branches かもしれない。

親 lifecycle への影響

• child 全部未完 → parent は waiting_on_branch_set
• required subset 完了 → parent は integrating
• branch conflict 発生 → parent は blocked / replan_pending
• join 完了 → parent は active or completion_ready

このように、branch-and-join は lifecycle を 平坦な一本道ではなく、多経路の待ち合わせを持つ構造 にする。

---

Branch and Join と Governance Surface の関係

branching は governance を複雑にする。
なぜなら sibling 間で visibility、capability、approval topology が同一ではないことが多いからである。

重要な問い

• branch 同士は互いの raw output を全部見てよいのか
• branch ごとに capability をどう分けるか
• join に必要な evaluator / approver は誰か
• 一つの branch failure で全体を freeze するか
• partial join を許すか

原則

• child は通常、parent より狭い capability を持つ
• sibling 間 visibility は明示すべきである
• join gate は独立の governance surface を持ちうる
• parent retains final authority unless explicitly delegated

つまり branch-and-join は、
単なる parallelism ではなく governed multi-path execution である。

---

Branch and Join と Process Delta の関係

各 child は通常、親の durable state を直接書き換えず、
Process Delta を返す。

Child return が返しうるもの

• artifact delta
• decision delta
• failure delta
• evaluation delta
• operational memory candidate
• unresolved issue set
• residual risk note

Join がすること

• delta を束ねる
• conflict を解く
• 比較する
• reduce / synthesize する
• 親の次の admissible subject を作る

ここで重要なのは、
join は 複数 delta を integrated continuation に変える のであって、
それ自体が durable state write ではないことだ。

---

Branch Conflicts

branch が複数あると、しばしば conflict が起きる。
PCE 2.0 では、これを explicit に扱うべきである。

典型的な conflict

1. Scope conflict

二つの branch が同じ scope を黙って書き換えている。

2. Decision conflict

alternative branch が互いに矛盾する rationale を返す。

3. Evaluation conflict

一つの branch は pass と言い、もう一つは fail と言う。

4. Governance conflict

branch A は local approval 済み、branch B は parent approval を要求する。

5. Recovery conflict

一つの branch は recoverable だが、もう一つは invalidated している。

必要なこと

join contract には少なくとも

• conflict detection rule
• conflict resolver
• escalate path
• abandon / supersede policy

が必要である。

---

Failure propagation と cancellation

branch の failure が全体にどう影響するかは、明示されなければならない。

代表パターン

1. Hard dependency propagation

required branch が fail したら parent も blocked になる。

2. Soft dependency propagation

optional branch が fail しても parent は進める。

3. Replaceable branch

失敗 branch を別 child で置き換えられる。

4. Winner-takes-rest

alternative join で一つが選ばれたら、他 branch は abandoned / superseded になる。

5. Incident-induced cancellation

branch 内 incident が parent authority により全 branch set を止める。

この policy がないと、orphan branch や zombie branch が生まれやすい。

---

Recovery coupling

branch set では recovery も複雑になる。
各 child は独自の Recovery Point を持ちうるが、
join には branch-set recovery semantics が必要である。

重要な問い

• 一つの child だけ recover できればよいのか
• join は古い child return を使ってよいのか
• parent の governance drift で全 child return が stale になるか
• partial join 後に未参加 branch を later 追加できるか

原則

• join 前には required branch returns の freshness を確認すべきである
• parent governance drift は branch return の revalidation を要求しうる
• branch set の recovery は parent の current durable reality と reconcile されるべきである

つまり branch-and-join は、
recovery-aware でなければ長時間 process に耐えない。

---

いつ Branch を切るべきか

次の条件があるなら branch を切る価値が高い。

1. Scope が十分に分離できるとき

child 同士が bounded scope を持てるなら並行化しやすい。

2. Capability surface が違うとき

read-only analysis、write execution、risk review を分けたい場合。

3. Alternative を比較したいとき

winner-take-all か comparative join を設計したい場合。

4. Evaluation / risk / rollback を本線から分離したいとき

validation branch や incident isolation branch が有効である。

5. Return contract が明示できるとき

子が何を返すべきか言えるなら branch 化しやすい。

6. Failure を局所化したいとき

一つの path の failure を parent 全体へ広げたくない場合。

短く言えば、
bounded autonomy と explicit reintegration の両方が設計できるときに branch を切る
のが基本である。

---

いつ Branch を切らない方がよいか

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

1. 局所 sequence で十分なとき

同一 actor、同一 bundle、同一 capability、同一 output なら local sequencing の方が自然である。

2. shared mutable scope が大きすぎるとき

ほとんど同じ file / artifact / decision surface を触るなら、branch 間 conflict が多くなりやすい。

3. join contract を定義できないとき

何をどう統合するか言えないなら、branch は作ってはいけない。

4. retained authority が曖昧なとき

child が親 authority を暗黙に持つような設計は危険である。

5. branch overhead が benefit を上回るとき

handoff、recovery、join、audit のコストが高すぎる場合である。

短く言えば、
再統合の意味が弱いなら branch を切らない方がよい。

---

Branch Contract と Join Contract

PCE 2.0 では、branch-and-join を明示するなら少なくとも二つの契約を持つとよい。

Branch Contract

各 child が

• 何のために切られたか
• 何をしてよいか
• 何を返すべきか
• どこで止まるべきか

を定める。

Join Contract

branch set 全体について

• 何が揃えば join 可能か
• どう統合するか
• conflict をどう解くか
• どの authority が次を開くか

を定める。

この二つがあることで、

• branch は orphan にならず
• join は ad hoc にならず
• sibling conflict も traceable になる

---

Branch-and-Join の最小スキーマ

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

branch_set:
  set_id:
  parent_frame_ref:
  purpose:
  branch_kind:
    # partitioned | alternative | validation | redundant | incident_isolation | synthesis_support
  retained_authorities:
  shared_constraints:
  shared_governance:
  branch_specs:
    - child_frame_ref:
      local_goal:
      capability_boundary:
      visibility_boundary:
      success_signal:
      return_contract:
      cancel_conditions:
      local_failure_policy:
  join_contract:
    join_kind:
      # all_of | any_of | quorum | comparative | reducer | approval_gated | partial
    required_branches:
    readiness_rule:
    required_evidence:
    conflict_resolution:
    integration_owner:
    integration_eval:
    required_approvals:
    output_form:
    failure_policy:
    cancellation_policy:
  recovery_coupling:
  provenance:

join instance を別に持つなら、次のように置ける。

join_state:
  join_ref:
  parent_frame_ref:
  state:
    # waiting | partial_ready | integrating | satisfied | blocked | abandoned | superseded
  received_returns:
  missing_returns:
  unresolved_conflicts:
  freshness_checks:
  legal_next_transitions:
  audit_refs:

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

1. branch set が sibling 全体の単位としてある
2. retained authority がある
3. child ごとの branch contract がある
4. join kind と required branches がある
5. conflict / failure / cancellation policy がある
6. recovery coupling がある

つまり Branch and Join は、
単なる「並列実行した」ではなく、
multi-path continuity contract として表現されるべきである。

---

小さな例

feature.checkout.coupon-combination frame で、spec approval 後に三つの branch を切るとする。

• impl.core-change
• tests.edge-cases
• rollback-readiness

親は次を retain する。

• global goal ownership
• final code review approval
• final memory write
• incident sink

branch set は次のように表せる。

branch_set:
  set_id: bs.feature.checkout.coupon-combination.impl-validation
  parent_frame_ref: feature.checkout.coupon-combination
  purpose: >
    implementation, edge-case test design, rollback readiness を並行に進め、
    review-ready package を親に返す
  branch_kind: partitioned
  retained_authorities:
    - global_goal_ownership_by_product_owner
    - final_review_approval_by_reviewer
    - final_memory_write_by_memory_writer
    - incident_sink_by_product_owner
  shared_constraints:
    - payment_gateway_changes_are_out_of_scope
    - coupon_precedence_rule_is_baseline_constraint
  shared_governance:
    - all_branch_returns_must_be_traceable
  branch_specs:
    - child_frame_ref: feature.checkout.coupon-combination.impl.core-change
      local_goal: >
        approved spec に従って core logic を実装し、diff と local test evidence を返す
      capability_boundary:
        permissions:
          - limited_write
      visibility_boundary:
        visible:
          - target_files
          - approved_spec_summary
      success_signal: impl_delta_ready
      return_contract:
        required_deltas:
          - artifact_delta
          - implementation_note
          - rollback_note
      cancel_conditions:
        - parent_reframed
      local_failure_policy:
        - rollback_local_changes_if_scope_violation

    - child_frame_ref: feature.checkout.coupon-combination.tests.edge-cases
      local_goal: >
        stacked discount と precedence に関する edge-case tests を整理し、test additions を返す
      capability_boundary:
        permissions:
          - limited_write_test_scope
      visibility_boundary:
        visible:
          - current_test_suite
          - approved_spec_summary
      success_signal: test_delta_ready
      return_contract:
        required_deltas:
          - artifact_delta
          - edge_case_note
      cancel_conditions:
        - parent_reframed
      local_failure_policy:
        - emit_failure_delta_if_spec_gap_found

    - child_frame_ref: feature.checkout.coupon-combination.rollback-readiness
      local_goal: >
        current変更の rollback feasibility と blast radius を確認し、review package 用 note を返す
      capability_boundary:
        permissions:
          - read_only
      visibility_boundary:
        visible:
          - diff_ref
          - current_checkout_architecture_summary
      success_signal: rollback_note_ready
      return_contract:
        required_deltas:
          - decision_delta
          - residual_risk_note
      cancel_conditions:
        - parent_reframed
      local_failure_policy:
        - escalate_if_rollback_not_clear

  join_contract:
    join_kind: all_of
    required_branches:
      - feature.checkout.coupon-combination.impl.core-change
      - feature.checkout.coupon-combination.tests.edge-cases
      - feature.checkout.coupon-combination.rollback-readiness
    readiness_rule:
      - all_required_returns_present
      - no_open_hard_conflict
    required_evidence:
      - code_diff_ref
      - test_additions_ref
      - rollback_note_ref
    conflict_resolution:
      on_scope_conflict: escalate_to_product_owner
      on_test_vs_impl_conflict: return_to_impl_rework
    integration_owner: reviewer
    integration_eval:
      - eval.feature.checkout.coupon-combination.artifact.v1
    required_approvals:
      - code_review_approval
    output_form:
      - integrated_review_package
    failure_policy:
      on_required_branch_fail:
        - block_parent_progression
        - allow_rework_or_replan
    cancellation_policy:
      on_parent_superseded:
        - abandon_all_children
  recovery_coupling:
    each_child_has_own_checkpoint_policy: true
    join_requires_freshness_check_on_all_returns: true
  provenance:
    created_by: feature.checkout.coupon-combination

この例で重要なのは、child がただ parallel に走るのではなく、

• 何を返すべきか
• 親が何を retain するか
• どの条件で join が開くか
• conflict をどう扱うか

が先に定義されていることだ。

---

Branch and Join の不変条件

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

1. No branch without explicit purpose

なぜ branch を切るのか説明できなければならない。

2. No child in a branch set without a return contract

何を返すのか不明な child は orphan branch になりやすい。

3. No branch without retained authority clarity

親が retain する authority を明示しなければならない。

4. No join without explicit join contract

join は ad hoc にやってはならない。
required branches、readiness rule、conflict resolution が必要である。

5. Join is not merge

join 完了は durable state 更新を自動化しない。

6. Child return is delta-based, not raw-context-based

親へは raw local context ではなく delta / evidence / unresolved issues を返すべきである。

7. Branch failure propagation must be defined

一つの child failure が parent と sibling にどう影響するか決める必要がある。

8. Cross-branch visibility must be explicit

sibling 同士が何を見えるかは明示的に制御すべきである。

9. Recovery coupling must be coherent

recovery 後に stale な child return を join に使ってはならない。

10. Superseded branches must not silently remain active

winner-take-all や reframe 後に不要になった branch は abandoned / superseded として処理すべきである。

---

最低限の自己点検

ある process が branch-and-join-aware かどうかは、次で点検できる。

1. なぜ branch を切るのか明確か
2. 各 child の local goal と scope を言えるか
3. 親が retain している authority を言えるか
4. child ごとの return contract があるか
5. join kind を言えるか
6. required branches と optional branches を区別できるか
7. conflict resolution と failure policy があるか
8. join と merge を混同していないか
9. sibling 間 visibility / capability を制御できているか
10. branch recovery と stale return の扱いがあるか

このどれかが欠けるなら、その process はまだ branch-and-join を十分に設計していない。

---

関連する概念

Branch and Join は、PCE 2.0 の multi-path process topology の中核として、次の概念と強く結びつく。

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

---

暫定的なまとめ

Branch and Join が言っていることは、最終的には次の一文に集約できる。

複雑な仕事を複数の path に広げることは簡単だが、それを壊さずに一つの process へ戻すことは難しい。
だから branch には bounded autonomy が、join には explicit integration contract が必要であり、親はそのあいだ global authority と continuity を保持しなければならない。

PCE 2.0 において branch は parallelism のためだけではない。
join も単なる集計ではない。
両者は together で、複数の bounded child path を使いながら、親の process integrity を保つための topology である。

だから Branch and Join は、単なる workflow pattern ではない。
それは、PCE 2.0 において 複数経路の局所自律と、明示的な再統合を両立させるための階層的 process topology である。