fix(structure): the index resolves a parent naming a segment of its own document

K3-21 C. `resolve_structure` asks `_segment_lookup` first for a `parent`
edge: `(source_file, segment_id)` -> concept name, keyed off each concept's
own frontmatter (`DocumentStructure.declared`, no file read again), so a
pointer lands only inside the pointing concept's document -- `p1` exists in
every document of a multi-document bundle. A value no segment answers to is a
document number and is looked up exactly as before; a pointer naming nothing
keeps `UNRESOLVED_MARKER`. The rendering rule is untouched: a resolved
relation renders as its subject, so `parent: p1977?` becomes `parent: p1977`.

Moved on purpose, each named: both segmented goldens' index files
(`examples/ingest-golden-segmented{,-okf-v0-2}/expected-bundle/krav/1-{1,2}/
index.md`), whose declared parents s1 and s2 -> s0 rendered `parent: s0?`
while s0 stood in the bundle -- four lines, `?` removed. The four goldens
`test_the_four_existing_goldens_are_untouched` guards are not among them.
`skills/okf-consume/` regenerated, because the golden's index bytes -- and so
its ref -- moved. `test_shell_parent`'s byte test now expects the resolved
facet. README and CLAUDE.md no longer say the index renders it unresolved.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Kjell Tore Guttormsen 2026-09-11 13:55:03 +02:00
commit 59703699a5
10 changed files with 50 additions and 17 deletions

View file

@ -1,6 +1,6 @@
---
name: b-golden-segmented-okf-v0-2-consume
description: Answer one question about the OKF bundle `b-golden-segmented-okf-v0-2` (3 concepts, ref sha256-tree:f85646c1f77982a69b97afca08209f369b79cd39c217f6f2c074c2dc5bac23fe) from a bounded payload assembled by a deterministic pre-pass, marking every claim with its source, its title and its provenance locator. Use whenever a question is about what that bundle's documents require, say or contain. Generated by `okf skill`; every value below is measured against this bundle at this ref.
description: Answer one question about the OKF bundle `b-golden-segmented-okf-v0-2` (3 concepts, ref sha256-tree:cce7a02c769793cdb6e3afda45c955461b57373deab13a986d8bf7843d6e436f) from a bounded payload assembled by a deterministic pre-pass, marking every claim with its source, its title and its provenance locator. Use whenever a question is about what that bundle's documents require, say or contain. Generated by `okf skill`; every value below is measured against this bundle at this ref.
---
# b-golden-segmented-okf-v0-2 consumption
@ -9,7 +9,7 @@ Answer one question about the `b-golden-segmented-okf-v0-2` bundle, from the pay
assembled, at one ref.
**This file is an instantiated copy of `skills/okf-consume-template/SKILL.md`,** generated by `okf skill` for one bundle: `b-golden-segmented-okf-v0-2` at ref
`sha256-tree:f85646c1f77982a69b97afca08209f369b79cd39c217f6f2c074c2dc5bac23fe`. Every value below was measured against those bytes. If the
`sha256-tree:cce7a02c769793cdb6e3afda45c955461b57373deab13a986d8bf7843d6e436f`. Every value below was measured against those bytes. If the
bundle moves, the ref moves with it and this file is stale — regenerate
it rather than editing a number here. The section headings are fixed:
the contract checker reads them by name.
@ -25,7 +25,7 @@ Step 1 is always the pre-pass. Run it, read its JSON payload, and judge that.
okf consume \
examples/ingest-golden-segmented-okf-v0-2/expected-bundle \
--question "your question" \
--ref sha256-tree:f85646c1f77982a69b97afca08209f369b79cd39c217f6f2c074c2dc5bac23fe \
--ref sha256-tree:cce7a02c769793cdb6e3afda45c955461b57373deab13a986d8bf7843d6e436f \
--out /tmp/payload.json
```

View file

@ -2,7 +2,7 @@
"contract": "okf-consumption/1",
"bundle": {
"bundle_id": "b-golden-segmented-okf-v0-2",
"ref": "sha256-tree:f85646c1f77982a69b97afca08209f369b79cd39c217f6f2c074c2dc5bac23fe"
"ref": "sha256-tree:cce7a02c769793cdb6e3afda45c955461b57373deab13a986d8bf7843d6e436f"
},
"budget": {
"unit": "utf-8 bytes of emitted JSON",