# Modular Runtime Phase 4 — Compaction, Horizon Renewal, and Verification Cache

Date: 2026-08-01

Status: accepted deterministic mechanisms

## Accepted outcome

The long-build lane can now shrink accepted graph detail, renew its bounded planning window, and reuse exact trusted verification without adding another graph, scheduler, database authority, or model-owned state transition.

These mechanisms are deliberately narrow:

| Mechanism | Accepted behavior | Refused behavior |
|---|---|---|
| Graph compaction | Replace one accepted milestone and its accepted-only ancestors with one content-addressed, read-only summary node | Compact running, queued, validating, revising, blocked, canceled, retry-relevant, or evidence-incomplete work |
| Horizon renewal | Promote exactly the next one or two coarse milestones after all current detailed milestones are checkpointed | Skip, rename, reorder, repeat, or lose coarse work; renew from a stale revision |
| Verification cache | Reuse a passed trusted command only for the exact source tree, parsed command, trusted environment fingerprint, policy version, and evidence bytes | Cache failures, unreaped processes, dirty integration workspaces, corrupt evidence, or a merely similar command/tree/environment |

## Replay-safe graph compaction

Every compaction is derived from an immutable milestone checkpoint and the current accepted graph. The summary retains:

- the checkpoint identity and SHA-256;
- the graph revision and SHA-256 before compaction;
- accepted contract and foundation versions;
- the exact integration head and accepted commits;
- boundary artifacts still consumed by active or later work;
- every recursively discoverable evidence SHA-256;
- the milestone decisions and completion time;
- the exact compacted node IDs and any absorbed prior summary IDs.

The controller computes ready nodes before and after compaction and refuses the transition unless the ordered ready-node set is byte-equivalent. An exact replay returns the existing summary without advancing the graph revision. Later compaction may absorb an active earlier summary node, but the earlier immutable summary record remains audit history. Ordinary graph writes still cannot rewrite accepted nodes or milestone summaries.

SQLite close/reopen tests prove that compacted graph identity, summary history, accepted lineage, and ready-node decisions survive process loss. Existing attempts, process results, integration jobs, reviews, and checkpoints remain in their original stores; compaction does not create an archive database.

## Bounded horizon renewal

`LongBuildModule` now compacts every accepted milestone automatically. If interruption occurs after checkpoint persistence but before graph compaction, reopen performs the missing deterministic compaction before dispatching new work.

When the detailed window is exhausted and coarse milestones remain, the same active horizon row is renewed with compare-and-set revision control. A read-only Sol/high proposal receives the previous sealed horizon and exact checkpoints, but deterministic code accepts it only when it promotes the exact first one or two coarse milestones and preserves the untouched suffix. Exact replay is a no-op; a successful renewal increments the durable horizon revision once.

The three-milestone deterministic fixture proves two horizons, automatic compaction after both completed milestones, exact prefix promotion, zero planner replay after SQLite close/reopen, rejection of a skipped coarse milestone, and recovery from checkpoint-before-compaction interruption.

## Trusted verification cache

The cache is a content-addressed artifact store, not an authority store. Both direct and batch Git integrators use the same trusted adapter. A lookup key includes:

- exact Git source-tree SHA;
- source command and its strictly parsed executable/arguments;
- trusted environment SHA-256;
- cache policy version.

A cache entry additionally addresses the exact passed process transport, including stdout and stderr. Cache hits still require the detached integration workspace to be clean. A changed tree, command, environment, policy, evidence hash, failed command, unreaped process tree, or corrupt entry becomes a miss. With the cache omitted, prior integration receipts retain their original byte shape.

## Deterministic verification

Commands:

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

Results:

- 221 deterministic tests passed across 43 active suites;
- 15 separately gated live tests were skipped by the deterministic lane;
- TypeScript passed with no diagnostics;
- 64 runtime source files average 179 logical lines, with p50 141 and p90 414;
- the largest runtime source file is 494 logical lines;
- no runtime source file crosses the 500-line cohesion-review threshold;
- `git diff --check` passed.

Focused proofs live in `graph-compaction.test.ts`, `long-build-renewal.test.ts`, `long-build-batch.test.ts`, `verification-cache.test.ts`, `git-direct-integrator.test.ts`, and `git-batch-integrator.test.ts`.

## Authority accounting

This slice adds no second graph, state writer, scheduler, worker runner, integration queue, or planning database. `WorkGraphStore` owns the atomic compaction transition, `MilestoneHorizonStore` owns compare-and-set renewal in the existing row, and the verification cache stores only independently revalidated artifacts. The deterministic controller remains the sole authority for state, acceptance, and integration.