RFC: wiki_export — on-demand bridge from .omc/wiki/ to a personal cross-project wiki

[rolldav]

Problem

.omc/wiki/ (the bundled LLM Wiki, skills/wiki/SKILL.md) is explicitly
modeled on Karpathy's "LLM Wiki" idea, and by design it's project-local and
git-ignored. That's the right default for project knowledge — but plenty of
users already keep a personal, durable, cross-project wiki that follows the
exact same pattern (an Obsidian vault, a Logseq graph, or just a folder of
markdown notes with YAML frontmatter). Once both exist, they diverge
silently: nothing captured in .omc/wiki/ ever reaches the store the user
actually keeps long-term, and there's no bridge between the two.

Proposal: wiki_export

An opt-in, on-demand, one-way export from .omc/wiki/ to a configured
external folder:

• Off by default. wiki.externalSync.enabled (in .omc-config.json,
  the same file the rest of wiki.* already reads from) must be explicitly
  set. No filesystem access outside .omc/wiki/ happens otherwise.
• One-way. OMC wiki -> external wiki only. Nothing ever flows back, and
  the export logic never mutates .omc/wiki/.
• Idempotent. Every exported page embeds a content-hash marker in its
  frontmatter (omc-sync-hash: ...). Re-exporting an unchanged page is a
  no-op.
• Never silently overwrites content it doesn't own. If the destination
  file wasn't created by a previous wiki_export run, or was edited since,
  the configured conflictPolicy decides: skip (default) leaves it alone,
  manual copies the OMC-side version into <target>/_omc-sync-incoming/
  for the user to reconcile by hand, overwrite-if-newer compares
  frontmatter timestamps.
• Path-safe category mapping. categoryMap lets a category route to a
  subfolder under the target; a folder containing .. or an absolute path
  is rejected the same way .omc/wiki/ page paths already are.
• Two frontmatter dialects (rich / plain), both plain markdown +
  YAML. Neither shells out to anything, detects an installed app, or adds a
  dependency — the target can be an Obsidian vault, a Logseq graph, or an
  empty folder; wiki_export doesn't know or care.

Why this isn't #1890/#1928 again

I know this repo already went through this once: #1890 added an Obsidian
MCP/CLI integration (vault detection, obsidian_* tools shelling out to the
obsidian binary), and it was reverted alongside closing #1928, with the
maintainer's call being to keep app-specific integrations external to the
core repo rather than bundle them.

wiki_export is a different shape of feature, not a resubmission of that
one: it has no CLI dependency, detects no installed app, and knows nothing
about Obsidian specifically — it writes plain markdown + YAML frontmatter to
a folder the user points it at. If that folder happens to be an Obsidian
vault, that's incidental; it works identically for a Logseq graph or a bare
folder of notes. There's no obsidian_* tool surface here, and nothing to
revert if a specific app's format ever changes.

Where this stands

I have a full implementation ready — the wiki_export MCP tool, the
export/conflict-resolution core, config loading, 16 new unit tests (safety
gates, idempotency, conflict handling, both rendering dialects), docs, and a
skills/wiki/SKILL.md update — passing against current dev (existing
wiki test suite green, tsc --noEmit clean, lint clean, full build clean).
I'd rather confirm direction here first rather than drop an unsolicited PR,
given the history above.

Two open questions I'd want maintainer input on before opening the PR:

1. Config surface. wiki.* currently reads from .omc-config.json, a
   different file than the omc.jsonc surface the rest of
   docs/settings-schema.md documents. Is .omc-config.json still the
   right place for a new wiki setting, or should this (and the existing
   wiki.* keys) move to omc.jsonc?
2. On-demand only, for now. This version only exports when explicitly
   invoked (wiki_export() or /wiki export) — no SessionEnd or
   timer-based auto-sync. That seemed like the safer place to start, but
   happy to hear if automatic sync behind the same enabled flag would be
   preferred instead.

Happy to open the PR against dev as soon as there's a steer on either of
these (or on the feature at all).

[AAMARVA]

This is a fantastic RFC. Moving local project documentation out of isolated silos like .omc/wiki/ and into a shared, cross-project space is exactly where the ecosystem needs to go.
From the AAMARVA side, this hits close to home. We’re working heavily on the agentic infrastructure layer—specifically how independent agents discover each other, communicate securely, and share context. An open, cross-project wiki bridge would be huge for allowing agents across different frameworks to dynamically ingest local project context without manual handholding.
A couple of thoughts/questions from an infrastructure perspective:
• Handling Sensitive Data: Project wikis often accidentally include API endpoints, environment naming conventions, or sensitive architectural details. How are you thinking about sanitizing or filtering data during the export? (On our end, something like this would map nicely to a Secrets Preserver layer to ensure credentials don't leak into the personal wiki vault).
• Link Schema: Preserving internal relative links across different markdown parsers (like standard MD vs. Obsidian’s wikilinks) can get messy. Sticking to a clean, highly standardized Markdown output would make cross-framework ingestion way easier.
Definitely following this closely let us know how we can help test or support the design!