S7: delete both consumer source-reads — the category is wrong, proven twice in 24h #248

Re-scoped 2026-08-12. The first draft asked "close it or own it" and leaned toward restoring the source read. An expert review and a second live breakage settled it: the category is wrong, and this story is a deletion.

Part of #241, Gate 1 — blocks PR #240. Registers C-92, C-94; sharpens C-87.

The evidence, which is now conclusive

Two repositories, the same refactor, 24 hours apart, both times because their code got better. The regex was measuring their code quality and reporting it as our failure. ADR-017 §7 already said we were never entitled to depend on another repository's file layout; this is that prediction landing twice.

There is no version of this check that survives. A repo that renames a constant, extracts a helper, or moves a file breaks it — and every one of those is an improvement we would be penalising.

Work

1. Delete test_the_consumer_still_filters_on_the_name_until_it_checks_itself and _CONSUMER_FILTER, _CONSUMER_PATH_MANAGER, _CONSUMER_SELF_CHECK_PENDING — both partners, the whole mechanism.
2. Drop the views-crafdapi sibling checkout from .github/workflows/run_pytest.yml and from SIBLINGS, if that check was its only consumer — measure, do not assume. Update the note, which currently states a retirement condition contradicting ADR-017 §5.
3. Register the gap honestly (C-92) with an owner and a trigger. Do not pretend the consumer-side checks cover it — they do not:

4. File one issue each on views-faoapi and views-crafdapi: their registry-binding check binds a constant; ask them to bind the query to that constant. Note for views-faoapi that prediction/manager.py:117 applies the name filter conditionally (if hasattr(...) and model_name), so a falsy name drops it silently. This is a condition of being a consumer, statable in the contract, and it works for a third-party consumer too.

What is deferred, and why it is the right deferral

The expert review's answer is a producer-side read-only findability preflight: after upload, query the store read-only for a document whose name equals the declared label, assert non-empty, log and raise. It is legal — the registry's [test_environment] table says "read-only preflight validation is the only permitted live check" — the APPWRITE_READ_API_KEY slot already exists, and it is the only mechanism that survives a third-party private consumer, because it asks nothing of them.

It is still deferred, and honestly so. It needs a read credential wired into the launcher, which is an operator action and not a code change; it adds a live network call to the delivery path; and delivery works today. Building it now would be building the right thing at the wrong time.

Registered as C-94. Trigger: a delivery is reported empty, or APPWRITE_READ_API_KEY is provisioned for the launcher. Owner: this repository.

Acceptance criteria

• No test in this repository parses another repository's source. Verified by grep.
• The suite is green on development — including the currently-red crafd case, green by deletion of the wrong check, not by weakening an assertion.
• SIBLINGS and the workflow agree, and no note states a retirement condition that contradicts an ADR.
• Issues filed on views-faoapi and views-crafdapi, each with file:line evidence.
• C-92 records the gap, the table above, and C-94's trigger.
• wc -l tests/test_product.py is lower.

Note on sequencing

The crafd test is red now. Do not xfail it to buy time — land this story. It is a deletion; it is faster than the workaround.

Labels

story, implementation, documentation