feat: add product-owned operational reset

.github/product-version-operations/operational-reset-v1-2.7.22.json

@@ -0,0 +1,16 @@
+{
+  "baseline_version": "2.7.21",
+  "classification_rationale": "user-authorized-operational-reset-v1",
+  "component": "product",
+  "event_lineage": "user-authorized-operational-reset-v1",
+  "expected_head": "03f9514e0f1e66a79ccb684c9fdbe51b28b88090",
+  "operation_id": "operational-reset-v1-2.7.22",
+  "policy_revision": "forge-bootstrap-release-cadence-v2",
+  "product": "forge",
+  "projection_paths": "product-version.json",
+  "release_class": "PATCH",
+  "requested_bump": "patch",
+  "requested_version": null,
+  "schema_version": "1",
+  "target_version": "2.7.22"
+}

.github/workflows/forge-production-release.yml

@@ -276,19 +276,19 @@ jobs:
         with: { python-version: '3.11' }
       - name: Read back, hash, and reinstall both published distributions
         env:
+          READBACK_CACHE_TOKEN: ${{ github.run_id }}-${{ github.run_attempt }}
           VERSION: ${{ needs.release-context.outputs.version }}
         run: |
           set -euo pipefail
           wheel="forge_autonomy-$VERSION-py3-none-any.whl"; sdist="forge_autonomy-$VERSION.tar.gz"
-          curl --fail --silent --show-error "https://pypi.org/pypi/forge-autonomy/$VERSION/json" -o pypi.json
-          python3 - "$wheel" "$sdist" release-input/dist/SHA256SUMS pypi.json <<'PY'
-          import json, sys
-          expected = {line.split()[1]: line.split()[0] for line in open(sys.argv[3])}
-          files = {item['filename']: item for item in json.load(open(sys.argv[4]))['urls']}
-          for name in sys.argv[1:3]:
-              assert name in files and files[name]['digests']['sha256'] == expected[name], 'remote hash mismatch'
-              print(files[name]['url'])
-          PY
+          python3 scripts/pypi_distribution_readback.py \
+            --version "$VERSION" \
+            --hashes release-input/dist/SHA256SUMS \
+            --output pypi.json \
+            --cache-token "$READBACK_CACHE_TOKEN" \
+            --attempts 24 \
+            --interval-seconds 15 \
+            --timeout-seconds 10
           mkdir registry-readback
           for artifact in "$wheel" "$sdist"; do
             artifact_url="$(python3 - "$artifact" <<'PY'

README.md

@@ -106,6 +106,23 @@ The exact instance-ID comparison is consistency evidence, not a newly invented
 cryptographic peer identity; preflight reports the latter as `NOT_ASSERTED`.
 `CONFIGURED` is therefore never presented as `LIVE_READY`.
 
+## Operational-history reset
+
+Forge schema 38 provides a bounded, product-owned maintenance service under
+`forge server reset`. Start with the strictly read-only installed preview:
+
+```text
+forge --data-root "/path/to/Forge Server" server reset preview
+forge --data-root "/path/to/Forge Server" server reset status
+```
+
+The mutating `prepare`, `apply`, `resume`, `verify`, and `finish` commands are
+documented in the [operator runbook](docs/operations/FORGE_OPERATIONAL_RESET_RUNBOOK.md).
+They preserve instance/peer/provider/security/allocator bindings, use a verified
+SQLite-consistent private backup, fence owning writers durably and reject
+unknown tables/files/symlinks. They do not reset EP, create a Mission, rotate or
+print credentials, or provide arbitrary SQL/table deletion.
+
 ## Deterministic runtime health evaluation
 
 Forge now provides a library-only, read-only health evaluator in

docs/architecture/FORGE_OPERATIONAL_RESET_V1.md

@@ -0,0 +1,136 @@
+# Forge operational-history reset V1
+
+**Status:** implemented product service and local administration CLI; source
+qualification is recorded separately from protected delivery, release and
+installed use. **Scope:** Forge-owned state only. This is neither a factory
+reset nor a general SQL/database administration surface.
+
+## Contract and boundary
+
+The profile `forge-operational-history-v1` creates a new dataset generation
+while retaining the Runtime Instance, project/EP binding, operator/security
+authority, provider configuration, credential references, identifier
+high-watermarks and anti-replay evidence. It never reads or writes Engineering
+Platform CENTRAL and never invokes EP's CLI.
+
+The same immutable operation identity binds:
+
+- exact Runtime Instance ID, canonical database path/binding, marker and schema;
+- plan, request, effect-set and meaningful-source-revision digests;
+- real locally bound operator and current `SECURITY_APPROVAL` plus
+  `OWNER_PROGRAMME_AUTHORIZATION` authority;
+- installed implementation digest and Git source revision when genuinely
+  available (`UNAVAILABLE_IN_INSTALLED_PACKAGE` is explicit otherwise);
+- exact acknowledged referential findings wholly inside the purge set;
+- one verified recovery backup and its manifest digest;
+- dataset generation before/after, artifact steps and final verification.
+
+There is no `--force`, arbitrary table list, peer SQL or automatic rollback.
+The stable machine envelope is `contract_version=operational-reset-v1` and
+contains no bearer values or raw credential verifiers.
+
+## Schema-owned data classification
+
+Schema version 38 owns this complete table mapping. Any additional application
+table blocks reset until this contract is updated. SQLite indexes, triggers and
+system objects are validated separately and are not purge candidates.
+
+| Category | Tables | Reset treatment |
+| --- | --- | --- |
+| `INSTALLATION_AND_CONFIGURATION` | `runtime_metadata`, `execution_host_peer_configuration`, `planning_provider_security_config`, `planning_provider_external_session_config` | Preserve exactly. Credential references stay references; no Keychain read/dump/rotation. |
+| `SECURITY_AND_AUTHORITY_LEDGER` | `installation_operator_binding`, `installation_operator_audit`, `governance_authority`, `governance_capability_grants`, `governance_decisions`, both provider-security/session audit tables, `planning_provider_generation_permits`, `mission_id_allocations` | Preserve. Pending/transport-committed provider permits become non-executable `INVALIDATED_BY_OPERATIONAL_RESET`; allocator history is unchanged. |
+| `OPERATIONAL_HISTORY` | Mission state/lifecycle/recommendation/review/intake/amendment/evidence tables; Action derivation/result/reattempt/closure tables; execution context/receipt/integration/delegation/scheduler/correlation/exchange tables; token-preflight tables; bootstrap portfolio snapshot; Forge operational logs | Tombstone replay-sensitive identities, archive eligible external evidence, then delete in the schema-owned child-first transaction. |
+| `DERIVED_CACHE_OR_PROJECTION` | `mission_runtime_projections`, `planning_state`, `dispatcher_state` | Delete from the active generation. |
+| `MAINTENANCE_AUDIT` | `operational_reset_state`, `operational_reset_operations`, `operational_reset_audit`, `operational_reset_tombstones`, `operational_reset_artifact_steps` | Preserve; excluded from Mission/run/usage views. |
+| `UNKNOWN_OR_UNSUPPORTED` | Anything else | Destructive progression blocked. |
+
+Record-level rules matter. `planning_provider_generation_permits` remain in the
+security ledger but lose executable state. Mission-bound token and reattempt
+records are removed only after their receipt/request/authorization identities
+become durable reset tombstones. Old correlation, submission, Action and receipt
+identities cannot be reintroduced through owning writers.
+
+## External data classification
+
+The database, WAL/SHM and owning lock are SQLite/runtime control, not domain
+history. `instance/runtime-instance.json`, prior `backups/`, locks and strict
+installation/qualification artifacts are preserved. In particular
+`artifacts/controlled-installation-*` and entries under
+`artifacts/{installation,qualification}/` retain installation/artifact/product
+qualification provenance.
+
+Only product-shaped operational paths are eligible:
+
+- `artifacts/{operational,runtime,missions}/...`: archive in the operation's
+  recovery backup, verify digest, then remove from active ingest;
+- recognized `.json`, `.jsonl` and `.journal` entries under `journals/`, and
+  `.log`/`.jsonl` entries under `logs/`: archive, verify and remove;
+- regular files under `cache/`: remove as derived cache, without claiming them
+  as recovery evidence.
+
+Unknown artifacts, instance files, top-level files, special files, unreadable
+entries and every symlink block. The service never follows a symlink and never
+touches repositories, source, documents, other workspaces or other instances.
+
+## State machine, fencing and crash recovery
+
+```text
+read-only PREVIEW
+  -> PREPARED (durable writer fence + exact authority/request binding)
+  -> BACKUP_VERIFIED
+  -> DATABASE_APPLIED (one domain transaction)
+  -> APPLIED (every filesystem step reconciled)
+  -> VERIFIED
+  -> COMPLETED (writer fence released)
+```
+
+Normal owning `RuntimeDatabase` opens fail while maintenance is active. Every
+already-open connection is fenced by schema triggers that directly consult the
+durable state before a write, without requiring a connection-local UDF during
+normal operation. The reset transaction temporarily removes only its exact
+delete/update fence triggers under `BEGIN IMMEDIATE` and restores them before
+commit. A process-local OS lock is therefore not the crash boundary. The
+same-root mutation lock serializes runtime service ticks and maintenance
+commands. A raw/peer SQL writer is unsupported and does not become a product
+interface.
+
+`resume` rereads the same operation. A failure before the SQLite commit leaves
+the whole operational population. A failure after commit continues forward.
+Each external item has a durable step; if removal happened before its step write,
+resume accepts absence only when the verified archive copy still matches.
+Neither resume nor uncertainty creates another reset.
+
+## Backup and recovery
+
+Prepare uses SQLite's online backup API after the durable writer fence, then
+converts the isolated image to a self-contained non-WAL snapshot. The private
+`0700` operation directory contains a `0600` database, marker, archived external
+artifacts and manifest. The manifest binds source instance/schema/version,
+operation/plan/request, source counts, exact known FK findings, inclusions,
+exclusions and per-file SHA-256. It excludes Keychain, provider login/session,
+venv/tooling, cache, locks and earlier backups.
+
+Verification copies the database into a temporary non-active root, performs
+`quick_check`, reconstructs the meaningful source revision and compares external
+digests. A known operational orphan remains honestly listed in the backup; the
+backup is byte/semantic recovery evidence, not falsely labelled FK-clean.
+
+Forward reconciliation is the normal recovery. Do not copy the old database
+back over a running instance and do not use it to undo later revocations,
+budgets or external effects. A physical restore requires a separately authorized
+stopped-root recovery decision; it must first reconcile security/external state.
+
+## Postconditions
+
+Verify requires `integrity_check=ok`, `quick_check=ok`, zero foreign-key errors,
+zero rows in every operational/projection table, no active pre-reset provider
+permit, no active classified operational file, exact preserved-table digests,
+same Runtime Instance/marker/peer binding, the expected dataset generation and
+a still-verifiable recovery backup. Only its exact verification digest releases
+maintenance. “Clean” therefore means no old active/executable operational
+population; security tombstones, allocator history and maintenance audit remain.
+
+Repository document `missions/MISSION-0003.md` is reported as a historical
+repository-document namespace. It is not an active Runtime Mission. The reset
+does not rename it, fabricate a Mission, reset the allocator or promise that the
+next runtime identity will display `MISSION-0003`.

docs/architecture/FORGE_SERVER_CONFIGURATION_AND_DATA_OPERATIONS_V1.md

@@ -8,6 +8,14 @@ explicit, guarded data operations; it does not authorize their execution now.
 The [scoped roadmap](../roadmap/FORGE_OPERATIONS_CONSOLE_V1.md) and
 [documentary DAG](../roadmap/forge-operations-console-v1.json) track this work.
 
+> **Bounded delivered slice:** the separate
+> [Forge operational-history reset V1](FORGE_OPERATIONAL_RESET_V1.md) now
+> implements and qualifies the owning local application service/CLI needed for
+> clean-state preparation. This does not implement FC-EXPORT, FC-IMPORT,
+> FC-RELOCATE, FC-VACUUM, the Console/API/daemon or full FC-STATE/FOC-Q. Its
+> protected delivery, release, installation and live preview remain evidence
+> dimensions separate from source implementation.
+
 ## 1. Locality and ownership
 
 ```text

docs/operations/FORGE_OPERATIONAL_RESET_RUNBOOK.md

@@ -0,0 +1,124 @@
+# Forge operational reset operator runbook
+
+This runbook uses only the installed Forge-owned CLI. Replace the placeholders
+with values returned by the immediately preceding JSON receipt. Keep the Forge
+data root explicit for every command. Exit code `0` means the command produced
+its declared readback; exit code `1` means no success may be inferred.
+
+> **Production safety:** in the current preparation assignment run `preview`
+> only against the selected live root. Every command from `prepare` through
+> `finish` changes maintenance/backup/reset state and is destructive or enables
+> destructive continuation. Use those commands only during the later explicitly
+> authorized clean-CENTRAL preflight.
+
+## 1. Read-only preview
+
+```text
+forge --data-root "/absolute/Forge Server" server reset preview
+```
+
+Record `target.instance_id`, `target.database_identity`, `schema_version`,
+`dataset_generation`, `plan_digest`, `relevant_revision_digest`, counts,
+blockers, exact `required_fk_acknowledgements` (under `details`) and the
+preserved-bindings digest. A schema-37 installation may be inventoried, but
+reports `SCHEMA_MIGRATION_REQUIRED`; preview never migrates it.
+
+## 2. Enter maintenance and create/verify backup — MUTATING
+
+```text
+forge --data-root "/absolute/Forge Server" server reset prepare \
+  --operation-id "forge-reset-<approved-reference>" \
+  --plan-digest "sha256:<preview-plan>"
+```
+
+For a specifically reviewed operational-only FK finding, repeat its exact ID:
+
+```text
+  --acknowledge-operational-fk "sha256:<exact-issue-id>"
+```
+
+There is no broad ignore option. Findings reaching preserved or unknown data
+block. Prepare authenticates the installed local operator and current Security/
+programme capabilities, activates the durable writer fence, produces the
+consistent backup and returns `request_digest` plus verified `backup.digest`.
+If backup creation fails, leave the instance in maintenance and use `status`;
+do not start another operation.
+
+## 3. Apply the reset — DESTRUCTIVE
+
+```text
+forge --data-root "/absolute/Forge Server" server reset apply \
+  --operation-id "forge-reset-<approved-reference>" \
+  --plan-digest "sha256:<preview-plan>" \
+  --request-digest "sha256:<prepared-request>" \
+  --backup-digest "sha256:<verified-backup>"
+```
+
+## 4. Verify — MAINTENANCE REMAINS ACTIVE
+
+```text
+forge --data-root "/absolute/Forge Server" server reset verify \
+  --operation-id "forge-reset-<approved-reference>" \
+  --plan-digest "sha256:<preview-plan>" \
+  --request-digest "sha256:<prepared-request>" \
+  --backup-digest "sha256:<verified-backup>"
+```
+
+Require `state=VERIFIED`, all operational counts zero, all integrity checks
+green, unchanged target/bindings and a non-empty `verification_digest`.
+
+## 5. Interrupted operation
+
+```text
+forge --data-root "/absolute/Forge Server" server reset status \
+  --operation-id "forge-reset-<approved-reference>"
+
+forge --data-root "/absolute/Forge Server" server reset resume \
+  --operation-id "forge-reset-<approved-reference>" \
+  --plan-digest "sha256:<preview-plan>" \
+  --request-digest "sha256:<prepared-request>" \
+  --backup-digest "sha256:<verified-backup>"
+```
+
+Resume reconciles the same operation through verification. If failure happened
+before a backup digest exists, omit `--backup-digest`; the same PREPARED operation
+finishes its backup first. Do not automatically restore or create a replacement
+operation.
+
+## 6. Release maintenance — MUTATING
+
+```text
+forge --data-root "/absolute/Forge Server" server reset finish \
+  --operation-id "forge-reset-<approved-reference>" \
+  --verification-digest "sha256:<verified-result>"
+```
+
+An unapplied PREPARED/BACKUP_VERIFIED operation may instead be safely cancelled:
+
+```text
+forge --data-root "/absolute/Forge Server" server reset finish \
+  --operation-id "forge-reset-<approved-reference>" \
+  --cancel-before-apply
+```
+
+Cancellation is forbidden after database apply. After successful coordinated
+Forge and EP verification, perform the separately authorized read-only local
+HTTP authentication/preflight; it must not create a Mission or submission.
+
+## Coordinated later clean-CENTRAL preflight
+
+1. Run installed read-only preview for Forge and EP; bind both target and plan
+   digests to one external maintenance reference.
+2. Resolve the historical document/runtime Mission namespace decision before T0
+   if the normal allocator cannot produce the desired display label.
+3. Prepare both owning operations; confirm both durable maintenance states and
+   both verified backups.
+4. Recheck both exact plans under their writer fences.
+5. Apply each owning reset sequentially. If either fails, keep both products in
+   maintenance and resume the same owning operation; never auto-resume the first.
+6. Verify both empty operational generations, preserved identities/peer binding,
+   security/allocator state and backups.
+7. Finish both only after the joint coordinator has recorded both verification
+   digests. Then run the non-generating HTTP authentication check.
+
+This recipe is intentionally not executed by the current implementation task.

docs/reports/FORGE_OPERATIONAL_RESET_DELIVERY_STATUS.md

@@ -0,0 +1,29 @@
+# Forge operational reset delivery status
+
+The bounded Forge-owned operational-history reset is implemented in source with
+schema 38 and the `forge server reset` command family. It is independent from
+the planned Operations Console, full export/import/relocation product and Forge
+Server daemon. Those broader nodes remain planned.
+
+Status dimensions are deliberately separate:
+
+| Dimension | State |
+| --- | --- |
+| Architecture/contract | IMPLEMENTED in `FORGE_OPERATIONAL_RESET_V1.md` |
+| Application service and CLI | IMPLEMENTED |
+| Isolated synthetic positive/negative/crash qualification | PASSED locally: 23 reset regressions within `scripts/validate.sh` |
+| Full repository source gate | PASSED locally: 694 tests, product-version and offline-projection validation |
+| Independent protected-candidate review/checks | NOT YET EVIDENCED |
+| Protected review/merge | NOT YET EVIDENCED in this source branch |
+| Stable release publication | NOT YET EVIDENCED |
+| Installed artifact | NOT YET EVIDENCED |
+| Live selected-root preview | NOT PERFORMED by this source-delivery record |
+| Production reset | NOT AUTHORIZED / NOT PERFORMED |
+| Mission 3 | NOT STARTED |
+
+The intended stable patch release is `2.7.22` under
+`forge-bootstrap-release-cadence-v2`: protected exact-head review/merge, one
+clean wheel/sdist build, full qualification bound to their SHA-256 values,
+draft GitHub release, PyPI publication, registry digest readback, installed-wheel
+smoke, durable publication/cleanup receipt and completion. No branch-local test
+or wheel build is presented as published or installed evidence.

docs/roadmap/FORGE_OPERATIONS_CONSOLE_V1.md

@@ -118,6 +118,15 @@ FOC-Q must qualify all packages, including restart and interrupted data operatio
 stale snapshots, non-portable credentials, unchanged cumulative budgets,
 EP-absent/upgraded two-host layouts, refresh load and truthful timeout enforcement.
 
+### Bounded operational-reset slice
+
+`FORGE_OPERATIONAL_RESET_V1` is implemented as an owning application service
+and thin `forge server reset` CLI, with schema-owned preserve/purge rules,
+durable writer fencing, verified recovery backup and interrupted-operation
+reconciliation. It advances only the reset-specific clean-state preparation
+slice. FC-STATE, FOC-5, FOC-Q and every Console node remain PLANNED until their
+broader evidence is delivered; the reset adds no Console/API prerequisite.
+
 ## EP parity, logging, five languages and discovery/pairing
 
 The [admin-parity contract](../architecture/FORGE_CONSOLE_EP_PARITY_AND_PAIRING_V1.md)