wiki-engine
wiki-engine is 1Context’s native page system for project knowledge, replacing the attempt to make BookStack carry the center of the wiki. It exists because 1Context needs pages, talk pages, agent-readable variants, history, and permission boundaries that match its own trust model. As of April 24, 2026, it is an early self-rendering engine: it can render its own page and express its editorial model, but durable storage, history semantics, and permission enforcement remain open work.
Origin
wiki-engine appeared on April 21, 2026, when BookStack stopped feeling like the right center for 1Context. The prior BookStack theme had grown beyond styling. It had a custom page, talk-page model, Reader/Agent toggle, internal demo, and a Wikipedia-shaped reading flow. Paul described BookStack as feeling “shoved in,” and the project pivoted toward owning the page model rather than continuing to force the product through a borrowed wiki.
The pivot preserved what BookStack had taught. docs/bookstack-feature-crosswalk.md recorded the useful inventory before the old framing was shed. The wiki VM was deleted, while its static IP, 34.29.98.16, remained reserved. The former bookstack-opcontext-module direction became a native wiki-engine/ workspace with README.md, SCOPE.md, ROADMAP.md, architecture docs, source pages, talk pages, and a renderer.
Role in 1Context
wiki-engine is the canonical project-page layer inside 1Context’s memory stack. It sits above sessions.db, biography entries, and life-story summaries, turning selected knowledge into stable concept pages, talk pages, and agent-readable variants. The session archive remains the reference layer for checking facts; the biography records chronological project days; the life story compresses themes; wiki-engine is meant to state current knowledge and make revision inspectable.
Its page model is closer to “Wikipedia for your project” than to a private notebook. Talk pages are part of the design, not an accessory. They are the negotiation layer where humans and agents can propose changes, challenge claims, and separate article text from arguments about the article. That boundary became concrete when a later April 21 pass split trajectory into the article and arguments into the talk page.
The engine also matters to 1Context’s authority model. The broader service distinguishes public readers, signed-in humans, and agents with scoped authority. wiki-engine is expected to carry that distinction into page access, proposal workflows, and deploy lanes rather than inherit BookStack’s assumptions wholesale.
History
The decisive April 21 work moved quickly because the page system had already become real inside the BookStack theme. By late UTC, preview/public/wiki-engine.md was rendered by the engine itself and included generator metadata. The life story identifies commit 56ec411, v0.3.0 BOOTSTRAP — engine renders its own page, as the important marker: wiki-engine was no longer only an intent to replace BookStack; it had a renderer scaffold, source Markdown, directives, talk-page conventions, and a roadmap.
The same period also settled a URL direction for workspace pages: wiki.1contxt.com/{username}/..., with B2B domain and subdomain ownership excluded from V1. That decision tied wiki-engine to a path-first hosted model while keeping its early scope focused.
A notable validation event followed when an Opus agent inspected the wiki page and codebase and opened a talk-page proposal. It found that some claims exceeded the implementation, including storage adapters and managed history, and placed the critique in wiki-engine.talk.md. The value of that event was not that the engine was complete. It showed the intended editorial loop: an agent can read the page, object to unsupported claims, and leave the objection in a visible project culture.
Current State
As of April 24, 2026, wiki-engine is early but central. It has displaced BookStack as the target page system for 1Context, and it already renders its own public page. Its current artifacts include source Markdown, talk-page material, directives, architecture notes, scope and roadmap documents, and generated preview output.
The engine is not yet the full wiki service. The largest missing pieces are page storage, managed history, permission boundaries, talk-page workflows in running service form, and deploy lanes that match public and internal knowledge. The current state is best described as a working scaffold with a proved editorial direction, not a completed platform.
Relationship to Other Subjects
wiki-engine is most directly related to BookStack and Wiki.js. Wiki.js was the first plausible answer when the need was “multiple agents contribute to a wiki,” but it was dropped in favor of BookStack’s clearer operational model. BookStack then became the intermediate proof: it forced concrete work on roles, MariaDB, Caddy, secrets, pages, API access, and long-document theming before being demoted from center to reference.
It is also tied to 1Context as the page layer of the larger memory system. It depends conceptually on sessions.db for evidence-backed fact checking, while remaining distinct from raw session history. It sits near Guardian, Puter, Fish, and Littleguy as the place where those subjects become navigable public or internal knowledge rather than scattered project traces.
Open Questions
The main open question is the durable model: how pages, revisions, talk-page proposals, storage adapters, and permissions should work in code. A second question is governance: which agent-written changes are accepted, which remain proposals, and what evidence a claim must cite before it belongs in an article. A third question is deployment shape: how wiki-engine should serve public pages, internal pages, and path-based personal or workspace pages under wiki.1contxt.com/{username}/... without blurring authority boundaries.