Docs point at where a value lives and how to read it, never the value itself

This commit is contained in:
Ian Gulliver
2026-09-21 20:49:17 -07:00
parent aa0715577c
commit 6a9060cbf1
+2
View File
@@ -43,6 +43,7 @@
# Docs
- No dates in docs files, and no changelog-style update framing ("Additions:", "corrected", "changed"). Docs carry current state, historical items, and future plans as one timeless present-tense document; change narrative lives in git history. A document's own revision date (e.g. a datasheet's) is fine.
- Docs point at where a value lives and how to read it - a command that prints it, the console page that holds it - never the value itself. A value copied into a doc is stale the day it is written; a config value, a DNS record, an allowlist, a key's restrictions, a list of hostnames each gets the command or the page, not a snapshot.
# Git
@@ -63,6 +64,7 @@
- Zero comments in new code. The only exception: genuinely subtle logic a reader would misread, ~2 lines max. Design rationale goes in chat/commit message, never in source. Package docs: one line naming what it is.
- Flags are liabilities. Hardcode settled values; always-on behavior over switches. No opt-outs for behavior that's always right.
- No fallback paths. Assume required resources exist and fail loudly (fatal is fine). One path through the code, not two.
- Converting from A to B means switching to B, not writing an abstraction layer over both. Delete A. No interface with two implementations, no adapter, no translation at a boundary, no keeping A's types as the internal representation while B is bolted on — unless there is genuinely no other way, in which case say so and ask first. A layer that lets both exist means the switch never happened: the old one stays wired up, the new one goes untested, and which one is actually running becomes a thing to discover later.
- 750ms is an obscene client request latency. Never accept it as "fine" — move the slow work off the request path (queue it, write back, defer it) rather than making the user wait on it.
- Prefer early return over nested if/else when the if branch exits.
- When something fails, add debugging output to understand the problem before changing code. Don't guess.