# Modular Runtime Phase 4 — Compatible Batch Canary 01

Date: 2026-08-01

Status: accepted live batch slice; Phase 4 gate remains open

Execution time: 129.823 seconds

## Accepted outcome

Two real `gpt-5.6-luna` workers at `xhigh` reasoning implemented disjoint Care Dashboard modules from one pinned Git base in isolated worktrees. Their processes overlapped for 80.187 seconds while the integration queue contained zero jobs and held zero claims. Each worker changed exactly one owned file and passed its focused behavior command.

Only after both sealed candidates were independently accepted did the existing integration queue claim them as one durable two-member epoch. The trusted host built one deterministic union commit, ran the union of both focused commands plus the shared system command once, and moved the authoritative first-parent history once.

The controller then closed SQLite after Git promotion but before recording the epoch receipt. Reopening recovered the exact epoch, made zero further model calls, reconstructed the identical union commit and evidence, atomically accepted both graph nodes, and advanced the graph integration head to the already-promoted commit.

This accepts the compatible batch seam. It does not accept all of Phase 4.

## Exact live evidence

| Boundary | Result |
|---|---|
| Base | `90cdcf8bbabbc6c2646d27c9c2d16dd6ac0931c9` |
| Person worker | PID 83014; 80.207 seconds; candidate `626c33abc8e51be6baa4b2938acdc7a61849930f` |
| Priority worker | PID 83040; 127.281 seconds; candidate `71201a11c932458075ddad739066b8746186024a` |
| Process overlap | 80.187 seconds; starts separated by 20 ms |
| Queue during implementation | 0 total jobs; 0 claimed jobs |
| Durable epoch | `ie-14583c232013bc903dcac1e2`; two topologically ordered members |
| Union checks | `npm run test:priority`, shared `npm run test:system` once, `npm run test:person` |
| Union commit | `dc65f765de073b2c1c58b967c8c803b5632385ba` |
| Authority movement | one first-parent promotion |
| Forced reopen | after Git promotion, before SQLite terminal receipt |
| Resume | exact epoch and receipt replay; zero model calls; both nodes accepted atomically |

Evidence directory: [`evidence/MODULAR_RUNTIME_PHASE4_BATCH_CANARY_01`](./evidence/MODULAR_RUNTIME_PHASE4_BATCH_CANARY_01/)

`run-summary.json` SHA-256: `9e5e7eb4ca865d8ffb705a2a8cb44db57d3bb0e30b2360cc043361d8d051b32d`.

## Measured speed result

The two observed worker durations sum to 207.488 seconds. Their actual concurrent span was 127.301 seconds. On this exact workload, overlap removed 80.187 seconds from the implementation critical path: a 38.647% worker-time reduction and 1.630× measured worker-lane speedup.

This is a measured comparison against serial execution of the same observed worker durations, not a claim that every workload receives the same speedup. Planning, acceptance, and integration remain serialized where authority requires it.

## Compatibility contract

The controller admits an initial batch of exactly two candidates only when all of these are true:

- both jobs belong to the same project and exact base commit;
- both durable attempts are accepted candidates with current graph, contract, and foundation lineage;
- both graph nodes are cooperative and validating;
- neither node is upstream or downstream of the other;
- their logical write resources differ;
- shared logical claims are read-compatible at the same version;
- their independently inspected changed-file sets are disjoint;
- their job checks exactly match their durable implementation packets.

The selection is deterministic by graph topology and job identity. Candidate implementation never owns or waits on the integration claim.

## One authority, not a second scheduler

Batching extends the existing `IntegrationQueue` with one nullable durable `epoch_id`. It does not add a scheduler, branch authority, transaction manager, model role, or workflow language. The graph controller still owns every state transition, SQLite still owns durable execution truth, and one integration queue still serializes promotion.

The epoch references existing work contracts, accepted attempt envelopes, resource-derived ownership, check lists, graph state, and integration jobs. It does not persist a competing copy of those records.

## Git promotion and recovery

The trusted adapter independently rechecks both exact commits, same-base ancestry, and claimed-versus-real changed files. Git's merge-tree machinery creates the disjoint union tree without changing authority. A deterministic commit is then created with the base and both candidate commits as parents, fixed epoch metadata, and a stable message.

Verification runs in a detached worktree at that union commit. Only after every unique command passes and the authoritative worktree remains clean at the pinned base does Git fast-forward once. If a combined check fails, a candidate conflicts, lineage changes, or changed-file evidence is false, the authoritative head remains the base.

Because the union commit is deterministic, a crash after Git moves but before SQLite completes is recoverable. The reopened controller reads the same claimed epoch, reconstructs the same commit SHA, reruns its checks, and records one shared terminal receipt for both jobs in the same SQLite transaction as both graph transitions and the integration-head update.

## Deterministic failure proof

Current tests additionally prove:

- overlapping changed-file claims are not batched;
- a union check failure leaves Git authority at the exact base;
- false changed-file evidence is rejected before union verification;
- an epoch claim survives SQLite close/reopen with exact membership;
- a whole claimed epoch can be requeued together;
- success or rejection terminalizes both jobs atomically;
- rejection moves both validating graph nodes to `revising` without advancing the graph head;
- replay cannot change a terminal epoch result.

## Current-revision regression

Commands:

```text
pnpm --filter @orchestrator/modular-builder-core test
pnpm --filter @orchestrator/modular-builder-core build
pnpm --filter @orchestrator/modular-builder-core check:source
NO_COLOR=1 RUN_LIVE_CODEX=1 PHASE4_BATCH_EVIDENCE_DIR=<absolute-evidence-path> pnpm --filter @orchestrator/modular-builder-core exec vitest run test/live-integration-batch-canary.test.ts --reporter=verbose
```

Results:

- 205 deterministic tests pass across 39 active suites;
- 13 separately gated live tests remain excluded from the deterministic lane;
- TypeScript passes with no diagnostics;
- 58 runtime source files average 176 logical lines, with p50 142 and p90 402;
- the largest runtime source file is 494 logical lines;
- no runtime source file crosses the 500-line cohesion-review threshold;
- live compatible batch canary: 1/1 in 129.823 seconds;
- two real Luna/xhigh calls, zero human checkpoints, and zero model calls after reopen.

## Exact boundary before the next slice

This canary proves the runtime batch authority and real concurrent worker path directly through the graph controller. The current `LongBuildModule` still intentionally dispatches only one member of a ready wave, so it does not yet consume this batch seam automatically.

The next smallest slice is to connect dependency-safe long-build waves to the accepted two-member batch path without duplicating scheduling, candidate acceptance, retry, or integration logic. After that, Phase 4 still requires graph compaction, bounded horizon renewal, cache proof, and a named combined system review before its full gate can close.