# 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 `` 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 /r5-install/export cd && 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 `` on ONE document.** It says the tag carries K3-19's directory naming; it says nothing about how other publishers fill ``. - **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.