How we keep this wiki navigable and trustworthy. Short rules, applied consistently.
Structure
- Every directory has an
index.mdthat 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, notLoad 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 (CreatedModifiedDatepriorityfrontmatter > 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.