Wiki App Shape

The wiki perspective (wiki.careervector.corbet.ch) is one site presenting the same knowledge mesh through six primary entry points. The shape of the app — its tabs, its index, its host — is intentional, not incidental. This document describes that shape so a new contributor or agent can pick up the wiki as a product, not as a pile of routes.

Tab architecture

The active Wiki tab slice currently exposes six top-level tabs, each with a distinct epistemic role:

The tabs are not skins — each is a different projection of the same canonical graph. Promoting sibling projections such as Ops into the tab slot is a deliberate product-scope decision, not a routing detail.

Blueprint is the deliberately finite entry projection. It renders the exact 5x4 operating map and opens one canonical Markdown contract per authored region. The typed model owns placement and presentation order; the Markdown owns meaning.

Journal is still a Wiki projection, one of the nine graph hubs, and a real content lane. It is exposed as a first-class Wiki tab because the current app needs both structural graph reading and temporal working memory in the same shell.

Atlas visualization

The Atlas tab is the visual surface of the knowledge graph. It surfaces:

• A graph snapshot (nodes + edges) rendered as a 3D atlas.
• A section shelf grouping nodes by content section.
• Curated trails through the graph for onboarding paths.
• A weak-link hotspot list ranked by heat plus missing-required-link counts.

Atlas is intentionally a navigator, not an editor. Mutations to the graph happen by editing source-of-truth artifacts (.md frontmatter, .graph.ts annotations). The Atlas reflects the current build.

Librarian retrieval

The Librarian tab is the wiki's search surface. It runs a tokenizing, stopword-filtered query over three indexes — pages, graph nodes, and the codebook manifest — and returns a unified, weighted result list. The same function backs /api/wiki/search.json so an MCP agent can retrieve the same cited evidence a human reader sees.

The Librarian is the retrieval lens; it does not synthesise, summarise, or opinionate. Synthesis happens in agents that consume /api/wiki/search.json results and cite them back to the user.

Journal temporal memory

Journal is the wiki's temporal-memory projection and hub. Documents are sorted by a YYYY-MM or YYYY-MM-DD prefix discovered in their path, then bucketed into incident, QA, ops, and learning lanes. Journal content is where the project's working memory, investigations, and dated stories live; it is the answer to "what happened recently, and what did we learn?"

Journal complements Atlas: where Atlas asks "how does the system hang together?", Journal asks "what did the people working on it just discover?".

Codebook implementation map

The Codebook tab starts from implementation hub nodes and then shows the artifacts that ground them: source files, routes, API modules, MCP tools, workers, components, libraries, configs, migrations, and tests. The manifest builder reads inline @graph annotations across the source tree and emits evidence groupings for the page to render. A reader should be able to move from "which implementation realizes this behaviour or idea?" to "which files prove that implementation exists?" in one hop.

Build-time index

The wiki is a single Cloudflare Worker bundle with all content baked in at build time. wiki/src/lib/wiki-index.ts uses import.meta.glob to enumerate every wiki/content/**/*.md at Vite build time. URL mapping (e.g. README.md → directory index) and section grouping happen once, in the build, never at request time. There is no D1, R2, or KV read on the page-load hot path.

Consequence: any page that exists on disk at build time is reachable; any page that does not, is not. There is no "draft" state and no per-request content lookup. To publish, merge to main and ship a new Worker bundle.

SvelteKit on Cloudflare Workers

The wiki runs SvelteKit prerendered as static HTML, served from a Cloudflare Worker. prerender = true on the root layout commits us to that mode: no SSR at request time, no D1 binding on the page-load path, no per-request auth. The app.d.ts ambient platform declaration only types env.APP_MODE, cf, and ctx.waitUntil / passThroughOnException for the few API endpoints that do run at the edge.

Prerendered API surface:

This shape is the wiki-side instance of CareerVector's [[zero-budget-default]] and [[cloudflare-workers-limit-discipline]]: serve static content from the edge, keep the request-time surface minimal.

Admin perspective chrome

The wiki shares its top-of-page chrome — the HeaderBar with perspective switcher and the PrivateFooter — with the other CareerVector admin perspectives (cv-admin-*). The shared chrome is the visible promise that all admin perspectives draw from the same knowledge hub: switch perspective and the chrome stays, the body changes. The Knowledge Hub Control mounts into the right slot of that chrome regardless of which perspective the user is on, so a single graph stays a click away from every tab.