Explore deepening Pass modules around per-kind execution #802

Strength: Worth exploring · Dependencies: mock

Files: src/pass.rs, src/architect.rs, src/pickup.rs, src/security.rs

Before

flowchart LR
  A[Architect run] --> P[Pass effects interface]
  K[Pickup run] --> P
  S[Security run] --> P
  subgraph Shared[Pass module]
    P --> R[Architecture review execution]
    P --> F[Security execution]
    P --> D[Run dispatch]
  end
  P --> L[Launch and GitHub adapter]
  P --> T[In-memory adapter]
  classDef broad stroke:#dc2626,stroke-width:2px;
  class P broad

After — candidate ownership, subject to exploration

flowchart LR
  subgraph Architect[Architect run module]
    A[Architect run] --> R[Architecture review execution]
  end
  K[Pickup run] --> D[Run dispatch]
  subgraph Security[Security run module]
    S[Security run] --> F[Security execution]
  end
  R --> D
  F --> D
  R --> L[Launch and GitHub adapter]
  F --> L
  D --> L
  R --> T[In-memory adapter]
  F --> T
  D --> T
  classDef deep stroke-width:3px;
  class Architect,Security deep

Problem: the shared Pass effects interface couples three independently changing modules to Architecture review lifetimes, Pickup work and Security execution, reducing locality.

Evidence:

• At reviewed head 05cca76, the shared interface declares 23 operations, including Architecture review callbacks and ten Security-specific operations; both adapters implement the entire interface.
• Architecture review execution takes a conclusion callback on the mutable adapter while Sessions stay open, so background-work failure attribution and Worktree lifetime span the Architect run module and the shared implementation.
• Pickup reservation and refresh already live outside this interface, while the shared Run dispatch implementation earns reuse through its asks, Command record transitions and child outcome accounting.

Solution: explore moving per-kind execution into its owning Pass module, keeping shared Run dispatch where it earns leverage, and test whether this yields depth through a smaller interface at each seam.

Deletion test: deleting the current shared module outright would scatter useful dispatch and recording behavior; the candidate must instead concentrate per-kind lifetime knowledge without duplicating that behavior.

Why this is not Strong: a narrower trait alone would only move methods; the scan did not establish a complete design that hides more implementation knowledge or reduces test setup enough to justify the migration.

What to settle: demonstrate the proposed ownership with an Architecture review execution experiment, preserving conclusion-failure attribution and cleanup; compare caller knowledge and test setup before choosing whether to deepen the other Pass modules or keep the current design.

Testing direction: the interface is the test surface; retain the existing CLI behavior checks and replace displaced internal tests rather than adding a parallel suite, with the production adapter and in-memory adapter crossing the same seam.

Wins, if demonstrated:

• Locality for per-kind execution changes
• Leverage from shared Run dispatch
• Depth through smaller tested interfaces

Covered by: no matching open issue found after reading the open issue titles and bodies and repeating the coverage search before publication.

Constraints: preserve scheduler ownership, skip ordering, Claim rules, reservation lifetime, interruption finishing and private Security recording; no ADR conflict identified, and no behavior change or implementation is authorized by this idea.