# Modular Runtime Phase 3 — Live Backend Feature Canary 01

Date: 2026-08-01

Status: accepted backend slice; Phase 3 overall remains open

## Accepted outcome

One real `backend_feature` moved through the graph lane without operator input:

1. Sol/high inspected a disposable Git repository read-only and produced one schema-valid packet for the exact admitted `catalog-api` node.
2. The packet preserved project, work-item, recipe, mode, module, base, contract, foundation, and API-artifact lineage.
3. Luna/xhigh started from an attempt-isolated worktree, remained offline, changed exactly `src/catalog-route.mjs`, and passed `npm run test:catalog`.
4. Deterministic host code inspected the real diff, rejected out-of-scope ownership, and sealed one candidate commit.
5. The trusted verifier reran the worker-safe unit command and then ran `npm run test:integration`, which started the real HTTP server on localhost and proved known and missing response paths.
6. The serialized integration queue accepted exact base/candidate/check lineage, fast-forwarded the authoritative repository, and moved the graph node to `accepted`.

The live test completed in 185.480 seconds. The disposable repository ended clean at the exact candidate commit with one commit above the pinned base. The unit and HTTP integration commands also passed independently after authoritative integration.

This accepts the backend half of the Phase 3 gate. It does not accept `ui_foundation`, `ui_change`, independent visual review, a UI vertical slice, long-build execution, release authority, or Hermes.

## Canary product

The fixture began with a failing Catalog API route that always returned HTTP-style status 501 and `{ error: "not_implemented" }`. Its accepted contract required:

- a known id to return status 200 with exactly `{ id, name, available }`;
- a missing id to return status 404 with exactly `{ error: "not_found", id }`;
- no edit outside `src/catalog-route.mjs`;
- one focused unit command and one real HTTP integration command.

The graph pinned `api-contract:catalog@v1` as an accepted dependency, `catalog-contract-v1` as the contract version, `feature:catalog` as the only write domain, and `catalog-api` as the terminal `backend_feature` node.

## Defects the gate exposed before acceptance

Two rejected live runs were retained as design evidence rather than relabeled as success:

| Rejected run | Deterministic result | Correction |
|---|---|---|
| 66.744 seconds | The runner rejected a Sol packet whose pinned graph version differed from the admitted node | `SolPlanningTarget` now carries exact contract and foundation versions; planning, module admission, and runner diagnostics enforce them |
| 346.771 seconds | One Luna attempt returned an inconsistent stopped envelope; the clean retry then correctly stopped because its sandbox could not bind the required localhost server | Acceptance now separates offline `commands` from post-seal `trustedCommands`; Luna keeps no network authority and the controller owns localhost/browser/simulator verification |

The retry path also revealed that an attempt replay recomputed `enqueuedAt`. Resource admission now preserves the first durable queue age while still rejecting changed priority, duration, mode, or claims.

## Capability boundary admitted by this canary

- Luna runs only `acceptance.commands` inside its offline `workspace-write` sandbox.
- The trusted host reruns those commands against the sealed candidate.
- The trusted host alone runs `acceptance.trustedCommands` that need localhost, browser, network, simulator, external-service, or similar capabilities.
- Candidate acceptance requires worker-safe evidence; final integration requires every worker and trusted-host command.
- Adding a trusted command does not grant Luna network access and does not weaken final acceptance.
- The combined command budget remains one to four unique direct commands.

This is intentionally one small contract field, not a general workflow engine or permission language.

## Verification evidence

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 pnpm --filter @orchestrator/modular-builder-core exec vitest run test/live-backend-feature-canary.test.ts --reporter=basic
```

Current-revision results:

- 149 deterministic tests passed across 26 active suites;
- six real-model tests remain separately gated and are skipped by the deterministic suite;
- the Phase 3 backend live canary passed 1/1 in 185.480 seconds;
- TypeScript completed with no diagnostics;
- 36 source files average 162 logical lines, with p50 130 and p90 358;
- the largest source file is 459 logical lines;
- `graph-work-runner.ts` is 380 logical lines, `graph-coordinator.ts` 339, `codex-sol-planner.ts` 245, and `backend-feature-module.ts` 130;
- no source file crosses the 500-line review threshold.

## Exact boundary before the UI slice

The backend module proves that one admitted graph node can become accepted product behavior through real Sol planning, Luna implementation, clean bounded retry semantics, deterministic sealing, independent trusted verification, serialized integration, and durable graph acceptance. Phase 3 still requires the visual side: a pinned `ui_foundation`, one bounded `ui_change`, running-product captures, deterministic behavior checks, independent visual judgment, and one accepted integrated UI vertical slice.