docs(release): R1, v0.8.0 tagged locally and installed from the tag

The release itself is `4d1f9d3` and the tag stays there; this is the record.

Three deviations are named rather than glossed. The commissioning acceptance
`grep -rn 'v0.7.0' = 0 outside CHANGELOG` cannot be met, because three files
under `docs/` name the old tag as a fact about the past and a report is made
false by being rewritten. It also contradicts the same order's instruction to
keep the `v0.7.0` row in README's tag history, so the criterion was narrowed to
what it protected -- no install line and no "current tag" claim on the old tag
-- and every grep here was run against a known-positive first. Third, the
version also lives without a `v` prefix in `src/`, where no search for `v0.7.0`
reaches it; a packaging test caught it, and left alone the tag would have
reported 0.7.0 to every consumer installing it.

The gate was installation FROM THE TAG, not from the worktree: 26 concepts /
52 md / 0 of 5 rejected on the five-document folder, `proposed 828 plan(s);
0 document(s) with no boundary` on the 828-file HTML corpus, and `conformant:
15 rules ... 0 findings`. The limits travel with them -- one machine, one
interpreter, one corpus per row, and "the tag installs" is not "the tag is
right".

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Kjell Tore Guttormsen 2026-09-10 21:14:19 +02:00
commit 02f9876e16

View file

@ -0,0 +1,159 @@
# R1: release v0.8.0
**Date:** 2026-09-10
**Release commit:** `4d1f9d3` · **Tag:** `v0.8.0`, local and annotated, UNPUSHED
**Predecessor:** `v0.7.0` on `1260fac`, untouched
## 1 What this round did, and what it did not
It set a version number, closed the CHANGELOG entry rounds 13 and 14 had
written, pointed every install line at the new tag, corrected README's test
count, and put a local annotated tag on the release commit. No `src/` behaviour
changed, no extractor or arm was added, no flag default moved, `uv.lock` and the
`[extract]` extra are untouched, and nothing was pushed.
The functionality the tag carries was measured in the two rounds before it: the
`.xml` core file type read as NISO-STS and the PDF arm's collision counter
(round 13), and the declared-structure route taking `.xml` from 15 of 2 761 to
**2 761 of 2 761** boundaries and from 23 to **2 761** concepts at the shipped
defaults, hit@1/8/50 from 0/6 · 0/6 · 0/6 to **3/6 · 5/6 · 6/6** (round 14).
Nothing in this round re-measures any of that.
## 2 Premises, re-measured before building on them
Every figure the order carried was reproduced on this machine before any file
was edited. Two came out differently than the order's own body text.
| premise | order said | measured here |
|---|---|---|
| `git rev-parse HEAD` | `078b7df` | `078b7df` |
| `git ls-remote origin refs/heads/main` | `9d5ebc3` in the body, `078b7df` in the 21:01 update | **`078b7df`** — 0 unpushed commits at start |
| `git status --short` | empty | empty |
| `git tag --points-at 1260fac` | `v0.7.0` | `v0.7.0` |
| `git tag --points-at HEAD` | empty | empty |
| `pyproject.toml:7` | `version = "0.7.0"` | same |
| `v0.7.0` in README/llms.txt | 8 occurrences, named lines | 8, all on the stated lines |
| `v0.7.0` files under `docs/` | 3 | 3 |
| suite, worktree | 1 575 passed + 1 skipped, 95.01 s | **1 575 passed, 1 skipped, 90.41 s** |
| `ruff --version` | 0.16.6 | 0.16.6 |
| `ruff check .` / `format --check .` | clean / 117 files | clean / 117 files |
| `mypy src` | 21 source files | 21 source files |
The push list therefore starts at zero commits behind, not three. It does not
start empty: the release commit and the tag are both unpushed by construction.
## 3 Three deviations, stated before the work rather than after
**D1 — the order's own, carried forward.** The commissioning STATE named the
acceptance criterion `grep -rn 'v0\.7\.0'` = 0 outside CHANGELOG. That cannot be
met and should not be: three files under `docs/` name `v0.7.0` as a fact about
the past, and a report saying what was measured on `v0.7.0` becomes false by
being rewritten. Measured: 3 such files, unchanged by this round.
**D2 — mine, found when the criterion was run.** The order also says (3c) to
keep the `v0.7.0` row in README's tag-history list. Those two instructions
contradict each other: keeping the row means the grep cannot reach 0. The list
states of itself that "These are not install lines. They record what each
earlier tag was", so the row was kept and the criterion was narrowed to what it
was actually protecting — that no INSTALL line and no "current tag" claim points
at the old tag:
```
$ grep -rn 'okf\.git@v0\.7\.0' README.md llms.txt # 0 hits, exit 1
$ grep -rc 'okf\.git@v0\.8\.0' README.md llms.txt # README 4, llms.txt 1 (known-positive)
$ grep -rn 'v0\.7\.0' README.md llms.txt # 1 hit: README:96, the history row
$ grep -rln 'v0\.7\.0' docs/ | wc -l # 3, unchanged
```
The known-positive control is not decoration: the same query shape was published
in O5 as "4 absolute paths -> 0" against paths it could not have matched either
way. A zero from a query never shown to find anything is not a measurement.
**D3 — mine, found by a gate, not by a list.** The order's eight-occurrence
table is exhaustive for the `v0.7.0` FORM. The version also lives without the
`v` prefix at `src/llm_ingestion_okf/__init__.py:79`, where no search for
`v0.7.0` reaches it. `test_packaging.py::test_the_declared_version_agrees_with_
the_packaged_one` failed on the first commit and named it. The order says "no
`src/` change"; that line is the other half of the version, not behaviour, and
leaving it would have shipped a tag reporting `0.7.0` to every consumer that
installed it. It was fixed and the commit amended. Confirmed downstream: the
tool installed from the tag resolves as `llm-ingestion-okf==0.8.0`.
## 4 The four gates, after `git add` and after commit
`ruff 0.16.6`, on `4d1f9d3`:
```
$ .venv/bin/ruff check src tests tools All checks passed!
$ .venv/bin/ruff format --check . 117 files already formatted
$ .venv/bin/mypy src Success: no issues found in 21 source files
$ .venv/bin/python -m pytest -q 1575 passed, 1 skipped, 15 warnings in 88.49s
```
README's published count was `1515`, measured 2026-09-09; it now says 1575, the
figure above. The sentence about the earlier published figure was repaired in
the same edit — changing only the date would have made "the figure published
here until that day was 596" false, since 1515 stood between 09-09 and today.
`tests/test_docs_promises.py` was run after the README edits: 5 passed.
## 5 The acceptance gate: installation FROM THE TAG
`uv tool install` cannot reach an unpushed tag over git, so the tag was exported
and installed from a local path, in O6's form
(`docs/2026-09-09-o6-forsteskjerm-og-skillmodi.md` § 5). The bytes are the tag's;
the channel is not.
```
$ git archive v0.8.0 | tar -x -C /tmp/r1-release-v080/r1-install/export
$ uv tool install --force "llm-ingestion-okf[extract] @ file:///tmp/r1-release-v080/r1-install/export"
- llm-ingestion-okf==0.7.0 (from file:///tmp/okf-v070)
+ llm-ingestion-okf==0.8.0 (from file:///tmp/r1-release-v080/r1-install/export)
Installed 1 executable: okf
```
Three rows, each with its denominator, all run from the installed binary:
| row | measured | expected |
|---|---|---|
| `okf project` on the five-document folder | 5 documents read, **26 concepts**, **52 md files**, **0 of 5** left out | 26 / 52 / 0 of 5 |
| `okf build` on the 828-file HTML corpus | `proposed 828 plan(s); 0 document(s) with no boundary; 0 unreadable`; 6 015 md | 828 of 828 |
| `okf skill` + `okf consume` + `okf check` | `conformant: 15 rules over 8 excerpts and 18 withheld entries, 0 findings` | 15 rules, 0 findings |
The HTML build was run twice into separate scratch directories and the two are
`diff -rq`-identical. `~/okf-test/dokumenter` and `~/repos/vegnormal-okf` were
read only; no file under `build/860019-side-inn-100` has an mtime inside this
session, and the two modified files in that repo's worktree
(`STATE.md` 21:05, `experiments/resonnering/kjor_m2.sh` 21:11) belong to a
session running there in parallel, not to this one.
The tool was uninstalled afterwards (`uv tool uninstall llm-ingestion-okf`;
`which okf` now exits 1). Note that a `0.7.0` build from `/tmp/okf-v070` had been
installed before this round and was replaced by `--force`; uninstalling does not
restore it.
## 6 Honesty limits
- **The install measurement is ONE machine with ONE interpreter.** Python 3.14.0
in the worktree, 3.11 in the uv tool environment, macOS, Intel. It says the
tag's bytes build and run here. It says nothing about another OS, another
Python, or the git channel a consumer will actually use — which was not
exercised at all, because the tag is unpushed.
- **The `okf project` figure of 26 is ONE corpus of 5 documents.** It is a
regression check against a known number, not a property of the tool.
- **828 of 828 is ONE publisher's HTML from ONE product.** The generality of the
`.html` row rests on that corpus and no other.
- **The grep criterion was changed deliberately** (D1, D2). The published
acceptance in the commissioning STATE is not the one that ran, and the reason
is that historical reports are not rewritten. Anyone reading for "0 hits"
should read § 3 instead.
- **"The tag installs" is not "the tag is right."** No functionality is verified
in this round beyond what rounds 13 and 14 already measured. The three rows
above are smoke measurements chosen because their expected values were known;
they do not re-derive 2 761 of 2 761, and no `.xml` document was in any of
them.
- **The CHANGELOG carries no compare link for `[0.8.0]`**, and none was added.
This file has published none since `[0.6.0]`; inventing one would be a claim
about a URL nobody fetched.
- **The tag is UNPUSHED.** A consumer installing from `@v0.8.0` against Forgejo
does not find it until the operator pushes.