docs(publisher-services): reconcile BE-04 implementation blockers - #817
Merged
ja573 merged 5 commits intoAug 15, 2026
Merged
Conversation
A fresh independent review measured a BE-04 implementation candidate against the BE-04 specification and found three defects in the specification itself. Correct the requirements rather than work around them in code. Finding A - distribution_job_attempt_error_result_check was not NULL-safe. PostgreSQL rejects a row only when a CHECK evaluates to FALSE and admits it when the result is UNKNOWN, so `(error_code IS NULL AND error_detail IS NULL) OR result = 'FAILED'` accepted an open attempt (result IS NULL) carrying error fields. Reproduced against the full specified constraint set on a disposable PostgreSQL 17.10. Specify the NULL-safe expression with its three-valued truth table, fix the required rejections and acceptances on INSERT and UPDATE, and require the observed catalog expression and truth-table results as evidence. The state machine is unchanged. Finding B - the exact report statement-count contract was unsatisfiable. Two of the three specified DataLoaders were keyed by distribution_job_id, which exists only after the latest-job loader resolves; for such a dependent-arrival cohort the only bound provable from pinned dataloader 0.18.0 semantics is ceil(N / max_batch_size) <= dispatches <= N. Reject that shape rather than weaken the control, and require one field-specific, first-level, request-local composite loader keyed by publisher_id resolving the job, its targets and its attempts in three set-based statements per dispatch chunk. State the arithmetic exactly, separate BE-04's structural properties from the shared ADR-0007 chunking property it consumes, and require a scheduler-independent zero-dispatch assertion for the second-level loaders on the report path. ADR-0007's shared 200/10 configuration is unchanged, no look-ahead or request-scoped store is introduced, and no unrelated loaders are merged. Finding C - `cargo test -p thoth-client` does not build at the authorized base either: thoth-api does not compile with its backend feature off and only the workspace and build-dependency edges enable it. Remove it as a BE-04 gate rather than report it as passing or repair unrelated dependency architecture here; require the workspace runs the repository's own CI already uses, with an explicit demonstration that thoth-client's tests executed within them, and record the standalone failure as pre-existing packaging debt for a separate task. Also record the addendum and its post-addendum implementation gate in a new section 34, and correct two sentences the repository now disproves. Documentation only. No runtime, migration, contract, workflow or manifest change. PR #816 and PR #799 untouched. No specification is approved and no implementation is authorized.
…dence Update the programme tracker truthfully: BE-04 becomes BLOCKED - IMPLEMENTATION CANDIDATE EXISTS - SPECIFICATION ADDENDUM REQUIRED. An implementation candidate exists as a draft, unmerged pull request; that is observed repository state and is not a delivery, an approval, readiness or merge readiness. Record the three open specification defects, correct the narrative sentence that said the implementation branch does not exist, and add item 15 covering the addendum and the gate that must be satisfied before BE-04 implementation resumes. Add the addendum implementation report with the preflight table, the demonstrated truth table for the NULL-safe constraint, the source-level analysis of dataloader 0.18.0 and Juniper 0.16.2 that rejects the nested-loader route, the independently reproduced thoth-client failure at the authorized base, the consistency search, and the required review focus. No approval decision is issued. Add the CHANGELOG entry under Unreleased. Automatic job creation remains inactive and nonexistent, no distribution_job relation exists on develop, and no production action exists.
Three findings were raised against the addendum's first revision. All three are
corrected here; the three substantive addendum decisions (NULL-safe attempt-error
constraint, Route A composite loader, thoth-client gate resolution) are not
reopened.
Finding 1 - the statement arithmetic was not mathematically exact. It used one
page-global boolean, `2 + (3 if J else 1) * C_job + C_assign`, but cost is
decided per dispatch chunk: a multi-chunk page can contain a chunk that resolves
jobs (3 statements) and another that resolves none (1 statement). Replaced
throughout by
statements = 2 + 3 * C_job_nonempty + 1 * C_job_empty + 1 * C_assign
with the four named cases evaluated mechanically - job-only/report on a page
with jobs give 5 and 6, and on a page without give 3 and 4 - plus a worked
multi-chunk example and a rule that multi-chunk pages are derived from the
actual per-chunk classification. Also removes the self-contradictory
`C_job = C_assign = 1`: for the job-only selection C_assign is 0, because that
selection does not select enabledDistributionPlatforms. Loader-dispatch
acceptance is now stated per loader - each selected first-level loader has its
expected chunk count, each unselected loader has zero, and the second-level
loaders have zero report-path dispatches - rather than as a blanket claim that
every loader dispatches once.
Finding 2 - the control records conflated "addendum 01 is not approved" with
"BE-04 never had an approved specification". The live GitHub authority shows
otherwise: PR #814 is merged, its merge commit is the authorized base
ed32712, and it carries the CTO's explicit
BE-04 implementation authorization against that base, naming the merged BE-04.md
as the repository-authoritative specification. Corrected to APPROVED BASELINE /
ADDENDUM 01 NOT YET APPROVED across the specification header, sections 6.3 and
31, the new section 34.0, the tracker and the changelog. The baseline approval
and the implementation authorization are preserved as historical authority; the
implementation candidate is properly authorized work, and is blocked because the
contract it was built against is being corrected, not because it was
unauthorized. The authorization is insufficient - not void - for the corrected
contract. Clearly labelled historical DRAFT and remediation narrative is
retained, and no review or approval comment identifier is transcribed into a
committed file (ADR-0005 section 5).
Finding 3 - an unsupported inference about BE-02. The claim that an unexpected
chunk count would apply "equally" to BE-02's merged assignment loader is
withdrawn: ADR-0007 requires field-specific query-count evidence per adopting
field and establishes no universal sublinear bound for arbitrary arrival timing.
The escalation rule now requires the cause to be classified on evidence as
BE-04-specific, a shared-foundation dependency/runtime regression, or another
execution shape; only the second escalates to the owning Shared Thoth GraphQL /
Backend Architecture programme, the control that a genuine shared finding must be
surfaced rather than worked around locally is preserved, and no claim about
another field's loader may be made without verifying that field.
Documentation only. No runtime, migration, contract, workflow or manifest
change. PR #816 and PR #799 untouched.
Committed control documents must stay truthful before review, after review, before merge and after merge (docs/engineering/AGENTS.md section 1.1, ADR-0005 section 6). The addendum's records carried wording whose truth would change merely because PR #817 is reviewed, approved or merged. Removed and replaced by durable form; no substantive addendum decision is reopened. BE-04.md - Status becomes "APPROVED BASELINE + ADDENDUM 01 AUTHORITY CONDITION BELOW". - The header now states, durably: the approved baseline and its implementation authorization through PR #814; that this document carries the corrected addendum content; that approval authority is the CTO; the authority condition that the corrected content is repository-authoritative when the exact CTO-approved content is reachable from develop; and that live review, approval and merge evidence is the GitHub history of PR #817. - Section 34.0 restated as baseline and addendum authority rather than as a current approval state; sections 6.3, 31 and 34.5 follow. Section 31 no longer calls the implementation pull request draft, and states durably that the candidate was built against the baseline contract and does not satisfy the corrected one. - Section 33 no longer waits for someone to fill an approval block. It records that approval, review, authorization and merge are GitHub-owned terminal evidence, and that copying them here would need an approval-state commit, which ADR-0005 section 4.1 item 10 prohibits. No PR #814 comment identifier is transcribed. Implementation report - "Independent reviewer: required and absent" becomes a statement of the requirement and of reviewer independence, with the live review decision and its exact-head binding left to GitHub. - The preflight table is labelled a point-in-time observation record rather than a claim about current pull-request state. - No committed statement calls addendum 01 unapproved; approval authority and live approval state are GitHub-owned, and the report issues no approval decision. Tracker - BE-04 status becomes "BLOCKED - IMPLEMENTATION CANDIDATE REQUIRES CORRECTED-CONTRACT RECONCILIATION", which survives addendum review and merge. - Durable facts retained: the approved baseline through PR #814; candidate #816 properly authorized against ed32712; the candidate does not satisfy the corrected contract; continuation needs the corrected content repository-authoritative, a fresh base and a new CTO implementation authorization; live satisfaction is GitHub-owned. - PR references no longer commit draft or approval state. CHANGELOG - The entry describes the durable change and attributes approval and merge state to GitHub, so it stays true after approval and merge without another commit. Documentation only. No runtime, migration, contract, workflow or manifest change. PR #816 and PR #799 untouched.
Two residual documentation defects, plus one found by running the search variant-aware rather than literal. 1. The implementation report described its own framing as the "approved-baseline / not-yet-approved-addendum distinction". That is transient workflow state and becomes false when the CTO approves the addendum. Replaced by the "approved-baseline / corrected-addendum authority distinction", stated durably: the baseline is CTO-approved and repository-authoritative through PR #814, addendum 01 is the corrected specification content, the CTO is its approval authority, and its live review, approval and merge state is GitHub-owned. 2. The PR #817 changelog entry still described the tracker as updated to "BLOCKED - IMPLEMENTATION CANDIDATE EXISTS - SPECIFICATION ADDENDUM REQUIRED", which stopped being the tracker status when the previous commit made it lifecycle-neutral. It now states the current durable status, "BLOCKED - IMPLEMENTATION CANDIDATE REQUIRES CORRECTED-CONTRACT RECONCILIATION". The rest of that entry is unchanged. 3. A variant-aware search (not[- ]yet[- ]approved) found a hyphenated instance the earlier literal-space search missed: the tracker's programme note 14 still called the addendum "not-yet-approved". Replaced with its approval authority and authority condition. The report's consistency table is also reworded so its rows no longer contain the very tokens they report as absent, and it records that the search must be run variant-aware. Documentation only. No substantive addendum decision is reopened: the NULL-safe attempt-error CHECK and its truth-table requirements, Route A and its loader ownership, the per-chunk statement arithmetic and the 5/6/3/4 examples, ADR-0007's 200/10, the evidence-classified escalation rule, the BE-02 non-inference, the thoth-client gate resolution, the approved-baseline and implementation-authorization history, and the post-addendum implementation gate are all unchanged and verified present. No runtime, migration, contract, workflow or manifest change. PR #816 and PR #799 untouched.
Member
Author
CTO specification-addendum approval and merge authorizationBE-04-SPEC-ADDENDUM-01 is approved at exact head:
Merge of PR #817 is authorized only at that exact head. This approval and merge authorization do not authorize BE-04 implementation against the corrected contract. After this addendum is merged, BE-04 implementation requires a freshly verified new The connected GitHub account cannot submit an APPROVE review on its own pull request, so this conversation comment is the durable CTO approval/merge-authorization record. The guarded merge attempt at the approved head was rejected because PR #817 is still a draft; no merge occurred. |
ja573
marked this pull request as ready for review
August 15, 2026 10:50
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
This was referenced Aug 15, 2026
Merged
ja573
added a commit
that referenced
this pull request
Aug 15, 2026
Incorporate the authorized corrected specification base develop @ 8c0c54b (merge commit of PR #817, BE-04-SPEC-ADDENDUM-01) into the BE-04 implementation branch, under the CTO implementation reconciliation authorization recorded on PR #816 comment 5301898691. Conflicts: - docs/publisher-services/task-status.md - resolved in favour of the merged addendum record. The branch side asserted BE-04 as an IMPLEMENTATION CANDIDATE delivered against the pre-addendum contract, which the corrected specification contradicts. The develop side is repository-authoritative and is taken whole; the tracker is reconciled to its durable post-reconciliation form in a later commit of this branch, once the corrected contract is actually satisfied. CHANGELOG.md merged cleanly, preserving the #817 addendum entry alongside the existing BE-04 implementation entry. The BE-04 implementation entry is reconciled with the corrected contract in a later commit. No specification content is edited by this merge: BE-04.md arrives exactly as merged through PR #817.
ja573
added a commit
that referenced
this pull request
Aug 15, 2026
Bring the BE-04 implementation candidate into compliance with the corrected specification merged through PR #817, under the CTO implementation reconciliation authorization on PR #816 comment 5301898691. Correction A - the attempt-error CHECK is now NULL-safe. `distribution_job_attempt_error_result_check` was `(error_code IS NULL AND error_detail IS NULL) OR result = 'FAILED'`. PostgreSQL rejects a row only when a CHECK evaluates to FALSE and admits it when the result is UNKNOWN, so on an open attempt - `result IS NULL` under the closure check - the second arm was NULL and a row carrying `error_code`, or both error fields, was accepted. The constraint is now `... OR (result IS NOT NULL AND result = 'FAILED')`, which converts exactly those UNKNOWN rows to FALSE and changes no row the constraint already decided; the state machine is untouched. A new test proves the whole three-valued truth table on INSERT *and* on UPDATE, attributing each rejection to this constraint by name so a neighbouring constraint cannot stand in for it: five rejections (an open attempt with `error_code`, an open attempt with both error fields, and SUCCEEDED/ABANDONED/CANCELLED with either field set - each of the last three in both the code-only and code-plus-detail form) and three acceptances (an open attempt with both fields null, a closed FAILED attempt with valid fields, and a closed FAILED attempt with both null), each acceptance proven to have persisted. The first two rejections are the rows the old expression admitted. The stored catalog expression is asserted to remain NULL-safe. Diesel's table! macro does not encode CHECK constraints, so this migration correction has no `schema.rs` impact; migration/schema parity is otherwise unchanged. Correction B - one first-level composite report loader. `latestBackCatalogueJob` was backed by a latest-job loader keyed by `publisher_id` feeding two loaders keyed by `distribution_job_id`. That is a dependent-arrival cohort whose only provable bound is `ceil(N / max_batch_size) <= dispatches <= N`, so no exact statement count was satisfiable. It is replaced by one field-specific, request-local, `configured_loader`-built composite loader keyed by `publisher_id` whose value is the complete field: the latest PUBLISHER_BACK_CATALOGUE job together with its targets and attempts, or None. Its batch function runs inside one spawn_blocking boundary on one pooled connection acquired and dropped inside that closure: L1 always, then L2 and L3 exactly once each and only when L1 returned at least one job. It is total over its requested keys, and a failure in any of the three fails the whole chunk closed with no per-key fallback and no partially populated job. The resolver returns the preloaded payload directly, so `DistributionJob.targets` and `.attempts` read materialized values on the report path and issue no statement and no loader call there. The target and attempt loaders are retained solely for the single-job mutation payloads of completeDistributionJob, failDistributionJob and cancelDistributionJob, which still return lazy payloads, so neither is unused. The worker claim path is unchanged and still resolves its own payloads set-based without RequestLoaders. Section 25.12 query-count test rewritten. The previous test accepted the old divergence with `>= bound` and "far below the page size". It now measures both selections at page sizes 1, 25 and 200, on a page containing at least one job and on a page containing none, and derives every expectation from the measured per-chunk classification rather than hard-coding it: statements = 2 + 3 * C_job_nonempty + 1 * C_job_empty + 1 * C_assign `ObservedLoaderStats`/`BatchStats` gain an atomic per-chunk outcome record so the composite chunks can be classified as non-empty or empty L1 without pairing two separate observations. The test also asserts zero dispatches of both second-level loaders on the report path, exact selection dependence in both directions, that L2/L3 are absent for an empty chunk and occur exactly once for a non-empty one, and that every chunk partitions the requested key set. Measured, reproducibly across repeated runs, at every page size: job-only 5 and full report 6 on a page with a job; 3 and 4 on a page without one; C_job = 1; target and attempt dispatches 0. ADR-0007's 200/10 configuration is unchanged. No public GraphQL contract change: the generated SDL is byte-identical to the pre-reconciliation head.
ja573
added a commit
that referenced
this pull request
Aug 15, 2026
Bring the BE-04 implementation report, the programme tracker and the changelog into line with the corrected specification and with what the reconciliation actually measured. Implementation report: - records both authorized episodes without one erasing the other: the original base `ed32712766…` with the PR #814 authorization as valid history, and the corrected base `8c0c54bd…` with the fresh CTO reconciliation authorization on PR #816 comment 5301898691; - records the reconciliation preflight, the merge commit, the single conflict and how it was resolved, and the files the reconciliation touched; - adds section 6.2.1: the withdrawn and corrected CHECK expressions, why the old one admitted an open attempt carrying error fields, the exact observed pg_get_constraintdef, and the eight-case truth table on both INSERT and UPDATE; - records that Correction A has no schema.rs impact as a reviewed conclusion, because Diesel's table! macro does not encode CHECK constraints; - re-runs and records the migration evidence at the reconciled head, including the disposable-database CLI forward/revert/re-apply cycle, with both timing figures explicitly not production predictions; - replaces section 11.1 with the full twelve-case query-count matrix - two selections, three page sizes, job and no-job fixtures - showing derived equal to observed in every case and identical across five re-runs, and rewrites 11.2 around the composite loader's key, value, L1/L2/L3 shape, totality and fail-closed behaviour; - updates the command gate to the reconciled head's figures and states the thoth-client executed test counts for both workspace profiles; - removes the "report statement count diverges" limitation rather than rewriting it, because the corrected implementation satisfies the corrected contract, and records that no unresolved issue remains and that stop condition 23 did not fire, so nothing is claimed about BE-02's loader. Tracker: BE-04 moves to the durable, lifecycle-neutral status IMPLEMENTATION CONTROLLED BY PR #816 - RUNTIME INACTIVE. It records the PR #814 baseline authority as history, PR #817's corrected specification as repository-authoritative, the fresh reconciliation authority as GitHub-owned on PR #816, and the condition that repository authority for the implementation depends on its exact content becoming reachable from develop. New next-action item 16 records the reconciliation. Nothing asserts a state that a later GitHub event would falsify. Changelog: the merged #817 entry is preserved; the BE-04 implementation entry is reconciled in place - not duplicated - to describe the NULL-safe attempt-error check and the single composite report loader with its measured counts, and the statement that the implementation intentionally carries the three-loader divergence is removed. Two stale internal cross-references in the report are corrected.
ja573
added a commit
that referenced
this pull request
Aug 17, 2026
Codex raised a P1 on the tracker: it described BE-04 in transient workflow terms that merging PR #816 would immediately falsify, which is exactly what docs/engineering/AGENTS.md section 1.1 forbids in a committed file. Merging would have required an immediate corrective commit. The tracker now records the durable decision instead. BE-04's status becomes IMPLEMENTATION DELIVERED - RUNTIME INACTIVE in the summary paragraph, the task-table Status cell and the Acceptance cell. Present-tense lifecycle wording is removed throughout: "implementation candidate", "implementation branch", "IMPLEMENTATION CONTROLLED BY PR #816", the claim that the implementation is unmerged and that develop still lacks the distribution_job relations, and "merge would authorize". Repository authority is stated as an authority condition that attaches when the exact independently approved content is reachable from develop, and live review, approval, CI and merge state is left to GitHub under ADR-0005. Historical traceability is kept: delivery through PR #816, the baseline through PR #814, corrected Addendum 01 through PR #817, the doctrine merged through PR #820, and the authorizations recorded on issue #821 all remain. The wording is now true both before and after PR #816 merges. contracts.md registered thoth-pub/baboon as a verified consumer of the Thoth GraphQL and metadata export APIs on 2026-08-16, after this implementation report's consumer matrix was written, so BE-04 lacked the explicit Baboon impact assessment the cross-repository gate requires. Section 10.7 adds it as row 8, REMAINS COMPATIBLE, with the reasoning enumerated: the GraphQL change is additive, no existing field is removed, retyped, made stricter or given a required argument, no existing default changes incompatibly, the export format and export-availability semantics are untouched, the discovery fields Baboon queries are unmodified, and DISSEMINATION_WORKER governs only the new worker mutations. No Baboon source change or downstream task is required. The assessment is dated honestly: it was added during this review remediation after Baboon became a verified consumer, not during the original implementation. Baboon was read only through this repository's own repository-map records and was not modified. The matrix now covers every currently verified consumer, with thoth-sphinx kept separate as a planned future consumer rather than as compatible, and cc-license excluded on evidence as a crate this repository consumes. Section 1.9 records this episode: starting head baab314, incorporated develop 6f192ea, a two-file write budget, no new files, and no runtime, specification, GraphQL, migration or cross-repository source effect. baab314 is recorded as this episode's authorized starting state, an ordinary merge that pre-dates it and that this agent did not create. Episode counts, the authority table, the commit tables, the write-budget and action-authorization matrices and the confirmations are reconciled accordingly. The prior process-exception history is preserved unchanged: one authorized push, two unauthorized pushes, their two unauthorized automatic staging-pr-* publications, the CTO's acceptance, no retroactive authorization and no cleanup requirement. Documentation and control only. No runtime, source, test, migration, specification, ADR, CHANGELOG, workflow or contract-map change, and no downstream repository was touched.
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
1 participant
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.
What this is
A specification and control correction, not implementation.
BE-04-SPEC-ADDENDUM-01reconciles three defects a fresh independent reviewfound by measuring the BE-04 implementation candidate against the approved
baseline BE-04 specification. All three are defects in the specification,
so they are corrected in
docs/engineering/ai-delivery/tasks/BE-04.mdratherthan worked around in code.
Two specification states, and neither erases the other
BE-04.mdas merged intodevelopthrough PR #814 — CTO-approved and repository-authoritative. The CTO separately and explicitly authorized BE-04 implementation on that PR againstdevelop @ ed32712766c8f5a1951bb53ec3192e18f067c7d2. Both are preserved as historical authority.PR #816 was created under that authorization and is properly authorized work.
It is blocked because the contract it was built against is being corrected — not
because it was unauthorized. The baseline authorization is insufficient, not
void, for implementation against the corrected contract.
No runtime implementation is authorized by this PR. Nothing under
src/,thoth-api/,thoth-api-server/,thoth-client/,thoth-errors/,migrations/,.github/,Cargo.toml,Cargo.lockorschema.rschanges.PR #816 remains blocked and untouched. Its branch was not modified, rebased,
pushed to or closed; it was read as evidence only. PR #799 is untouched.
Base:
developated32712766c8f5a1951bb53ec3192e18f067c7d2, verified beforeany edit. This branch was created from that exact SHA, not from PR #816.
The three findings
A - the attempt-error
CHECKwas not NULL-safedistribution_job_attempt_error_result_checkwas specified and implemented as(error_code IS NULL AND error_detail IS NULL) OR result = 'FAILED'. PostgreSQLrejects a row only when a
CHECKevaluates toFALSEand admits it when theresult is
UNKNOWN. On an open attempt —finished_at IS NULLand thereforeresult IS NULL— the first arm isFALSEandresult = 'FAILED'isNULL, sothe row is accepted with error fields set.
Reproduced against the full specified constraint set on a disposable
PostgreSQL 17.10: an open attempt carrying
TRANSPORT_FAILUREand a detailstring inserted successfully.
Corrected to the NULL-safe form, with the full three-valued truth table in
section 7.4, the five required rejections and three required acceptances in
section 25.4 (on
INSERTandUPDATE), a matching acceptance criterion, andan evidence obligation for the observed catalog expression and truth-table
results. The state machine is unchanged: the correction turns previously
UNKNOWNrows intoFALSEand changes no row the constraint already decided.B - the exact report statement-count contract was unsatisfiable
Route B is REJECTED. No hard, N-independent constant bound can be proved for
the nested-loader shape. From pinned
dataloader0.18.0,try_loaddispatcheswhatever is pending when the first waiter's yield budget expires and nothing
bounds the number of dispatch opportunities; from Juniper 0.16.2, list items and
selection sets resolve through
FuturesOrderedin one task, so a cohort whosekeys are available at resolver entry coalesces, while a cohort whose keys arrive
only after an upstream loader resolves arrives staggered — the upstream batch
function holds the loader state lock across its database round trip. For such a
cohort the only provable bound is
ceil(N / max_batch_size) <= dispatches <= N,which is linear in N. The candidate's measurements (5/7/11 job-only and 6/8/6
full report at page sizes 1/25/200, unstable between runs) are the symptom, not
the finding. ADR-0007 sections 4.5, 4.6, 10.3 and driver 11 already decline to
guarantee what the specification demanded.
Route A is SELECTED and specified normatively.
latestBackCatalogueJobisbacked by one field-specific, first-level, request-local loader keyed by
publisher_idwhose value is the complete field value, so the whole field is oneloader-first cohort. Exact SQL ownership, per dispatch chunk:
DISTINCT ON (publisher_id) ... WHERE publisher_id = ANY($1) AND kind = 'PUBLISHER_BACK_CATALOGUE' ORDER BY publisher_id, created_at DESC, distribution_job_id DESC... FROM distribution_job_target WHERE distribution_job_id = ANY($2) ORDER BY distribution_job_id, platform... FROM distribution_job_attempt WHERE distribution_job_id = ANY($2) ORDER BY distribution_job_id, attempt_number DESCDeterministic arithmetic, stated per dispatch chunk because L2 and L3 are
skipped for a chunk whose L1 returns no job:
C_job_nonemptyC_job_emptyC_assignC_assignis 0 for the job-only selection, which does not selectenabledDistributionPlatforms. A multi-chunk page is derived from the actualper-chunk classification, never collapsed to a page-global flag.
The correction separates what BE-04 owns from what it consumes. Structural and
provable: two root statements; three statements per composite-loader chunk that
resolves a job, one otherwise; one per assignment-loader chunk; every statement
set-based; exact selection dependence; and zero dispatches of the target and
attempt loaders on the report path — a scheduler-independent assertion. Not
BE-04's property: the dispatch-chunk count, the shared ADR-0007 property whose
bound
ceil(N / 200)and evidence are ADR-0007's own. Section 25.12 measures theper-chunk classification and asserts a derived total.
Loader-dispatch acceptance is stated per loader, not as a blanket rule: each
selected first-level loader has its expected chunk count, each unselected
loader has zero, and the second-level loaders have zero report-path dispatches.
An unexpected
C_job > 1at N ≤ 200 blocks BE-04 (stop condition 23) and must beclassified on evidence as (a) BE-04-specific, (b) a shared-foundation
dependency/runtime regression, or (c) another execution shape. Only (b) escalates
to the owning Shared Thoth GraphQL / Backend Architecture programme, and a genuine
shared finding must be surfaced there rather than worked around locally. No
claim is made about BE-02's loader, or any other field's, without independently
verifying that field — ADR-0007 requires field-specific evidence per field and
establishes no universal sublinear bound.
Not done, each outside this task's authority: no change to ADR-0007's
200/10;no look-ahead-driven load shaping (which would reintroduce the ADR-0006 mechanism
ADR-0007 retired); no request-scoped result store; no merge of unrelated loaders
to make a count fit. The composite loader is not such a merge — targets and
attempts of the latest job are sub-structure of the one value the field returns,
which is ADR-0007 section 4.4's "one reviewed logical field/query family". Its
accepted cost, materializing targets and attempts even when neither is selected,
is stated in the specification and recorded as a known limitation. The two
second-level loaders may be retained only for single-job mutation payloads.
C - the
thoth-clientgatecargo test -p thoth-clientwas mandatory and does not build at the authorizedbase. Verified independently on a branch identical to
develop:20 ×
cannot findgraphqlincrate``, plus unresolvedschema, `db` and`diesel`, each annotated "the item is gated behind the `backend` feature".
Repository evidence: `thoth-client` depends on `thoth-api` without features under
`[dependencies]` and with `features = ["backend"]` under `[build-dependencies]`;
`thoth-api/src/lib.rs` gates `graphql`/`db`/`schema` behind `backend` and
`thoth-api` does not compile with it off; `build.rs` imports
`thoth_api::graphql::create_schema`; and Cargo's v2 feature resolution builds the
normal-dependency copy without `backend` for a single-package build, while a
workspace build unifies it with the root package's `backend` edge.
Resolution: the standalone command is removed as a BE-04 gate and is not
described as passing.
cargo test --workspaceandcargo test --workspace --releaseare required instead, with an explicit obligation to show thatthoth-client's tests executed within each run (an executed count, not agreen summary). Generated-SDL evidence continues through the normal workspace
build path. The standalone failure is recorded as pre-existing repository
packaging/test-mode debt for a separate task, not a BE-04 regression.
No repository control is waived. The repository's own control is the
workspace run:
.github/workflows/build_test_and_check.ymlrunscargo buildand
cargo test --workspace, and requires no single-packagethoth-clientexecution. Had it required one, the correct outcome would have been
BLOCKEDwith the prerequisite repair task named; that branch is preserved as new stop
condition 24.
Tracker
docs/publisher-services/task-status.mdrecords BE-04 asBLOCKED - IMPLEMENTATION CANDIDATE EXISTS - SPECIFICATION ADDENDUM REQUIRED,
with the approved baseline and its implementation authorization recorded as
historical authority and addendum 01 recorded as not yet approved. Nothing is
described as delivered, ready, approved or merge ready. Automatic job creation
remains inactive and nonexistent, no
distribution_jobrelation exists ondevelop, and no production action exists.What remains required
Merging this addendum does not by itself resume BE-04 implementation, and it
neither extends nor withdraws the baseline authorization — which was real, was
bound to
develop @ ed32712766…and to the baseline contract, and isinsufficient for the corrected contract because both the requirements and the
base have moved. Still required, in order:
develop;develophead;developand the correctedrequirements.
Verification
git diff --checkclean; 89 relative Markdown links resolved, 0 broken; everystated statement-count example evaluated mechanically against the formula (5, 6,
3, 4 and the multi-chunk worked example, all consistent); consistency search
performed over
error_result_check,result = 'FAILED', "error fields on anon-FAILED", "five statements", "six statements",
C_job = C_assign(0),(3 if J else 1)(0),C_job_nonempty/C_job_empty, "every loader",200,"yield", "upstream loader", "equally", "same deviation",
BE-02,cargo test -p thoth-client, "specification remains unapproved" (0), "nospecification is approved" (0), "specification candidate", "approved
specification", "PR #814",
5296197259(0 — the authorization is referencedthrough the pull request, not by comment identifier, per ADR-0005 section 5),
"READY" and "BLOCKED". No normative sentence claims a property PR #816 disproves,
and every remaining approval statement distinguishes the approved baseline from
the unapproved addendum.
Full evidence:
docs/engineering/ai-delivery/implementation-reports/BE-04-SPEC-ADDENDUM-01-implementation-report.md.Remediation round (second review pass)
Three findings were raised against this addendum's first revision and are
corrected in this same PR, without reopening the three substantive addendum
decisions:
(3 if J else 1)formmispriced a mixed multi-chunk page, and
C_job = C_assign = 1wasself-contradictory for the job-only selection. Replaced by the per-chunk
formula above, with the 5 / 6 / 3 / 4 cases and a multi-chunk worked example,
and with per-loader dispatch acceptance replacing "every loader dispatches
once".
never had an approved specification. Corrected to APPROVED BASELINE /
ADDENDUM 01 NOT YET APPROVED, with PR docs(publisher-services): specify BE-04 durable distribution jobs #814's approval and the implementation
authorization preserved as historical authority.
evidence-classified escalation rule that still requires a genuine shared
finding to be surfaced to the owning programme.
Full detail is in section 5.5 of the implementation report.