fix: markdown parsing bugs affecting wiki-style content

[knee5]

Summary

• splitBody mis-splits on horizontal rules: plain --- in article bodies was treated as a compiled_truth/timeline separator, causing 83% content truncation across a 1,991-article knowledge base (e.g., a 23,887-byte article stored as 593 bytes; 4,856 of 6,680 wikilinks lost from the DB).
• inferType missing wiki subtype mappings: articles under /wiki/analysis/, /wiki/guides/, /wiki/hardware/, /wiki/architecture/ all silently defaulted to type='concept', breaking type-filtered queries.
• Frontmatter double-encoded in Postgres engine: JSON.stringify(x)::jsonb causes postgres.js v3 to store a JSONB string literal instead of an object, making frontmatter->>'key' return NULL and GIN indexes ineffective.

Why this matters

Any wiki/notebook with markdown horizontal rules or non-default subdirectory types hits these. Found while migrating a 1,991-article knowledge base where 83% of articles were truncated in the DB.

Changes

splitBody(): No longer treats plain --- as a sentinel. Recognized split points are now: <!-- timeline --> (preferred, unambiguous), --- timeline --- (decorated separator), or --- only when the next non-empty line is a ## Timeline or ## History heading (backward-compat fallback). serializeMarkdown updated to emit <!-- timeline --> for round-trip stability.

inferType(): Added path-segment mappings for /wiki/analysis/, /wiki/guides/ (and /wiki/guide/), /wiki/hardware/, /wiki/architecture/, and /wiki/concepts/ (and /wiki/concept/). concept remains the default fallback.

postgres-engine JSONB: Replaced all three JSON.stringify(x)::jsonb call sites (putPage, putRawData, logIngest) with this.sql.json(x), which is postgres.js v3's native JSONB serialization. Also fixed rowToChunk in utils.ts to handle embeddings returned as JSON strings (a symptom of the same mismatch). PGLite engine is unaffected.

Testing

854 tests pass. New tests added for: horizontal rules in body, <!-- timeline --> sentinel, heading-gated splits, wiki subtype inference.

Backwards compat

Existing PGLite behavior unchanged. Postgres engine writes now produce valid JSONB (queries that used frontmatter->>'key' which returned NULL will start returning values after next write — this is a correctness fix, but downstream code that relied on the NULL behavior should be checked).

[garrytan]

Hey @knee5 — thank you for finding and fixing this. The 1,991-article wiki repro made the bug case-shut. PR #196 (v0.12.1 hotfix) just merged into the queue and re-implements all three of your fixes (splitBody sentinel, inferType wiki subtypes, JSONB triple-fix) with expanded scope:

• Schema audit found 5 affected JSONB columns, not 3 (added page_versions.frontmatter which is downstream via INSERT...SELECT, plus files.metadata from a separate command path)
• New gbrain repair-jsonb command auto-fixes existing rows on upgrade via the v0_12_1 migration orchestrator
• New test/e2e/postgres-jsonb.test.ts round-trips all 5 sites against real Postgres — the regression test that should have caught this originally
• CI grep guard at scripts/check-jsonb-pattern.sh to prevent the bug class from sneaking back in
• Wikilink extraction ([[page]] syntax) and resolveSlug ancestor search came over verbatim

Re-implemented rather than cherry-picked because PR #187 went CONFLICTING after Minions v7 / knowledge graph landed. Your test cases are ported verbatim. Co-authorship preserved in the commit trailers.

Mind if I close this PR in favor of #196? Want to make sure you're OK with the merger before I do — your name's on every relevant commit and the CHANGELOG. Thanks again.

[knee5]

Hey @garrytan — thank you, better outcome than I hoped for. The expanded JSONB audit (page_versions.frontmatter + files.metadata), the gbrain repair-jsonb migration orchestrator, the round-trip E2E test, and the CI grep guard are exactly the kind of scope tightening I didn't know to do. Test cases ported with co-authorship is generous.

Yes, please close #187 in favor of #196.

Two scope items from the original PR aren't in v0.12.0 and I'd like to offer as focused follow-up PRs if you want them:

1. gbrain orphans command — returns the actual list of under-linked page slugs for enrichment prioritization, complementary to gbrain doctor. doctor reports the aggregate ("link coverage 85%, timeline 17%"); orphans returns the slug + title + domain list that drives which pages to enrich next. The filtering logic is the load-bearing part — excludes raw/, scratch/, pseudo-pages, entities/*/_index, auto-generated pages. On my 2,146-page brain the unfiltered count is ~1,247 (every raw podcast transcript); the filtered count is 3, and those 3 are real gaps worth acting on. Flags: --count, --json, --include-pseudo. Comes with test/orphans.test.ts. If you'd rather this be a doctor subcommand flag (doctor --orphans) I can reshape.

2. Wikilink + domain-slug support in v0.12.0's link-extraction.ts canonical extractor. extractEntityRefs currently matches only [name](path) markdown. Karpathy-style wiki brains (mine, likely Wintermute's too) use [[page]] and [[page|display]] as the dominant link form — so the auto-link post-hook on put_page sees nothing. One commit adds:

   • Obsidian wikilink regex alongside the markdown regex in extractEntityRefs (both regexes driven by a shared DIR_PATTERN constant, so adding a new entity dir only touches one string)
   • DIR_PATTERN extended with entities|tech|finance|personal|openclaw so domain-organized wikis participate in the graph layer alongside the canonical people|companies|meetings|... dirs

   After enabling it on my brain: gbrain extract links --source db went from extracting nothing new to materializing +1,377 typed edges on a single pass. Markdown-link extraction behavior is unchanged; adding a parallel wikilink code path, not replacing anything. Backward compatible.

Either/both sound useful, or should I drop them? Happy to open a clean PR against v0.12.0 master if you want to evaluate. Thanks again for the thorough treatment — I'll upgrade and run gbrain repair-jsonb when v0.12.1 tags.