[M1/Correctness] Implement dual-axis temporal storage and queries

[samovers]

Parent: #167
Depends on: #170, #173, #174, #192

Outcome

Implement the accepted ADR so every historical answer is pinned independently to domain-valid time and tenant knowledge order.

Acceptance criteria

• Allocate one monotonic tenant knowledge position to each governed write batch; every record in that batch shares the position.
• Store explicit valid-time intervals for domain facts that have temporal force, with constraints matching [M1/ADR] Specify valid-time and knowledge-time semantics #170.
• Expose repository/query APIs that require both a valid-time cut and a knowledge-position cut where history matters.
• Remove ambiguous as_of/capture-time substitution and reject naive or semantically unclassified timestamps.
• Update in-force selection, supersession/correction, freshness, qualification, materialization keys, context snapshots, and replay to use the correct axis.
• Add indexes and exclusion/uniqueness constraints needed by the approved interval semantics without treating recordedAt as total order.
• Pin both temporal cuts in every derived snapshot, review decision, and output receipt.
• Consume [M1/Security] Persist pre-tenant operational security audit safely #192's trusted-binding boundary: pre-binding failures never receive a tenant batch or position, and a durable refusal after binding enters exactly the bound tenant's governed batch.
• Add tests for future-effective, expired, late-arriving, corrected, equal-wall-clock, interval-boundary, whole-batch visibility, rollback, cross-tenant, historical replay, pre-binding no-tenant invariance, and the post-binding refusal switch.

Boundaries

Implement #170 exactly. Do not implement or invent the #192 audit lane, infer tenant attribution, reuse a tenant table for pre-binding failures, invent missing domain dates, change law/contracts, activate profiles, alter manifests/active sets, or raise capability claims.

Bounded first-delivery path — 2026-09-11

Renewed canonical Phase A approval at exact PR #11 head 4494924998183fe3fa7bc1b63b76a85893335044 is the canonical planning basis, not executable authority. The current path is a working pending-review operation claim with truthful result recovery and current authorized readback, followed by one separately specified temporal write/read child. The precursor does not satisfy this epic: the later child must bind the exact domain-time carrier and prove independent valid-time and knowledge-position cuts.

Authorization, shared transaction coordination, compatible successor command/selection and exact temporal/read bindings remain dependencies. #170/#173/#174/#192 are completed foundations, not work to reopen. Keep #180/#181/#182/#183/#185 responsibilities separate. No epic acceptance criterion, label or status is changed and no ready Delivery child is claimed by this note.

The initial authorization scope is exactly ASSERT_OPERATION_CLAIM and RECEIVE_READ_DATA, with full unchanged rules and all required dependencies. History completeness/historical-admission verification under CP2A-DEP01 remains unresolved; an inactive writer, empty lookup or permanent UNAVAILABLE is not closure. No new qualifying action, read target, writer, schema, runtime or public activation is introduced.

What is next: complete the separately governed claim/read prerequisites, then select the exact temporal Delivery boundary and tests. Do not close #176 with a record lookup or idempotency replay.

[samovers]

Contract review — production RuntimeBundle persistence admission

Contract identity: ofarm.temporal-governance-production-runtime-bundle-persistence-admission.issue176.v0.1
Reviewed base: ef2c7f13882dc57aea158bd7a19c8e62d023423b
Verdict: Changes required — two Blockers.

The central architectural correction is sound: production RuntimeBundle persistence is owned by the numbered tenant PostgreSQL migrations and ofarm.publish_runtime_bundle(...). kernel/schema.sql, kernel/store.py, and kernel/runtime_bundle_repository.py remain quarantined legacy-M1 authorities and must not be changed.

The current production state also supports the contract’s premise: the authoritative tenant migration head is V3; runtime_bundle_component_role_check excludes TEMPORAL_GOVERNANCE_ARTIFACT; and ofarm.publish_runtime_bundle(uuid,text,jsonb) independently enforces the same closed role vocabulary under the dedicated publisher grant.

Blocker 1 — the Phase A authority is not durable or pinnable

The contract says Phase A changes no files and creates no branch. That leaves no reviewed repository path or exact bytes for the mandatory conformance prerequisite to authenticate.

The accepted conformance pattern applies an exception only after proving the authorizing RFC’s exact path, byte length, and SHA-256. This persistence boundary requires a later exception for:

kernel/migrations/0004_temporal_governance_runtime_bundle_role.sql

But the conformance prerequisite must merge before that migration exists. Without a merged persistence-admission RFC pin, the exception would effectively be authorized by filename alone and could survive deletion or material amendment of the contract that justified it.

Smallest correction

Add an intended Phase A RFC path, for example:

docs/rfcs/OFARM_Temporal_Governance_Production_RuntimeBundle_Persistence_Admission_RFC_v0_1.md

Then require this sequence:

1. explicitly approve the exact contract;
2. merge a documentation-only PR containing only that RFC;
3. approve a separate conformance-posture contract that pins the merged persistence RFC’s exact path, byte length, and SHA-256;
4. merge a separate conformance implementation that permits the role to be absent from or occur only in the exact future 0004 path, continues to refuse it everywhere else, and refuses before applying the exception when the persistence RFC is missing or mismatched; and
5. only then begin persistence Phase B.

The conformance tests should independently cover missing authority, wrong length, same-length/wrong-digest authority, allowed absence, allowed exact-0004 occurrence, and refusal in every other migration and existing forbidden path.

Blocker 2 — the Phase B allowlist omits a mandatory readiness trust anchor

The allowed-file list omits:

deployment/postgresql/catalog_identity.py

That file contains TENANT_CATALOG_VERIFIER_DIGEST, the external trust anchor for the exact ofarm.verify_tenant_structure() and ofarm.observe_tenant_contract() routine pair. Migration execution and production structural readiness authenticate that pair before trusting the migration-owned verifier.

Migration 0004 must update the structural verifier to recognize:

• migration count and head version 4;
• the V4 prefix digest;
• the changed publish_runtime_bundle(...) function fingerprint; and
• the resulting complete structural catalog fingerprint.

Changing the verifier body necessarily changes the external verifier-pair digest. Leaving TENANT_CATALOG_VERIFIER_DIGEST at its V3 value would make final migration verification and startup readiness fail closed. The previous additive tenant migration, 0003_tenant_knowledge_position.sql, correspondingly updated this trust-anchor file.

Smallest correction

Add deployment/postgresql/catalog_identity.py to the Phase B allowlist, limited to the mechanically recomputed TENANT_CATALOG_VERIFIER_DIGEST.

Also update:

• TGPDA-011 to name both the migration-owned structural verifier and the external verifier-pair trust anchor;
• the proposed architecture to distinguish the publication-function fingerprint, complete migration-owned catalog fingerprint, and external verifier-pair digest;
• Section 16’s mechanical outputs;
• the traceability table; and
• verification to cover tenant structural readiness and tamper refusal.

At minimum, include the affected readiness lanes, such as:

python3 -m pytest -q kernel/tests/test_postgresql_readiness_unit.py
python3 -m pytest -q kernel/tests/test_postgresql_structural_compatibility.py -k tenant

Non-blocking clarifications

Clarify the apparent tension between “must not publish an actual temporal RuntimeBundle” and “publisher exact success”:

Phase B must not publish or select a temporal RuntimeBundle in any checked-in or production deployment. Disposable real-role PostgreSQL tests must publish one exact model-valid temporal component and its required schema through ofarm.publish_runtime_bundle(...) to prove V4 admission and atomic membership.

That test should verify exact publication, complete membership, idempotent replay, and the absence of selection, activation, lifecycle, command, route, output, or audit effects.

Also state that the migration runner—not migration SQL—owns the atomic ledger append advancing the observed migration head and prefix digest.

Boundaries that should remain unchanged

Do not add temporal identity rows, schema validation, carrier semantics, lifecycle checks, or command-closure validation to SQL. The database should admit only the role vocabulary; the merged RuntimeBundle model remains the semantic validator.

Do not modify:

• kernel/migrations/0001_initial.sql;
• kernel/schema.sql;
• kernel/store.py;
• kernel/runtime_bundle_repository.py;
• kernel/runtime_bundle.py;
• the active component catalog;
• profiles, manifests, decision logs, commands, routes, outputs, or [M1/Security] Persist pre-tenant operational security audit safely #192.

Disposition

• Active-baseline files affected: none.
• Change classification: production implementation/conformance contract under the accepted migration architecture.
• Baseline-law change: none.
• Blockers: two — no durable digest-pinnable Phase A authority; and omission of the external catalog-verifier trust-anchor file.
• Follow-ups: the already separated catalog/publication, tenant selection, authorization, command, read, output, and audit boundaries.
• Preferences: clarify disposable positive publication evidence and runner-owned ledger advancement.
• Approval status: not ready for explicit approval until both Blockers are corrected.

[samovers]

Review — amended production RuntimeBundle persistence-admission contract

Verdict: Changes required — one Blocker.

The amendment closes the prior two findings:

• it now requires a durable, documentation-only RFC before the conformance exception can be created; and
• it adds deployment/postgresql/catalog_identity.py to Phase B, limited to the mechanically recomputed TENANT_CATALOG_VERIFIER_DIGEST.

It also correctly incorporates a disposable positive-publication test and clarifies that the migration runner—not migration SQL—owns the ledger append.

Blocker — the migration state machine requires a pre-migration trust-anchor check that the allowed implementation cannot perform

The contract requires this transition:

PRODUCTION_SCHEMA_V3_ROLE_CLOSED
  -> EXACT_V3_HISTORY_STRUCTURE_AND_VERIFIER_PAIR_AUTHENTICATED
  -> ONE_ATOMIC_RUNNER_TRANSACTION
  -> PRODUCTION_SCHEMA_V4_ROLE_ADMISSIBLE_INERT

It then requires the runner to authenticate the exact V3 migration history and external verifier-pair digest before migration 0004 changes the database.

That is not the active runner protocol. For a V3 database with a local V4 set, the runner:

1. validates sources and opens the protected transaction;
2. verifies the ledger contract and exact existing-history prefix;
3. executes migration 0004;
4. proves migration SQL did not alter the ledger;
5. appends the V4 ledger row itself; and
6. only when the just-applied migration is the final local migration calls _verify_final_service_structure(...).

That final check authenticates the verifier/observer pair through verify_catalog_identity(...) and then invokes the migration-owned structural verifier. There is no external verifier-pair authentication of the V3 state before migration 0004 executes.

deployment/postgresql/catalog_identity.py also contains one current tenant digest:

TENANT_CATALOG_VERIFIER_DIGEST

Phase B proposes replacing it with the V4 digest; it does not retain distinct V3 and V4 trust anchors. The Phase B allowlist also does not permit deployment/postgresql/migration_runner.py to change.

As written, implementation would have to do one of the following:

1. edit the runner and add historical-digest selection outside the allowlist;
2. duplicate the external digest algorithm or old trust anchor in migration SQL;
3. retain multiple digests without a runner seam that selects the prior one; or
4. falsely claim V3 external authentication when only history and migration-local guards were checked.

Smallest correction

Do not expand the runner. Align the contract with the existing additive-migration protocol.

Replace the migration state with:

PRODUCTION_SCHEMA_V3_ROLE_CLOSED
  -> EXACT_V3_HISTORY_AND_PRIOR_DEFINITIONS_GUARDED
  -> ONE_ATOMIC_RUNNER_TRANSACTION
  -> EXACT_V4_VERIFIER_PAIR_AND_STRUCTURE_AUTHENTICATED
  -> PRODUCTION_SCHEMA_V4_ROLE_ADMISSIBLE_INERT

Use this ordering:

1. the runner verifies the exact V3 ledger contract, exact V3 migration-history prefix, locked provisioning boundary, and authoritative local V4 migration set;
2. migration 0004 refuses unless the expected V3 role constraint, publication-function definition, and V3 verifier source markers needed for controlled replacement are exact;
3. migration 0004 applies the role-constraint, publication-function, and migration-owned verifier changes;
4. the runner proves migration SQL did not alter the ledger;
5. the runner appends the exact V4 ledger row;
6. the runner authenticates the V4 verifier/observer pair using the new TENANT_CATALOG_VERIFIER_DIGEST;
7. the runner executes the complete V4 structural verifier; and
8. only then does the transaction commit.

This preserves the actual trust chain:

• exact immutable migration source and history before execution;
• exact migration-local guards on the prior definitions being changed;
• atomic DDL plus runner-owned ledger append; and
• independent external authentication of the complete final verifier/observer pair before commit.

A tampered unchanged observer still changes the final V4 pair digest and rolls back the transaction. A tampered constraint, publisher function, or verifier source required for the controlled update refuses inside migration 0004. No historical external-digest mechanism is needed.

If pre-migration external verifier-pair authentication is considered mandatory, the contract must instead pin the current V3 digest, permit changes to migration_runner.py, retain both prior and final digests, and define deterministic selection by exact observed migration head. That is materially larger and is not justified for this additive one-role migration.

Previous findings: closed

Durable Phase A authority

The amended sequence now correctly requires explicit approval, a documentation-only RFC PR, merge of that RFC, a separately pinned conformance contract, a separate conformance implementation for only the exact future 0004 path, and persistence implementation only after that prerequisite merges.

External readiness anchor

The Phase B boundary now includes deployment/postgresql/catalog_identity.py, limited to the recomputed tenant verifier-pair digest. TGPDA-011 and the verification plan now cover both the migration-owned structural fingerprint and the external verifier/observer trust anchor.

Positive persistence evidence

The contract now correctly distinguishes deployment from disposable conformance evidence. It requires one real-role test to publish an exact model-valid temporal component and its exact required schema, verify atomic membership and idempotent replay, and prove no selection, lifecycle, activation, command, route, output, or audit effect follows.

Non-blocking wording preferences

1. State explicitly that the exact 0004 path being missing is valid before persistence Phase B:

RFC valid; 0004 missing                      -> pass
RFC valid; 0004 exists without the role      -> pass
RFC valid; role occurs only in exact 0004     -> pass
RFC valid; role occurs in another migration  -> refuse

2. Qualify the final stop condition:

Outside the expressly permitted disposable real-role PostgreSQL test, implementation must stop if any temporal candidate byte or temporal RuntimeBundle must be published.

3. deployment/postgresql/README.md maintains an exact migration inventory, so adding 0004 should be a required update rather than conditional wording.

Disposition

• Affected active-baseline files: none.
• Change classification: production implementation/conformance contract under the accepted migration architecture.
• Baseline-law change: none.
• Previous blockers: closed.
• Remaining blockers: one—the pre-migration external verifier-pair authentication step is incompatible with the active runner and Phase B allowlist.
• Follow-ups: the separate conformance contract and implementation, then catalog/publication custody, tenant selection, authorization, command integration, and later read/output boundaries.
• Approval status: not ready for explicit approval until the migration ordering is corrected.

[samovers]

Review verdict

Changes required — one Blocker.

I reviewed the amended version whose migration state is:

PRODUCTION_SCHEMA_V3_ROLE_CLOSED
  -> EXACT_V3_HISTORY_AND_PRIOR_DEFINITIONS_GUARDED
  -> ONE_ATOMIC_RUNNER_TRANSACTION
  -> EXACT_V4_VERIFIER_PAIR_AND_STRUCTURE_AUTHENTICATED
  -> PRODUCTION_SCHEMA_V4_ROLE_ADMISSIBLE_INERT

This version closes the earlier design findings: it establishes a durable RFC authority, defines the missing-0004 conformance posture, includes the external catalog-verifier trust anchor, preserves the unchanged migration runner, requires migration-local prior-definition guards, and confines positive publication to disposable real-role tests.

Blocker — the detailed ordering still places locked V3 verification before the transaction starts

Section 9 requires:

1. validation of the authoritative local V4 migration set;
2. verification of the exact V3 ledger contract, V3 history prefix, and locked provisioning boundary;
3. starting the protected migration transaction.

That order is not executable with the unchanged production migration runner. A locked provisioning-boundary observation cannot occur before the runner starts its protected transaction and acquires the migration lock.

The active runner’s actual order is:

1. validate and preflight the local authoritative migration set;
2. observe infrastructure and connect;
3. call _begin_and_lock(...), which begins the protected transaction and takes the migration lock;
4. set the owner role;
5. inspect the locked provisioning boundary;
6. verify the ledger contract and exact existing migration-history prefix;
7. execute the next migration;
8. prove that migration SQL did not alter the ledger;
9. append the migration-ledger row;
10. authenticate and run the final structural verifier when the new migration is the local head; and
11. commit.

The contract simultaneously forbids changing deployment/postgresql/migration_runner.py. Therefore an implementation cannot satisfy the stated order without either:

• changing the runner outside the Phase B allowlist; or
• claiming that a locked verification happened before the lock and transaction existed.

The second would be a false verification claim.

Smallest correction

Replace the migration state with:

PRODUCTION_SCHEMA_V3_ROLE_CLOSED
  -> AUTHORITATIVE_LOCAL_V4_SET_VALIDATED
  -> ONE_PROTECTED_RUNNER_TRANSACTION_OPEN_AND_LOCKED
  -> EXACT_V3_LEDGER_HISTORY_AND_BOUNDARY_VERIFIED
  -> PRIOR_DEFINITIONS_GUARDED_AND_V4_DDL_APPLIED
  -> EXACT_V4_LEDGER_ROW_APPENDED
  -> EXACT_V4_VERIFIER_PAIR_AND_STRUCTURE_AUTHENTICATED
  -> PRODUCTION_SCHEMA_V4_ROLE_ADMISSIBLE_INERT

Replace the detailed ordering with:

1. the runner validates the authoritative local V4 migration set before connecting;
2. the runner observes the fixed infrastructure and opens the migrator route;
3. the runner begins the protected migration transaction, takes the migration lock, and fixes the catalog-output settings;
4. inside that locked transaction, the runner verifies:
   • the locked provisioning boundary;
   • the exact migration-ledger contract; and
   • the exact V3 migration-history prefix;
5. migration 0004 refuses unless the expected V3:
   • role constraint;
   • publication-function definition; and
   • verifier source markers needed for controlled replacement
     are exact;
6. migration 0004 applies the role-constraint, publication-function, and migration-owned verifier changes;
7. the runner proves migration SQL did not alter the ledger or widen the provisioning boundary;
8. the runner appends the exact V4 ledger row;
9. the runner authenticates the final V4 verifier and observer pair through the new TENANT_CATALOG_VERIFIER_DIGEST;
10. the runner executes the complete V4 structural verifier; and
11. only then does the runner commit.

This correction changes no authority, file allowlist, migration design, trust anchor, or implementation surface. It only makes the normative ordering match the existing runner.

Earlier findings: closed

Durable authority and conformance exception

The contract now requires the persistence decision to be explicitly approved, published as a one-file RFC, merged, and then pinned by exact path, byte length, and SHA-256 in a separate conformance contract. The conformance matrix correctly treats these states independently:

• exact RFC with missing 0004: pass;
• exact RFC with role absent from 0004: pass;
• exact RFC with role only in 0004: pass;
• role in another migration: refuse;
• missing or mismatched RFC: refuse before applying the exception.

That resolves the prior authority-provenance gap.

Final V4 external trust anchor

The Phase B allowlist now includes:

deployment/postgresql/catalog_identity.py

limited to the mechanically recomputed TENANT_CATALOG_VERIFIER_DIGEST. The contract correctly requires final V4 authentication of both:

• the migration-owned complete structural verifier; and
• the external digest of the exact verifier/observer routine pair.

That matches the repository’s two-anchor readiness architecture.

Positive publication evidence

The contract now explicitly permits one disposable real-role test to publish an exact model-valid temporal component and its exact required schema. It requires atomic membership, exact replay, and proof that no lifecycle, selection, activation, command, route, output, or audit effect follows. This is appropriately bounded conformance evidence rather than checked-in or deployed publication.

Disposition

• Affected active-baseline files: none.
• Change classification: production implementation/conformance contract under the accepted PostgreSQL migration architecture.
• Baseline-law change: none.
• Previous blockers: closed.
• Remaining blocker: one ordering contradiction—the contract verifies a locked V3 boundary before starting the transaction that provides the lock.
• Preferences: none beyond the required ordering correction.
• Approval status: not ready for explicit approval until Section 9 is reordered. No broader redesign is required.

[samovers]

Contract re-review — changes required

Contract: ofarm.temporal-governance-production-runtime-bundle-persistence-admission.issue176.v0.1

Reviewed base: ef2c7f13882dc57aea158bd7a19c8e62d023423b

Verdict: one Blocker remains.

The previous migration-ordering contradiction is closed. The amended ordering now matches the unchanged runner: authoritative-set preflight, infrastructure observation, protected transaction and migration lock, locked V3 boundary/history verification, migration-local prior-definition guards, DDL, proof that migration SQL did not alter the ledger, runner-owned V4 ledger append, final external verifier-pair authentication, complete V4 structural verification, and commit.

Blocker — migration 0004 changes a digest that the governed-command candidate requires to equal the current full migration-set head

The exact governed-command candidate and its top-level const schema pin the tenant knowledge-position prerequisite with:

migrationSetHead = sha256:ba7a193e96ca78d01edf529ed2e20bbd1810c0a3a0c13bc717969e8c5c739bf0

The active temporal conformance checker does not treat that value as the stable prefix through migration 0003. _tenant_authoritative_migration_set_head() parses the top-level TENANT_AUTHORITATIVE_MIGRATION_SET.digest, and validate_command_binding(...) requires the candidate value to equal that evolving full-set digest.

Persistence Phase B necessarily appends migration 0004 and updates TENANT_AUTHORITATIVE_MIGRATION_SET. The full digest therefore changes from the V3 value to a new V4 value. The resulting posture is:

candidate migrationSetHead = V3 digest
checker expected head      = V4 full-set digest

Consequently, conformance/temporal_contract_candidate_check.py will fail after an otherwise valid V4 migration-set update.

This conflicts with the proposed boundary because Phase B simultaneously requires:

• advancing deployment/postgresql/migration_sets.py to V4;
• leaving candidate and schema bytes unchanged;
• leaving the temporal conformance checker unchanged during persistence Phase B;
• keeping temporal conformance green; and
• making no model, lifecycle, or decision-log change.

All five cannot hold under the current checker.

Why the candidate must not be updated

Changing the candidate’s migrationSetHead to the V4 digest is not a mechanical database-release update. The command schema is an exact top-level const, the candidate has a pinned digest, and the RuntimeBundle model admits the exact governed-command bytes. Such a change would cascade into candidate/schema identities, model-admission rules, currentness evidence, and the three-subject governance decision. That crosses multiple forbidden boundaries.

Smallest controlled correction

Add a mandatory pre-Phase-B conformance correction that preserves the knowledge-storage prerequisite as the exact stable migration prefix through 0003_tenant_knowledge_position.sql.

The migration framework already defines the right mechanism: MigrationSet.prefix_digest(version) is a stable identity for the exact history through a version and remains independently verifiable after later migrations are appended.

The conformance correction should:

1. parse TENANT_AUTHORITATIVE_MIGRATION_SET;
2. locate exactly migration version 3;
3. require:
   • filename 0003_tenant_knowledge_position.sql;
   • source digest sha256:d59af77e23fe012203696023ec343038dbcab5d5ffb9689be11ba67dca22f827;
   • byte length 6565; and
   • applied prefix digest sha256:ba7a193e96ca78d01edf529ed2e20bbd1810c0a3a0c13bc717969e8c5c739bf0;
4. compare the candidate’s migrationSetHead with that exact version-3 prefix digest, not with the evolving full migration-set digest; and
5. continue to validate the complete current authoritative migration set independently.

The resulting meaning is:

candidate migrationSetHead
= exact head of the approved knowledge-storage release through migration 0003
= stable prerequisite prefix
≠ prohibition on later tenant migrations

Focused tests must prove:

• V3 as the current full head passes;
• appending an exact migration 0004 passes while the V3 prefix remains unchanged;
• editing, renaming, removing, reordering, or changing migration 0003 refuses;
• changing the V3 prefix digest refuses;
• zero or multiple matching version-3 entries refuse;
• changing the candidate’s pinned V3 value refuses; and
• substituting the later V4 full-set digest into the candidate does not silently become valid.

Required contract amendment

Add this prerequisite to Sections 4, 5, 14, 16, and 18:

Before persistence Phase B, a separately approved conformance amendment must preserve the governed-command candidate’s knowledge-storage prerequisite as the exact stable migration-set prefix through 0003_tenant_knowledge_position.sql. The checker must not compare that prerequisite with the evolving full tenant migration-set digest.

The already planned conformance contract may own both the exact-0004 role exception and this prefix-stability correction, but both changes must be explicit and independently tested.

Non-blocking terminology preference

Rename:

TGPDA-001 — One new database role

to:

TGPDA-001 — One new persisted RuntimeBundle component-role value

In PostgreSQL, “database role” normally denotes a principal such as ofarm_app or ofarm_runtime_bundle_publisher, while this contract explicitly forbids PostgreSQL role changes.

Disposition

• Previous ordering blocker: closed.
• Remaining blockers: one — the immutable command candidate is currently bound to the evolving full migration-set digest.
• Required persistence Phase B change: none beyond the current plan once the prefix-stability conformance correction has merged.
• Approval status: not ready for explicit approval until the stable V3 prerequisite-prefix rule is added to the required sequence.