llm-ingestion-okf/docs/2026-09-11-r5-release-v083.md

R5: release v0.8.3

A patch release and nothing else. It carries what rounds 19 and 20 landed and no tag had: a NISO-STS document's own <doc-number> naming its directory and titling its sources entry, okf build --frontmatter KEY=VALUE, description from an STS section's first spec point (K3-19), and the okf consume fix that keeps a leading directory every concept id shares out of the first fusion signal, with okf build --shell-parent shipped off (K3-20). The reason the two are tagged together is measured: K3-19 alone took the known-positive from rank 1 to not delivered at the default k (13 at k = 50), and K3-20 A is what put it back at rank 1. No behaviour change in src/ beyond the version string, no push.

Tag: v0.8.3, local and annotated, on 0963dfa (chore(release): 0.8.3). v0.8.2 stays on b6c54e9, v0.8.1 on 3daf983 and v0.8.0 on 4d1f9d3 -- verified with git tag --points-at, all three 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] block closed as [0.8.3] — 2026-09-11 with its five entries and its closing --ingested-at paragraph moved unedited, five install lines to @v0.8.3, the tag-history list given a v0.8.3 row and v0.8.2 demoted, two prose lines on the guard pairing and the test count with its history corrected where the tag would otherwise make them false, one commit, four gates, one tag.

The block carries two ### Added headings (Added, Fixed, Changed, Added). Both were kept. One Added section would have meant moving an entry body across the Fixed and Changed entries, and the entries are the rounds' own, in the order the rounds wrote them.

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

2 Premises, re-measured before building on them

premise	re-measured
HEAD at dispatch	4595dde, 0 commits over it, tree clean
git ls-remote origin refs/heads/main	7cca9e0
remote tags v0.8*	v0.8.0 -> 4d1f9d3 and v0.8.1 -> 3daf983 only; v0.8.2 is not pushed
uv.lock for this package	0.8.2 before the bump
install lines: README 4, llms.txt 1	confirmed, README at lines 12, 62, 77 and 552
grep -rn 'v0\.7\.0|0\.7\.0' README.md docs llms.txt CLAUDE.md	33 lines over 10 files, not 32 over 9; README still exactly one (the v0.7.0 history row), llms.txt and CLAUDE.md 0
[Unreleased] content	five entries over four headings, as the order said
guard source in [tool.uv.sources]	still tag v1.3.0, dependency still >=1.2,<2.0
ruff	0.16.6
coordination inbox / order queue	0 messages; this order the only pending one

3 The lockfile

pyproject.toml and __init__.py were bumped first, then uv lock was run and its diff measured: exactly one line, version = "0.8.2" -> "0.8.3" 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.

4 README lines the tag would otherwise make false

• The two guard-pairing lines name v0.8.3 instead of v0.8.2 and nothing else, because the tag's [tool.uv.sources] still points at guard v1.3.0.
• The test count is 1668 collected, 1667 passed, 1 skipped. The sentence saying that the figure published before the v0.8.2 release was the passed count stays: it is still true of the past, and it still explains why two numbers are given. The history parenthesis gains "at 1658 after K3-19, and at 1667 after K3-20 and through the v0.8.3 release"; changing only the last figure would have made the previous published one false.
• grep -rn 'okf\.git@v0\.8\.2' README.md llms.txt returns nothing (exit 1), run beside the known-positive okf\.git@v0\.8\.3 = README 4 + llms.txt 1. A bare v0.8.2 remains three times, all intentional: the v0.8.2 history row, the test-count sentence, and the count history. grep -rln 'v0\.7\.0' docs/ is 6 before and after.

5 The four gates, after git add and after commit

ruff 0.16.6. ruff check src tests tools -- All checks passed. ruff format --check . -- 125 files already formatted. mypy src -- no issues in 21 source files, rc 0 (the first run's rc was read through a pipe and did not count, so it was re-run with rc taken directly). pytest -q -- 1667 passed, 1 skipped, 1668 collected, re-measured on the release commit. The skip is OKF_HTML_CORPUS unset. tests/test_default_bundle_pin.py alone: 7 passed of 7, in the working tree against the pinned artifact on this machine -- not in the export.

6 The acceptance gate: installation FROM THE TAG

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

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

row	measured
version from the tag's bytes	0.8.3 (importlib.metadata)
uv lock --check in the export	rc 0
len(contract_check.RULES)	16
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, 109 of them images under graphics/ (43 png, 41 jpg, 25 bmp), coded unreadable
R761 document directory (new this round)	r761-prosesskoden/, not the delivery file's UUID stem; denominator 1 document
hit@1 / 8 / 50 on the R761 bundle	6/6 / 6/6 / 6/6 at the default k and at k = 50, N = 6 scored of 8 asked
the known-positive (new this round)	rank 1 at the default k and rank 1 at k = 50, denominator 1
--shell-parent (new this round)	675 of 710 heading-only concepts carry parent:; 0 of 2 761 without the flag, and 0 non-heading-only concepts with it; --shell-parent and --no-shell-parent both in okf build --help
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

"Heading-only" was counted as a concept whose body, after the frontmatter, is at most one non-blank line and that line a heading: 710 on both bundles.

The hit@k instrument lives in the consumer's repository and was only read. It writes its payloads to fixed paths another session also writes, so it ran as a scratch copy that differs from the original in exactly those two output paths (diff: 2 lines).

The suite was not run inside the export this round.

7 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.
• r761-prosesskoden is ONE publisher's <doc-number> on ONE document. It says the tag carries K3-19's directory naming; it says nothing about how other publishers fill <std-ident>.
• 675 of 710 are shells in ONE document, and okf consume does not read parent yet. The row measures that the key is written, not that it helps any reader.
• hit@1 and the known-positive rank are 6 scored questions and ONE known-positive on ONE bundle, against a fasit someone else set. They are re-measured from the tag's bytes, which is all they add.
• The known-negative is ONE constructed question on ONE small bundle.
• The grep criterion is deliberately NOT "0 hits on v0.8.2". Three bare occurrences remain and must. The zero on okf.git@v0.8.2 ran beside a known-positive, 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-19 and K3-20 already measured; the rows above prove the exported bytes run and reproduce the counts the repository already published.