How we keep this wiki navigable and trustworthy. Short rules, applied consistently.

Structure

  • Every directory has an index.md that serves as its curated landing page — a short intro plus links to the pages inside, in reading order. Don’t rely on Quartz’s raw folder listing as the entry point. The Honcho specs index is the model.
  • Filenames are kebab-case, no spaces, no capitals (load-testing.md, not Load Testing.md). Slugs become URLs.
  • One top-level section per audience/concern: company/, onboarding/, engineering/, runbooks/, ml/, growth/, office/, meta/. See Source of Truth for what belongs in the wiki at all.

Frontmatter & dates

  • Use title: frontmatter on every page.
  • Do not hand-maintain a date: field. Quartz is configured to show the git last-modified date (CreatedModifiedDate priority frontmatter > git > filesystem, defaultDateType: "modified"), so a stale hand-typed date just masks the real one. Let git drive recency.

Moving & renaming pages

  • When you move a page, grep for inbound links and fix them in the same commit. This is a single repo with a closed link graph, so a find-and-replace is complete.
  • Don’t add aliases: as a habit — redirect stubs accumulate as cruft. Add an alias only for a page with known external inbound links (a URL pasted into Slack or an onboarding email that people have bookmarked).

Specs

  • Active spec is <name>.md. Prior versions rotate to <name>.v1.md, <name>.v2.md, …
  • When a spec ships, move it to the project’s specs/done/ and rewrite it to describe the as-shipped state, with a history pointer to the prior .vN.md.
  • The flow for non-trivial work is spec → Ultraplan → phased PRs.

ADRs

  • One ADR log per project that has architectural decisions (projects/<x>/adr.md). The Honcho ADR is the format to follow: context → decision → consequences, newest at top.

Maintenance discipline

  • Durable artifacts land in the wiki before (or with) the merge. Extend the existing spec-first rule: a non-trivial change ships its spec/ADR/runbook update in the wiki as part of the same work, not “later.”
  • Quarterly staleness review. Sort pages by git last-modified; for anything old, either refresh it, mark it historical, or delete it. Stale-but-present is worse than absent.