# 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/<program_name>/main.go and put the program's code in
  ./internal/<program_name>/.  This allows for multiple programs to be
  implemented in the same repository without cluttering the root directory.
  main.go should simply import and call <program_name>.CLIEntry().  The
  full implementation should be in ./internal/<program_name>/.

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