ADW Pipeline System — Decision Input Form

1

D1: Should the pipeline support batched issue processing?

Current throughput is 15 issues total with queue depth never exceeding 2. Single-issue processing keeps failures isolated.

Recommended: Option A

A: Single-issue (current) Recommended

Simple, isolated failures, clean logs. No throughput bottleneck at current scale.

B: Batched (N issues/session)

Higher throughput. Risk of shared context contamination and harder debugging.

C: Parallel workers

Best throughput. Redis contention risk. Resource limits on VPS.

2

D2: How to handle implementations exceeding Claude CLI context?

Long implementations risk context exhaustion mid-pipeline. Current behavior fails and notifies, losing progress.

Recommended: Option B (v2)

A: Fail + notify (current)

Simple and transparent. Loses all progress on failure.

B: Checkpoint + resume (v2) Recommended

Checkpoint at step boundaries. Resume from last successful step. Preserves progress.

C: Decompose into sub-issues

Scales naturally. Requires issue graph logic. Future consideration.

3

D3: What retry/backoff strategy for GitHub API failures?

Transient GitHub API errors can cause pipeline failures. No retry logic exists currently.

Recommended: Option B

A: No retry (current)

Simple. Fragile on transient errors.

B: Exponential backoff (3 retries) Recommended

Standard pattern: 1s / 2s / 4s delays. Robust and well-understood.

C: Circuit breaker

Prevents cascade failures. Complex for current scale. Overkill.

4

D4: Should ADW auto-update CSA _handoff.json back-link?

When ADW processes a CSA handoff, the manifest could be updated with issue links and status. This creates full traceability.

Recommended: Option B

A: No back-link (current)

Simple. No cross-system dependency. Manifest becomes stale.

B: Auto-update manifest Recommended

ADW writes adw_issues_created array and updates status to handed-off. Full traceability.

C: GitReport reconciles

Decoupled approach. Delayed visibility. Good fallback option.

5

D5: How should the allowlist scale?

Current manual allowlist of 22 repos works fine. Decision is about future-proofing when repo count grows or team expands.

Recommended: Option B (v2)

A: Manual curation (current)

Full control. Explicit. Doesn't scale past 30+ repos.

B: Convention-based auto-discovery (v2) Recommended

Repos with .adw-pipeline.json auto-enroll. Allowlist becomes deny-list.

C: GitHub topic-based

Uses existing GH metadata. Requires topic discipline across repos.

Respondent

ADW Pipeline System — Decisions