Skip to content

fix(product): the upload interlock named a gate that no longer gates - #301

Merged
Polichinel merged 1 commit into
developmentfrom
fix/297-gate-docstrings-name-a-satisfied-gate
Aug 26, 2026
Merged

fix(product): the upload interlock named a gate that no longer gates#301
Polichinel merged 1 commit into
developmentfrom
fix/297-gate-docstrings-name-a-satisfied-gate

Conversation

@Polichinel

Copy link
Copy Markdown
Collaborator

Story 1 of the sprint closing the 2026-08-26 /falsify findings.

The finding

product.py is the single source of truth for the §11.4 upload interlock. Each partner named a precondition on first live enablement. Both were already satisfied:

product said it waits for actually satisfied
unfao faoapi's C-161 closure notice 2026-07-20; residual shipped faoapi v1.5.4, 2026-08-21
crafd views-crafdapi selection guard in production 2026-08-12, views-crafdapi#53

Neither named the gate that holds — views-appwrite#171, without which the upload path cannot be rehearsed against a real store (#18).

A reader asking why does nothing upload? got a wrong answer in both partners, pointing at two different innocent repositories. That is how views-faoapi spent a month believing the hold was theirs (#294).

Stub disposal, in the same change

On length

My first draft blew the 700-line partner budget test_doc_accuracy enforces. The budget was right; the prose wasn't. What didn't fit is in the commit message and will go on #294.

Noted, not fixed: crafd/ is now at 699/700. The budget exists to notice that, and the next line added there fails. Out of scope for this PR.

Verification

507 passed, 3 skipped, 40 xfailed. test_falsification_release_readiness: 3 xfailed (S1, S3, S4), no XPASS. ruff clean.

🤖 Generated with Claude Code

Both products documented a precondition on first live enablement, and both
had been satisfied:

  unfao  "faoapi's C-161 closure notice"          met 2026-07-20; the residual
                                                  it left open shipped in faoapi
                                                  v1.5.4 on 2026-08-21
  crafd  "the views-crafdapi selection guard      met 2026-08-12, views-crafdapi#53;
          deployed in production"                 their production serves real data

Neither named the gate that actually holds: views-appwrite#171, the
non-production Appwrite decision, without which the upload path cannot be
rehearsed against a real store at all (#18).

This is not cosmetic staleness. product.py is the single source of truth for
this switch, so a reader asking why nothing uploads got a wrong answer — in
both partners, pointing at two different innocent repositories. It is the
mechanism by which views-faoapi spent a month believing the hold was on their
side before asking (#294, 2026-08-22).

Found by /falsify, 2026-08-26. Its two stubs are disposed of in the same
change rather than carried:

  S5  DISCHARGED — this fix is what it asked for.
  S6  WITHDRAWN — it asserted the correction-procedure banner disappears, which
      cannot happen until FAO answers Note 07 Decision B.1. A test that can only
      go green on an external party's reply is decoration (C-102), and #292
      tracks the item better. Withdrawing it also corrects the audit: the nine
      mislabelled cells WERE disclosed to FAO as Note 07 Topic G on 2026-08-21,
      and the audit reported that disclosure as missing.

Kept short deliberately. The first draft ran to twenty lines and put
views-postprocessing/{unfao,crafd} over the 700-line partner budget that
test_doc_accuracy enforces. The budget was right and the prose was not; the
reasoning that did not fit lives in this message and on #294.

Noted, not fixed: crafd/ now sits at 699/700. The budget exists to notice
exactly that, and the next line added there will fail. Out of scope here.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@Polichinel
Polichinel merged commit 766c9f4 into development Aug 26, 2026
4 checks passed
@Polichinel
Polichinel deleted the fix/297-gate-docstrings-name-a-satisfied-gate branch August 26, 2026 13:18
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