Wave-loop driver: end-to-end orchestration of the deterministic wave loop

[Ryan-Atkinson87]

Assemble the end-to-end deterministic wave loop (Spec §4.2) — the driver that ties together every Phase-1/2/3 primitive into the full run, proving the loop end-to-end on code_runner itself (and Trive). This is the capstone integration issue for the phase.

Spec §4.2 (the wave loop — full), §4.1 (roles split: deterministic engine presses the buttons), §4.3 (fresh sessions), §17.7 (render instructions at run start), §1 Principle 1 (sequencing/git/gating/PR/sync are plain Python).

Acceptance criteria

• At run start, render provider instruction files per repo (Provider-format renderer (compose personas to CLAUDE.md + skill files) #22) from the execution profile (execution-profile.yaml schema and fail-fast loader #21, generated by Tech-lead profile-generation session (propose execution-profile, human-confirm before write) #23).
• Drive Spec §4.2 in order: sync integration branch + create the wave agent branch (Phase 2 Agent-branch lifecycle: per-wave branch creation, merge-sync, slug derivation #10); if the wave is unplanned (GitHub issue/milestone reader and dependency-order wave assembly #26), invoke the planner persona session to create GitHub issues (§4.2 step 3) — Notion creation deferred to Phase 5; order issues by dependency (GitHub issue/milestone reader and dependency-order wave assembly #26).
• For each unblocked issue, under the concurrency scheduler (Wave concurrency scheduler (parallel-across-repos, serialised merge queue, configurable cap) #25): dependency check (algorithmic; unmet → park + continue, §4.2 step a) → feature branch (Feature-branch lifecycle: per-issue branch, review diff, serialised merge, delete #11) → implement-gate-fix loop (Bounded implement-gate-fix loop with 30-min checkpointing and stuck-agent guard #27) → backend API-contract verification for backend: true repos (§4.2 step e, using workflow-api-contract-verification) → internal review cycle (Bounded internal-review cycle (PR-body fill, review-feedback-re-review, merge on approve) #28) → merge.
• Sessions run strict-deny / locked-down (Claude tool-permission and hook lockdown (allowed_tools, strict-deny, Pre/PostToolUse) #18) throughout.
• A board/Notion sync hook is called at §4.2 step h but is a no-op/stub until Phase 5 (trackers) — the call site exists so Phase 5 is additive.
• Parked blockers do not stop the wave: the engine continues other unblocked issues and collects every parked blocker (§4.2, §9).
• When all issues are Done or parked: keep the agent branch current with the integration branch (merge if it advanced, §5.1), then trigger the hand-off engine (Phase 2 Hand-off engine: push agent branch and open one structured PR per repo #14) to push and open one PR per repo, listing parked blockers (§5.4).
• Crash-safe: the loop writes/reads state markers (Per-issue state markers and resume-or-reset crash recovery #24) at each step so a restart resumes or resets correctly (§18.2).
• All sequencing, git, gating, PR mechanics are plain Python; AI is invoked only for plan/implement/review/contract-verify judgement (Principle 1) — verified by review.
• An end-to-end test (sessions mocked) drives a small two-issue, one-repo wave from agent-branch creation through hand-off, including one parked blocker that does not halt the wave.

Notes

This is an integration/driver issue: it assembles the components built in #18, #22, #23, #25, #26, #27, #28 and Phase-2 #10/#14 — it should not re-implement them. Usage-monitor pausing (§4.2 "throughout") is Phase 4: the scheduler's step-down hook (#25) is present; the usage logic that drives it is not in scope here.

Depends on: #18, #22, #23, #25, #26, #27, #28, #14