feat: add run quality assurance

.github/workflows/canonical-versioning.yml

@@ -0,0 +1,21 @@
+name: Canonical versioning
+
+on:
+  push:
+    branches:
+      - '**'
+
+permissions:
+  contents: read
+
+jobs:
+  validate-version-source:
+    name: Validate committed canonical version source
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v5
+      - name: Read-only source consistency
+        run: |
+          python3 -m pip install --quiet .
+          python3 tools/qualification/advance_platform_build.py --source-root . --check
+          python3 tools/qualification/platform_version_consistency.py --source-root .

.github/workflows/engineering-platform-validation.yml

@@ -63,19 +63,25 @@ jobs:
       - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v5
       - uses: actions/setup-python@5fda3b95a4ea91299a34e894583c3862153e4b97 # v7
         with: {python-version: '3.12'}
-      - name: Build and install next canonical Engineering Platform wheel
+      - name: Build and install committed canonical Engineering Platform wheel
         run: |
           python3 -m pip install build coverage
-          python3 tools/qualification/build_platform_wheel.py --source-root . --install-python "$(command -v python3)"
+          version="$(python3 -c 'import tomllib; print(tomllib.load(open("pyproject.toml", "rb"))["project"]["version"])')"
+          python3 tools/qualification/build_platform_wheel.py --source-root . --version "$version" --install-python "$(command -v python3)"
       - name: Import, bytecode and qualification smoke
         run: |
           python3 -c "import engineering_platform, engineering_platform.execution_host"
           python3 -m compileall -q src/engineering_platform
           PYTHONPATH=src python3 tools/qualification/console_route_ownership_guard.py --source-root src
-          python3 tools/qualification/platform_version_consistency.py --source-root .
+          python3 tools/qualification/platform_version_consistency.py --source-root . --installed-python "$(command -v python3)"
           python3 -m unittest discover -s tests -p 'test_*.py'
       - name: Qualify installed P-TRANSPORT 3×2 ingress matrix
         run: python3 tools/qualification/p_transport_installed_ingress_matrix.py --source-root .
+      - name: Qualify deterministic Genesis and Managed execution E2E
+        # The E2E script creates an isolated CENTRAL data root and a local bare
+        # Git origin for Managed.  CI therefore exercises both execution modes
+        # without mutating a GitHub repository.
+        run: python3 tools/qualification/p_deterministic_execution_e2e.py --source-root .
       - name: Qualify HTTP JSON API, OpenAPI and Postman contract
         run: PYTHONPATH=src python3 tools/qualification/http_json_postman_contract.py --source-root .
       - name: Enforce Engineering Platform coverage contract

.github/workflows/ep-server-production-release.yml

@@ -98,9 +98,12 @@ jobs:
           python3 -m pip install "dist/engineering_platform-${{ needs.release-context.outputs.version }}-py3-none-any.whl"
           python3 -m compileall -q src/engineering_platform
           PYTHONPATH=src python3 tools/qualification/console_route_ownership_guard.py --source-root src
-          python3 tools/qualification/platform_version_consistency.py --source-root .
+          python3 tools/qualification/platform_version_consistency.py --source-root . --installed-python "$(command -v python3)"
           python3 -m unittest discover -s tests -p 'test_*.py'
           python3 tools/qualification/p_transport_installed_ingress_matrix.py --source-root .
+          # This uses an isolated CENTRAL root and local bare Git origin; the
+          # release gate never writes to an external GitHub repository.
+          python3 tools/qualification/p_deterministic_execution_e2e.py --source-root .
           PYTHONPATH=src python3 tools/qualification/http_json_postman_contract.py --source-root .
       - name: Enforce production coverage and security gates
         run: |

docs/development/ENGINEERING_PLATFORM_ROADMAP.md

@@ -279,6 +279,13 @@ one bounded Forge Action still enter through HTTP, receive durable identity,
 be admitted, mutate its repository, validate/review/repair/finalize, retain
 terminal evidence, and reconcile after Forge restart?
 
+`EP_RUN_QUALITY_ASSURANCE_V1` is a bounded EP execution-contract increment:
+reuse the existing quality lifecycle step for pinned, independent read-only
+quality and security assurance, structured findings/readback and one shared
+three-round repair budget. It is not a second orchestrator, generalized Agent
+topology, or a claim of installed qualification until exact-head delivery and
+installed evidence are retained.
+
 | Umbrella gate | Exact first-loop capability | Evidence state at this proposal | First-loop disposition |
 | --- | --- | --- | --- |
 | Phase-3 package/install | A clean installed Server/CENTRAL/runtime that can run the canary | Historical dependency authority says incomplete; no current installed-proof claim is made here | `AUTONOMY_CRITICAL` bounded capability; full historical phase needs reconciliation |

docs/development/LOCAL_AGENT_RUNNER.md

@@ -40,6 +40,20 @@ is a separate Engineering Platform release. The private dashboard displays
 them with the corresponding live components, while its status bar displays the
 Engineering Platform version and Git commit.
 
+`BOOTSTRAP_RELEASE_CADENCE_V2` (`engineering-platform-bootstrap-release-cadence-v2`)
+makes CI read-only. One bounded engineering increment defaults to `PATCH`;
+documentation-only work is explicit `NO_BUMP`; `MINOR` is an explicit
+capability/release boundary; and `MAJOR`/`EXACT` require applicable authority.
+Version preparation happens before final qualification through the protected
+delivery seam. Repair, requalification and main merge reuse that operation and
+never create a secondary allocation. Existing V1 receipts remain historical.
+
+The event policy is shared with Forge and Workspace and is canonically defined
+by Forge Platform in [Canonical product versioning](https://github.com/pcvantol/forge-platform/blob/main/docs/architecture/CANONICAL_PRODUCT_VERSIONING.md).
+Engineering Platform retains its richer package/manifest projection and its
+own release-publishing authority; the shared policy grants neither publication
+nor deployment authority.
+
 At runner startup, `engineering-execution-host` reads the manifest and rejects an unsupported
 platform major version, older runner, older Bootstrap Contract, unsupported
 checkpoint/memory/report format or unsupported Codex CLI. Diagnostics state the

docs/engineering/EP_PRODUCER_READBACK_CONTRACT.md

@@ -1,6 +1,6 @@
-# EP producer readback contract v1.1
+# EP producer readback contract v1.2
 
-`v1.1` is the consumer-visible, authenticated readback contract for a
+`v1.2` is the consumer-visible, authenticated readback contract for a
 canonical EP submission.  It belongs to the existing EP Server HTTP JSON API;
 it is not a second API, consumer database, queue, or execution authority.
 
@@ -20,12 +20,19 @@ storage.
 
 ## Response identity and evidence
 
-The JSON response is schema version `1.1` and contains the immutable canonical
+The JSON response is schema version `1.2` and contains the immutable canonical
 submission ID, project/repository IDs, producer provenance, submitted
 correlation/mission/engineering-action IDs, and a server-computed
 `accepted_request_digest`. `run` is `null` until CENTRAL has claimed the
 accepted submission; once present, its run ID and lifecycle state are canonical.
 
+`disposition` is separate from the execution result. It records the current
+submission state, monotone revision, worker eligibility and, where an operator
+command exists, its operation/event reference, verified actor reference,
+reason and timestamp. `DECLINED` is terminal for the submission while keeping
+`run: null` and `result.outcome: NOT_STARTED`; EP never fabricates an execution
+receipt, commit or terminal artifact for a declined-but-unclaimed submission.
+
 Forge requests place the versioned, exact execution identity under
 `constraints.forge_execution`: host, repository, correlation, mission and
 revision, intent and revision, action, runtime-prompt ID/digest, and retry
@@ -52,7 +59,31 @@ is present in the checkpoint's verified commit evidence. `VALIDATION_ONLY`,
 they are not fabricated into successful delivery.
 
 The machine-readable response shape is
-[`producer-readback-v1.schema.json`](../../src/engineering_platform/schemas/producer-readback-v1.schema.json).
+[`producer-readback-v1.2.schema.json`](../../src/engineering_platform/schemas/producer-readback-v1.2.schema.json).
+
+## Operations Console queue disposition
+
+The Console-only mutation boundary is separate from the producer API:
+
+```
+POST /api/queue-disposition?project={project_id}
+Authorization: Bearer <EP-issued, project-scoped operator credential>
+```
+
+The exact JSON v1.0 request has `contract_version`, a unique `operation_id`,
+`submission_id`, `expected_state`, integer `expected_revision`, `disposition`
+and a bounded operator `reason`.  It rejects duplicate JSON names, unknown or
+missing fields, stale state/revision, unknown submissions and invalid state
+transitions. Replaying the same operation ID and exact command is idempotent;
+using that ID for a different command is a conflict.
+
+Authentication and queue authority are deliberately distinct. A scoped
+producer credential receives `403 OPERATOR_CAPABILITY_REQUIRED`; no credential
+receives `401 UNAUTHENTICATED`. `QUEUE_HOLD_RESUME` permits defer, quarantine
+and resume. `QUEUE_DECLINE` permits terminal decline, including the direct
+`QUARANTINED -> DECLINED` path. The worker claim and this command arbitrate in
+one CENTRAL transaction, so a claimed submission returns `409` and is never
+cancelled by a queue action.
 
 ## Forge consumer mapping fixture
 

docs/engineering/EXECUTION_HOST_ARCHITECTURE.md

@@ -28,10 +28,17 @@ Genesis target. A Genesis run only evaluates its target profile; a Managed run
 only evaluates its repository profile. JSON status files are projections, not
 an ownership or lifecycle authority.
 
-Lifecycle phase identifiers are compatibility contracts. Their presentation is
-mode-aware: the shared `REPAIR_AGENT` phase is projected as pull-request check
-repair for Managed work and autonomous quality repair for Genesis. This is a
-display-only distinction; no checkpoint or transaction state is translated.
+Lifecycle phase identifiers are compatibility contracts. `QUALITY_CONTROL_AGENT`
+is the shared post-implementation assurance boundary: it invokes independent
+read-only Quality and Security reviewers on one pinned candidate. It cannot
+write the repository, create a PR, or approve an implementer's work. Findings
+are immutable, versioned checkpoint evidence; a missing, malformed, or
+candidate-mismatched required review is `UNRESOLVED`, never a pass. Only the
+shared `REPAIR_AGENT` role may correct accepted blockers. Its run-wide,
+persistent budget is three rounds total, spanning local validation, assurance,
+hosted checks and finalization; a new SHA, phase, resume or PR does not reset
+it. The Console projects the same stored review identities and repair rounds
+for live and historical runs.
 
 The immutable profile lists repository, remote, upstream, clean-worktree,
 branch, workspace authorization, host and capability qualification, providers,
@@ -60,7 +67,37 @@ previous lease history.
 EP serializes mutating work at the repository/execution-scope boundary: no more
 than one mutating execution may own a scope at once. FIFO is the default queue
 ordering within that scope, but admission and selection remain policy-driven;
-FIFO is not a second planning authority. The active mutation lease starts with
+FIFO is not a second planning authority.
+
+## CENTRAL queue operator handling
+
+CENTRAL owns the durable queue record after admission; Forge remains the
+authority for the originating Action intent.  Consequently, an Operations
+Console operator must never delete a queued submission or silently make it
+disappear.  Queue handling is an explicit, per-submission, reasoned state
+transition with an append-only audit event and producer-visible readback.
+
+The state machine is `QUEUED -> DEFERRED|QUARANTINED|DECLINED`,
+`DEFERRED -> QUEUED`, and `QUARANTINED -> QUEUED|DECLINED`. `DECLINED` has no
+outgoing transition. Direct `QUARANTINED -> DECLINED` never creates an
+intermediate `QUEUED` state or a worker-eligible window. A declined submission
+is terminal but retained with its correlation and reason. A lifecycle worker
+selects only admitted `QUEUED` submissions; queue disposition never cancels a
+claimed run.
+
+Forge observes these dispositions through the canonical producer-readback
+contract and reconciles its own Action state.  EP does not invoke Forge
+internals, mutate Forge storage, or infer cancellation.  Until a versioned
+Forge callback contract exists, readback is the required reconciliation path.
+Queue commands carry a versioned operation ID, expected state and monotone
+revision, and are arbitrated with the worker claim in CENTRAL. Origin checking
+is CSRF protection only, never operator authentication. The authenticated
+consumer must additionally hold an active, project-scoped capability:
+`QUEUE_HOLD_RESUME` for defer/quarantine/resume and `QUEUE_DECLINE` for the
+terminal decline transition. Consumer credentials do not imply either grant.
+The installation owner grants or revokes this narrow capability with the
+Server CLI; it is not a producer-facing or dashboard-managed role system.
+The active mutation lease starts with
 the accepted execution and is retained through provider work, validation,
 delivery, finalization and reconciliation. It is released only after terminal
 or governed recovery evidence establishes that the scope is safe for later

docs/engineering/EXECUTION_HOST_OPERATIONS.md

@@ -127,12 +127,13 @@ terminal date, and a repeated recovery cannot add a second run or count.
 ## Controlled provider-interruption qualification proof
 
 For the dedicated, one-shot recovery proof, an operator may arm only an
-already-admitted, non-terminal run before it reaches `QUALITY_CONTROL_AGENT`:
+already-admitted, non-terminal run before it reaches `EXECUTE_AGENT`:
 
 ```sh
 python3 -m tools.engineering.provider_recovery arm-controlled-interruption \
   --repo /Users/pcvantol/Documents/GitHub/djconnect \
-  --run-id <run-id> --phase QUALITY_CONTROL_AGENT
+  --run-id <run-id> --phase EXECUTE_AGENT \
+  --central-database <CENTRAL_DATA_ROOT>/epdata.sqlite
 ```
 
 Inspect the exact control with `controlled-interruption-status` and cancel an
@@ -144,6 +145,70 @@ once consumed it cannot be disarmed or fired again. Prompt text and submission
 provenance cannot create this control, and it never creates a retry submission
 or new root run.
 
+For qualification, run the control together with the recovery tests rather
+than treating an armed marker as a passing result. The required evidence is:
+`ARMED` before the boundary, one `CONSUMED` control artifact at
+`EXECUTE_AGENT`, one recovery/retry lineage, and one terminal outcome.
+The deterministic installed E2E lives in
+`tools/qualification/p_deterministic_execution_e2e.py`. It uses an isolated
+CENTRAL root and local Git fixture to exercise Genesis, Managed, and a third
+controlled-recovery lane. The third lane pauses only its deterministic
+qualification adapter after the canonical `INITIALIZE` checkpoint, arms the
+real run-bound control through the installed CLI, and verifies `CONSUMED`, one
+same-run `RECOVERED` lineage, terminal assurance evidence, and the run in the
+dashboard's project-scoped history. The dedicated provider-recovery unit suite
+additionally qualifies unsafe and ambiguous recovery branches.
+
+### Installed qualification runtime composition
+
+The installed E2E also exercises the real host-preflight runtime checks. Its
+temporary CENTRAL root owns a minimal executable under
+`managed-codex-cli/bin/codex`; it reports the fixed qualification runtime
+version and is written into that root's `server.json` before the Server starts.
+This is a composition fixture, not a provider fallback: the deterministic
+qualification agent remains the only component that performs the test work.
+The launcher exists so `runtime_executable` and `runtime_invocation` are
+verified through the same configured EP-managed runtime boundary as a normal
+installation. It is removed with the temporary qualification root and never
+creates or relies on an account-wide Codex installation.
+
+Consequently, CI always runs Genesis, Managed and armed recovery with a real
+preflight. The separate external GitHub profile below additionally proves the
+remote-write adapter and merge boundaries; it is not invoked by ordinary CI.
+
+### Explicit external Managed GitHub qualification
+
+The default deterministic qualification never contacts GitHub. To prove the
+Managed hand-off against an approved dummy repository, an operator must supply
+all three values deliberately:
+
+```sh
+python3 tools/qualification/p_deterministic_execution_e2e.py --source-root . \
+  --managed-repository /absolute/path/to/clean-dummy-checkout \
+  --managed-github-repository owner/approved-dummy-repository \
+  --allow-managed-github-writes
+```
+
+The command rejects a dirty checkout, a non-matching `origin`, unavailable
+GitHub access, or a missing explicit write flag. It commits and pushes an
+implementation branch, creates and verifies its PR, then acts as the explicit
+operator only for that named disposable fixture: it merges the implementation
+PR, verifies the host-created `codex/finalize-<run-id>` Finalization PR,
+merges it, and requires the canonical run to reach `COMPLETE`. It repeats the
+same real remote handoff and finalization for the armed recovery lane, proving
+the same-run `RECOVERED` lineage rather than merely an armed marker. Remote
+branches are deleted by the GitHub merge operation; the fixture repository and
+the optional persistent local qualification root are retained for inspection.
+This profile is intentionally excluded from CI and release gates.
+
+## CENTRAL project lanes
+
+CENTRAL retains a FIFO lane per project. It permits at most one active,
+blocked-with-open-resolution, or retry-pending run in that project. The
+Lifecycle Worker may dispatch one eligible run from each different project in
+parallel, so a Genesis and a Managed run in separate projects may overlap; a
+second run in either same project cannot.
+
 ## Local repository validation gate
 
 Validation is selected from the actual bounded-branch diff. Documentation and

package.json

@@ -1,7 +1,7 @@
 {
   "name": "engineering-platform-browser-validation",
   "private": true,
-  "version": "2.1.6",
+  "version": "2.3.0",
   "scripts": {
     "test:engineering-dashboard": "PYTHONPATH=src python3 -m engineering_platform.dashboard_browser_validation",
     "test:engineering-dashboard-logic": "node --test tests/engineering/dashboard_status_store.test.mjs tests/engineering/ui_localization_contract.test.mjs",

pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "engineering-platform"
-version = "2.1.6"
+version = "2.3.0"
 description = "Local-first Engineering Platform execution operations runtime"
 readme = "README.md"
 requires-python = ">=3.11"

src/engineering_platform/ENGINEERING_PLATFORM_CONFIG.json

@@ -3,7 +3,7 @@
   "platform": {
     "id": "engineering-platform",
     "name": "Engineering Platform",
-    "version": "2.1.6",
+    "version": "2.3.0",
     "generation": 2,
     "documentation_namespace": "engineering-platform",
     "capability_registry_version": 1

src/engineering_platform/ENGINEERING_PLATFORM_VERSION.json

@@ -1,15 +1,15 @@
 {
   "bootstrap_contract": "2026.12",
   "checkpoint_format": 1,
-  "dashboard_version": "2.1.6",
+  "dashboard_version": "2.3.0",
   "handoff_protocol": 1,
   "memory_format": 2,
   "minimum_codex_cli": "0.146.0",
   "inbox_protocol": 1,
-  "platform_version": "2.1.6",
+  "platform_version": "2.3.0",
   "report_format": 2,
-  "runner_version": "2.1.6",
+  "runner_version": "2.3.0",
   "status_model": 1,
   "storage_schema": 41,
-  "watcher_version": "2.1.6"
+  "watcher_version": "2.3.0"
 }