Initial commit: RouteWatch BGP stream monitor

- 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

CLAUDE.md

@@ -0,0 +1,97 @@
+# 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.