Your docs can ship in the same flow as your code.

Wikix is a practical wiki for release-heavy teams who are tired of fixing docs after release day.

Markdown/MDX as source of truth Canonical / and /{slug} routes Proposal-first publishing

Built as a pet project around one idea: docs should feel like part of delivery, not cleanup.

The gap we keep seeing in fast teams

  • Code is reviewed and merged, but docs wait in another tool and ship later.
  • People lose time on handoffs: edit here, copy there, reformat, republish.
  • Onboarding pages and runbooks quietly drift after each release cycle.

The real cost is context switching, rework, and avoidable production confusion.

How Wikix keeps the flow simple

  1. Edit docs directly in .md/.mdx files.
  2. Open a proposal and review with explicit role gates.
  3. Publish with atomic writes and keep search in sync.

No hidden wiki namespace. No extra format. No custom publish glue.

Product model in one view

File-native content

Pages stay in .md/.mdx, so ownership and history remain clear in existing workflows.

Predictable URLs

Homepage is /, pages are /{slug}, and legacy /wikis/* stays redirect-only.

Controlled publishing

RBAC roles, required comments for key actions, and audit events make publishing accountable.

Reliable operations

Atomic writes plus sync/reindex flows keep filesystem state and search index aligned.

Why this is different from a generic docs stack

Typical setup

Many teams end up with several tools, manual handoffs, and brittle publishing glue.

Wikix

One contract: markdown/MDX source, predictable routing, proposal flow, and built-in ops controls.

Best fit today

Teams with frequent releases that need docs to move with code, not after it.

Reality check

Wikix does not replace discipline. It makes a good documentation process easier to enforce.

What already exists in the product

Routing contract

Single wiki per deployment, canonical / and /{slug}, legacy path kept as redirect-only.

Publish contract

Proposal-first flow with role gates, audit log, and atomic writes for content updates.

Operations contract

BFF API proxy plus sync/reindex paths for safe recovery after manual file edits.

Who gets value first (current hypothesis)

Game and mod teams

Patch notes, lore, and player guides that should stay aligned with frequent updates.

Smaller OSS projects

Architecture docs and contributor guidance reviewed in a familiar, Git-native flow.

Internal platform teams

Private operational docs where explicit permissions and auditability matter.

Early AI-enabled teams

Markdown/MDX structure is easier for assistants to read and draft against, with humans in control.

14-day pilot that proves real value

  1. Days 1-3: bootstrap one wiki and import existing markdown pages.
  2. Days 4-8: configure contributor/maintainer roles and run proposal reviews.
  3. Days 9-14: publish one real release cycle through the same workflow.

Success signals: fewer manual handoffs, cleaner review trail, and docs updated in the release window.

AI roadmap, with guardrails

  • Now: human-led publishing with RBAC and audit controls.
  • Next: read-focused assistant context over pages and search.
  • Later (gated): assistant-created proposal drafts through existing review rules.

No autonomous direct publish is planned before policy gates and safety checks are proven in practice.

If this feels like your team: start with one repo, one docs stream, and one release cycle.