# Modular Runtime Phase 4 — Durable Horizon and Exact Resume Slice 01

Date: 2026-08-01

Status: accepted deterministic slice; Phase 4 gate remains open

## Accepted outcome

The long-build lane can now preserve a bounded Sol planning horizon across controller loss and continue from accepted graph truth without planning or implementing the same work twice. The new layer does not own another scheduler, worker lifecycle, resource broker, graph, or integration path. It records long-build intent around the existing `WorkGraph`, advances one existing graph module per controller event, and derives immutable milestone checkpoints only from accepted nodes and exact integration receipts.

This slice proves the minimum durable spine needed before a live multi-module canary. It does not yet claim compatible batch integration, graph compaction, warm-cache reuse, bounded horizon renewal, a real Sol adapter, or measured wall-time improvement.

## Mechanisms admitted

| Mechanism | Exact responsibility | Authority boundary |
|---|---|---|
| `LongBuildHorizonPlan` | Seal one or two detailed milestones plus at most twelve coarse later milestones | Read-only Sol/high proposes; deterministic host validates and seals |
| `MilestoneHorizonStore` | Persist one immutable active horizon and immutable milestone checkpoints | Passive SQLite persistence; it does not advance work state |
| `LongBuildModule.advance()` | Resolve the active milestone, rank its dependency-ready wave, and invoke one existing node module | One controller event; `GraphCoordinator` remains the graph lifecycle owner |
| Milestone checkpoint | Record exact graph revision, integration head, accepted nodes and commits, versions, decisions, metrics, and next horizon | Created only from accepted graph truth and integration receipts |

Two tables were added: `long_build_horizons` and `milestone_checkpoints`. Three bounded runtime source files carry the new behavior. No general workflow language, second graph store, polling supervisor, new process runtime, new lease system, or alternate integration mechanism was added.

## Contract invariants

- A horizon contains exactly one or two detailed milestones.
- A later milestone map contains at most twelve coarse entries; it is not an executable whole-project plan.
- Each detailed graph node belongs to exactly one milestone.
- An unfinished dependency cannot be omitted from the horizon or placed after its consumer.
- The deterministic host pins the project-request SHA-256, graph revision, integration head, accepted contract/foundation versions, creation time, and the read-only `gpt-5.6-sol`/high planner route.
- A stored project request is compared canonically, so harmless object-key order cannot create false lineage drift.
- An existing horizon is reused idempotently; a different plan cannot reuse its identity.
- Checkpoints require every named node to be accepted.
- Every writable accepted node requires a successful integration receipt.
- Checkpoint node and milestone identities are safe and unique.
- Ready work is ranked by downstream unlock depth, then stable topological order.
- In-flight recovery work is preferred over fresh dispatch.
- Until compatible batch integration exists, the module reveals the full safe wave but dispatches only its highest-unlock node so every fresh packet starts from the current integration head.

## Forced-interruption proof

The deterministic canary uses a two-milestone Helios graph:

1. `interfaces-and-api`: an already-accepted read-only interface node plus writable `catalog-api`;
2. `running-home`: writable `caregiver-home` depending on the first milestone;
3. `release-preview`: retained only as a coarse later horizon.

The first controller creates one durable horizon, integrates `catalog-api`, advances the graph and integration head, and is then forcibly interrupted before it can checkpoint the milestone. SQLite is closed and reopened. A second controller is constructed with a planner that throws if called.

On reopen the system:

- loads the original sealed horizon;
- makes zero additional planning calls;
- makes zero additional `catalog-api` implementation calls;
- recognizes the accepted first milestone from graph truth and writes its missing checkpoint;
- dispatches only newly ready `caregiver-home` from the advanced integration head;
- writes the second checkpoint after its exact integration receipt exists;
- returns `horizon_complete` on the following event;
- contains exactly two integrated jobs: one per writable node.

## Verification

Commands:

```text
pnpm --filter @orchestrator/modular-builder-core build
pnpm exec vitest run packages/modular-builder-core/test/long-build-horizon.test.ts packages/modular-builder-core/test/long-build-module.test.ts --reporter=verbose
pnpm --filter @orchestrator/modular-builder-core test
pnpm --filter @orchestrator/modular-builder-core check:source
```

Results:

- TypeScript passed with no diagnostics;
- five focused horizon and resume tests passed;
- 184 deterministic tests passed across 35 active suites;
- ten separately gated live tests remained skipped in the deterministic suite;
- 53 source files average 174 logical lines, with p50 142 and p90 370;
- the largest source file remains 492 logical lines;
- no source file crosses the 500-line cohesion-review threshold.

## Exact boundary of this acceptance

This is a deterministic controller-reopen proof, not the Phase 4 long-build gate. The executor in the restart canary is synthetic and writes the same durable integration/graph records expected from existing graph modules; it does not launch real Sol or Luna processes. The module currently dispatches one member of a planned compatible wave because atomic batch promotion has not yet been admitted.

Phase 4 remains open until current-revision evidence proves at least:

1. a real read-only Sol/high horizon planner;
2. a live multi-module build using existing backend/UI modules and Luna/xhigh workers;
3. forced process/controller interruption with exact resume and no duplicate model work;
4. compatible candidate batching with one atomic or recoverably ordered promotion boundary;
5. bounded horizon renewal and graph compaction without losing product lineage;
6. system-level acceptance, warm-cache reuse, critical-path behavior, and measured wall-time improvement.

The next slice is the real Sol/high horizon adapter plus a live interruption canary. It must reuse the current graph, attempt, process, lease, verification, and integration mechanisms.