Wikantik Content vs Code Deployment

The single most common operational confusion in this project: deploying code does not deploy content. Production's page store and database persist across every release; the docs/wikantik-pages/ directory in the repo seeds fresh installs only.

The two paths

Change	Path
Application code, templates, bundled system pages	Release + deploy — Wikantik Release and Deploy Process
Wiki page content (articles, hubs, runbooks)	MCP authoring tools against prod, or bin/remote.sh pages-push for bulk rsync

Content-path details

• Normal path: the admin-MCP authoring surface (write_pages, update_page, rename_page, delete_pages) — wired as session tools pointing at production. Optimistic locking via expectedContentHash; frontmatter merges on update.
• Bulk path: bin/remote.sh pages-push LOCAL_DIR [--mirror] / pages-pull — rsync of the page store; --mirror deletes remote pages absent locally, so use with care.
• Refusals are by design: bundled system pages (About, Main, LeftMenu, CSS themes, help pages — anything in the system-page registry) refuse MCP writes so agents cannot silently mutate shipped chrome. Main.md is additionally generated from Main.pins.yaml; CI's regression test reverts hand-edits.
• Async re-index: every save re-chunks and re-embeds off-thread. A page is BM25-searchable immediately; dense retrieval catches up when the embed queue drains. Bulk corpus re-embeds do not refresh the lucene-hnsw index mid-run — only on successful completion.

Verification after content changes

verify_pages (links/metadata/SEO/retrieval lint) followed by a live assemble_bundle query for anything retrieval-sensitive — the static lint alone does not prove retrievability. Policy context: Content Program Policy.

See Also

• Wikantik Release and Deploy Process
• Host: docker1 — Wikantik Production