The wiki only works if we agree on what belongs in it. The root cause of scattered knowledge is that we never declared what goes where — so durable knowledge leaked into Drive docs and Linear tickets, and no single place could be trusted. This page is the contract.

The rule

Knowledge typeCanonical homeWhy
Processes, runbooks, ADRs, specs, org/ownership, onboardingWikiDurable, discoverable, versioned in git
API reference, code architecture, dev commandsRepo (CLAUDE.md / README / AGENT.md)Lives next to the code, moves with it
Active work: tickets, cycles, statusLinearTransient by nature
Drafts / collaborative editingDrive (scratch only)Nothing canonical lives here
Org chart, HR recordsHR softwareSystem of record; link out, don’t duplicate

Rule of thumb: if you’d be sad to lose it when a Linear ticket is archived or a Drive doc is forgotten, it belongs in the wiki. Linear links out to the wiki spec; the wiki spec does not depend on Linear to be understood.

Wiki vs repo

The dividing line is durability vs. proximity to code:

  • If understanding it requires reading the code alongside it (API endpoints, function contracts, dev setup), it belongs in the repo’s CLAUDE.md / README / AGENT.md.
  • If it’s a decision, a process, a runbook, or a design that outlives any one PR, it belongs in the wiki — even if it references code.

When in doubt, put the decision and rationale in the wiki (as an ADR or spec) and the mechanics in the repo, and link them.

Promoting content into the wiki

  • From Linear: copy durable docs in. Leave the originals in Linear — no redirects needed.
  • From Drive: Drive is scratch only. If something durable is sitting there, promote it to the wiki; otherwise assume it isn’t important enough to keep.

What this is not

This is a default, not a straitjacket. A short-lived experiment doc can live in Linear; a deeply code-coupled note can live in a repo. The point is that the durable, cross-cutting knowledge a new teammate needs has exactly one home: here.