feat(export): OKF re-export honesty — reproduce foreign frontmatter#102
Merged
Conversation
…ly foreign type+keys
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Completes the OKF round-trip so that a page imported from a foreign bundle re-exports honestly rather than as a generic concept.
Import captures an imported document's original frontmatter under an
x-okfsnapshot (an unknowntypesuch asBigQuery Tablemaps tokind: conceptwhile the raw type and any producer-specific keys are preserved). Until now nothing read that snapshot back, so re-export emittedtype: conceptand dropped foreign keys. This wires the snapshot through and re-exports with the right contract:ExportPagecarries an optionalxOkfsnapshot;collectreads thex-okfblock back from page frontmatter.mapPageToOkfFrontmatter:typeand any unknown producer keys (e.g.vendorKey);title,description,tags,timestamp) from the current page, so local edits after import are reflected rather than publishing stale snapshot values;x-llmwikiprovenance block (content hash, page directory, provenance) from the current page;x-okfinto the exported OKF doc (it stays a llmwiki-side record).x-okf.okfPathat import, so a page's origin survives review approval and is surfaced bycollectExportPages(previously it lived only on the review candidate and was lost once approved).Why
A foreign bundle should survive import→export honestly — preserving the producer's own
typeand keys while still reflecting any local edits and layering llmwiki's own provenance. This lets llmwiki act as a faithful pass-through for third-party OKF content.Scope / known limitation
Re-export places every document at
<pageDirectory>/<slug>.md— the llmwiki slug is the identity the OKF link rewriter and index TOC understand (/concepts|queries/<slug>.md). A foreigntables/customers.mdtherefore re-exports asconcepts/tables-customers.md; its original path is preserved durably underx-okf.okfPathfor diagnosis. Faithful reconstruction of nested original bundle paths is intentionally deferred — it requires extending the slug-based link/index model.Test plan
npx tsc --noEmit,npm run build,npm test(1619 passed),npx fallow(0 above threshold), dupes cleantype+ producer key survive import→exporttype: BigQuery Table+vendorKeyx-okfdoes not leak into exported OKF frontmatterokfPathpersists on the live page across realreview approveand is surfaced by export# Citations