sneak
92f7527cc5
- Connects to RIPE RIS Live stream to receive real-time BGP updates - Stores BGP data in SQLite database: - ASNs with first/last seen timestamps - Prefixes with IPv4/IPv6 classification - BGP announcements and withdrawals - AS-to-AS peering relationships from AS paths - Live routing table tracking active routes - HTTP server with statistics endpoints - Metrics tracking with go-metrics - Custom JSON unmarshaling to handle nested AS sets in paths - Dependency injection with uber/fx - Pure Go implementation (no CGO) - Includes streamdumper utility for debugging raw messages
98 lines
4.8 KiB
Markdown
98 lines
4.8 KiB
Markdown
# 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.
|