LLM Wiki

Appearance

Built 26/04/18 11:07commit 70d11fe

LLM Wiki Operating Architecture ​

中文 | English

Summary ​

This page explains the specific operating architecture shown in the standalone LLM Wiki Architecture diagram: what each region means, what each connector means, and why some relationships are shown explicitly while others are left implicit.

This is narrower than Vault Architecture. The vault-architecture page explains the durable three-layer model of the repository. This page explains the concrete day-to-day operating path from capture to maintenance to publication.

Regions ​

Capture Inputs ​

This region represents the source-entry side of the system.

  • Chrome means browser-side capture through the clipper workflow.
  • Notes means manual text capture, local drafting, and direct markdown edits.
  • Images means screenshots and other visual evidence that may later be interpreted with OCR.

These are separated because they are different input modalities, even though they all eventually influence the same local repository.

Local Knowledge Workspace ​

This region is the local working surface and durable local state.

  • llm-wiki repo is the repository itself, including raw/, wiki/, docs, and repository rules.
  • Obsidian is the primary local reading and editing surface.
  • Bilingual corpus emphasizes that durable pages are maintained in English plus .zh sibling form.
  • Rules and memory refers to AGENTS.md, index.md, and log.md, which shape how maintenance should land.

The local workspace is intentionally modeled as the main hub because the system is local-first: capture, synthesis, and authoring happen here before publication.

Codex Maintenance Boundary ​

This region represents the maintenance layer rather than a separately deployed service.

  • Ingest Loop represents source integration work.
  • Codex agent represents the maintenance session that reads repo rules and performs updates.
  • Wiki outputs represents the durable synthesized result written back into the repository.

The dashed pink outer frame means “logical maintenance boundary,” not an isolated runtime environment.

Versioning & Site Build ​

This region represents the path from maintained local state to shareable site output.

  • Git workflow means local commits and intentional history packaging.
  • GitHub means the canonical remote and shared source of truth.
  • VitePress means the static rendering layer that turns repository content into a readable site.

Hosted Access ​

This region represents delivery and consumption.

  • Vercel hosts the deployment.
  • Public URL is the stable browser entry point.
  • Readers represents actual use from desktop and mobile browsers.

Connector Types ​

The diagram uses different connector styles for different meanings.

  • Solid gray arrows mean primary operating flow.
  • The pink dashed arrow means a secondary maintenance-side path rather than the dominant publish chain.
  • Vertical arrows inside the hosted region are layout-driven simplifications used to keep the right side readable.

The diagram is selective rather than exhaustive. It shows the relationships needed to explain how the system works end to end, not every possible dependency between every box.

Connector-By-Connector Meaning ​

Capture To Workspace ​

  • Chrome -> llm-wiki repo: clipped browser content lands as local source material.
  • Notes -> Obsidian: manual authoring and local editing usually happen through the local editing surface.
  • Images -> Bilingual corpus: screenshots and image evidence often end up informing durable knowledge after interpretation.

These arrows represent the most representative landing paths, not the only paths that can exist.

Workspace To Maintenance ​

  • llm-wiki repo -> Ingest Loop: new or updated source material is the main trigger for ingest work.
  • Obsidian -> Codex agent: local reading, editing, and inspection often precede or accompany maintenance sessions.
  • Bilingual corpus -> Wiki outputs: durable knowledge is extended through maintenance rather than recreated from scratch each time.

Maintenance To Publication ​

  • Codex agent -> GitHub: once maintenance lands as committed repository state, it moves into the canonical shared remote path.
  • GitHub -> Public URL: the public site ultimately depends on the versioned remote state plus deployment flow.

The center-right region does not draw every intermediate arrow between Git workflow, GitHub, VitePress, and Vercel. Those relationships are still real, but the diagram compresses them to keep the main story legible.

Hosted Vertical Arrows ​

  • Public URL -> Vercel: the public endpoint is backed by the hosting platform.
  • Public URL -> Readers: the same endpoint is what readers actually consume in the browser.

These are shown vertically because the hosted region is organized as a stacked delivery block.

Pink Dashed Arrow ​

The pink dashed arrow is intentionally different from the main solid arrows.

  • It denotes a maintenance-side auxiliary path.
  • It is not the main publication pipeline.
  • It exists to show that maintenance activity can feed the broader system without becoming the dominant end-to-end flow.

This is why it is dashed and pink instead of solid gray.

Why Some Boxes Have No Direct Line ​

Missing lines are deliberate.

Shared Region Already Explains The Relationship ​

Some boxes live inside the same region because containment already explains the relationship well enough.

Examples:

  • Obsidian and llm-wiki repo are both inside the local workspace because one is the editing surface for the other.
  • Rules and memory influences maintenance, but the repo rules are already part of the local workspace and the maintenance boundary narrative.

The Relationship Is Real But Not Primary ​

Some dependencies are omitted because drawing them would add density without improving understanding.

Examples:

  • Git workflow -> GitHub
  • GitHub -> VitePress
  • VitePress -> Vercel

Those relationships exist, but drawing each one separately would make the center-right side more crowded while telling roughly the same story already conveyed by the region structure.

The Diagram Prefers Operating Clarity Over Exhaustiveness ​

The goal is not to behave like a dependency graph generator. The goal is to make the operating model easy to read.

So the rule is:

  • draw a line when removing it would make the lifecycle ambiguous
  • omit a line when the enclosing region or adjacent flow already explains the relationship sufficiently

Design Intent ​

The architecture favors a local-first operating model with a compact publication path.

  • capture begins in ordinary local tools
  • durable synthesis is written back into the same repository
  • version control remains visible and intentional
  • publication is automated after repository state is pushed
  • browser access is treated as a downstream presentation layer, not as the editing system itself