About Wiki

TL;DR: The Hussh Wiki is a durable, public/private knowledge layer for Hussh. It turns founder context, product decisions, repo architecture, and reusable artifacts into linked markdown that humans can browse and agents can read through MCP.

Status as of 2026-05-26: This is the canonical public entry point for understanding how the wiki is created and maintained. It intentionally collates the highest-signal wiki-system topics instead of creating a separate page for every implementation detail. The current architecture uses Drive as the private source workspace, Cloud Storage and Firestore as the serving/index plane, and a scheduled Git export as the audit/export/bootstrap mirror until the hosted serving plane finishes its stability window.

Relations

LLM Wiki pattern — landscape & R&D — origin pattern and ecosystem context.
Hussh wiki — scalable app + MCP architecture — runtime architecture.
Public vs private surfaces — public/private visibility contract.
Artifact capture — how generated files, code, diagrams, and docs become durable wiki entries.
Wiki code alignment loop — how founder intent, repo docs, and code stay synchronized.
Codex skill layer — agent-side governance for repeatable wiki, release, design, and audit work.
Claude session wiki-touch protocol — Claude session wiki-touch protocol
Public founder profile — public founder context for the wiki.

Why this exists

Chats are useful for the moment. The wiki is where the durable meaning goes.

The operating idea comes from Andrej Karpathy's LLM Wiki pattern: keep raw sources immutable, maintain synthesized wiki pages, and let a schema/governance layer teach agents how to update the system. Hussh extends that pattern into a live product surface:

public pages for community-readable product philosophy and architecture;
private pages for founder memory, sensitive people/entity context, and work-in-progress material;
MCP tools so agents can search, read, cite, and, when authorized, write;
a Next.js reader so humans and agents use the same canonical content;
Drive source files so content can change without application redeploys;
Cloud Storage and Firestore snapshots so public reads are fast, cacheable, and observable;
Git history so every change remains auditable while the repo mirror is still part of rollback and provenance.

Topic map

Use these pages instead of creating overlapping new pages:

Topic	Read this	Purpose
Origin pattern	LLM Wiki pattern	Explains raw → wiki → schema and where Hussh sits in the broader LLM Wiki landscape.
Runtime architecture	Wiki-as-app architecture	Explains reader, MCP server, Drive source, Cloud Storage/Firestore serving, git audit, search, auth, and deployment.
Public/private rules	Public vs private surfaces	Explains what anonymous users can see and what remains private/auth-gated.
Artifacts	Artifact capture	Explains how code, SVG, Mermaid, HTML, documents, and Drive-backed files are saved.
Human/agent search	Wiki search — dual-audience UX + AX	Explains search design for humans and agents.
Scaling	Wiki scaling and search	Explains how the system grows without collapsing into a slow flat file search.
Repo alignment	Wiki code alignment loop	Explains how implementation decisions become repo docs, wiki pages, or tests.
Agent governance	Codex skill layer	Explains the skill layer that keeps repeatable wiki/release/design workflows consistent.

Update protocol

Future wiki-system captures should patch an existing About Wiki page first. Create a new wiki/about/<slug>.md page only when the capture introduces a genuinely new contract, durable workflow, or reader/MCP behavior that cannot be cleanly folded into the topic map.

Prefer this order:

Update this page when the change is a top-level explanation.
Update one of the topic-map pages when the change belongs to an existing topic.
Add an internal repo doc when the change is operational or developer-facing.
Add a test when the change is a behavior that must not regress.
Remove or consolidate stale overlapping pages when a new page becomes canonical.

This keeps the wiki useful for agents: fewer duplicate pages, stronger canonical anchors, and less need to re-derive which page is authoritative.

Source and serving model

The markdown files in this GitHub repo are still useful, but they should not be treated as the final runtime database.

Current rule:

Keep wiki/** in Git for audit history, review, local development, disaster recovery, and bootstrap until the Drive → Cloud Storage/Firestore plane has passed a production stability window.
Use Drive as the human source workspace for markdown, raw captures, private files, and private artifacts.
Use Cloud Storage and Firestore for public/private serving snapshots, indexes, metadata, dates, aliases, checksums, and self-repair state.
Use the daily backup export job to mirror source markdown into Git; ordinary MCP writes should not create per-write Git commits.
Do not remove repo markdown just to reduce bloat while history, diff, rollback, and export still depend on it.

The end state is not "Drive as a public database." Drive is the authoring/source layer. The serving layer is hosted, indexed, permission-filtered, and cacheable.

Recent platform upgrades

The latest generation of the wiki improves four things:

No-redeploy content flow: content CRUD can move through MCP/Drive and publish derived snapshots without rebuilding the reader.
Scheduled export mirror: Git stays useful for audit, review, and disaster recovery without sitting on the hot write path.
Stronger chronology: published and edited dates are separated, so section pages can sort by name, edited date, or published date without losing original article history.
Safer public/private boundaries: anonymous MCP and public reader surfaces expose only public indexes and sanitized relations; private Drive source files stay restricted.
Lean release checks: ordinary releases now run a core MCP functionality gate, while the full MCP audit remains available for storage, auth, write-tool, and artifact changes.

Agent workflow

When using the wiki through MCP:

Search for the user-facing phrase first.
Read the most specific page, then this page only if system context is needed.
Cite clean reader URLs, not raw markdown paths.
For write access, default uncertain material to private.
Prefer patching canonical pages over creating near-duplicate pages.
After any wiki-system change, check whether a repo doc or test should be updated too.

What belongs here

This domain is for the wiki as a system: how it is structured, governed, queried, written, deployed, and kept aligned with code.

It is not the place for product theses, partnership notes, private founder memory, or implementation runbooks. Those belong in their existing product/concept/entity/project/docs locations.