Repository navigation
v2.3.0 — Support Parallel reviews ( Code review, Security review)
v2.3.0 — Parallel reviews
Code review and security review now run at the same time. Both shipped SDLC pipelines (flow.config.json + workflow-template/sdlc.config.json) launch the two reviewers concurrently off the same coding output — the happy path pays one review round instead of two.
What changed
- One line per config: "parallelWith": "code-review" on security-review — the existing parallelWith mechanism (v1.3.0), engine untouched
- Both review workers start together; testing stays the join barrier (reads both verdicts, readiness-gated ≥ 200 bytes each)
- Failure semantics: either review FAILing loops back to coding with a fix note; after the fix the whole review group re-runs — a fix can disturb either aspect, so both look again (previously a security fail already re-ran code-review; now the doctrine is symmetric). Bounded by maxRetries (default 2)
- Docs updated: README (What's new, feature line, Mermaid), CONFIGURATION.md §3.9 (second shipped pair + how to skip one member), ROADMAP v2.3.0 row
Upgrading
npx re-init keeps your existing configs unless --force — to get parallel reviews on an existing install, add "parallelWith": "code-review" to security-review in your flow.config.json (and workflow-template/sdlc.config.json if you use it). To skip one member of a parallel pair, also remove the parallelWith line.
Known edge (queued engine follow-up)
A definite FAIL in a parallel group currently preempts the stop for a hard-capped still-running sibling (pre-existing outcome ordering, first reachable now that reviews run ∥ with onFailGoto members). Hardening queued in the roadmap: still-running outranks the jump. Rare trigger, recoverable.
Testing
New E2E E31 pins the group semantics (concurrent launch, fix note, whole-group re-dispatch on retry, join barrier). Suite 328/328 (315 from v2.2.0 + 13 new), fully offline.
Includes