PEC is the coordination plane: a rebuildable, non-authoritative projection of governed file truth with an ephemeral presence layer. It dispatches nothing, arbitrates nothing, and has no ruling-write path. Its value must survive graceful absence: no governed act may require PEC. Read the product's current exact source and owner records; do not treat an advisory PEC result as authority. PEC instructions

The live entry is projects/pec/loop/LOOP_INIT.md, reached through the project's current launcher and AGENTS.md. The loop's full Step 0 refreshes remote references, validates receipts, checks retired-workplan absence, reads decision/profile/decomposition/hold sources, and discovers actual Remaining surfaces. Do not substitute a general quick-start command block for this adopted procedure during execution. The retained _DomainEngines/pec paths in old citations resolve through D-PEC-80's relocation maps; they are not a second live loop. PEC loop

Select work from deliverable _STATUS.md ## Remaining and the exact scope of its grant. A missing Remaining section means no recorded selectable scope, not completion and not permission to invent an assignment. The loop permits an explicitly scoped owner request for preparation or correction without a Remaining item, but that exception does not authorize production or bypass a merged owner prerequisite. Owner acts and hold releases required by the loop are observed on fetched origin/main; predecessor work on the run branch is a different condition. PEC loop §5

The write fences are unusually specific. Default project-local surfaces are bounded coordination, the listed instruction surface, and the one-time status pointer allowance. Every other write—including new v2 source, scaffolding, manifests, and configuration—requires an owner-ruled D-PEC packet naming exact paths, acts, verification, and rollback. Existing code or a valid PRD grants no broader implementation permission. Instruction changes also retain Root's applicable scope requirements. PEC write fences · PEC loop §3

The old core, server, web, agent-sidecar, tools, fixtures, and prototype workspace manifests are a frozen reference corpus. Read and cite them; do not edit, delete, or repurpose them as live v2 implementation. Do not run the old server or a mutating CLI against a non-scratch database. V2 carries useful machinery as cited patterns under its exact packets. It remains content-minimal: paths, counts, SHAs, states, and hashes, not file or diff contents. Runtime retains session/delegation/turn ownership; PEC creates no second execution loop. PEC frozen-corpus and data rules

Before dispatch, review, fan-in, production reliance, consumption, or promotion, perform the reliance-hold preflight for the actual target and operation. Its interface is:

python3 execution/_Scripts/pec_reliance_hold.py \
  --register execution/_Coordination/ACTIVE_RELIANCE_HOLDS.csv \
  --target <exact-project-relative-target> \
  --operation <actual-intended-operation>

The tool supports historical-read-only-inspection, exact-correction-preparation, candidate-validation, dispatch-for-production, rely-for-production, consume, and promote. Use the intended act, not a less restrictive label. Missing or malformed hold data fails closed. A successful historical inspection preflight authorizes only that checked inspection. PEC loop §8 · PEC hold tool

Current bounded v2 code exists under v2/src/pec_v2, with API contracts, configuration, standard-library tests, posture tools, and documentation in adjacent v2 folders. Older “implementation does not exist” prose is dated product-stage history. Later exact packet evidence establishes particular work without proving full product readiness. Similarly, an adopted candidate PRD postimage is not necessarily applied to the live PRD. Read the controlling act and actual files. PEC operational source map and currency review

The current software profile registers v2-api-contract, v2-loop-registry, v2-store-guard, v2-core-posture, and harness-self-check. Use an explicitly compatible Python and the exact packet's finite checks; a legacy prototype npm CI pass does not prove that v2 checks ran. Required system kill/parity evidence remains unmet when unavailable, not an invented pass. Existing role/model conventions and stale launcher references need owning-loop compatibility treatment; a newer Root notice alone does not silently migrate PEC's accepted method. PEC profile · PEC loop §8 · PEC operational review

PEC retains one branch per run, one commit and receipt per iteration, a validated receipt chain, and a PR at terminus or when a merged prerequisite is needed. The September 22 development-loop notice leaves its accepted basis unchanged. Retiring obsolete Task Management launchers does not migrate PEC selection or create a new intake. Keep those outputs while adopting App/Piping undertakings use graph-based continuity. Close out only exact granted scope and preserve human-gated lifecycle, artifact acceptance, release, and professional reliance as separate acts. PEC loop §§5–7 · PEC development-loop notice