Proposal: make OpenWiki a workspace-backed knowledge operating system

[winterwd1201]

Why this matters

OpenWiki has grown into something more ambitious than a capture-and-summarize tool. For users who already have a local knowledge base, the current model still has a structural gap:

• old knowledge can be read into the app,
• new knowledge can be created inside the app,
• but the app is still too close to being a separate island instead of a durable knowledge workspace.

I prototyped a workspace-backed approach locally and wanted to upstream the product direction first before trying to split the implementation into smaller mergeable PRs.

Core proposal

Treat OpenWiki as a knowledge operating system / index layer built on top of a local workspace, instead of only a private app database.

A unified internal model could look like this:

• Inbox: newly captured, unprocessed material
• Raw: cleaned / normalized source material
• Wiki: structured knowledge (cases, concepts, themes, dashboards)
• Insights: derived reports and higher-level analysis

This model should work for both:

1. New users
   • OpenWiki initializes a standard workspace for them.
2. Existing knowledge-base users
   • OpenWiki maps existing folders into the same internal model without forcing them to fully adopt one exact directory naming scheme.

Design principles

• One product, one knowledge model, multiple source strategies
  • managed workspace
  • external knowledge base
  • hybrid mode
• Filesystem is the durable asset
  • the app database should act more like an index/cache/graph layer
• Do not silently rewrite a user's existing knowledge base
  • promotion into formal knowledge should be explicit or confirmation-based
• Imported or synced knowledge should remain legible and interoperable to other tools/AI systems

What the local prototype explored

The local prototype I built explores these directions:

• workspace setup / onboarding for managed, external, and hybrid modes
• writing newly captured material into inbox/ and raw/
• syncing local RAW content and local wiki content into the app
• evolving the knowledge layer beyond just source pages toward case / concept / theme / dashboard
• supporting local wiki navigation ([[wikilink]]) inside the app
• showing theme relationships in knowledge pages
• using draft / candidate layers instead of directly polluting formal knowledge
• making insights more robust with OAuth-first behavior, JSON repair, adaptive batching, and visible progress

Suggested upstream path

I do not think this should land as one huge PR.

A better path seems to be:

1. align on the product direction here
2. split the prototype into smaller PRs, for example:
   • insights stability + adaptive batching
   • setup / onboarding modes
   • workspace protocol (inbox/raw/wiki/insights)
   • external RAW/wiki sync
   • wikilink navigation + theme relationships
   • draft/candidate promotion workflow

Why I’m opening this first

The implementation is already quite different from v0.1.6, so I wanted to upstream the intent and product architecture before treating the code as a direct merge request.

If this direction is interesting, I can split the prototype into smaller PRs in the order that makes the most sense for the project.