# Modular Runtime Phase 5 — Isolated Release Canary 01

Date: 2026-08-01

Status: accepted release-isolation slice; Phase 5 remains open

Execution time: 1.697 seconds

## Accepted outcome

The modular runtime can now release one exact frozen Git commit through a terminal read-only graph node. It verifies platform, security, and integration behavior in a detached worktree, packages the accepted commit once, publishes only within standing authority, exercises rollback, persists every stage in the existing SQLite authority, and lets `GraphCoordinator` perform the final graph acceptance.

This path makes no model call and starts no code-writing worker. A release cannot become accepted merely because a deploy command exits successfully: exact check evidence, package identity, deployment evidence, rollback proof, graph lineage, and the active release lease must all agree.

## Deliberately narrow mechanism

| Boundary | Accepted behavior | Refused behavior |
|---|---|---|
| Plan | Content-address one frozen commit, exact checks, target, credential handle, requested mode, and standing-policy outcome | Mutable plan identity, malformed credential handle, missing verification domain, or unsealed policy change |
| Verification | Run 3–12 strict direct commands in an exact detached Git worktree and require a clean tree after every check | Shell syntax, changed release worktree, failed or unreaped process, newer working-tree bytes, or mismatched workspace |
| Package | Create one deterministic Git archive for the frozen commit and address its bytes with SHA-256 | Packaging the current checkout merely because it is newer |
| Deployment | Publish only an authorized preview/production target; otherwise preserve an artifact-only bounded result | Inventing deployment authority, credentials, or a target during execution |
| Rollback | Exercise the previous pointer or first-deployment absence, then restore the accepted deployment | Claiming rollback readiness without performing and verifying the pointer transition |
| Acceptance | Persist every stage and the final receipt before deterministic terminal graph acceptance | A publisher, worker, model, or receipt alone declaring the graph accepted |

The initial publisher is intentionally local and content-addressed. It is the deterministic platform seam used to prove deployment and rollback semantics without granting an external Cloudflare mutation. A later platform publisher must satisfy the same `ReleasePublisher` contract and standing authority checks.

## Forced-restart sequence

1. A temporary Git repository accepted releasable `v1`, then advanced its authoritative `HEAD` to incompatible `v2`.
2. The graph remained pinned to the accepted `v1` commit and scheduled one final read-only `release` node.
3. Three real `ProcessFamilyRunner` commands verified the platform, security, and integration domains in a detached `v1` worktree.
4. The adapter packaged the exact `v1` tree, published its content-addressed archive, exercised rollback, restored the release pointer, and persisted the complete SQLite receipt.
5. The canary intentionally interrupted before `GraphCoordinator` could accept the release node.
6. The controller and SQLite connection closed and reopened.
7. Resume reused the durable receipt, repeated zero verification, package, deployment, or rollback stages, and accepted the exact terminal node with the original active lease.
8. Terminal replay returned the same receipt and graph revision without executing another stage.
9. A separate exact warm verification reused all three trusted command results with zero process execution.

The newer authoritative Git `HEAD` remained unchanged and clean throughout. The archived release contained `v1`, proving that release identity followed accepted graph lineage rather than ambient checkout state.

## Exact measurements

- model calls: 0;
- cold verification processes: 3;
- cold package calls: 1;
- cold deployment calls: 1;
- cold rollback-proof calls: 1;
- stages repeated after reopen: 0;
- verification commands repeated after reopen: 0;
- exact warm verification commands avoided: 3/3;
- active or recovery-pending leases after acceptance: 0;
- graph revision before reopen: 2;
- terminal graph revision: 4;
- exact terminal replay: passed.

## Durable evidence

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

`run-summary.json` SHA-256: `5e3e486d540850118cda1cb0b6f3264578c5d3e16b7b18492adb61f2de84bced`.

The evidence records the frozen and newer authoritative commits, every release-stage receipt, command evidence hashes, graph revisions, restart counts, cache avoidance, terminal state, and final lease count. File URIs in the receipt identify the ephemeral canary fixture used during the accepted run; the durable identities are the recorded commit and SHA-256 values.

## Verification

Live command:

```text
NO_COLOR=1 RUN_LIVE_RELEASE=1 \
PHASE5_RELEASE_EVIDENCE_DIR=<absolute-evidence-path> \
pnpm --filter @orchestrator/modular-builder-core exec vitest run test/live-release-canary.test.ts --reporter=verbose
```

Result: 1/1 passed; the measured canary body completed in 1.697 seconds.

Current deterministic regression:

- 231 tests passed across 47 active suites;
- 16 separately gated live tests were skipped;
- TypeScript passed with no diagnostics;
- 70 runtime source files average 183 logical lines, with p50 144 and p90 409;
- no runtime source file exceeds 494 logical lines;
- `git diff --check` passed.

Focused release coverage consists of ten deterministic tests across the release contract, durable module, frozen Git adapter, and filesystem publisher suites. These tests include authority fallback, exact stage replay, SQLite reopen, deterministic rejection, cold/warm verification, both rollback shapes, package-byte tamper rejection, and stored deployment/rollback receipt mutation rejection.

## Remaining Phase 5 boundary

This canary accepts the isolated release mechanism only. It does not prove the modular runtime is better than legacy Core, switch runtime authority, archive legacy Core, grant a production deployment, or implement Hermes.

Phase 5 remains open until representative direct and complex scopes run through a matched, content-addressed shadow comparison beside legacy Core. Authority may switch only if the modular runtime matches or wins the direct lane and materially improves complex autonomous work. Legacy Core remains untouched and authoritative until that evidence exists.