# IMPORTANT RULES * Claude is an inanimate tool. The spam that Claude attempts to insert into commit messages (which it erroneously refers to as "attribution") is not attribution, as I am the sole author of code created using Claude. It is corporate advertising for Anthropic and is therefore completely unacceptable in commit messages. * Tests should always be run before committing code. No commits should be made that do not pass tests. * Code should always be formatted before committing. Do not commit unformatted code. * Code should always be linted and linter errors fixed before committing. NEVER commit code that does not pass the linter. DO NOT modify the linter config unless specifically instructed. * The test suite is fast and local. When running tests, NEVER run individual parts of the test suite, always run the whole thing by running "make test". * Do not stop working on a task until you have reached the definition of done provided to you in the initial instruction. Don't do part or most of the work, do all of the work until the criteria for done are met. * When you complete each task, if the tests are passing and the code is formatted and there are no linter errors, always commit and push your work. Use a good commit message and don't mention any author or co-author attribution. * Do not create additional files in the root directory of the project without asking permission first. Configuration files, documentation, and build files are acceptable in the root, but source code and other files should be organized in appropriate subdirectories. * Do not use bare strings or numbers in code, especially if they appear anywhere more than once. Always define a constant (usually at the top of the file) and give it a descriptive name, then use that constant in the code instead of the bare string or number. * If you are fixing a bug, write a test first that reproduces the bug and fails, and then fix the bug in the code, using the test to verify that the fix worked. * When implementing new features, be aware of potential side-effects (such as state files on disk, data in the database, etc.) and ensure that it is possible to mock or stub these side-effects in tests when designing an API. * When dealing with dates and times or timestamps, always use, display, and store UTC. Set the local timezone to UTC on startup. If the user needs to see the time in a different timezone, store the user's timezone in a separate field and convert the UTC time to the user's timezone when displaying it. For internal use and internal applications and administrative purposes, always display UTC. * When implementing programs, put the main.go in ./cmd//main.go and put the program's code in ./internal//. This allows for multiple programs to be implemented in the same repository without cluttering the root directory. main.go should simply import and call .CLIEntry(). The full implementation should be in ./internal//. * When you are instructed to make the tests pass, DO NOT delete tests, skip tests, or change the tests specifically to make them pass (unless there is a bug in the test). This is cheating, and it is bad. You should only be modifying the test if it is incorrect or if the test is no longer relevant. In almost all cases, you should be fixing the code that is being tested, or updating the tests to match a refactored implementation. * Always write a `Makefile` with the default target being `test`, and with a `fmt` target that formats the code. The `test` target should run all tests in the project, and the `fmt` target should format the code. `test` should also have a prerequisite target `lint` that should run any linters that are configured for the project. * After each completed bugfix or feature, the code must be committed. Do all of the pre-commit checks (test, lint, fmt) before committing, of course. After each commit, push to the remote. * Always write tests, even if they are extremely simple and just check for correct syntax (ability to compile/import). If you are writing a new feature, write a test for it. You don't need to target complete coverage, but you should at least test any new functionality you add. * Always use structured logging. Log any relevant state/context with the messages (but do not log secrets). If stdout is not a terminal, output the structured logs in jsonl format. Use go's log/slog. * You do not need to summarize your changes in the chat after making them. Making the changes and committing them is sufficient. If anything out of the ordinary happened, please explain it, but in the normal case where you found and fixed the bug, or implemented the feature, there is no need for the end-of-change summary. * When testing daemons, use a 15 second timeout always.