From 1e890ffbccd48c2ec2a8c250f97c9d27b40465b4 Mon Sep 17 00:00:00 2001 From: sneak Date: Thu, 8 Jan 2026 05:29:08 -0800 Subject: [PATCH] Fix spelling, punctuation, and capitalization in CLAUDE.md --- CLAUDE.md | 57 +++++++++++++++++++++++++++++++++++++------------------ 1 file changed, 39 insertions(+), 18 deletions(-) diff --git a/CLAUDE.md b/CLAUDE.md index 4f92752..ae5e64b 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -1,38 +1,59 @@ -# repository rules +# Repository Rules -* never use `git add -A` - add specific changes to a deliberate commit. a - commit should contain one change. after each change, make a commit with a +Last Updated 2026-01-08 + +These rules MUST be followed at all times, it is very important. + +* Never use `git add -A` - add specific changes to a deliberate commit. A + commit should contain one change. After each change, make a commit with a good one-line summary. * NEVER modify the linter config without asking first. * NEVER modify tests to exclude special cases or otherwise get them to pass - without asking first. in almost all cases, the code should be changed, - NOT the tests. + without asking first. In almost all cases, the code should be changed, + NOT the tests. If you think the test needs to be changed, make your case + for that and ask for permission to proceed, then stop. You need explicit + user approval to modify existing tests. (You do not need user approval + for writing NEW tests.) -* when linting, assume the linter config is CORRECT, and that each item +* When linting, assume the linter config is CORRECT, and that each item output by the linter is something that legitimately needs fixing in the code. -* when running tests, use `make test`. +* When running tests, use `make test`. -* before commits, run `make check`. this runs `make lint` and `make test` - and `make check-fmt`. any issues discovered must be resolved before +* Before commits, run `make check`. This runs `make lint` and `make test` + and `make check-fmt`. Any issues discovered MUST be resolved before committing unless explicitly told otherwise. -* when fixing a bug, write a failing test for the bug FIRST. add - appropriate logging to the test to ensure it is written correctly. commit - that. then go about fixing the bug until the test passes (without - modifying the test further). then commit that. +* When fixing a bug, write a failing test for the bug FIRST. Add + appropriate logging to the test to ensure it is written correctly. Commit + that. Then go about fixing the bug until the test passes (without + modifying the test further). Then commit that. -* when adding a new feature, do the same - implement a test first (TDD). it - doesn't have to be super complex. commit the test, then commit the +* When adding a new feature, do the same - implement a test first (TDD). It + doesn't have to be super complex. Commit the test, then commit the feature. -* when adding a new feature, use a feature branch. when the feature is +* When adding a new feature, use a feature branch. When the feature is completely finished and the code is up to standards (passes `make check`) - then and only then can the feature branch be merged in to `main` and the + then and only then can the feature branch be merged into `main` and the branch deleted. -* write godoc documentation comments for all exported types and functions as +* Write godoc documentation comments for all exported types and functions as you go along. + +* ALWAYS be consistent in naming. If you name something one thing in one + place, name it the EXACT SAME THING in another place. + +* Be descriptive and specific in naming. `wl` is bad; + `SourceHostWhitelist` is good. `ConnsPerHost` is bad; + `MaxConnectionsPerHost` is good. + +* This is not prototype or teaching code - this is designed for production. + Any security issues (such as denial of service) or other web + vulnerabilities are P1 bugs and must be added to TODO.md at the top. + +* As this is production code, no stubbing of implementations unless + specifically instructed. We need working implementations.