Repository navigation
Conversation
The BE-04 test the_migration_directory_sorts_after_every_existing_one asserted via names.last() that the BE-04 migration remains the newest migration forever - a point-in-time condition no repository with later migrations can satisfy, and one the first post-BE-04 migration (the approved MET-WP1-01 20260826_v1.8.0 registry migration) necessarily falsifies. Rename the test to the_migration_directory_keeps_its_exact_historical_name and keep only the durable invariant: the BE-04 migration directory exists with its exact historical name 20260814_v1.7.0, which is its version identity in __diesel_schema_migrations on every migrated database. The sorting and names.last() logic existed solely to enforce the obsolete "is newest" condition and is removed; no other test, schema, migration, runtime behaviour or dependency changes. Test-only correction authorized by the #836 implementation-HOLD specification amendment and its approved independent review.
Add migration 20260826_v1.8.0 creating the canonical Metrics registry foundation (issue #836): four closed registry enums (metric_platform_ownership_class, metric_measure_category, metric_measure_unit, metric_reporting_grain) and the three metric_ registry tables (metric_platform, metric_measure, metric_platform_measure) with design-fixed short identifiers, non-blank required-text checks, unique stable codes, non-cascading registry foreign keys, a supported_grains contract enforcing non-empty / no-NULL / no-duplicate reporting grains at the database boundary, and exactly the constraint-derived indexes (no speculative secondary index). Seed exactly the two approved measures - title_sessions (USAGE, methodology cloudfront-title-session/2) and net_units (SALES, signed units) - with their exact approved definitions. Seed no metric_platform and no metric_platform_measure rows: source/platform mappings remain explicitly unapproved and are not inferred from DistributionPlatform. Update the manually maintained thoth-api/src/schema.rs contract atomically with the migration (ADR-0003), register the three new model modules, and add the Rust domain types (closed DB enums and persisted row types; no Rust platform-name enum and no DistributionPlatform conversion, per ADR-0002; metric_platform_measure deliberately has no timestamp columns) with 35 focused database/model tests covering enum labels and round-trips, exact seeds, constraint rejections, non-cascading deletes, order-preserving custom enum-array round-trips and latest-migration-only rollback/reapplication through the embedded harness. The slice is additive and inactive: no GraphQL/API surface, no registry administration, no collection/import/serving/export behaviour, no dependency changes and no production migration.
…n report Record the durable consequences of the MET-WP1-01 registry foundation (issue #836): WP1 entry is complete and WP1 becomes IN PROGRESS - started, not complete - once this slice is integrated into feature/metrics; stale claims that no feature/metrics branch or approved WP1 child specification exists are removed; CG-08 is reconciled to RESOLVED for WP1 entry (2026-08-26) in the existing dated-resolution style with the four-component entry rationale; CG-03, CG-04, CG-09, CG-10, CG-11 and CG-13 are unchanged; later Sphinx/client/source/WP5 gates stay attached to their owning work packages. Add the bounded CHANGELOG entry and the MET-WP1-01 implementation report with fresh post-correction validation, migration timing/locking, preservation and GraphQL non-impact evidence.
Record draft PR #839 and the first automatic CI run set at head 9e6a0cb: check-changelog, run-migrations, classify, build, test and format_check succeeded, and the authorized automatic staging image ghcr.io/thoth-pub/thoth:staging-pr-839 was pushed (sha256:e96651e82f3acc2281c31d5ea6542d815b85d417ba65d950346359214a2807de). The lint job fails on exactly three pre-existing clippy::useless_format findings in thoth-api/src/model/tests.rs (lines 887/893/899), a file byte-identical to the implementation base, untouched by this branch and outside the amended MET-WP1-01 write budget; CI's stable clippy 1.98.0 extended useless_format coverage beyond the local 1.97.0 toolchain, and the intervening documentation-only merges never ran the lint job. Per resume authorization 5430172038 the task therefore remains HOLD for merge until a further #836 specification amendment (or another explicit control-plane decision) authorizes the out-of-budget correction and CI provides the complete required evidence. No out-of-budget edit, manual CI action or merge action is taken.
The first automatic run set (head 9e6a0cb) failed only the lint job: three pre-existing clippy::useless_format findings in thoth-api/src/model/tests.rs (lines 887/893/899), a file byte-identical to the implementation base and outside the amended write budget. The second automatic run set (after the report commit) is fully green, including a complete lint job. Job logs establish the root cause: GitHub's ubuntu-24.04 runner image is mid-rollout - ubuntu24/20260823.283 ships Rust stable 1.98.0, whose clippy flags the three sites, while ubuntu24/20260816.277 (and the local 1.97.0 toolchain used for the required local gates) does not. The lint job is therefore nondeterministic for any substantive Rust change until the three pre-existing sites are corrected under their own authorization; this is escalated as an unresolved repository-wide issue, not silently worked around. No manual CI dispatch/rerun, out-of-budget edit or merge action was taken.
Independent exact-head source review of head ea408c7 returned CHANGES REQUIRED: setup_registry_db() asserted that the MET-WP1-01 migration (20260826) is the latest applied migration and used a single revert_last_migration, recreating the same future-fragile "must remain the newest migration forever" invariant class that this branch removed from the historical BE-04 test. The first later repository migration would have failed the complete Metrics registry suite with no MET-WP1-01 regression. Replace that with revert_through_registry_migration(), modelled on the durable revert_through_be04 pattern in distribution_job/tests.rs: assert only that 20260826 is applied (containment, never latest), revert migrations in reverse order until 20260826 itself has been reverted, then re-run all pending migrations. Later migrations are tolerated and no future migration name is hard-coded. Rename latest_only_rollback_removes_the_registry_and_reapplication_restores_it to reverting_through_the_registry_migration_removes_it_and_reapplication_restores_it and route it through the helper; its ledger assertion (max applied version < 20260826 after the revert) is durable under any later migration. No schema, migration content, dependency or runtime change; one CHANGELOG sentence describing the harness is re-worded to match. Single-step latest-only rollback remains recorded as point-in-time acceptance evidence at the implementation baseline (where 20260826 was the actual latest migration) in the implementation report.
Independent exact-head source review of head ea408c7 returned CHANGES REQUIRED: the report transcribed live PR CI state ("PASSING at the current head") into repository source, which is structurally recursive - a commit recording the current head's CI result creates a new head whose CI has not yet run, and had already caused source commits whose only purpose was transcribing changing CI results. Restrict section 11 to durable evidence: PR #839 and its GitHub Actions records are named as the sole authority for live PR/head/CI state, and the two retained CI observations are explicitly historical and bound to their exact heads (9e6a0cb: lint failure; bec1cce: all checks green), kept because they document the ubuntu-24.04 runner-image rollout variance (Rust 1.98.0 vs 1.97.x clippy) and its pre-existing out-of-budget useless_format cause. Sections 1.3, 3, 4.2/4.3, 5, 6, 6.1-6.2, 9, 10 and 14 are reconciled to the corrected revert-through test harness and record the CHANGES REQUIRED outcome and its corrections; the disposable-database runs in sections 6.1-6.2 are marked as historical acceptance evidence bound to the implementation baseline, where 20260826 was the actual latest migration. No further commit will be made merely to transcribe a CI result.
…foundation MET-WP1-01: establish Metrics registry schema and Rust domain foundation
Add migration 20260827_v1.8.0 creating the closed
metric_source_acquisition_type enum (DRIVER, PUBLISHER_UPLOAD, OPERAS,
ADMIN_IMPORT) and the metric_source, metric_source_account and
metric_source_checkpoint tables: unique stable source codes, account
identity UNIQUE(source_id, external_key), checkpoint identity
UNIQUE(source_account_id, partition_key), non-blank identity-key checks,
non-negative optional lookback/finalization-day checks, non-cascading
foreign keys to source, metric_platform and (optionally) publisher,
non-secret configuration JSONB defaulting to '{}', nullable generic JSONB
cursor, repository-standard UUID defaults and updated_at trigger, and
exactly the constraint-derived indexes plus the single operational index
on lease_expires_at.
Update the manually maintained schema.rs contract atomically with the
migration (ADR-0003), add the three Queryable model modules and 28 focused
database/model tests (including targeted revert-through rollback/reapply
of the source-state migration), record the slice in the Metrics tracker
and CHANGELOG, and add the MET-WP1-02 implementation report.
Additive and inactive: no rows seeded, no source/platform mappings, no
lease/claim concurrency behaviour, no GraphQL/authorization surface, no
driver or Sphinx integration, and no production migration, deployment or
activation. WP1 remains in progress.
…eport Record PR #843, the per-job CI outcomes for implementation head a26e772, the authorized automatic staging image publication (ghcr.io/thoth-pub/thoth:staging-pr-843) and its digest, and the analysis of the pre-existing ubuntu-24.04 runner-image clippy 1.98 lint failure (three untouched useless_format sites in thoth-api/src/model/tests.rs), which is outside this task's write budget and is reported as a reviewer finding rather than rerun or fixed here.
MET-WP1-02: establish the Metrics source-state foundation (#841)
# Conflicts: # CHANGELOG.md
…ation Add the third bounded WP1 slice on the feature/metrics programme integration branch (issue #863): the durable import and import-error state foundation. Migration 20260828_v1.8.0 creates the two closed enums metric_import_status (UPLOADED, QUEUED, PROCESSING, COMPLETED, COMPLETED_WITH_ERRORS, FAILED) and metric_import_error_severity (ERROR, WARNING), and the two evidence tables metric_import and metric_import_error. Import identity is source-account scoped and the design-fixed two-path idempotency contract is enforced by two mutually exclusive partial unique indexes: (source_account_id, upstream_report_id) where an upstream report ID is supplied, and otherwise (source_account_id, raw_sha256, format_version) where a raw hash is. Both evidence columns stay nullable, and no constraint requires an import to carry idempotency evidence at row creation: the later upload/claim APIs own that rule. The single design-required operational index is (status, created_at). Constraints are exactly those authorized: ten CHECKs on metric_import (four non-blank identifiers, six non-negative counters), two on metric_import_error (non-blank error_code and message), and non-cascading foreign keys to metric_source_account, the canonical publisher and the owning import, so durable import evidence is never silently erased. Deliberately absent are any import-period ordering check, counter-relationship check, row_number sign/range check and status/timestamp transition constraint. created_by stays plain text with no account foreign key or identity semantics. Update the manually maintained schema.rs contract atomically with the migration (ADR-0003), add the matching Rust persistence/domain types and closed DB enums, and add 38 focused database/model tests covering enum round-trips, exercised database defaults, the complete constraint, foreign-key and index inventories, both idempotency predicates and targeted revert-through rollback and reapply through the embedded migration harness. The slice is additive and inactive: no row is seeded, no GraphQL/API surface, upload/claim/complete operation, status transition, lease, retry, queue semantics or idempotent-return behaviour is implemented, no canonical record/revision/provenance, coverage/rollup/OPERAS state, publisher-platform approval or capability enforcement is added, Publisher Services distribution_job* schema and types are not reused, and no dependency, Cargo feature, source/platform mapping or production migration, deployment or activation is introduced. The public GraphQL SDL is byte-identical to the base build. WP1 remains in progress.
MET-WP1-03: establish Metrics import and import-error state foundation
…to v1.9.0
Thoth v1.8.0 has been published, and the repository's `make migration` target
derives the migration suffix from the workspace version by incrementing the
minor, so the next migration suffix is now v1.9.0. The three unreleased Metrics
migration directories on `feature/metrics` were created while the workspace
baseline was 1.7.0 and therefore still carry the `_v1.8.0` release suffix that
the published release now owns.
Rename the three directories to their correct release/display suffix:
thoth-api/migrations/20260826_v1.8.0 -> 20260826_v1.9.0
thoth-api/migrations/20260827_v1.8.0 -> 20260827_v1.9.0
thoth-api/migrations/20260828_v1.8.0 -> 20260828_v1.9.0
All six up.sql/down.sql blobs are preserved byte-for-byte with their file modes;
Git records every move as a 100%-similarity rename and the diff contains no SQL
content change.
Diesel derives a migration version from the text before the first underscore, so
the versions remain exactly 20260826, 20260827 and 20260828 and the suffix-only
rename is ledger-neutral: an already-applied migration is neither replayed nor
reported pending because its directory display name changed. This was proven on
a single disposable PostgreSQL database by applying the chain from the
pre-rename source, rebuilding the embedded migration source after the rename and
re-running the harness, leaving the `__diesel_schema_migrations` rows and their
run_on timestamps byte-identical. Full chain apply/revert/reapply also succeeds
from both sources with an identical resulting schema.
Update only the current forward-looking migration-path references: the
MET-WP1-01, MET-WP1-02 and MET-WP1-03 CHANGELOG entries and the three Metrics
test doc comments. The executable MET_WP1_0*_MIGRATION_VERSION constants stay
date-only and unchanged.
Release-number coordination only: no migration SQL, schema semantics,
thoth-api/src/schema.rs contract, Rust domain type, GraphQL/API surface,
authorization, data, dependency, Cargo/workspace version, Makefile or deployment
state changes. The historical MET-WP1-01/02/03 implementation reports and prior
issue, PR and review evidence keep their original `_v1.8.0` wording as
point-in-time provenance and are deliberately not rewritten.
Refs #766
Refs #868
Record the durable implementation evidence for the v1.9.0 migration release/display suffix reconciliation: exact authorized base and preflight results, the complete changed-path inventory and write-budget compliance, the before/after SQL blob proof against the authorized anchors, the disposable PostgreSQL full chain apply/revert/reapply, the same-database ledger-neutrality proof with a rebuilt embedded migration source, the repository validation commands and their exact results, external/runtime/data/auth/security effects, limitations and the remaining gates. The report is evidence only. It is not self-approval, and the implementing agent does not review, approve or merge its own work. Refs #766 Refs #868
Complete section 11 of the implementation report with the observed automatic workflow evidence for PR #871 at head 6691190: build-test-and-check 33372926680 success run-migrations 33372926670 success check-changelog 33372926615 success publish-to-dockerhub 33372926642 success All ten PR checks pass. The run-migrations workflow independently reproduced the apply/revert/reapply chain on a disposable postgres:17 service, and the CI lint job supplies the authoritative Clippy result for this head, resolving the local toolchain skew recorded as a limitation. Also record the explicitly authorized automatic staging-image publication, ghcr.io/thoth-pub/thoth:staging-pr-871 at digest sha256:c7b80a18ca5196f5b55bdfd6f9067fc2e24ca0f7bbd4720e9e5efe43bb68b6c8, noting that its image.revision label is the ephemeral pull_request merge ref rather than the task head. No workflow was manually dispatched, rerun or cancelled. Evidence only; this records no approval. Refs #766 Refs #868
…n-reconcile MET-MIG-V1.9-RECON-01: reconcile unreleased Metrics migration suffix to v1.9.0 (#868)
…enance foundation Adds the additive, inactive canonical record-history foundation approved in issue #872: migration 20260831_v1.9.0 creating the closed enums metric_record_revision_status and metric_record_provenance_classification and the three canonical history tables metric_record, metric_record_revision and metric_record_provenance, together with the manually maintained schema.rs contract, the matching Rust domain modules and focused database tests. Canonical identity is carried by a unique non-blank identity_hash rather than a natural composite key, because record identity excludes both the acquisition route and the value. No publisher, imprint or series attribution is stored on the record: current attribution is derived from live Thoth metadata. The intentionally circular record/current-revision relationship is created additively - metric_record with a nullable current_revision_id, then metric_record_revision, then the constraint - and both same-record invariants are enforced declaratively by composite foreign keys over (record_id, current_revision_id) and (record_id, supersedes_revision_id) against a supporting (record_id, record_revision_id) unique key. Neither pointer can name a revision owned by another record, with no trigger and no new dependency. The down migration drops the circular constraint explicitly before dropping either participating table. Metrics alpha-2 country storage is a separate nullable CHAR(2) representation enforcing shape only; the existing bibliographic alpha-3 CountryCode enum is neither modified, aliased nor reused. Revision value stays a signed BIGINT with deliberately no blanket non-negative constraint, because sales measures may report signed net units. Additive and inactive. No row is seeded, and the slice implements no identity or content hashing, no normalized-observation validation, no DOI/ISBN/ROR resolution, no first-arrival, duplicate, revision, conflict or retraction transaction, no managed-source revision authorization, no publisher finality, no rollup delta, no period-overlap detection or concurrency primitive, no GraphQL, authorization or administration surface and no production migration. The generated public GraphQL SDL is byte-identical to the base build. WP1 remains IN PROGRESS, not complete. Refs #872 Refs #766
Records the bounded implementation evidence for the canonical Metrics record, revision and provenance foundation: preflight results, the exact authorized base and branch, the write-budget and action-authorization compliance, the schema/constraint/index inventory, the empty and representative populated disposable PostgreSQL 17 apply/revert/reapply evidence with data-preservation and locking observations, the byte-identical GraphQL SDL comparison, and the exact repository validation commands and results. This report is implementation evidence, not self-approval. No pull request is created and none is authorized. Refs #872 Refs #766
…hema MET-WP1-04: establish canonical Metrics record, revision and provenance foundation
Adds migration 20260901_v1.9.0 creating the closed metric_coverage_status enum (COMPLETE, PARTIAL, UNKNOWN) and the metric_coverage table: one durable record of what a source account's import reported it covers for one platform/measure over one half-open period, independent of and prior to any canonical metric_record computation. Direct non-cascading foreign keys to metric_source_account, metric_import, metric_platform and metric_measure; half-open period ordering (period_end > period_start); non-null coverage_status, country_coverage and institution_coverage; nullable notes. No coverage uniqueness beyond the primary key and no speculative secondary index, matching the approved design. Updates the manually maintained schema.rs contract under ADR-0003, adds the metric_coverage Rust domain module and focused database/model tests. Additive and inactive: no coverage row is seeded, no coverage calculation/finalization/zero-versus-unknown behaviour, no normalized ingestion or ingestMetricBatch transaction, no GraphQL surface. WP1 remains in progress. Issue: #875
Records MET-WP1-05 as implemented on feature/metrics--wp1-coverage with draft PR #876 open against feature/metrics, explicitly not merged. WP1 remains IN PROGRESS.
Comment 5491893730 was intended as the pre-implementation implementation-authorization/handoff comment but was posted malformed via gh api -f body=@<path>, which did not substitute the file's contents and instead persisted the literal local path string. Corrects the implementation report's claims accordingly: the report no longer states that the durable handoff comment posted correctly, and no longer attempts to record its own final head SHA. The exact resulting head/tree is recorded in the post-push #875 completion comment instead. No implementation file, migration or test is affected.
…oard-contract MET-WP4-03B: complete the optimized protected metricDashboard contract
…-postmerge-corr-01 MET-WP7-PREREQ-03: fix historical evidence validation
…1-docs MET-WP4-03A-OPS-01: reconcile monthly rollup operations documentation
…erations Add the two METRICS_INGEST_SERVICE-only maintenance operations for the MET-WP4-03A derived monthly projections (issue #951, Specification Amendments 1 and 2): - verifyMetricRollupMonths: one read-only REPEATABLE READ snapshot that independently derives the expected monthly state from metric_rollup_work_day by set-based SQL sharing nothing with the writer, compares all four monthly tables by logical identity, and returns only bounded expected/actual/missing/extra/mismatched counts plus frontier facts. Pending rollup lag is reported as lag; a work-day row above the frontier fails closed. - rebuildMetricRollupMonths(expectedAppliedThroughSequence): one all-or-nothing transaction under the singleton state-row lock that requires the pinned frontier, no work-day row above it and at most 100000 represented month keys, verifies first, returns rebuilt=false without any monthly write when already exact, and otherwise truncates the four tables, recomputes every key in chunks of at most 50 through the existing reviewed recomputation, verifies again and commits only an exact result under lock_timeout 5s, statement_timeout 30s and a 120s server-side elapsed ceiling. Neither operation touches the work-day projection, rollup deltas, the frontier, canonical records or the generic reconciliation ledgers. No migration, table, index, dependency, role or query-side surface is added; the generated schema change is strictly additive.
…pshot (CR-1) Independent review of 8061ac0 found that verifyMetricRollupMonths froze its REPEATABLE READ snapshot before touching the four monthly projection tables, while rebuildMetricRollupMonths replaces them with a transactional TRUNCATE. PostgreSQL's TRUNCATE is not MVCC-safe, so a verifier snapshot older than a concurrent rebuild's truncate could see tables it had not yet accessed as empty and report an incoherent monthly state. The verifier now executes LOCK TABLE on exactly the four monthly tables IN ACCESS SHARE MODE immediately after SET LOCAL statement_timeout and before its first query, and holds it until the transaction ends. ACCESS SHARE conflicts only with the rebuild's ACCESS EXCLUSIVE, not with the ROW EXCLUSIVE writes of normal incremental completion, so routine monthly maintenance stays concurrent while an exceptional truncate can no longer cross a verifier snapshot in either direction. The verifier remains read-only; no state-row lock, FOR UPDATE, advisory lock, mutex or coordination table is introduced, and the rebuild's TRUNCATE is unchanged. Tests pin the exact statement order (the lock precedes every query) and its table list and mode, and add two deterministic race tests between the production verifier and the production rebuild, synchronised through an instrumentation pause point and pg_locks/pg_stat_activity evidence rather than timing: a verifier holding its locks blocks a real rebuild at its TRUNCATE and returns one coherent pre-rebuild snapshot; a verifier arriving while a rebuild holds the tables waits at its LOCK with no query issued and then returns exactly the committed rebuilt state.
MET-WP4-03A-OPS-02: protected monthly verification and rebuild contract
Merge the approved develop reconciliation branch into feature/metrics after independent exact-head review.
Add the two additive yearly section projections (metric_rollup_work_country_year, metric_rollup_work_institution_year; migration 20260928_v1.9.0, created empty, no backfill), maintain them inside completeMetricRollupDeltas with exactly four fixed set-based statements after the monthly projections and before terminalization and the frontier advance, make verifyMetricRollupMonths authoritative over six derived projection families with the expected yearly state derived independently from metric_rollup_work_day, and make rebuildMetricRollupMonths replace and re-verify all six derived tables inside the unchanged operational envelope. MetricRollupMonthVerification gains exactly the additive fields countryYear and institutionYear; the maintenance operations and their result types now describe the six-family contract (Specification Amendments 4 and 4A, #952). No operation, argument, type shape or authorization changes. Unit B serving remains separately gated and inactive.
Prose-only correction of findings CR-2 and CR-3 of independent exact-head review 5909936816 on PR #959, under authorization 5910208407. No executable Rust or SQL, Diesel schema, GraphQL schema or description, test or behaviour change. CR-2: the metric_rollup_delta module documentation and the 20260928_v1.9.0 migration comments now describe Unit A as the yearly producer, verification and rebuild foundation approved through Specification Amendments 4, 4A and 4B. They state that verifyMetricRollupMonths already exposes the additive countryYear and institutionYear families, that no metricDashboard source reads the yearly tables, that the Unit B reader remains separately gated and on HOLD, and that an authorized historical rebuild and exact six-family verification precede any activation. The earlier K-3 spike is cited only as historical technical evidence, not implementation authority. CR-3: the MET-WP4-03C-A CHANGELOG entry now states that operation names, arguments, existing fields with their types and nullability, and authorization are unchanged, and that MetricRollupMonthVerification gains exactly two additive result fields, countryYear and institutionYear. It also describes the Amendment 4B lock-light no-op rebuild path. This supersedes the wording of a7a4b1f, whose message says there is no type shape change: the verification result type gains the two additive fields.
MET-WP4-03C-A: add the yearly derived-state producer (#952)
…n index Issue #952, Specification Amendments 5, 5A and 5B, B1 handoff 6018413540 with corrections 6018808058 and 6020065296, CTO authorization 6021659207. Migration 20261006_v1.9.0 creates the derived metric_coverage_run table (ten non-null columns, composite primary key, four plain foreign keys, run_end > run_start), exactly four permanent secondary indexes including the H2 partial metric_record_native_grain_idx, and the one trigger metric_import_maintain_coverage_runs with its function maintain_metric_coverage_runs_from_import(): READ COMMITTED only, metric_source_account FOR UPDATE, hull-scoped recomputation from raw coverage and terminal import evidence with historical coverage-platform and import-publisher provenance, outer-fragment preservation and maximal coalescing. No historical backfill. Adds the protected METRICS_INGEST_SERVICE mutations verifyMetricCoverageRuns (read-only repeatable-read keyset pages, byte-exact domain fingerprint, independent per-day verification with V1-V4 structural counts) and rebuildMetricCoverageRuns (one account, read-committed, account row lock, independent pre- and post-verification, 5s/30s timeouts), with the three approved result types and the H1-local error boundary. Adds the frozen producer and verifier identity manifests, the acceptance suite, and the narrow CORR-01 predecessor-test corrections.
…re (#952) Replace producer_manifest.txt with the exact producer manifest frozen by HANDOFF-CORR-05 (37 dependency entries) and verifier_manifest.txt with the exact verifier manifest frozen by HANDOFF-CORR-04 (17 dependency entries), and update the exact-content and entry-count assertions in tests.rs to match. The identity algorithm, every manifest dependency file, the migration, schema, GraphQL contract, policy and H1/H2 logic are unchanged.
…verage-foundation MET-WP4-03C-B1: add H1/H2 coverage foundation
…n slice (#982) Import the exact authorized develop history (b44303c) into feature/metrics--wp11-thoth-api-integration, created from exact feature/metrics bfdcd51, by an ordinary ancestry-preserving merge (parent 1 = feature/metrics, parent 2 = develop). The only conflict is the CHANGELOG.md [Unreleased] > Added hunk. It is resolved exactly as Specification Amendment 3 requires: the 27 feature/metrics-side Added entries first, in their existing order and content, immediately followed by the develop-side THOTH-ASYNC-01-CTRL-01 entry; every cleanly merged line is left verbatim as Git produced it. Documentation and control records only. No schema, migration, runtime, authorization, GraphQL/API, generated-contract or CI workflow change.
…e-flow doctrine (#982) Correct only the current, non-historical Thoth Metrics programme-flow and status prose in the eight-path child-A write budget so that it no longer instructs later work to use the completed feature/metrics line or claims that no Metrics foundation beyond MET-WP1-01 exists: - branching-and-release-workflow.md section 5 (Thoth-only prose/example) - repository-map/branch-topology.md section 2 (Thoth-specific lines) - docs/metrics/README.md (status header, section 6 current-decision claims, adjacent #766/#981 note, final present-tense paragraph) - docs/metrics/task-status.md (section 4 Thoth-only flow note; section 5 heading plus adjacent historical-snapshot status note) - docs/engineering/README.md (section 6 Metrics readiness sentences, section 7 Thoth Metrics entry, section 9 Outstanding paragraph) - docs/metrics/rollout-plan.md (stale Stage 0/1 slice-availability claims) - repository-map/control-gaps.md (CG-08 stale current-scope sentences) The doctrine is lifecycle-neutral: the final integration of the Thoth feature/metrics line into develop is governed by #981 through the separately gated stages A -> A2 -> B; after A2 no normal new feature/metrics--<slice> is created except a separately authorized develop-refresh recovery; after the final integration, later Thoth-side Metrics work follows the STANDARD feature/<area>/<task> -> develop flow. No stage is described as already complete, feature/metrics is not described as merged or retired, and historical entry-gate evidence is preserved. Documentation only. No schema, migration, runtime, authorization, GraphQL/API, generated-contract or CI workflow change.
Add exactly one entry as the first item under [Unreleased] > Changed for MET-WP11-THOTH-API-01-A (child A of #981), describing the develop-history import and the durable Thoth Metrics programme-flow/doctrine reconciliation as documentation and control records only. No other CHANGELOG line is touched; no PR number is cited because none has been assigned.
…ral (#982) Correct blocking finding H-F13-01 from the independent exact-H review of bb24c61 in exactly the two already-approved regions: - control-gaps.md CG-08: keep the historical statement that slices already merged after MET-WP1-01 were separately specified, independently reviewed and authorized; describe each #981 integration stage as separately gated, requiring its applicable specification, independent review and explicit CTO action authorization before execution. - docs/metrics/README.md section 6 final paragraph: replace the transient "remains unauthorized until" wording with the durable invariant that each A, A2 or B action, later work package or task is separately gated and may proceed only after its applicable specification, independent review and explicit action-authorization requirements are satisfied. Documentation only. No other line, path or control-gap status changes.
…i-integration MET-WP11-THOTH-API-01-A: reconcile develop into the Metrics programme line
… 2.3.10 (#985) Pin diesel_derives 2.3.10 in Cargo.lock (the version and checksum lines of its stanza only; diesel stays 2.3.10). Its QueryableByName derive emits shorthand named-field initializers, so the 346 generated clippy::redundant_field_names positions in 36 Rust files no longer fire under -D warnings. No Rust source, manifest, migration, schema.rs, GraphQL, authorization, workflow or lint configuration changes. Record the single one-time CI-correction slice in the four Thoth-specific post-A2 programme-flow paragraphs (#981 / #985), add the #985 changelog entry and the implementation report.
MET-WP11-B-CLIPPY-01: restore unsuppressed Clippy with diesel_derives 2.3.10
This was referenced Oct 23, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Final B integration for #981 / Thoth Metrics WP11.
This PR integrates the completed, independently governed Metrics programme line
into develop after child A and terminal A2 branch retirement.
Exact authorized source:
feature/metrics @
d5451f8
Exact authorized base at PR creation:
develop @
b44303c
A2 completion receipt:
#981 comment 6198611715
B gate reconstruction:
#981 comment 6198937684
CTO B PR-publication authorization:
#981 comment 6201955766
The PR is intentionally DRAFT.
MERGE IS NOT AUTHORIZED.
Required final merge method, if separately approved later:
GitHub TRUE MERGE COMMIT.
Squash and rebase merge are prohibited.
B is source integration only. This PR does not authorize migration execution,
release, deployment, production activation, client cutover, historical rebuild,
or deferred B2 work.