# Modular Runtime Phase 2 — Work Graph and Resources Gate

Date: 2026-08-01

Status: accepted; Phase 2 gate progress 4/4

## Accepted outcome

The graph lane now has one deterministic coordination path joining a persisted `WorkGraph`, a central persisted `ResourceBroker`, and a serialized persisted `IntegrationQueue`. Two projects can own compatible worker leases at the same time. Conflicting cooperative writers are ordered globally. Expired ownership enters recovery instead of silently granting a duplicate writer. An accepted candidate moves through validating and exact-lineage integration before its graph node becomes immutable `accepted` history.

This gate does not claim that the Phase 3 backend/UI recipes, a live multi-node Sol-to-Luna product build, the long-build horizon, release authority, or Hermes exist. Those remain later gates.

## Gate evidence

| Required behavior | Current evidence | Result |
|---|---|---|
| Two projects progress concurrently | `graph-coordinator.test.ts` grants disjoint Helios and Atlas nodes in one scheduling cycle; `phase2-concurrency.test.ts` starts both real detached worker processes and observes both process groups alive concurrently | accepted |
| Compatible nodes overlap | The broker compatibility matrix allows disjoint domains, immutable reads, next-version writers, and isolated competitive candidates; the real process gate holds two disjoint project leases simultaneously | accepted |
| Conflicting writers serialize | `graph-coordinator.test.ts` proves the older Helios `feature:shared` writer runs while Atlas remains queued, then Atlas receives the lease only after exact Helios release | accepted |
| Killing one worker does not disturb the other project | The real process gate reaps Helios by its recorded process group, proves Atlas is still alive, then records only Helios as `revising` while Atlas remains `running` | accepted |

## Mechanisms admitted in Phase 2

### Persisted WorkGraph

- validates node, edge, project, artifact, contract, and foundation identity;
- rejects cycles, dangling nodes, duplicate edges, and unproduced artifact versions;
- derives readiness deterministically from accepted dependencies;
- calculates a stable topological order;
- preserves accepted nodes as immutable history;
- bounds breaking invalidation to actual consumers and descendants;
- routes non-breaking additions to reverification;
- rejects stale compare-and-set writers and survives database reopen.

The graph is canonical JSON in SQLite. No graph database or workflow language was added.

### Central ResourceBroker

- persists multi-claim requests and leases;
- grants a complete claim bundle atomically;
- implements cooperative, competitive, and read-only compatibility;
- distinguishes logical, physical, and integration resource classes;
- permits immutable `read(vN)` beside `write(vN+1)`;
- serializes same-domain cooperative writers and all same-resource exclusive claims;
- orders by deterministic priority plus age;
- prevents younger work from stealing one claim needed by an older blocked bundle;
- moves expired leases to `recovery_pending` until exact process ownership is resolved;
- preserves unrelated project leases during release and recovery;
- rejects changed durable attempt identity after restart.

### Serialized IntegrationQueue

- persists accepted candidate lineage and exact required checks;
- allows only one claimed integration job per project;
- orders by graph revision, topological position, then durable job id;
- allows separate projects to hold integration claims concurrently;
- accepts only exact base/candidate/fast-forward lineage with every named check passed;
- replays an identical terminal receipt idempotently and rejects changed terminal truth;
- requeues or rejects an abandoned integrator claim explicitly;
- survives database reopen.

### GraphCoordinator

- is the sole Phase 2 path that advances graph state around resource and integration transitions;
- validates base, contract, foundation, dependency-read claims, work mode, and one primary logical write before dispatch;
- reconciles already-active leases after controller/database reopen;
- atomically records `running -> validating`, queues integration, and releases the worker lease;
- atomically records integration acceptance or bounded revision;
- recovers or releases one expired dispatch without changing another project;
- leaves agent judgment outside deterministic scheduling and never treats process exit as acceptance.

## Verification run

Commands:

```text
pnpm --filter @orchestrator/modular-builder-core test
pnpm --filter @orchestrator/modular-builder-core build
pnpm --filter @orchestrator/modular-builder-core check:source
```

Results:

- 124 deterministic tests passed across 23 active suites;
- five real Phase 1 Sol-to-Luna canaries remain separately gated and were intentionally skipped by the fast suite;
- the real Phase 2 process-isolation canary passed on macOS/POSIX process groups;
- TypeScript completed with no diagnostics;
- 32 source files average 159 logical lines, with p50 124 and p90 344;
- the largest source file is 459 logical lines;
- `graph-coordinator.ts` is 321 logical lines, `resource-broker.ts` 344, `work-graph.ts` 358, and `integration-queue.ts` 212;
- no source file crosses the 500-line review threshold.

## Exact boundary before Phase 3

Phase 2 proves deterministic graph mechanics and process isolation. It does not yet prove a product recipe can turn a Sol-produced graph node into a real Luna implementation and accept it in a running backend or UI. Phase 3 must add one module at a time and pass shared conformance fixtures before the first real backend feature and first real UI vertical slice may be claimed.