§3's okf_version MUST now states the value is the upstream OKF version alone;
a plugin's own layout revision belongs in the optional okf_layout marker (§12).
Marked explicitly NOT YET ENFORCED — no checker validates the value's shape, so
an emitter still carrying a layout string conforms today.
No convention version bump: §12 ties a bump to a change in the §3 floor, and the
set of conforming bundles is unchanged (a clarification, deliberately inert).
Non-enforcing is the deliberate shape. okr ratified the split and owns the
migration, but their scripts/okf-* are file-fenced frozen through the 1.8.0
consolidation. Enforcing okf_layout presence now would redden the STEG 3 parity
gate on okr with nothing they could do until that ships. Enforcement is a
separate scoped step after their migration lands.
log.md records the round's other settled items, each verified against ground
truth rather than accepted as asserted: the roll-up carrier is a no-op for the
public-mirror class (builder tolerates absence by design); the catalog runs no
index.md generator (read-side only), so commons' inherited item is stale; the
okf_version ruling already existed in §12; and the catalog's okf-check.mjs is
NOT byte-identical to okr's (141 differing lines), so parity here is behavioural
over the §3 floor in default read-mode via check-okf-parity.mjs — never byte
identity.
Verified: suite 73/73, check-okf-parity 8/8 exit 0, check-versions 11 OK/0 WARN/
0 ERROR.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CPHvLhn2U3j2XD3Cn8zeYa
Kjell Tore Guttormsen
9ca2c8bdaf