Skip to content

fix(delivery): C-77 — name the historical document from the declaration, not a directory - #218

Merged
Polichinel merged 1 commit into
developmentfrom
fix/c77-historical-consumer-name
Aug 4, 2026
Merged

fix(delivery): C-77 — name the historical document from the declaration, not a directory#218
Polichinel merged 1 commit into
developmentfrom
fix/c77-historical-consumer-name

Conversation

@Polichinel

Copy link
Copy Markdown
Collaborator

B1 of the sequenced plan, taken first because views-models#333 is being written this week.

The defect

Both partners' historical upload named its store document from self._model_path.model_name — the views-models postprocessor directory name, a fact in another repository's filesystem. The forecast leg used the declared product.CONSUMER_DOCUMENT_NAME.

The two legs upload separately and views-faoapi/views-crafdapi select them separately — forecasts by the newest manifest, historical actuals by category="historical" — and both filter on the document name. Disagreement means the delivery half-arrives, and the failure mode is an empty endpoint, not an error. That is ADR-013 §4.1a's exact shape, the one that left six orange_ensemble documents stranded in unfao_bucket for months.

Why now, and why it is safe

Delivery-neutral, verified before touching anything. CONSUMER_DOCUMENT_NAME is "un_fao" and the views-models directory is un_fao, so model_name already resolved to the same string. No delivered byte changes. What changes is that the agreement is a declaration rather than a coincidence.

It was about to be sprung. views-models#333 creates CRAF'd's launcher directory. Whoever named it would have decided, without knowing it, whether CRAF'd's historical artifact was retrievable. I posted that constraint on the issue on 2026-08-04; this removes the need for anyone to honour it.

The guard

test_both_delivery_legs_name_the_document_from_the_declaration asserts exactly one forecast leg and one historical leg per partner. Mutation-proven three ways: revert one leg, add a third, stop declaring on the forecast leg.

Its first draft counted with a plain substring and reported three legs where there are two — consumer_name=product... contains name=product.... The lookbehind is deliberate and the comment says so.

Verification

372 passed / 40 xfailed / 0 failed
ruff check .  ->  All checks passed!

Register 83 / 16 open / 67 resolved. The two managers remain in lockstep (normalised diff unchanged at 2 lines, the one known prose divergence).

One residual, unchanged: the guard is a source scan, because the managers cannot be instantiated without Appwrite env and a views-models path manager. That is this repo's standing pattern and the reason #18 exists.

…on, not a directory

Both partners' historical upload passed `name=self._model_path.model_name`. That value
comes from the views-models postprocessor DIRECTORY name — a fact in another
repository's filesystem. The forecast leg passes the declared
`product.CONSUMER_DOCUMENT_NAME`.

The two legs upload separately and the consumer selects them separately: forecasts by
the newest manifest, historical actuals by category="historical". Both filter on the
document name. So if the legs disagree the delivery half-arrives, and the failure mode
is an empty endpoint rather than an error -- ADR-013 s4.1a's exact shape, the one that
left six orange_ensemble documents stranded in unfao_bucket for months.

Delivery-neutral, verified before changing anything: CONSUMER_DOCUMENT_NAME is "un_fao"
and the views-models directory is un_fao, so model_name resolved to the same string. No
delivered byte changes. What changes is that the agreement is a declaration rather than
a coincidence.

Fixed now rather than when it broke, because it was about to be sprung. views-models#333
creates CRAF'd's launcher directory this week, and whoever named it would have decided
-- without knowing it -- whether CRAF'd's historical artifact was retrievable. The
constraint was posted on that issue on 2026-08-04; this removes the need for anyone to
honour it.

Guard: test_both_delivery_legs_name_the_document_from_the_declaration asserts exactly
one forecast leg and one historical leg per partner. Mutation-proven three ways --
revert one leg, add a third, stop declaring on the forecast leg. Its first draft counted
with a plain substring and reported three legs where there are two, because
`consumer_name=product...` contains `name=product...`; the lookbehind is deliberate.

372 passed / 40 xfailed / 0 failed. ruff clean. Register 83/16/67.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@Polichinel
Polichinel merged commit 2c57bd6 into development Aug 4, 2026
4 checks passed
@Polichinel
Polichinel deleted the fix/c77-historical-consumer-name branch August 4, 2026 01:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant