Fix same-operation reset revalidation

docs/engineering/EP_CENTRAL_OPERATIONAL_RESET_V1.md

@@ -2,7 +2,7 @@
 
 **Owning product:** Engineering Platform.  **Profile:**
 `EP_CENTRAL_OPERATIONAL_HISTORY_V1`.  **Server schema:** 68.  **Candidate
-release:** 2.3.82.
+release:** 2.3.83.
 
 This is a bounded local maintenance route for removing EP operational history
 while retaining installation identity, project and repository attachment,
@@ -33,6 +33,17 @@ the installation lock, derives the real local actor as `uid:<uid>:<account>`,
 persists `PREPARING`, and thereby activates database triggers that reject
 normal INSERT/UPDATE/DELETE entry points after any process restart.
 
+Plan version 2 separates that approved meaning from current availability.
+General `preview` remains read-only and reports `MAINTENANCE_ALREADY_ACTIVE`
+while any operation owns the writer fence; it cannot join that operation.
+Only `revalidate` accepts an already prepared operation ID and original plan
+digest. It read-only re-proves the real actor, exact active fence owner and
+phase, target/database/schema, source-row contents, preserved project/
+consumer/security/configuration bindings, generation, verified backup and
+product/implementation provenance, and returns a separate revalidation digest.
+It creates no operation, authority, backup or domain write. Version-1 prepared
+plans are rejected rather than reinterpreted under version 2.
+
 The durable states are:
 
 ```text
@@ -57,6 +68,12 @@ capability is present only on the maintenance service's connections. Preview
 requires the complete schema-derived normal-writer trigger set plus every
 maintenance-table guard before it can be allowed.
 
+`apply` calls the same owning revalidation and then repeats actor, target,
+schema/table set, active-operation ownership, meaningful source, preserved
+bindings, schema objects, implementation provenance and generation checks
+inside its actual database mutation transaction. A successful earlier
+revalidation therefore cannot survive later fence loss or drift.
+
 Before the first external effect, `abort` may move `PREPARING` or `AUTHORIZED`
 to terminal `ABORTED` and release the fence. It is rejected after artifact
 archiving or database apply starts. A failed-backup resume accepts only the
@@ -336,19 +353,26 @@ engineering-platform-maintenance prepare \
   --backup-root "/exact/protected/recovery/root" \
   --allow-operational-fk "fk:<child>:<rowid>:<parent>:<index>"
 
-# 2. DESTRUCTIVE: archive active artifacts/Inbox and purge the approved DB set.
+# 2. READ-ONLY: re-prove this exact prepared operation. A general preview still
+#    blocks new operations during maintenance and is not this gate.
+engineering-platform-maintenance revalidate \
+  --data-root "/exact/Engineering Platform Server/data" \
+  --operation-id "central-clean-<coordinator-reference>" \
+  --plan-digest "$PREVIEW_PLAN_DIGEST"
+
+# 3. DESTRUCTIVE: archive active artifacts/Inbox and purge the approved DB set.
 engineering-platform-maintenance apply \
   --data-root "/exact/Engineering Platform Server/data" \
   --operation-id "central-clean-<coordinator-reference>" \
   --plan-digest "$PREVIEW_PLAN_DIGEST"
 
-# 3. Prove physical/referential integrity, operational emptiness, backup and bindings.
+# 4. Prove physical/referential integrity, operational emptiness, backup and bindings.
 engineering-platform-maintenance verify \
   --data-root "/exact/Engineering Platform Server/data" \
   --operation-id "central-clean-<coordinator-reference>" \
   --plan-digest "$PREVIEW_PLAN_DIGEST"
 
-# 4. Only after the coordinated Forge+EP verification authorizes normal writers.
+# 5. Only after the coordinated Forge+EP verification authorizes normal writers.
 engineering-platform-maintenance finish \
   --data-root "/exact/Engineering Platform Server/data" \
   --operation-id "central-clean-<coordinator-reference>" \
@@ -388,6 +412,11 @@ as subprocesses. Its receipt directory is mode `0700`, its receipt and lock are
 mode `0600`, updates are atomic and fsynced, and symlinks or a concurrent
 coordinator process are rejected.
 
+Coordinator contract v2 invokes each owning product's operation-bound
+`revalidate` command; it no longer substitutes a second general preview or
+normalizes product output. Existing v1 coordinator receipts are deliberately
+refused and must not be reused as fresh reset authority.
+
 Choose a new joint reference and two distinct product operation IDs. Bind the
 exact installed CLI files, target roots and protected EP backup root during the
 initial preview:
@@ -458,11 +487,12 @@ in this delivery; do not run them against CENTRAL as part of installation. The
 joint receipt reaches `COMPLETE` only after both owning verifications, explicit
 resume authorization and both owning finishes.
 
-Immediately before every individual `finish`, the harness calls both owning
-`verify` commands again and requires each product to report `VERIFIED` or
-`COMPLETED`. This is a two-phase pre-finish readiness check, not a distributed
-transaction: the owning finishes remain sequential. If the first product has
-already reached `COMPLETED` and the second finish fails, the receipt records
+Immediately before every individual `finish`, the harness calls owning
+`verify` for an active verified operation and read-only owning `status` for a
+peer that is already terminal. It requires each product to report `VERIFIED`
+or `COMPLETED`. This is a two-phase pre-finish readiness check, not a
+distributed transaction: the owning finishes remain sequential. If the first
+product has already reached `COMPLETED` and the second finish fails, the receipt records
 `RECONCILIATION_REQUIRED`; reconciliation truthfully returns the pair
 `COMPLETED`/`VERIFIED`, keeps the unfinished product fenced, and requires an
 explicit retry of that same second finish. It never rolls the first product
@@ -501,11 +531,11 @@ decision.
 
 ## Delivery status
 
-The installed 2.3.81 read-only preview proved schema 68, `quick_check`, foreign
-keys and counts, but exposed a false `EXTERNAL_SYMLINK_UNSAFE` blocker by
-descending into a preserved updater `candidate-venv`. Release 2.3.82 contains
-the targeted opaque-boundary correction and synthetic positive/negative
-qualification. Protected PR review, hosted full gates, release publication,
-artifact-byte qualification and a new installed live preview remain separate
-evidence. Installation may activate schema 68 and the chat relationship repair
-but must not automatically prepare/apply a reset or delete historical rows.
+Release 2.3.82 remains the completed opaque-updater-boundary correction.
+Candidate 2.3.83 adds only the operation-bound revalidation contract and the
+coordinator-v2 consumer required by this remediation. Candidate qualification
+uses non-editable wheels, separate CLI processes, real SQLite backups and
+owning mutations on synthetic roots. Protected review, hosted full gates,
+release publication, artifact-byte qualification and installed repetition
+remain separate evidence until completed. An installation must not automatically prepare/apply
+a reset or delete historical rows.

docs/engineering/EP_SERVER_PRODUCTION_RELEASE.md

@@ -35,6 +35,14 @@ canonical staged wheel filename and digest are verified, with an explicit
 incomplete-state readback. It never turns an arbitrary operation sibling,
 malformed marker or linked boundary into known product data.
 
+The 2.3.83 corrective patch keeps schema 68. It adds a read-only,
+operation-bound revalidation command for an already `AUTHORIZED` reset and
+makes the external coordinator use that owning command instead of a second
+general preview. General preview still blocks new work during maintenance;
+apply repeats the source, authority, fence, backup, target and implementation
+checks at its mutation boundary. Publication and installation do not authorize
+a production reset.
+
 ## Release-operation lifecycle V1
 
 After both the production-wheel and dashboard qualifications succeed, the

package.json

@@ -1,7 +1,7 @@
 {
   "name": "engineering-platform-browser-validation",
   "private": true,
-  "version": "2.3.82",
+  "version": "2.3.83",
   "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 tests/engineering/dashboard_translation.test.mjs",

pyproject.toml

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

src/engineering_platform/ENGINEERING_PLATFORM_CONFIG.json

@@ -3,7 +3,7 @@
   "platform": {
     "id": "engineering-platform",
     "name": "Engineering Platform",
-    "version": "2.3.82",
+    "version": "2.3.83",
     "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.3.82",
+  "dashboard_version": "2.3.83",
   "handoff_protocol": 1,
   "memory_format": 2,
   "minimum_codex_cli": "0.146.0",
   "inbox_protocol": 1,
-  "platform_version": "2.3.82",
+  "platform_version": "2.3.83",
   "report_format": 2,
-  "runner_version": "2.3.82",
+  "runner_version": "2.3.83",
   "status_model": 1,
   "storage_schema": 45,
-  "watcher_version": "2.3.82"
+  "watcher_version": "2.3.83"
 }