MET-MIG-V1.9-RECON-01 - Reconcile unreleased Metrics migration directory suffixes to v1.9.0

[ja573]

MET-MIG-V1.9-RECON-01 - Reconcile unreleased Metrics migration identities to v1.9.0

Status: DRAFT - FRESH INDEPENDENT SPECIFICATION REVIEW REQUIRED / IMPLEMENTATION DEPENDENCY HOLD

Programme: Thoth Metrics - canonical ingestion, Sphinx orchestration and client cutover
Stage: release-number / migration-identity reconciliation before final Metrics integration
Parent programme issue: #766
Predecessor state: MET-WP1-01 / #836, MET-WP1-02 / #841 and MET-WP1-03 / #863 are merged to feature/metrics
Release coordination: #864 / PR #866 published Thoth v1.8.0; #867 (REL-1.8.0-DEV-RECON-01) is the separate release-forward task into develop
Task ID: MET-MIG-V1.9-RECON-01
Repository: thoth-pub/thoth
Workflow: PROGRAMME_INTEGRATION
Programme integration branch: feature/metrics
Exact specification-inspection baseline: feature/metrics @ f06230ba7bff099c0c0fb34b4747057b4a9b7a30
Observed develop at task setup: 665583371e0bbb64bf2d71836b4ce1a73e57d3a2
Published v1.8.0 / master commit: 9ae1e56714096507d2d210b5b315361d626626c9
Expected implementation base: NOT YET BOUND - DEPENDENCY HOLD
PR target after separate implementation authorization: feature/metrics
Proposed task branch after separate authorization: feature/metrics--v1.9-migration-reconcile
Risk: HIGH
Owner: CTO
Approved by: NOT YET APPROVED
Runtime effect at this gate: NONE
Production migration/deployment/activation authorization: NONE

Issue creation records a proposed bounded migration-identity reconciliation specification only. It does not authorize migration/file renames, source/document edits, branch creation, disposable-database execution, commit, push, PR creation/update, automatic staging-image publication, manual CI, provider/runtime access, staging/production migration execution, merge, release, deployment, production activation, task-branch deletion, release-forward reconciliation, feature/metrics refresh, or implementation of another Metrics slice.

1. Objective

Reconcile the release identity of the unreleased Thoth Metrics migration chain after Thoth v1.8.0 was published for the ORCID batch API hotfix.

At the exact inspection baseline, feature/metrics contains three Metrics migrations created while the workspace release baseline was 1.7.0, so their directory suffixes are v1.8.0:

thoth-api/migrations/20260826_v1.8.0/
thoth-api/migrations/20260827_v1.8.0/
thoth-api/migrations/20260828_v1.8.0/

The published Thoth release now owns version v1.8.0. Repository make migration convention increments the current minor version, so after the release-forward reconciliation brings workspace version 1.8.0 to the development line, the next migration suffix is v1.9.0.

This task therefore renames the three unreleased Metrics migration identities to:

thoth-api/migrations/20260826_v1.9.0/
thoth-api/migrations/20260827_v1.9.0/
thoth-api/migrations/20260828_v1.9.0/

while preserving every up.sql and down.sql byte-for-byte and updating only current, semantically linked forward-looking repository references that would otherwise describe the next Metrics migration chain incorrectly.

This is release-number coordination only. It changes no Metrics schema semantics, runtime behavior, GraphQL/API contract, authorization, source mapping, data, dependency or deployment state.

2. Authority and dependency ordering

Controlling durable programme records:

1. Thoth Metrics: canonical ingestion, Sphinx orchestration and client cutover #766 comment 5460760037 established that Thoth v1.8.0 is reserved for the hotfix release line and requires Metrics migration/release references to reconcile to v1.9.0 before final integration/release.
2. Thoth Metrics: canonical ingestion, Sphinx orchestration and client cutover #766 comment 5461128004, after actual v1.8.0 publication and MET-WP1-03 merge, expands the inventory to the three paths above and requires a separate feature/metrics refresh from develop after REL-1.8.0-DEV-RECON-01: Reconcile v1.8.0 release into develop #867.
3. REL-1.8.0-PREP-01: Prepare Thoth v1.8.0 release #864 / PR REL-1.8.0-PREP-01: Prepare Thoth v1.8.0 release #866 define the v1.8.0 release and explicitly exclude Metrics source mutation from release preparation.
4. Live released source at 9ae1e56714096507d2d210b5b315361d626626c9 has workspace version 1.8.0; live Makefile migration generation increments the minor version, making v1.9.0 the next migration suffix.
5. The three Metrics migrations are absent from published v1.8.0; they remain unreleased programme-branch history.

2.1 Required ordering before implementation authorization

This specification may be reviewed now, but implementation is intentionally on HOLD until both conditions are satisfied:

1. REL-1.8.0-DEV-RECON-01: Reconcile v1.8.0 release into develop #867 has completed the separately controlled v1.8.0 -> develop release-forward reconciliation; and
2. a separately authorized/reviewed Metrics integration refresh has merged that updated develop state into feature/metrics.

Only then may this task bind an exact implementation base and proceed to separate CTO implementation authorization.

Rationale: doing the suffix reconciliation before the release-forward and Metrics refresh would knowingly edit a branch that is about to ingest the release-version/changelog state that motivates the rename, increasing conflict/rework risk. The refreshed base should naturally carry workspace version 1.8.0, making the v1.9.0 migration convention locally reproducible.

If the post-refresh feature/metrics delta materially changes the migration inventory, current migration references, release semantics or write budget below, return HOLD - SPECIFICATION/WRITE-BUDGET REBINDING REQUIRED and amend/re-review this specification rather than silently expanding scope.

3. Risk classification

HIGH.

The intended content change is mechanically narrow and contains no SQL/schema semantic change, but migration directory names are durable migration identities used by Diesel's migration ledger and later deployment history. A mistaken rename, partial rename, changed SQL blob or rename after a persistent environment has applied the old identity could create duplicate/replayed migration behavior or an irreconcilable migration ledger.

HIGH-risk controls therefore apply:

• written specification and fresh independent review before implementation;
• dependency HOLD until the release-forward and Metrics refresh are complete;
• exact SHA-bound implementation authorization;
• byte-identity proof for all six SQL files;
• full migration-chain apply/revert/reapply validation on disposable PostgreSQL;
• fresh independent exact-head source review;
• exact-SHA CTO merge authorization;
• no persistent-environment migration execution or history manipulation.

4. Explicit scope

4.1 Rename exactly the current three Metrics migration directories

At the specification baseline, the intended path-only moves are:

20260826_v1.8.0 -> 20260826_v1.9.0
20260827_v1.8.0 -> 20260827_v1.9.0
20260828_v1.8.0 -> 20260828_v1.9.0

for both up.sql and down.sql within each directory.

Requirements:

• preserve the date prefix exactly;
• preserve all six SQL file contents byte-for-byte;
• preserve file mode;
• do not edit SQL comments, whitespace or formatting merely to make the rename visible;
• old paths must be absent after the rename;
• new paths must contain the exact original blobs;
• no additional migration is created.

Immediately before implementation authorization, freshly inventory feature/metrics for Metrics-owned next-release migration directories still carrying _v1.8.0. If more than these three exist, HOLD - MIGRATION INVENTORY / WRITE-BUDGET AMENDMENT REQUIRED rather than silently renaming additional paths.

4.2 Update current forward-looking migration-path references only

The exact specification baseline contains current path references in:

• CHANGELOG.md for MET-WP1-01, MET-WP1-02, MET-WP1-03;
• thoth-api/src/model/metric_platform/tests.rs doc comment for the MET-WP1-01 migration;
• thoth-api/src/model/metric_source/tests.rs doc comment for the MET-WP1-02 migration;
• thoth-api/src/model/metric_import/tests.rs doc comment for the MET-WP1-03 migration.

Update those current references from v1.8.0 to v1.9.0 where still present on the freshly rebound implementation base.

The executable Diesel migration-version constants remain the date IDs (20260826, 20260827, 20260828) and must not be changed merely because the directory suffix changes.

CHANGELOG.md may add one bounded Unreleased entry for this task if required by repository changelog policy, but it must not duplicate or reinterpret the three WP1 schema descriptions. The existing WP1 entries should describe their current unreleased migration paths truthfully after the rename.

4.3 Durable implementation report

Add:

docs/engineering/ai-delivery/implementation-reports/MET-MIG-V1.9-RECON-01-implementation-report.md

The report must record exact base/head, path moves, before/after SQL blob hashes, reference changes, migration-chain validation, test results, CI/PR state, external effects, limitations and remaining gates. It is evidence only and is not self-approval.

4.4 Historical provenance is immutable

Do not rewrite historical point-in-time evidence to pretend the migrations were originally created under v1.9.0.

Specifically out of scope for path-string cleanup solely for this task:

• existing MET-WP1-01/02/03 implementation reports;
• MET-WP1-01 - Establish Metrics registry schema and Rust domain foundation #836, MET-WP1-02 - Establish Metrics source, source-account and checkpoint foundation #841, MET-WP1-03 - Establish Metrics import and import-error state foundation #863 issue bodies/comments;
• PR MET-WP1-01: establish Metrics registry schema and Rust domain foundation #839/MET-WP1-02: establish the Metrics source-state foundation (#841) #843/MET-WP1-03: establish Metrics import and import-error state foundation #865 bodies/reviews/comments;
• prior exact-head review/authorization/merge evidence;
• Thoth Metrics: canonical ingestion, Sphinx orchestration and client cutover #766/REL-1.8.0-PREP-01: Prepare Thoth v1.8.0 release #864 release-coordination comments that truthfully describe the prior v1.8.0 state.

Those records remain valid historical provenance. New task/report/merge records must explain the later rename instead of rewriting history.

5. Candidate implementation write budget

This is the maximum expected write envelope for later authorization; it is not active authorization.

Current files whose contents may change:

CHANGELOG.md
thoth-api/src/model/metric_platform/tests.rs
thoth-api/src/model/metric_source/tests.rs
thoth-api/src/model/metric_import/tests.rs

Path-only moves; SQL bytes must remain identical:

thoth-api/migrations/20260826_v1.8.0/up.sql
thoth-api/migrations/20260826_v1.8.0/down.sql
thoth-api/migrations/20260827_v1.8.0/up.sql
thoth-api/migrations/20260827_v1.8.0/down.sql
thoth-api/migrations/20260828_v1.8.0/up.sql
thoth-api/migrations/20260828_v1.8.0/down.sql

into:

thoth-api/migrations/20260826_v1.9.0/up.sql
thoth-api/migrations/20260826_v1.9.0/down.sql
thoth-api/migrations/20260827_v1.9.0/up.sql
thoth-api/migrations/20260827_v1.9.0/down.sql
thoth-api/migrations/20260828_v1.9.0/up.sql
thoth-api/migrations/20260828_v1.9.0/down.sql

New evidence file:

docs/engineering/ai-delivery/implementation-reports/MET-MIG-V1.9-RECON-01-implementation-report.md

No schema.rs, Rust model implementation, Cargo manifest/lockfile, GraphQL, workflow, provider/configuration, downstream repository or other Metrics document is in the candidate budget.

If the refreshed implementation base contains another current semantically linked reference whose correction is required for repository truthfulness or tests, return HOLD - WRITE BUDGET AMENDMENT REQUIRED with the exact path and occurrence before editing it.

6. Explicit non-goals / invariants

This task must not:

1. modify any migration SQL content or schema semantics;
2. create a fourth migration or collapse/reorder the three migrations;
3. change migration date prefixes or Diesel migration-version constants;
4. modify thoth-api/src/schema.rs or any persistence/domain model;
5. change Cargo/package versions, dependency pins or Cargo.lock - those belong to the release-forward history;
6. implement or modify GraphQL/API behavior;
7. change auth/security, entitlements, machine roles or source/platform mappings;
8. seed, backfill or mutate canonical data;
9. rewrite historical implementation/review/authorization/merge evidence;
10. run migrations against staging, production or another persistent shared database;
11. edit Diesel migration ledger rows to disguise an already-applied old identity;
12. perform REL-1.8.0-DEV-RECON-01: Reconcile v1.8.0 release into develop #867 or the post-REL-1.8.0-DEV-RECON-01: Reconcile v1.8.0 release into develop #867 feature/metrics refresh inside this task;
13. merge feature/metrics into develop;
14. modify thoth-app, Sphinx, dissemination or another repository;
15. deploy, tag, release, publish or activate Metrics behavior;
16. start another WP1/WP2+ slice automatically.

Invariants:

• the effective database schema produced by the full migration chain is unchanged;
• all six SQL blobs are byte-identical before and after;
• migration ordering by date prefix is unchanged;
• WP1 remains IN PROGRESS;
• the published Thoth release remains v1.8.0;
• the unreleased Metrics migration chain becomes v1.9.0-identified only after this task merges;
• implementing agent may not approve its own work.

7. Persistent-environment safety condition

The released v1.8.0 source does not contain these Metrics migrations, and no production migration was authorized by the three WP1 child tasks. That supports path renaming before release integration.

Nevertheless, if authoritative deployment/runtime evidence shows that any persistent shared staging/production database has applied one of the old directory identities (20260826, 20260827, 20260828) from this Metrics branch outside the recorded controls, return:

BLOCKED - EXISTING PERSISTENT MIGRATION HISTORY REQUIRES A SEPARATE MIGRATION-LEDGER/COMPATIBILITY PLAN

Do not rename around or manually edit persistent Diesel migration history within this task.

Disposable CI/local databases do not create this blocker.

8. Acceptance criteria

8.1 Dependency and exact-base gate

• REL-1.8.0-DEV-RECON-01: Reconcile v1.8.0 release into develop #867 is complete and its released v1.8.0 state is reachable from live develop.
• the separately controlled post-REL-1.8.0-DEV-RECON-01: Reconcile v1.8.0 release into develop #867 Metrics refresh is complete and live feature/metrics contains that updated develop state.
• a fresh exact feature/metrics implementation base SHA is recorded before authorization.
• live workspace version/migration convention on that refreshed base is consistent with v1.9.0 as the next migration suffix; otherwise HOLD.
• no additional Metrics _v1.8.0 migration has appeared; otherwise HOLD for inventory/spec amendment.
• proposed branch namespace preflight passes and feature/metrics--v1.9-migration-reconcile is absent before creation.

8.2 Path/blob identity

• exactly the three approved migration directories move from _v1.8.0 to _v1.9.0.
• old six SQL paths are absent.
• new six SQL paths are present.
• each new up.sql/down.sql blob/hash is byte-identical to its old counterpart.
• no SQL content diff exists.
• date ordering remains 20260826, 20260827, 20260828.
• no new migration is added.

8.3 Reference integrity

• current CHANGELOG.md WP1 migration paths identify v1.9.0.
• the three current test doc comments identify their renamed v1.9.0 paths.
• executable migration-version constants remain 20260826, 20260827, 20260828.
• no current forward-looking repository reference incorrectly claims these next-release Metrics paths are v1.8.0.
• historical reports/issues/PR/review evidence remains unchanged.

8.4 Migration/schema equivalence

Using disposable PostgreSQL only under later explicit implementation authorization:

• full migration chain applies cleanly from empty database;
• targeted revert/reapply behavior for MET-WP1-01/02/03 remains correct;
• representative populated current-schema migration validation remains clean;
• final schema/seed/data result is equivalent to the pre-rename migration chain;
• no production/staging/shared-persistent migration is executed.

8.5 Repository validation

At minimum:

cargo test -p thoth-api --features backend
cargo test --workspace
cargo check --workspace
cargo clippy --all --all-targets --all-features -- -D warnings
cargo fmt --all -- --check
git diff --check

Also record a path-level diff proving the SQL changes are renames only with identical contents.

8.6 API/compatibility

• public GraphQL/export behavior is unchanged.
• no generated client change is required.
• no downstream repository change is required.
• no auth/security/runtime behavior changes.

9. Automatic PR side effects

A later PR containing .rs reference updates and migration path moves is expected under current workflows to trigger normal PR build/test/lint/format, migration validation, changelog validation and staging container/image publication.

The staging image publication is an automatic external registry write. PR creation and that external side effect require a separate explicit authorization after fresh workflow/classifier verification at the exact task head. Manual CI dispatch/rerun/cancel remains separately unauthorized unless explicitly granted.

10. Rollout and rollback

Repository rollout only:

1. after dependencies complete, bind exact refreshed feature/metrics base;
2. separately authorize bounded implementation;
3. rename paths/update current references/validate;
4. obtain fresh independent exact-head source review;
5. separately authorize and merge only into feature/metrics;
6. retain the v1.9 reconciliation as a prerequisite for later final feature/metrics -> develop integration/release.

Before these migrations are ever applied to a persistent environment, source rollback is a separately authorized revert of this bounded reconciliation.

After any v1.9.0 identity has been applied to a persistent environment, do not revert migration directory identities in isolation; use a separately reviewed migration-history/forward-repair plan.

No production rollback is authorized here.

11. HOLD / BLOCKED / STOP

HOLD

HOLD if:

• REL-1.8.0-DEV-RECON-01: Reconcile v1.8.0 release into develop #867 is not complete;
• the required post-REL-1.8.0-DEV-RECON-01: Reconcile v1.8.0 release into develop #867 Metrics refresh is not complete;
• feature/metrics moves after exact implementation authorization;
• the refreshed branch changes the three migration contents or introduces additional _v1.8.0 Metrics migrations;
• a required current reference lies outside the candidate write budget;
• the expected branch already exists or namespace preflight fails;
• workspace/migration convention after refresh does not support v1.9.0;
• migration/workflow behavior changed materially;
• implementation would require SQL/schema/Cargo/dependency changes.

BLOCKED

BLOCKED if:

• authoritative evidence shows an old Metrics migration identity has been applied to a persistent shared environment and safe rename semantics are no longer established;
• release authority disagrees on whether v1.8.0 or v1.9.0 owns the Metrics migration chain;
• path renaming cannot preserve exact SQL/schema equivalence;
• a cross-repository or production migration-history change is required.

STOP

STOP if work begins to:

• change migration SQL/schema semantics;
• change package/release versioning outside the three migration suffixes and current references;
• modify GraphQL/API/auth/runtime behavior;
• edit persistent migration ledger state;
• run staging/production migrations;
• perform release-forward/branch refresh work;
• deploy/release/activate;
• merge feature/metrics -> develop;
• widen into another programme or later Metrics slice.

12. Action-authorization matrix at issue creation

Specification/review only.

Action	Authorized now
repository/GitHub read inspection for specification review	YES
issue review/comments under later explicit control action	NO
migration/file rename or source/doc modification	NO
branch/ref creation or movement	NO
local disposable migration execution	NO
commit	NO
push	NO
PR create/update/ready	NO
automatic GHCR staging publication	NO
manual CI dispatch/rerun/cancel	NO
provider/runtime read or write	NO
staging/production migration execution	NO
persistent migration-ledger edit	NO
merge	NO
release/tag/publication	NO
deployment/activation	NO
branch deletion	NO

13. Independent review expectations

Fresh independent specification review must inspect at minimum:

1. this complete issue;
2. Thoth Metrics: canonical ingestion, Sphinx orchestration and client cutover #766 comments 5460760037 and 5461128004;
3. REL-1.8.0-PREP-01: Prepare Thoth v1.8.0 release #864 / PR REL-1.8.0-PREP-01: Prepare Thoth v1.8.0 release #866 and live published v1.8.0 identity;
4. REL-1.8.0-DEV-RECON-01: Reconcile v1.8.0 release into develop #867 current state and the dependency ordering defined here;
5. exact live feature/metrics, develop and released v1.8.0 refs;
6. the three migration directories and all six SQL blobs;
7. current CHANGELOG.md and the three test doc comments named in section 4.2;
8. historical WP1 reports/reviews to confirm they are provenance that must not be rewritten;
9. Diesel migration identity semantics and the safety of renaming only because these migrations are unreleased/unapplied to persistent production state;
10. exact candidate write budget, validation, PR side effects and HOLD/BLOCKED/STOP conditions.

Decision must be one of:

APPROVED
CHANGES REQUIRED
BLOCKED
HOLD

Specification approval does not remove the implementation dependency HOLD and does not authorize implementation, PR creation, GHCR publication, merge, migration execution, release, deployment or activation.

14. Current gate

MET-MIG-V1.9-RECON-01
SPECIFICATION DRAFT
INSPECTION BASELINE: feature/metrics @ f06230ba7bff099c0c0fb34b4747057b4a9b7a30
RELEASE AUTHORITY: v1.8.0 @ 9ae1e56714096507d2d210b5b315361d626626c9
OBSERVED DEVELOP: 665583371e0bbb64bf2d71836b4ce1a73e57d3a2
RISK: HIGH
IMPLEMENTATION: HOLD - #867 + SEPARATE POST-RELEASE FEATURE/METRICS REFRESH REQUIRED
NEXT: FRESH INDEPENDENT SPECIFICATION REVIEW

After independent specification approval, CTO specification approval remains separate. Implementation authorization must wait until the dependency chain is complete and must bind the exact then-current refreshed feature/metrics SHA.

Refs #766
Refs #836
Refs #841
Refs #863
Refs #864
Refs #867

[ja573]

MET-MIG-V1.9-RECON-01 specification-remediation recording claim - ACTIVE

Date: 2026-08-29
Task: MET-MIG-V1.9-RECON-01
Issue: #868
Repository: thoth-pub/thoth
Executing agent: Thoth Metrics control plane

Exact review baseline

• feature/metrics @ f06230ba7bff099c0c0fb34b4747057b4a9b7a30
• develop @ 665583371e0bbb64bf2d71836b4ce1a73e57d3a2
• published v1.8.0 @ 9ae1e56714096507d2d210b5b315361d626626c9
• REL-1.8.0-DEV-RECON-01: Reconcile v1.8.0 release into develop #867 remains OPEN
• MET-MIG-V1.9-RECON-01 - Reconcile unreleased Metrics migration directory suffixes to v1.9.0 #868 had zero comments immediately before this claim

Authorized mutation scope

The CTO's current proceed authorizes only the control-plane mutations required to:

1. durably record the received fresh independent specification review decision CHANGES REQUIRED;
2. record a controlling specification amendment addressing the accepted F1-F5 review findings;
3. correct the issue title terminology if required by that amendment; and
4. release this claim.

No source, migration, branch, commit, push, PR, CI, provider/runtime, database, deployment, release, merge, activation or implementation authorization is included.

Current implementation dependency

Implementation remains HOLD pending both:

1. completion of REL-1.8.0-DEV-RECON-01: Reconcile v1.8.0 release into develop #867; and
2. a separately controlled post-release develop -> feature/metrics refresh.

This claim is for durable specification-review/remediation recording only.

[ja573]

MET-MIG-V1.9-RECON-01 independent specification review - CHANGES REQUIRED

Date: 2026-08-29
Task: MET-MIG-V1.9-RECON-01
Issue: #868
Review type: fresh independent cross-model specification review
Decision: CHANGES REQUIRED

Review bindings

• reviewed specification: MET-MIG-V1.9-RECON-01 - Reconcile unreleased Metrics migration directory suffixes to v1.9.0 #868 body as it existed at feature/metrics @ f06230ba7bff099c0c0fb34b4747057b4a9b7a30
• observed develop @ 665583371e0bbb64bf2d71836b4ce1a73e57d3a2
• published v1.8.0 @ 9ae1e56714096507d2d210b5b315361d626626c9
• REL-1.8.0-DEV-RECON-01: Reconcile v1.8.0 release into develop #867: OPEN during review; release-forward implementation branch observed in flight
• resolved dependency reviewed: diesel_migrations 2.3.2 / migrations_internals 2.3.0

Blocking findings accepted by the control plane

F1 - HIGH - Diesel migration identity premise is incorrect.

For the resolved Diesel 2.3.x implementation, migration version is derived from the path segment before the first underscore. Thus 20260826_v1.8.0 has ledger version 20260826; the _v1.8.0 suffix is the migration/display name, not the durable version stored in __diesel_schema_migrations. A suffix-only rename preserving 20260826 and SQL bytes is ledger-neutral and does not make an already-applied migration pending/replayable. The issue's section 3 rationale must be corrected.

F2 - HIGH - persistent-environment blocker/rollback mechanism is misframed.

Existing application of migration versions 20260826, 20260827 or 20260828 does not itself require a migration-ledger compatibility/repair plan solely because the display-name suffix changes. Unexpected application of these unreleased Metrics migrations to a persistent shared environment would instead be an unauthorized migration-execution control breach requiring HOLD/investigation and proof that applied SQL matches the current blobs. Section 7 and the related rollback wording must be corrected. Direct migration-ledger editing remains prohibited.

F3 - MEDIUM - HIGH risk classification is not supported by the actual task mechanics.

Repository doctrine classifies HIGH for effects such as migration execution on populated tables, auth, concurrency/idempotency semantics, backfill, canonical-data changes, production activation, cross-repo contracts and similar effects. This task changes no SQL, schema, runtime, data, auth, API or migration version prefix. The specification should be reclassified MEDIUM while retaining the existing strong verification controls, unless a separate accurate HIGH-risk failure mode is identified.

Non-blocking corrections adopted

F4 - LOW: add an explicit disposable-database ledger-neutrality proof: apply the pre-rename chain, switch to the post-rename source, and verify Diesel reports no pending/replayed 20260826/27/28 migration solely because of the suffix rename.

F5 - LOW: replace misleading migration identity/identities wording with precise migration directory release suffix/name terminology except when referring specifically to the Diesel version prefixes 20260826, 20260827, 20260828.

Scope findings that remain valid

The reviewer independently found the following parts of the draft specification sound:

• exactly three current Metrics _v1.8.0 migration directories at the reviewed baseline;
• the candidate write budget is complete/minimal for the current baseline;
• the historical-provenance boundary is correct;
• v1.8.0 is genuinely published and these three Metrics migrations are absent from that release;
• REL-1.8.0-DEV-RECON-01: Reconcile v1.8.0 release into develop #867 followed by a separately controlled develop -> feature/metrics refresh remains the correct prerequisite ordering;
• implementation must remain HOLD regardless of specification review disposition.

Required gate

MET-MIG-V1.9-RECON-01 SPECIFICATION CHANGES REQUIRED - IMPLEMENTATION HOLD

This review authorizes no source mutation, branch creation, commit, push, PR, CI, migration execution, merge, release, deployment or activation.

[ja573]

MET-MIG-V1.9-RECON-01 controlling specification amendment after independent review

Date: 2026-08-29
Task: MET-MIG-V1.9-RECON-01
Issue: #868
Review record: comment 5461403186 - CHANGES REQUIRED

This comment is a controlling amendment to the #868 issue body. Where this amendment conflicts with the original body, this amendment controls. Unchanged sections of the original body remain part of the specification.

No implementation is authorized by this amendment.

A1 - terminology and exact Diesel semantics

Replace the specification's use of migration identity/identities where it refers to the complete directory name with migration directory release suffix/name.

For the repository's resolved Diesel migration stack:

• diesel_migrations = 2.3.2;
• migrations_internals = 2.3.0;
• Diesel derives the migration version from the text before the first underscore;
• therefore:
  • 20260826_v1.8.0 has version 20260826;
  • 20260827_v1.8.0 has version 20260827;
  • 20260828_v1.8.0 has version 20260828;
• __diesel_schema_migrations records those date-prefix versions, not the complete directory string;
• the _v1.8.0 / _v1.9.0 portion is the directory migration/display name and is not the ledger version.

Accordingly, the bounded reconciliation remains exactly:

20260826_v1.8.0 -> 20260826_v1.9.0
20260827_v1.8.0 -> 20260827_v1.9.0
20260828_v1.8.0 -> 20260828_v1.9.0

with date prefixes unchanged and all six SQL blobs byte-identical.

A suffix-only rename satisfying those conditions is Diesel-ledger-neutral: it must not cause an already-applied 20260826, 20260827 or 20260828 migration to appear pending or replay solely because the display-name suffix changed.

A2 - risk classification

The task risk is amended from HIGH to MEDIUM.

Reason: this task performs no SQL/schema semantic change, migration execution on populated/persistent databases, data/backfill, auth/security, concurrency/idempotency behavior, GraphQL/API contract change, canonical-data change, provider write, production activation or cross-repository contract change. It is a bounded release-number/directory-name reconciliation on an unreleased programme branch.

The following controls remain required despite the MEDIUM classification because they directly protect the migration-path invariants:

• complete written specification;
• dependency HOLD and exact implementation-base rebinding;
• exact path inventory before implementation;
• exact preservation of all three date-prefix versions;
• byte-identity proof for all six SQL files;
• disposable PostgreSQL migration-chain verification;
• standard full repository validation and PR CI;
• fresh independent exact-head source review before merge;
• explicit CTO merge authorization bound to the reviewed head.

References in the original body stating Risk: HIGH, HIGH-risk controls or relying on suffix-as-ledger-identity reasoning are superseded by this amendment.

A3 - real failure modes

The migration safety rationale is replaced with these actual failure modes:

1. Date-prefix corruption. If a rename changes 20260826, 20260827 or 20260828, Diesel would see a different migration version; that could create replay/pending behavior and is prohibited.
2. SQL-byte drift. If any up.sql or down.sql changes while being moved, this stops being a path-only release-suffix reconciliation and could alter effective schema/rollback behavior; any byte difference is a STOP condition.
3. Partial path/reference reconciliation. Leaving an old directory or a current forward-looking repository reference would make repository/release state inconsistent and fails acceptance.

The task is not justified by a claim that changing _v1.8.0 to _v1.9.0 itself creates a new Diesel migration ledger identity.

A4 - persistent-environment safety condition

Original section 7 is superseded by the following:

A suffix-only rename with unchanged date prefix and SQL bytes is ledger-neutral even if Diesel has already recorded version 20260826, 20260827 or 20260828.

However, the three Metrics migrations are unreleased programme-branch work and no WP1 child task authorized their execution against a persistent shared staging/production database. Therefore, if authoritative runtime/deployment evidence shows that a persistent shared environment has nevertheless applied one of these migrations, return:

HOLD - UNAUTHORIZED PERSISTENT METRICS MIGRATION EXECUTION REQUIRES CONTROL RECONCILIATION

Before proceeding, establish:

• which environment applied which date-prefix migration version;
• when and by what deployment/action it was applied;
• that the applied SQL corresponds byte-for-byte to the current pre-rename migration blobs;
• whether the execution created any unrecorded operational/data effect.

This HOLD concerns an unauthorized execution/control breach; it is not a requirement for a migration-ledger repair merely because the directory suffix changes.

Direct editing of __diesel_schema_migrations remains prohibited.

Disposable local/CI databases do not trigger this HOLD.

A5 - rollback correction

Replace the original post-persistent-application rollback wording with:

• before merge of this reconciliation, rollback is simply abandonment/revert of this bounded source change under normal authorization;
• after merge, reverting the _v1.9.0 directory suffix back to _v1.8.0 while preserving date prefixes and SQL bytes remains ledger-neutral, but should not be done casually because it would reverse the repository/release-number coordination decision;
• never change an already-established date-prefix migration version or SQL content as a substitute for a forward migration/repair once persistent environments depend on that schema;
• never edit migration-ledger rows manually within this task.

No production rollback or migration execution is authorized here.

A6 - additional acceptance / validation

Add the following required acceptance evidence:

1. Prove all three Diesel migration versions remain exactly:

20260826
20260827
20260828

before and after the rename.

2. On a disposable PostgreSQL database, prove suffix-only ledger neutrality:

   • apply the full migration chain from the pre-rename source;
   • use the post-rename source with identical SQL and unchanged date prefixes;
   • query/run the repository migration harness and prove these three migrations are not pending or replayed solely because their directory suffixes changed.

3. Retain the existing required evidence:

   • exact path moves;
   • all six old paths absent and all six new paths present;
   • before/after SQL blobs/hashes byte-identical;
   • no SQL content diff;
   • date ordering unchanged;
   • no new migration;
   • current Changelog/test doc references updated;
   • historical point-in-time evidence unchanged;
   • full migration-chain apply/revert/reapply on disposable PostgreSQL;
   • full repository validation and git diff --check.

A7 - unchanged scope/write budget/dependencies

The independent review found the existing candidate write budget and historical-provenance boundary complete/minimal at the inspection baseline. They are unchanged by this amendment.

Implementation remains intentionally HOLD until both prerequisites are complete:

1. REL-1.8.0-DEV-RECON-01: Reconcile v1.8.0 release into develop #867 (REL-1.8.0-DEV-RECON-01) is complete and released v1.8.0 history is authoritative on develop; and
2. a separately controlled and reviewed develop -> feature/metrics refresh has completed.

After those prerequisites, #868 must freshly inventory the refreshed feature/metrics branch and bind an exact implementation-base SHA. If migration inventory, current references or required write budget materially differ from the current specification, return HOLD - SPECIFICATION/WRITE-BUDGET REBINDING REQUIRED and amend/re-review before implementation.

Current specification gate

The complete amended specification is:

original #868 issue body + this controlling amendment, with this amendment controlling conflicts.

Current gate:

MET-MIG-V1.9-RECON-01 SPECIFICATION AMENDED AFTER CHANGES REQUIRED - FRESH INDEPENDENT SPECIFICATION RE-REVIEW REQUIRED / IMPLEMENTATION HOLD PENDING #867 + SEPARATE POST-RELEASE feature/metrics REFRESH

This comment authorizes no branch creation, source/migration edit, commit, push, PR, CI, provider/runtime access, persistent migration, merge, release, deployment or activation.

[ja573]

MET-MIG-V1.9-RECON-01 specification-remediation recording claim - RELEASED COMPLETE

Date: 2026-08-29
Task: MET-MIG-V1.9-RECON-01
Issue: #868
Claim: 5461402296

Completed bounded mutations

• independent specification review durably recorded as CHANGES REQUIRED in comment 5461403186;
• controlling specification amendment recorded in comment 5461405206;
• task terminology corrected in the issue title to Reconcile unreleased Metrics migration directory suffixes to v1.9.0;
• risk in the amended specification is now MEDIUM;
• Diesel ledger/version semantics, persistent-environment handling, rollback wording and validation requirements are corrected by the controlling amendment;
• F4 ledger-neutrality verification and F5 terminology corrections are adopted.

Fresh post-mutation ref verification

• feature/metrics remains exactly f06230ba7bff099c0c0fb34b4747057b4a9b7a30;
• develop remains exactly 665583371e0bbb64bf2d71836b4ce1a73e57d3a2.

No source, migration, branch/ref, commit, push, PR, CI, provider/runtime, database, deployment, release, merge or activation mutation was performed.

Current gate

MET-MIG-V1.9-RECON-01 SPECIFICATION AMENDED AFTER CHANGES REQUIRED - FRESH INDEPENDENT SPECIFICATION RE-REVIEW REQUIRED / IMPLEMENTATION HOLD PENDING #867 + SEPARATE POST-RELEASE feature/metrics REFRESH

This release authorizes no implementation.

[ja573]

MET-MIG-V1.9-RECON-01 independent specification re-review recording claim - ACTIVE

Date: 2026-08-29
Task: MET-MIG-V1.9-RECON-01
Issue: #868
Repository: thoth-pub/thoth
Executing agent: Thoth Metrics control plane

Fresh control-plane preflight

• effective specification: original MET-MIG-V1.9-RECON-01 - Reconcile unreleased Metrics migration directory suffixes to v1.9.0 #868 body + controlling amendment 5461405206, with the amendment controlling conflicts;
• prior review: 5461403186 - CHANGES REQUIRED;
• prior remediation-recording claim 5461402296 is released COMPLETE by 5461407643;
• feature/metrics @ f06230ba7bff099c0c0fb34b4747057b4a9b7a30;
• develop @ 4546cb632428872b961ad6c17282984d298e3ade;
• REL-1.8.0-DEV-RECON-01: Reconcile v1.8.0 release into develop #867 is now CLOSED / completed;
• live develop...feature/metrics comparison is still diverged, so the separately controlled post-release develop -> feature/metrics refresh has not completed.

Authorized mutation scope

The CTO's current proceed authorizes only the control-plane mutations required to:

1. durably record the received fresh independent specification re-review decision APPROVED against the effective amended specification;
2. record the current dependency/gate state, including that REL-1.8.0-DEV-RECON-01: Reconcile v1.8.0 release into develop #867 is now satisfied but the separately controlled develop -> feature/metrics refresh remains outstanding; and
3. release this recording claim.

No issue-body/source/migration edit, branch/ref mutation, refresh, implementation-base binding, implementation authorization, commit, push, PR, CI, provider/runtime access, database migration, merge, release, deployment or activation is included.

This claim is for durable specification re-review recording only.

[ja573]

MET-MIG-V1.9-RECON-01 independent specification re-review - APPROVED

Date: 2026-08-29
Task: MET-MIG-V1.9-RECON-01
Issue: #868
Review type: fresh independent cross-model specification re-review after remediation
Decision: APPROVED
Risk: MEDIUM under controlling amendment 5461405206

Review bindings

The reviewed effective specification is:

original #868 issue body + controlling amendment 5461405206, with the amendment controlling every conflict.

Review lineage:

• first independent specification review 5461403186: CHANGES REQUIRED;
• controlling amendment 5461405206: addresses F1-F5 and supersedes the incorrect Diesel-identity/risk/persistent-environment premises;
• specification-remediation recording claim released COMPLETE by 5461407643;
• reviewed Metrics specification/source inspection baseline: feature/metrics @ f06230ba7bff099c0c0fb34b4747057b4a9b7a30.

Re-review disposition

The fresh independent re-review finds the amended specification complete and internally coherent for the bounded release-suffix reconciliation. The prior blocking findings are satisfied:

1. F1 remediated: Diesel ledger version is correctly defined as the date prefix before the first underscore (20260826, 20260827, 20260828); _v1.8.0 / _v1.9.0 is treated as the migration directory display/release suffix. A suffix-only rename preserving date prefixes and SQL bytes is therefore ledger-neutral.
2. F2 remediated: unexpected persistent execution of these unreleased Metrics migrations is correctly treated as an unauthorized execution/control breach requiring HOLD and reconciliation, not as a ledger-repair requirement caused by the suffix rename itself. Manual ledger editing remains prohibited.
3. F3 remediated: task risk is correctly reclassified MEDIUM, while retaining the stronger migration-path verification controls.
4. F4 remediated: disposable PostgreSQL validation now explicitly requires pre-rename apply followed by post-rename source use proving 20260826/27/28 are not pending/replayed solely because the suffix changes.
5. F5 remediated: terminology now distinguishes Diesel migration versions from migration directory release suffix/name.

The re-review also confirms the existing bounded scope/write budget and historical-provenance boundary remain appropriate at the inspection baseline.

Non-blocking implementation-review observations

These do not require another specification amendment, but must be carried into later implementation evidence/review:

• where stale original-body wording conflicts with the amendment, explicitly apply the amendment as controlling rather than reproducing the superseded rationale;
• perform the ledger-neutrality proof against the same disposable PostgreSQL database across the pre-rename/post-rename source switch;
• ensure embedded-migration verification genuinely rebuilds/uses the post-rename embedded migration set rather than relying on stale build output.

Fresh dependency state after re-review

Fresh live verification at recording time shows:

• REL-1.8.0-DEV-RECON-01: Reconcile v1.8.0 release into develop #867 (REL-1.8.0-DEV-RECON-01) is now CLOSED / completed;
• develop @ 4546cb632428872b961ad6c17282984d298e3ade;
• feature/metrics @ f06230ba7bff099c0c0fb34b4747057b4a9b7a30;
• develop...feature/metrics remains diverged (ahead_by=16, behind_by=13 in the queried direction), so the required separately controlled post-release develop -> feature/metrics refresh has not completed.

Therefore prerequisite #867 is satisfied, but implementation remains HOLD on the separate Metrics integration refresh.

After that refresh, #868 must freshly inventory the refreshed branch and bind an exact implementation-base SHA. If migration inventory, current references, release semantics or required write budget materially differ, return:

HOLD - SPECIFICATION/WRITE-BUDGET REBINDING REQUIRED

Decision / current gate

APPROVED - SPECIFICATION GATE SATISFIED. IMPLEMENTATION NOT AUTHORIZED.

Current gate:

MET-MIG-V1.9-RECON-01 SPECIFICATION APPROVED - IMPLEMENTATION HOLD PENDING SEPARATELY CONTROLLED develop @ 4546cb632428872b961ad6c17282984d298e3ade -> feature/metrics REFRESH; THEN FRESH BASE/INVENTORY REBINDING + CTO SPECIFICATION/IMPLEMENTATION GATES

This review authorizes no branch creation, source/migration edit, refresh, commit, push, PR, CI, provider/runtime access, persistent migration, merge, release, deployment or activation.

[ja573]

MET-MIG-V1.9-RECON-01 independent specification re-review recording claim - RELEASED COMPLETE

Date: 2026-08-29
Task: MET-MIG-V1.9-RECON-01
Issue: #868
Claim: 5461503692

Completed bounded mutations

• fresh independent specification re-review durably recorded as APPROVED in comment 5461505656;
• effective specification remains the original MET-MIG-V1.9-RECON-01 - Reconcile unreleased Metrics migration directory suffixes to v1.9.0 #868 body + controlling amendment 5461405206, with the amendment controlling conflicts;
• no issue-body/source/migration/ref/PR/provider/runtime mutation was performed;
• REL-1.8.0-DEV-RECON-01: Reconcile v1.8.0 release into develop #867 is now CLOSED / completed and that prerequisite is satisfied;
• develop @ 4546cb632428872b961ad6c17282984d298e3ade;
• feature/metrics @ f06230ba7bff099c0c0fb34b4747057b4a9b7a30;
• live branch comparison remains diverged, so the separately controlled post-release develop -> feature/metrics refresh remains outstanding.

Current gate

MET-MIG-V1.9-RECON-01 SPECIFICATION APPROVED - IMPLEMENTATION HOLD PENDING SEPARATELY CONTROLLED develop @ 4546cb632428872b961ad6c17282984d298e3ade -> feature/metrics REFRESH; THEN FRESH BASE/INVENTORY REBINDING + CTO SPECIFICATION/IMPLEMENTATION GATES

This release authorizes no implementation, branch/ref mutation, refresh, PR, CI, provider/runtime action, migration execution, merge, release, deployment or activation.

[ja573]

MET-MIG-V1.9-RECON-01 dependency update - refresh task #870 created

Date: 2026-08-29
Task: MET-MIG-V1.9-RECON-01
Dependency task: #870 (MET-BR-REFRESH-02)

The separate post-v1.8.0 develop -> feature/metrics refresh required before this task can be rebound is now durably specified in #870.

Exact current pre-refresh state remains:

• feature/metrics @ f06230ba7bff099c0c0fb34b4747057b4a9b7a30
• develop @ 4546cb632428872b961ad6c17282984d298e3ade
• merge base 665583371e0bbb64bf2d71836b4ce1a73e57d3a2

#868's independent specification approval remains valid as specification evidence, but implementation remains HOLD. After #870 is independently approved, separately authorized, executed, validated/CI-observed and independently approved at its exact resulting head, #868 must perform a fresh migration inventory and exact-base rebinding before any implementation authorization.

This comment authorizes no refresh, source/migration edit, branch/ref mutation, commit, push, PR, CI, provider/runtime action, migration execution, merge, release, deployment or activation.

[ja573]

MET-MIG-V1.9-RECON-01 fresh base/inventory rebinding claim - ACTIVE

Date: 2026-08-31
Task: MET-MIG-V1.9-RECON-01
Issue: #868
Programme: Thoth Metrics / #766
Repository: thoth-pub/thoth
Risk: MEDIUM under controlling amendment 5461405206
Executing agent: Thoth Metrics control plane
Status: ACTIVE

Fresh prerequisite / authority preflight

• effective specification remains the original MET-MIG-V1.9-RECON-01 - Reconcile unreleased Metrics migration directory suffixes to v1.9.0 #868 body + controlling amendment 5461405206, with the amendment controlling every conflict;
• independent specification re-review 5461505656 is APPROVED;
• its recording claim 5461503692 was released COMPLETE by 5461507100;
• prerequisite REL-1.8.0-DEV-RECON-01: Reconcile v1.8.0 release into develop #867 is CLOSED / completed;
• prerequisite refresh MET-BR-REFRESH-02 - Refresh feature/metrics from post-v1.8.0 develop #870 is CLOSED / completed after exact-head independent integration approval 5474541609;
• live feature/metrics is exactly 5604a447c1744f4cd5cc715c15a43d156cc0e62b, tree 9511ead35bd4c3421f153ecae24348ab487c8f25, with ordered parents f06230ba7bff099c0c0fb34b4747057b4a9b7a30 then 4546cb632428872b961ad6c17282984d298e3ade;
• live develop remains exactly 4546cb632428872b961ad6c17282984d298e3ade;
• root workspace version on the refreshed branch is 1.8.0 and the repository make migration rule increments the current minor version, so its next generated suffix is v1.9.0;
• proposed task branch feature/metrics--v1.9-migration-reconcile is absent and no open PR exists from that head.

Authorized scope of this claim

The CTO's current proceed is bound only to the fresh #868 inventory/exact-base rebinding gate. It authorizes read-only repository/GitHub inspection and the durable #868 control comments required to bind the implementation baseline if the approved specification remains materially unchanged.

It does not authorize task-branch creation, source/migration/document edits, disposable-database execution, commit, push, PR creation/update, CI dispatch/rerun, provider/runtime access, persistent migration execution, merge, release, deployment, production activation, task-branch deletion, or another Metrics slice.

If the fresh inventory or write budget differs materially from the independently approved specification, release this claim at HOLD - SPECIFICATION/WRITE-BUDGET REBINDING REQUIRED rather than authorizing implementation.

[ja573]

MET-MIG-V1.9-RECON-01 controlling post-refresh exact-base / inventory rebind

Date: 2026-08-31
Task: MET-MIG-V1.9-RECON-01
Issue: #868
Risk: MEDIUM
Prior independent specification approval: 5461505656
Refresh dependency: #870 - CLOSED / COMPLETED

This comment is the controlling post-refresh implementation-baseline rebind required by the approved specification. It does not amend the task's substantive scope. Read it with the original #868 body and controlling amendment 5461405206; that amendment continues to control all conflicts with the original body.

No implementation is authorized by this rebind.

1. Prerequisites are now satisfied

Fresh live verification establishes:

• REL-1.8.0-DEV-RECON-01: Reconcile v1.8.0 release into develop #867 (REL-1.8.0-DEV-RECON-01) is complete;
• MET-BR-REFRESH-02 - Refresh feature/metrics from post-v1.8.0 develop #870 (MET-BR-REFRESH-02) is CLOSED / completed;
• MET-BR-REFRESH-02 - Refresh feature/metrics from post-v1.8.0 develop #870 independent exact-head integration review 5474541609 approved the resulting programme head;
• live develop = 4546cb632428872b961ad6c17282984d298e3ade;
• live feature/metrics = 5604a447c1744f4cd5cc715c15a43d156cc0e62b;
• refreshed tree = 9511ead35bd4c3421f153ecae24348ab487c8f25;
• refreshed ordered parents = f06230ba7bff099c0c0fb34b4747057b4a9b7a30, then 4546cb632428872b961ad6c17282984d298e3ade.

Therefore #868's implementation dependency HOLD on #867 + the separately controlled post-release refresh is satisfied.

2. Exact implementation base rebound

The only implementation base that may be used by a later separately authorized #868 implementation is now:

feature/metrics @ 5604a447c1744f4cd5cc715c15a43d156cc0e62b

If feature/metrics moves before branch creation/implementation, HOLD - EXACT BASE REBINDING REQUIRED. Do not silently use a later programme head.

PR target remains:

feature/metrics

Proposed bounded task branch remains:

feature/metrics--v1.9-migration-reconcile

Fresh namespace preflight: the proposed branch is absent and there is no open PR using that head. Branch creation remains unauthorized at this gate.

3. Fresh migration inventory - unchanged

The refreshed branch contains exactly three Metrics next-release migration directories carrying _v1.8.0:

1. thoth-api/migrations/20260826_v1.8.0/
2. thoth-api/migrations/20260827_v1.8.0/
3. thoth-api/migrations/20260828_v1.8.0/

No fourth Metrics _v1.8.0 migration has appeared.

Directory/tree anchors:

• 20260826_v1.8.0 tree cfd4bb31c4e3e6d203e5046a42711250a41663ef;
• 20260827_v1.8.0 tree 3ece2d0289f025fcb584fb692eb8c5e632cd3af5;
• 20260828_v1.8.0 tree 7792a5cbed508a16ae0a0c83ab48079ed3c4a1ba.

Pre-rename SQL blob anchors that later implementation must preserve byte-for-byte:

Migration	up.sql blob	down.sql blob
20260826	c8efef3c9c944c950fca546ab13459025d3f1943	2f8fa64811f0c406e0f530dc7186372b910d80c5
20260827	ca60e1cf78ea8e8c09eba5f12ec9e58ec9d37aec	8c90d7b781377c440df4042152d0a7a93a015b12
20260828	61d1dbfdffa3c8b67156eadce445f06a689c2cb7	0e7a0f6d220080f59547842c3e859056f68f9f10

The Diesel migration versions remain the date prefixes 20260826, 20260827, 20260828; those values must remain unchanged.

4. Release-suffix convention - satisfied

The refreshed root Cargo.toml is version 1.8.0 and pins the workspace crates to =1.8.0.

The live Makefile migration target derives the current major/minor from Cargo.toml, increments the minor by one and creates thoth-api/migrations/<DATE>_v<MAJOR>.<MINOR+1>.0.

Therefore the repository's current next generated migration suffix is v1.9.0, matching the independently approved task premise.

No Cargo/Makefile change belongs to #868.

5. Current forward-looking reference inventory - unchanged in substance

The current references that must move from _v1.8.0 to _v1.9.0 remain exactly the approved set:

• CHANGELOG.md - the current MET-WP1-01, MET-WP1-02, and MET-WP1-03 Unreleased entries;
• thoth-api/src/model/metric_platform/tests.rs - MET-WP1-01 migration-path doc comment;
• thoth-api/src/model/metric_source/tests.rs - MET-WP1-02 migration-path doc comment;
• thoth-api/src/model/metric_import/tests.rs - MET-WP1-03 migration-path doc comment.

The three executable constants remain correctly date-only:

• MET_WP1_01_MIGRATION_VERSION = "20260826";
• MET_WP1_02_MIGRATION_VERSION = "20260827";
• MET_WP1_03_MIGRATION_VERSION = "20260828".

#870 imported exactly 13 release-forward paths. All Metrics-only paths were independently proven byte-identical to the pre-refresh f06230ba... baseline except the intentionally shared CHANGELOG.md; none of the 12 non-CHANGELOG imported release-forward paths expands #868's migration-reference write budget. The refreshed CHANGELOG.md retains the same three current Metrics _v1.8.0 references and additionally contains the historical v1.8.0 release section, which remains immutable provenance and is not rewritten by this task.

6. Candidate implementation write budget - unchanged

Later implementation may modify only, if explicitly authorized:

Content changes:

CHANGELOG.md
thoth-api/src/model/metric_platform/tests.rs
thoth-api/src/model/metric_source/tests.rs
thoth-api/src/model/metric_import/tests.rs

Path-only moves, with the exact SQL blobs above preserved:

thoth-api/migrations/20260826_v1.8.0/{up.sql,down.sql}
  -> thoth-api/migrations/20260826_v1.9.0/{up.sql,down.sql}
thoth-api/migrations/20260827_v1.8.0/{up.sql,down.sql}
  -> thoth-api/migrations/20260827_v1.9.0/{up.sql,down.sql}
thoth-api/migrations/20260828_v1.8.0/{up.sql,down.sql}
  -> thoth-api/migrations/20260828_v1.9.0/{up.sql,down.sql}

New evidence file:

docs/engineering/ai-delivery/implementation-reports/MET-MIG-V1.9-RECON-01-implementation-report.md

No schema.rs, model implementation, Cargo manifest/lockfile, Makefile, GraphQL/API, workflow, provider/configuration, downstream repository, historical WP1 implementation report or other Metrics document is in budget.

7. Specification disposition after rebind

The post-refresh inventory does not materially differ from the specification independently approved in 5461505656:

• migration count/path set: unchanged;
• Diesel date-prefix versions: unchanged;
• SQL blobs: preserved by MET-BR-REFRESH-02 - Refresh feature/metrics from post-v1.8.0 develop #870;
• current forward-looking references: unchanged in substance;
• required write budget: unchanged;
• risk: remains MEDIUM;
• release semantics: now directly confirmed on the refreshed 1.8.0 workspace;
• runtime/provider/cross-repository effect: NONE.

Therefore the specification does not require amendment or another independent specification re-review solely because of #870. The prior independent specification approval remains valid as specification evidence; this comment supplies the required fresh exact implementation-base binding.

8. Required implementation controls remain unchanged

A later implementation must still prove, among the existing acceptance requirements:

• date prefixes remain exactly 20260826, 20260827, 20260828;
• all six post-move SQL blobs equal the pre-rename blob anchors above;
• old paths are absent and new _v1.9.0 paths are present;
• historical point-in-time evidence remains unchanged;
• the disposable PostgreSQL ledger-neutrality proof uses the same database across pre-rename apply and post-rename rebuilt embedded-migration source;
• full migration-chain apply/revert/reapply succeeds on disposable PostgreSQL;
• repository-standard validation, git diff --check, PR CI and later fresh independent exact-head source review are completed;
• no persistent shared database migration, provider write, release, deployment or activation occurs.

Current gate

MET-MIG-V1.9-RECON-01 SPECIFICATION INDEPENDENTLY APPROVED + EXACT BASE/INVENTORY REBOUND @ 5604a447c1744f4cd5cc715c15a43d156cc0e62b - AWAITING SEPARATE CTO SPECIFICATION APPROVAL AND EXACT-SHA IMPLEMENTATION AUTHORIZATION

This rebind authorizes no implementation.

[ja573]

MET-MIG-V1.9-RECON-01 fresh base/inventory rebinding claim - RELEASED COMPLETE

Date: 2026-08-31
Task: MET-MIG-V1.9-RECON-01
Issue: #868
Claim: 5475280685
Rebind record: 5475285197
Status: RELEASED - COMPLETE FOR FRESH BASE/INVENTORY REBINDING GATE

Completed within this bounded gate:

• prerequisite MET-BR-REFRESH-02 - Refresh feature/metrics from post-v1.8.0 develop #870 reverified CLOSED / completed;
• live feature/metrics rebound exactly to 5604a447c1744f4cd5cc715c15a43d156cc0e62b;
• refreshed tree/ordered parents recorded;
• live develop @ 4546cb632428872b961ad6c17282984d298e3ade reverified;
• migration inventory freshly rechecked and remains exactly the three approved _v1.8.0 Metrics directories;
• all six pre-rename SQL blob anchors recorded;
• workspace 1.8.0 + current Makefile next-minor convention reverified as v1.9.0;
• current forward-looking reference set and candidate write budget rechecked and found materially unchanged from the independently approved specification;
• proposed task branch remains absent and no open PR exists from it;
• no specification amendment/re-review is required solely because of MET-BR-REFRESH-02 - Refresh feature/metrics from post-v1.8.0 develop #870;
• controlling exact-base/inventory rebind recorded as comment 5475285197.

Fresh post-record verification confirms feature/metrics remains unchanged at exact head 5604a447c1744f4cd5cc715c15a43d156cc0e62b, tree 9511ead35bd4c3421f153ecae24348ab487c8f25, ordered parents f06230ba... then 4546cb632....

No branch creation, source/migration/document edit, disposable-database execution, commit, push, PR mutation, CI dispatch/rerun, provider/runtime/database action, migration execution, merge, release, deployment, activation or next-slice implementation occurred.

Current gate

MET-MIG-V1.9-RECON-01 SPECIFICATION INDEPENDENTLY APPROVED + EXACT BASE/INVENTORY REBOUND @ 5604a447c1744f4cd5cc715c15a43d156cc0e62b - AWAITING SEPARATE CTO SPECIFICATION APPROVAL AND EXACT-SHA IMPLEMENTATION AUTHORIZATION

This release does not authorize implementation.