Wiki Knowledge Mesh

The Wiki should be one mesh, not one wiki per product.

QA and Ops stay separate as products and deployments. A CareerVector QA queue is not a JobCache QA queue. A CareerVector Ops anomaly is not a JobCache Ops anomaly. Their UI, API, MCP, hosts, checks, events, and runtime data stay product-specific.

Knowledge is different. The knowledge layer exists to explain why the products fit together, where code lives, what concepts depend on each other, and what an agent should read before touching a file. Splitting that layer would hide the links we need most.

Shape

The source of truth stays Git-backed:

  • wiki/content/** contains CareerVector and shared knowledge.
  • jobcache/wiki/content/** is imported into the same Wiki graph under the /jobcache/... URL namespace.
  • .graph.ts annotations attach implementation, test, API, MCP, infra, and event claims from code.
  • FalkorDB is a projection/cache for fast graph traversal, not the source of truth.

The mesh has product lenses:

  • mesh: everything.
  • careervector: CareerVector plus shared nodes.
  • jobcache: JobCache plus shared nodes.
  • qa: QA plus shared nodes.
  • ops: Ops plus shared nodes.
  • status: public status plus shared nodes.
  • wiki: Wiki engine and graph platform plus shared nodes.

The lens is a view filter, not a different ontology. The same page, codebook item, graph node, search result, or neighborhood can be visible through multiple lenses when the content is genuinely shared.

Runtime Boundaries

Do not merge product runtime data just because the knowledge graph is shared.

QA/OPS separation remains:

  • CareerVector QA reads CareerVector QA data.
  • JobCache QA reads JobCache QA data.
  • CareerVector Ops reads CareerVector operational data.
  • JobCache Ops reads JobCache operational data.

Shared code is encouraged. Shared runtime state is not.

The mesh should explain both products and show the relationship between their tests, incidents, APIs, MCP tools, source files, and architecture notes. It should not turn QA or Ops into one combined operational database.

API And MCP

The public Wiki API exposes the same mesh/lens model that the UI uses:

  • GET /api/wiki/lenses.json
  • GET /api/wiki/pages.json
  • GET /api/wiki/search.json?lens=<lens>
  • GET /api/wiki/neighborhoods.json?lens=<lens>
  • GET /api/wiki/graph.json
  • GET /api/wiki/codebook.json

The CareerVector MCP exposes read tools over these endpoints:

  • search_wiki_knowledge
  • get_wiki_graph_neighborhood
  • get_wiki_knowledge_hub_status

This gives agents the same contract as humans: search the mesh when the topic crosses products, narrow to a lens when editing one product, and use graph neighborhoods before changing connected code.

Rule

One mesh. Many lenses. Separate product runtimes.

If a thing is operational state, keep it in the owning product. If it is knowledge about code, architecture, APIs, MCP tools, QA evidence, Ops incidents, or product concepts, let it join the mesh and make its product lens explicit.

Source: wiki/content/architecture/WIKI-KNOWLEDGE-MESH.md