llm-ingestion-okf/docs/2026-09-11-r4-release-v082.md

R4: release v0.8.2

A patch release and nothing else. It carries three things a consumer on a tag did not have: okf check's sixteenth rule (bundle_mismatch, K3-15), the --title-covered stop beneath a title that answers more of the question (K3-17), and the regenerated skills/okf-consume/ (K3-18). The reason is measured: a consumer measured 15 rules on the 0.8.1 okf on its PATH, because rule 16 was on main and in no tag. No new command or flag, no behaviour change in src/ beyond the version string, no push.

Tag: v0.8.2, local and annotated, on b6c54e9 (chore(release): 0.8.2). v0.8.1 stays on 3daf983 and v0.8.0 on 4d1f9d3 -- verified with git tag --points-at, both still resolve there.

1 What this round did, and what it did not

Did: the version on all THREE lines it lives on (pyproject.toml, src/llm_ingestion_okf/__init__.py, and the package's entry in uv.lock), the [Unreleased] entries K3-15, K3-17 and K3-18 wrote closed as [0.8.2] without an edit, five install lines to @v0.8.2, the tag-history list given a v0.8.2 row and v0.8.1 demoted, two prose lines on the guard pairing and one test-count sentence with its history corrected where the tag would otherwise make them false, one commit, four gates, one tag.

Did not: no extractor, no arm, no flag moved. --pdf-outline and --bold-title stay OFF and --title-covered stays ON exactly as rounds 16 and 17 shipped it -- a release does not re-verify a default. No new dependency, [extract] untouched, skills/okf-consume-template/ untouched, skills/okf-consume/ not regenerated again, docs/ history not rewritten, nothing pushed.

2 Premises, re-measured before building on them

premise	re-measured
K3-18 landed as two commits	07df6a0 (chore(lock)) and 6858ff2 (regeneration), both in f5a002e..HEAD; HEAD 6858ff2, tree clean
git ls-remote origin refs/heads/main	7cca9e0
remote tags v0.8*	v0.8.0 -> 4d1f9d3 and v0.8.1 -> 3daf983, both already pushed
uv.lock for this package	0.8.1 before the bump
install lines: README 4, llms.txt 1	confirmed; the last README one had moved from line 519 to 524
grep -rn 'v0\.7\.0|0\.7\.0' README.md docs llms.txt CLAUDE.md	32 lines over 9 files, not 30 over 8 -- the two extra are the round 17 and 18 journals; README still exactly one (the v0.7.0 history row), llms.txt and CLAUDE.md 0
[Unreleased] content	five entries, not three: Added 1, Changed 2, Fixed 3 (K3-18 added two under Fixed) -- all five moved unedited
ruff	0.16.6
okf --version	still not a flag; version read with importlib.metadata

3 The lockfile, which the previous two releases missed

pyproject.toml and __init__.py were bumped first, then uv lock was run and its diff measured: exactly one line, version = "0.8.1" -> "0.8.2" under name = "llm-ingestion-okf". No other package moved, so the file was kept as uv lock wrote it. In the export of the tag, uv lock --check exits 0.

One sentence in the moved changelog now reads narrowly: the Fixed entry says "uv.lock records this package at 0.8.1". It describes K3-18's fix and was true of that commit; the released lock records 0.8.2. It was left as written, because the entries are the rounds' own and are not rewritten by a release.

4 The four gates, after git add and after commit

ruff 0.16.6. ruff check src tests tools -- All checks passed. ruff format --check . -- 120 files already formatted. mypy src -- no issues in 21 source files. pytest -q -- 1602 passed, 1 skipped, 1603 collected, the figure the README now publishes, re-measured on the release commit.

5 The acceptance gate: installation FROM THE TAG

No uv tool install, no uv tool uninstall, no --force. The operator's okf on PATH was located and not touched; everything ran from the export's own venv (CPython 3.11.14).

git archive v0.8.2 | tar -x -C <scratch>/r4-install/export
cd <export> && uv sync --frozen --extra extract

row	measured
version from the tag's bytes	0.8.2 (importlib.metadata)
uv lock --check in the export	rc 0
len(contract_check.RULES)	16, rule 4 rule_bundle_identity
okf check on skills/okf-consume/ and its payload	conformant: 16 rules over 3 excerpts and 0 withheld entries, 0 findings, rc 0
okf project on the five-document folder	26 concepts of 5 documents, 52 md, 0 of 5 left out
HTML corpus	proposed 828 plan(s); 0 document(s) with no boundary; 0 unreadable, 3 206 concepts / 6 015 md
R761 XML	2 761 concepts at shipped defaults, no arm flag; the folder holds 1 file at top level and 110 in total, and 109 are images under graphics/ (43 png, 41 jpg, 25 bmp), coded unreadable
hit@1 / 8 / 50 on the R761 bundle	6/6 / 6/6 / 6/6, N = 6 scored of 8 asked, known-positive at rank 1
round 17's known-negative on the five-document bundle	the section the question names at rank 1 (6 793 B), the neighbour at rank 2 (10 590 B); both concepts exist and both are delivered of 8

The suite was not run inside the export this round; R3 and K3-18 did, with the known export artefact as the one failure.

6 Honesty limits

• One machine, one interpreter. The installation is measured on one Intel Mac with the interpreter uv resolved in the export. It is not a portability claim, and the channel is a local export, not the Forgejo tag, which does not exist until the push.
• okf project's 26 is ONE corpus of five documents -- the same five every previous round used, so it is a regression control, not a sample.
• 828 of 828 and 2 761 of 2 761 are ONE publisher's files from ONE product. They say the reader lost nothing against its own denominator; they say nothing about documents nobody in that pipeline wrote.
• hit@1 is 6 scored questions on ONE bundle, against a fasit someone else set. It is re-measured from the tag's bytes, which is all it adds.
• The known-negative is ONE constructed question on ONE small bundle. Rank 1 says the K3-17 stop is in the tag; it says nothing about how often the shape it repairs occurs.
• The grep criterion is deliberately NOT "0 hits on v0.8.1". Three bare occurrences remain and must: the v0.8.2 history row naming what v0.8.1 lacks, the v0.8.1 history row itself, and the test-count history. The zero on okf.git@v0.8.1 ran beside a known-positive (okf.git@v0.8.2 = 5), so it is a measurement and not a query that could never match.
• "The tag installs" is not "the tag is correct". No functionality is verified here beyond what K3-15, K3-17 and K3-18 already measured; the rows above prove the exported bytes run and reproduce the counts the repository already published.