From Local Tool to Operating Practice

OpenWiki offers more than one way to keep a wiki useful, and choosing among them is an architecture decision rather than a menu preference. The question is who supplies research and credentials, where durable state lives, what kind of evidence can be grounded, and how a human will review the result. Comparing native and host-driven repository generation with personal ingestion, scheduled CI, and the visualizer gives an operator a practical rule: use each surface for the kind of continuity it can actually support.

Choosing who owns the run

In native repository generation, OpenWiki supplies the model, the planner, and a fresh page worker for each pending page. The worker researches the assigned topic, writes its Markdown, and submits sparse Claim decisions. OpenWiki's lifecycle core decides whether the job is current, validates the page, persists the Claim sidecar, and runs deterministic finalization. The model is inside the product's execution path, but it does not own the durable meaning of “complete.”

Host-driven generation changes the authoring environment. Codex, Claude Code, OpenCode, or Cursor supplies its own authenticated model and native repository tools. OpenWiki runs as a local stdio MCP server and exposes the same six operations over a narrow protocol: begin the run, submit the plan, request the next page, inspect Claims on demand, submit the page, and finish. The host researches and authors only the current page; OpenWiki retains the queue, Claim reconciliation, source-drift handling, indexes, provenance, and finalization.

That division is useful when a coding agent already has the repository context or tools an operator prefers. It also sets a limit. An MCP response can establish that a plan or page submission was accepted, but it cannot prove that the host model noticed every important repository fact. The host remains responsible for factual research, while OpenWiki provides the machinery that makes the accepted result durable and reviewable.

The host session manager adds guards that make this division enforceable. It allows one active process-local run, serializes lifecycle operations, requires the caller's runId to match the active run, and maps internal lifecycle errors to stable host-facing errors. These guards prevent two operations from racing the same queue or one caller from presenting another run's state as its own. They do not create a semantic guarantee that the host's prose is correct.

The host path is also narrower than native personal use. Host-driven runs currently support repository code wikis and use repository source and tests as context; connector context, including LangSmith observations, is not forwarded through this path. That is a deliberate boundary. The host integration reuses the repository maintenance contract, not every capability of the standalone OpenWiki process.

classDiagram class NativeGeneration class HostDrivenGeneration class PersonalConnectorIngestion class ScheduledCI class Visualizer class RepositoryLifecycle class LocalWiki class WikiArtifact NativeGeneration --> RepositoryLifecycle : OpenWiki model and durable queue HostDrivenGeneration --> RepositoryLifecycle : host context through MCP PersonalConnectorIngestion --> LocalWiki : connector data and confidence ScheduledCI --> RepositoryLifecycle : scheduled update and review RepositoryLifecycle --> WikiArtifact : Claims and finalization Visualizer --> WikiArtifact : Markdown links and OKF metadata

The important relationships are ownership relationships. Native and host-driven generation both drive the repository lifecycle. Personal ingestion writes a different kind of wiki. CI triggers maintenance and carries the result into review.