16-18 hours sequential → ~6.5 hours parallel.

A v0.6.3-class release campaign decomposes into 5 stages. The hard sequential chain (pre-tag → gates → tag/release → smoke → publish) sets the floor. Inside each stage, almost everything parallelizes — and the existing ship-gate + a2a-gate harnesses already support per-run isolation, so distributing across droplets is configuration, not engineering.

5 sequential stages 8+ parallel agents 17 droplets at peak ~9.5h saved ~$10-15 cost
The hard sequential chain

Five stages. Each gates the next.

These cannot collapse. The release tag has to land before the release pipeline runs. The release pipeline has to publish before the smoke can validate. Everything else inside each stage IS collapsible.

0h 1h 2h 3h 4h 5h 6h 7h 1. Pre-tag prep 1h (with overlap) 2. Gates (parallel) 2h 3. Tag + release pipeline 2h 4. Smoke (15m) 5. Sync + evidence (30m)

Total: ~5h45m. Add ~30-45m of buffer for terraform provisioning + first-time orchestration debugging — call it ~6.5h wall.

Stage by stage

Where the time goes — and what collapses inside each stage.

1 · Pre-tag prep
2h sequential→1h parallel
Sequential parts (must order): version bump → CHANGELOG promotion → commit. Parallel parts run concurrent on local CPU. Plus overlap: spin DigitalOcean droplets for ship-gate AND author the 6 new a2a scenarios during this stage — both ready the moment pre-tag finishes.
Sub-taskTimeConcurrency
Version bump (Cargo.toml)5mblocking
CHANGELOG promotion10mblocking
cargo fmt --check2mparallel
cargo clippy --pedantic8mparallel
cargo test --features sal15mparallel
cargo llvm-cov --fail-under-lines 9225mparallel (longest)
[overlap] terraform apply ship-gate infra5mconcurrent
[overlap] author scenarios 43-4845mconcurrent
2 · Gates — ship-gate phases + a2a-gate scenarios
7-9h sequential→2h parallel
All four ship-gate phases AND the a2a-gate scenarios run on independent DigitalOcean droplets. Existing ship-gate + a2a-gate harnesses already support per-run isolation via separate runs/<run-id>/ output dirs. Wall time = max of any single phase or batch.
Phase / batchDropletsTimeBottleneck
Ship-gate Phase 1 — Functional130msingle-node smoke
Ship-gate Phase 2 — Multi-agent (W=2 of N=3)31hfederation soak burst
Ship-gate Phase 3 — Migration230mv0.6.2→v0.6.3 path
Ship-gate Phase 4 — Chaos abbreviated32hlongest leg
A2A batch 1 (scenarios 1-12)130mscenario count
A2A batch 2 (scenarios 13-24)130mscenario count
A2A batch 3 (scenarios 25-36)130mscenario count
A2A batch 4 (scenarios 37-48 incl. new 43-48)145mnew scenarios pad it
Total132h= max(Phase 4, anything)
3 · Tag + release pipeline
2h→2h (already optimal)
GitHub Actions matrix is already parallel: 5 platform builds run simultaneously, then 5 publishing jobs (Homebrew / PPA / COPR / Docker / crates.io) in parallel. The 2h is mostly idle waiting for runners. Bound by cargo build --release per platform — can't compress further without changing the build itself.
JobTimeConcurrency
Build matrix × 5 platforms~45mparallel (already)
Sign + SBOM + upload~15mparallel (already)
Publish jobs × 5 channels~30mparallel (already)
Pipeline overhead + waits~30midle
4 · Distribution-channel smoke
2h sequential→15m parallel
Four channel-validation agents fire in parallel. Each: pull/install → version check → start daemon → call memory_capabilities, assert schema_version=2. Independent — no shared state.
ChannelTimeAgent runs on
Homebrew15mmacOS runner
crates.io15mLinux runner
Docker GHCR10mLinux runner
Fedora COPR15mLinux runner (dnf)
5 · Sync to main + evidence publish
1h→30m parallel
Two independent things: merge release branch back to main, and update the test-hub evidence page with the final verdict + per-gate results. Run concurrent.
The math

Sequential vs parallel — line by line.

Time math · v0.6.3-class release campaign

StageSequentialParallelSaved
1 · Pre-tag prep (with overlap)2h1h−1h
2 · Ship-gate phases 1-44h2h−2h
2 · A2A 48 scenarios5h45m−4h 15m
3 · Tag + release pipeline2h2h0
4 · Distribution-channel smoke2h15m−1h 45m
5 · Sync + evidence publish1h30m−30m
Total wall-clock16h~6.5h−9.5h

Note: Stage 2's a2a-gate runs concurrent with ship-gate phases — its 45m wall happens within ship-gate's 2h envelope. Total Stage 2 wall = max(phases, a2a) = 2h. The "−4h 15m" saving for a2a counts what we'd otherwise pay if it ran serial after phases.

Constraints

What the parallelism costs.

ConstraintImpact
DigitalOcean cost13-17 droplets at peak × ~$0.05-0.10/hr × ~3hr peak = ~$5-15 total campaign. Negligible vs the value of one extra release-day.
Coordination overheadFirst time we run distributed orchestration, expect ~1-2h debugging the first phase. Amortizes over future releases — orchestrator scaffolding is reusable for v0.7+.
Terraform provisioningterraform apply takes ~3-5min per phase. Built into the wall-time math above as part of stage 1 overlap.
Result aggregationIf any agent fails to memory_notify the orchestrator, fall back to S3-style polling of the harness's run JSON dump. Existing harnesses already write structured artifacts.
Failure cascadingA failing scenario in batch 1 doesn't kill batch 2 — independent droplets, independent runs. Failures surface in the test-hub evidence page; operator decides whether to re-tag or proceed.
DigitalOcean API rate limits13 droplets in a single terraform apply: well within limits. Sequential apply per phase if rate-limited.
Two execution options

A or B.

A — Sequential execution. Lower risk. Slower (~16h). Run one phase at a time, catch issues with full attention. Right call when shipping hardware-budget is tight or coordination orchestrator isn't built yet.

B — Parallel execution with orchestrator. Higher upfront cost (~3h orchestrator scaffolding). Then ~6.5h campaign. Net ~9.5h vs ~16h. Right call when shipping speed matters AND we can re-use the orchestrator for v0.7+ campaigns.

For v0.6.3 specifically: orchestrator scaffolding lives in this test-hub repo as a one-time investment. Every future release reuses it. Recommend B.