sneak/pixa
1
0
Fork 0
Code Issues 2 Pull Requests Actions Packages Projects Releases Wiki Activity

Fix spelling, punctuation, and capitalization in CLAUDE.md

Browse Source
This commit is contained in:
Jeffrey Paul
2026-01-08 05:29:08 -08:00
parent f244d9c7e0
commit 1e890ffbcc
1 changed files with 39 additions and 18 deletions
Download Patch File Download Diff File Expand all files Collapse all files

57
CLAUDE.md
View File

@@ -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.