Person/codekiln/GitHub/logseq-gardener/Analysis/Fable/26/09/12/0933 ET Use Logseq's own graph-parser as the oracle and require a byte-identical round trip

• Use Logseq's own graph-parser as the oracle and require a byte-identical round trip

  • Codex's Person/codekiln/GitHub/logseq-gardener/Analysis/Codex/26/09/12/0733 ET Test graph meaning and preserve the original source text adds two tests to the parser decision in Person/codekiln/GitHub/logseq-gardener/Analysis/Fable/26/09/12/0658 ET Pick the parser first and let the language follow: compare the graph the tool builds with the graph Logseq builds, and keep the original text so a later edit changes only the bytes it means to. Both tests are right, and both can run this week with tools already on this machine. Logseq's graph-parser is the reference answer: whatever it says a graph contains is what the new tool has to match.

  • Logseq's own parser can produce the answers to compare against

    • codekiln asked on the Codex page what a second comparison after syntax parsing means. lsdoc's test checks one file at a time: does lsdoc read this file into the same blocks and inline nodes that mldoc does. The second check reads the whole graph: does the new tool name the same pages, join the same aliases, give each block the same parent, and find the same backlinks that Logseq finds. Logseq computes those in ClojureScript after mldoc has parsed, so lsdoc's test never runs that code.
    • lsdoc's differential test compares its syntax tree with mldoc's on a normalized projection of blocks, inline nodes, and references, and its README says spans are excluded from that comparison (lsdoc README, The oracle). Page naming, alias and tag extraction, journal conversion, block order, and duplicate-ID handling sit above that tree, in Logseq's extract.cljc, so the differential test says nothing about them.
    • nbb-logseq is installed here through mise, the link-hygiene and flashcard skills already run ClojureScript scripts under it, and its README says the graph-parser's namespaces all load under it (nbb-logseq README). A short script can therefore run Logseq's own extract over the encode garden and write pages, aliases, tags, block parents, references, and explicit UUIDs to JSON. Check out logseq/logseq at the tag 0.10.15, the release codekiln's Brewfile pins the desktop app to, so the oracle and the app a person opens the garden in agree. That JSON file is the golden fixture the new tool's output is compared with, page by page, with the tag recorded beside it. Run the same dump over logseq/docs, the public Logseq graph cloned at ~/ghq/github.com/logseq/docs, so the comparison also covers a graph codekiln did not write, which the Brief asks for.
    • Run the comparison after edits as well as after a cold load, as Codex asks: remove an alias, move a block that carries an id::, delete the last link to a fileless page, and compare the incremental answer with a fresh rebuild.

  • The round trip is a pass-or-fail test

    • Parse every file in the encode garden and in logseq/docs, serialize each back, and require identical bytes. A parser that passes can support small edits. A parser that fails needs a separate layer that keeps original text and spans, which is what Codex describes. Tine's README says tine-core's tests include a parse/serialize round trip, that round-trip parsing is validated against a real Logseq graph, and that tine-check proves byte-faithful serialization without reading note content (Tine README, Testing). Running tine-check on the encode garden is the cheapest way to learn whether that claim holds for this corpus.
    • Files the round trip cannot reproduce are findings. Each one is either a construct the parser should learn or a file this garden should fix, and the list of them is the compatibility report the Brief asks for.

  • Rust when all three tests pass, OCaml when the syntax test fails

    • Rust on lsdoc and tine-core stays the path when lsdoc's differential test, the graph-parser comparison, and the byte round trip all pass on the encode garden. A failure in the graph comparison points at extract code the new tool must port; a failure in the round trip points at the serializer. OCaml on mldoc remains the fallback when the syntax comparison itself fails, and since Logseq's graph layer is ClojureScript, that path ports extract as well.