Use projects/chirality-runtime/AGENTS.md and its loop/LOOP_INIT.md. Recover the accepted ownership through execution/_Coordination/MIGRATION_ACCEPTANCE_2026-09-06.md, then docs/PRD_AUTHORITY.md, docs/PRD.md, and execution/_Decomposition/_AUTHORITY.md. Read HANDOFF_STATE.md, the newest receipt, and later linked amendments together. An old candidate label does not nullify a later owner act; migration acceptance does not activate every carrier or release every hold. Runtime entry · Runtime loop

The seven-carrier register and SCA-003-era records preserve a frozen accepted basis. The September 12 D-GOV-43/SCA-004 packet overlays that reading: it retires six carriers in place, revises retained stewardship, closes the obsolete held bindings through a purpose change, and preserves the separately disposed R16-B relationship. Some PRD, Scope-of-Work, register, and pointer bytes stay unchanged because Root pins them. Read the overlay and status histories; do not “repair” their old counts or frozen text merely to match a newer summary. Closure by retirement does not assert that the old held empirical acts were performed. Runtime PRD revision · Runtime impact assessment

The current architectural reading is an application-owned Runtime service hosting stock Codex. The App is its production consumer. Retained daemon package names, compatibility providers, and historical supplier/LaunchAgent proof records do not revive a separate daemon deployment, qualify another MVP engine, or authorize a client integration. Runtime owns its product contracts and services; shared instruction/tool changes route to Root, and client changes route to the owning project. PEC compatibility remains an opportunity to verify, not an MVP prerequisite silently declared satisfied. Runtime PRD revision · Runtime entry

Source is principally in the contracts, core, daemon, client, and cli packages, all under packages/; inspect their actual roots and dependencies before editing. Tests live in the maintained test surfaces, with frozen execution evidence kept outside the executable test inventory. The project manifest declares Node >=22.19.0, npm run typecheck, npm test, and npm run build. The profile registers typecheck and unit as always-checks. A connecting App/Runtime change also needs verification of the real client path; two component passes do not establish integration. Runtime package manifest · Runtime profile · Chirality change conventions

For an authorized shell-equipped actor, these are read-only sourced posture views from the checkout, not acceptance operations:

python3 tools/practitioner_harness/harness.py status --project runtime
python3 tools/practitioner_harness/harness.py drift --project runtime

The full live Runtime entry also specifies remote refresh and Git observations for actual execution. Do not claim fresh remote state from these two views alone. Its first return identifies divergence, local changes, accepted authority, current lifecycle/holds, exact task boundaries, available checks, prerequisites, and the next lawful manager action. Runtime loop · Practitioner harness

Runtime's September 22 development-loop notice communicates changed shared source only. It does not adopt the revision, repin a mirror, requalify a consumer or change Runtime product instructions. Preserve a durable project handoff under the governing run's closeout contract and record actual checks. Runtime explicitly claims no receipt validator or automatic receipt-format enforcement; do not invent one. Runtime development-loop notice · Runtime loop