Order G34 asked whether the corpus-wide rejection of a conformant `sources`
block reproduces against guard 1.1.0, on the premise that 1.1.0 introduced a
mapping-key allowlist on 08-21. It does reproduce, and the premise is off by
one release: v1.1.0 is dated 08-13 and carries no allowlist. The allowlist is
`5870483`, nine commits past that tag and carrying no tag of its own -- its
`__version__` still reads 1.1.0.
Measured, each point extracted with `git archive` and put on PYTHONPATH ahead
of the venv, resolved version confirmed per run. The conformant variant is 0
merged and the control 34 of 34 at 0.3.4, 1.0.0, 1.1.0 AND the allowlist
commit; the control merging is what shows the harness can pass at all. Seven
candidate `sources` carriers, and none that names a `resource` merges at any
of the four points, because `resource` is deliberately off the allowlist while
SPEC 5.1 makes it REQUIRED inside an entry.
Two things the plan did not know. v1.1.0 closed the one-key block sequence,
which the 2026-08-02 measurement recorded as the only shape carrying a section
10 pointer through Door C, so `unverified_references` is empty by construction
at >=1.1. And the allowlist commit moves this library's own goldens from 4 of
9 to 8 of 9 concepts through Door C, the `generated` stamp being exactly the
shape it admits.
The pin therefore holds at `>=0.3,<0.4` / `v0.3.4`. Lifting to v1.1.0 is
behaviour-free here (595 pass, the one red being the pin assertion itself) and
buys nothing on this axis; the gain sits on an untagged commit, and pinning
one trades a release channel for a moving target. The condition to revisit is
a fact, not a date: a guard tag containing `5870483`.
The 2026-08-02 table is left standing and dated rather than rewritten -- it is
true of the version it names.
Kjell Tore Guttormsen
32b4b76dc4