release: 1.3.0 to main - #309
Merged
Merged
Conversation
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>
…ame-a-satisfied-gate fix(product): the upload interlock named a gate that no longer gates
…o contract /review-base-docs found the mechanical layer healthy — validate_docs.sh passes, every doc a test can reach is accurate — and the human layer stale in exactly the places nothing reads. Five findings, four fixed here. **The CRAF'd manager had an intent contract in no form at all.** No CIC file and no class docstring, while its line-for-line twin has a 189-line contract. ADR-006 mandates one for orchestration and state-owning classes; the CIC README names both categories. The partner package was cloned and the contract was not. It is written as a DELTA, deliberately. Two 189-line documents describing one behaviour is not redundancy, it is two things that can disagree — which is C-75 verbatim, where this directory's files asserted opposite things about the same call for weeks. The new file states purpose, what it inherits, and a table of what differs. If the managers ever diverge behaviourally, C-33's extraction trigger has fired and the form should be revisited with the code. Registering it in _CIC_SUBJECT made the collaborator guard fire immediately: the document named the sibling CLASS in backticks, which crafd.py never references. The guard was right and the backticks were wrong — a markdown link to a sibling DOCUMENT is not a claim that the class reaches for a collaborator. Fixed by saying what was meant, not by exempting the file. **Both orientation documents omitted delivery/findability.py**, which shipped 2026-08-18. README and role_and_seams.md — the two files a new contributor opens first — both last touched 2026-08-04. Now listed in both, and a new guard asserts delivery/ stays complete in both. Mutation-proven: deleting the line reddens it. Scoped to delivery/ because it is the one directory both docs enumerate exhaustively; firing on the README's deliberate contract/wire/ abbreviation would be crying wolf (ADR-014 §3). **The sibling CIC was four days stale** — reviewed 2026-08-21, class changed 2026-08-25. It covered findability and TornRunError but not observed_through, the #297 boundary stamp. That gap was mine. Recorded, review date moved. **CLONING.md's "sixteen lines differ" is now fourteen** — the third time that number went stale, in the paragraph that warns it will. Removed rather than corrected; the diff command beside it is the source of truth and a number next to it is a liability. Two audit findings NOT fixed, and one of them was my error: - **ADR-004 does have trigger conditions.** The audit reported none; it has five. What it does not have is an owner. Reading them produced a better finding: at least three have FIRED — downstream systems depend on this repo, breaking changes now incur real coordination cost (views-models#403 took eight days; #439 is open), and ADR-013 §10 pins bytes across time. Recorded on the ADR with evidence. Writing the successor is an architectural decision, not a docs fix. - **pyproject's python range stays wrong.** Narrowing >=3.11,<3.15 to <3.12 is one line and correct, but it invalidates poetry.lock and forces a full re-resolve that would move pyarrow off the 16.1.0 the ADR-013 §10 fixtures pin (C-72). Attempted, measured, reverted. #295 owns it; the README now states the truth, which was the safe half. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…ocs-and-the-crafd-contract docs: the orientation documents froze on 2026-08-04, and CRAF'd had no contract
…in 48 hours Two updates to the inbound-visibility entry, both measured. The pin half: views-models moved both launchers 1.1.0 -> 1.1.1 on 2026-08-24, closing views-models#403 and the C-99 exposure this entry was written about. 1.2.0 published two days later and both launchers are behind again; views-models#439 asks for the same move a second time. The eight-day lag was not an incident, it is the steady state. Nothing about the first fix made the second lag less likely. The issue half: all 66 open issues org-wide naming this repository were read and triaged (down from 84 on 2026-08-21). Run because a /falsify audit had sampled eight and stated the limit rather than claiming the sweep was clean. Nothing is blocked by this repository that was not already known. The live asks are ours-to-them, not the reverse, and the commitment made on views-crafdapi#55 was honoured — the source-scraping check was replaced by one that reads the public registry. What the sweep found that no mechanism would have: #123 and views-datafactory#341 are the same decision, filed from both sides on 2026-07-20, owned by nobody for 37 days. Not a block — a block has an owner and a queue position. Recorded on #123. That argues for repeating the sweep rather than mechanising it, which is the opposite of what this entry previously implied. Still no mechanism proposed; the C-86 trade is unchanged. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…and-closeout docs(register): C-112 — the sweep was done, and the pin gap recurred in 48 hours
…oday (#286) views-pipeline-core 3.3.0 reached PyPI on 2026-09-19 with views-frames ">=1.10.2,<3.0.0" (their #488). Every earlier release pinned <2.0.0, which made `poetry lock` refuse this move outright; our own <2 pin was the last thing in the way. pyproject: views-frames ">=1.10.2,<2" -> ">=2.0.0,<3". The re-lock moved six packages and nothing else: views-frames 1.10.2 -> 2.0.0 the goal views-pipeline-core 3.0.1 -> 3.3.0 our range already allowed it views-evaluation 1.0.0 -> 2.0.0 pulled by pipeline-core 3.3.0 stepshift, views-transformation-library, xarray — transitive pyarrow 16.1.0 -> 16.1.0 UNMOVED: the ADR-013 §10 byte-parity fixtures are pinned to it (C-72) levenshtein 0.20.9 -> 0.20.9 UNMOVED: the cp311-only ceiling (C-104) Pre-flight was done on 2026-08-18 and holds: no in-place `.values` mutation (the one migration row that can break working code), no CONFORMANCE_FLOOR assertion, no call to assert_summarizer_contract. The byte question was measured on 2026-08-21: shards emitted through views_frames.io.arrow hash identically under 1.10.2 and 2.0.0 at the pinned toolchain, equal to the committed fixture. This is a re-lock, not a fixture re-vendor. Also picks up views-frames 1.11.0's fix to the MAP-containment law, which was wrong on tied draws — ~6% of rows on zero-inflated count posteriors, this platform's primary data shape (their C-88). This repo volunteered to take that first. views-evaluation 2.0.0's [frames] extra still caps views-frames <2 (views-evaluation#91). Not in our resolve: pipeline-core 3.3.0 requests views-evaluation without that extra, and this repo does not depend on views-evaluation or views-reporting directly. Checked against the lock. Verified in CI, not locally: the developer machine holds no interpreter that can install this lockfile (C-104), so the 3.11 CI job is the first execution of the locked environment. That is why this is a PR and not a push. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ANY1CCy9Xo7zjMY4XJ69v9
…mes-2 chore(deps): adopt views-frames 2.0.0 — the upstream blocker lifted today (#286)
…not the historical file Entry authored 2026-09-14 in another session and left uncommitted in the working tree for five days. Committed as written, plus the one `---` fence the integrity guard required between it and C-112. Tier 3: nothing silent, nothing corrupt — the numbers and join keys are right. The cost lands on an FAO engineer joining the forecast and historical files and finding their value columns named differently, and on the release note that committed to one naming for both. Register 112 -> 113 concerns, 31 -> 32 open. Integrity suite green. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ANY1CCy9Xo7zjMY4XJ69v9
…er-rename docs(register): C-242 — the consumer rename reached the forecast and not the historical file
…changed Bumps 1.2.0 -> 1.3.0. MINOR: two dependencies cross a major version and a statistics fix on tied draws comes in; no new failure modes, no behaviour change to the delivery, delivered bytes identical. The changelog entry leads with "no new failure modes" because that is the sentence a launcher needs — 1.2.0's entry led with three, and a consumer reading the next one should learn in one line that this is not that. Why this release exists now rather than later: the launcher in views-models installs from a git TAG (tools/launcher/postprocessor.sh:57), not from PyPI and not from poetry.lock. Everything merged since 1.1.1 is invisible to a server until a tag exists that a pin can name. 1.2.0 exists but was never pinned; this tag is what views-models#439 will ask for instead. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ANY1CCy9Xo7zjMY4XJ69v9
release: 1.3.0 — views-frames 2.0.0 and pipeline-core 3.3.0, bytes unchanged
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.
Promotes
developmenttomainfor 1.3.0.Since 1.2.0: views-frames 2.0.0 and pipeline-core 3.3.0 (bytes unchanged, CI-proven), the tied-draws fix, corrected
UPLOAD_ENABLEDdocstrings in both products, the CRAF'd intent contract, refreshed orientation docs with a guard, andCHANGELOG.mdcarrying all of it.No new failure modes. The interlock is unchanged and closed.
Cutting this tag is what lets views-models pin current code — the launcher installs from the tag, not PyPI.
🤖 Generated with Claude Code
https://claude.ai/code/session_01ANY1CCy9Xo7zjMY4XJ69v9