server
CLAUDE.md1.1k starsChanged 8 months agoMITView on GitHub
Single test: go test ./internal/server/http/ -run TestAPI_Version Cross-compile: make build-cross GOOS=darwin GOARCH=arm64 The frontend is a pre-built SPA downloaded during make build and embedded via go:embed in internal/frontend/. Buggregator is a debugging server that captures events from various SDKs (Sentry, Ray, Monolog, etc.) over HTTP and TCP, stores them in SQLite, and broadcasts to connected WebSocket clients in real time. Entry point is cmd/buggregator/main.go. It creates all modules, registers them with a module.Registry, builds an EventService, injects it into TCP…
In this repositoryOne other file it gives its agents.
- sentry-sdk-testingSkill
The file
We split this CLAUDE.md into the rules it gives an agent
1 rule. About 0 are common, 0 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈0
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 37
Every module implements module.Module (internal/module/module.go).
≈ “Common” is an estimate: at least 1 in 5 of the 26,980 CLAUDE.md files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
CLAUDE.md
This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
Build & Development Commands
make build # Full build: downloads frontend, builds PHP parser, compiles binary
make run # Build and run
go build ./... # Quick Go compilation check
go test ./... # Run all tests
go vet ./... # Lint (also used in CI)Single test: go test ./internal/server/http/ -run TestAPI_Version
Cross-compile: make build-cross GOOS=darwin GOARCH=arm64
The frontend is a pre-built SPA downloaded during make build and embedded via go:embed in internal/frontend/.
Architecture
Buggregator is a debugging server that captures events from various SDKs (Sentry, Ray, Monolog, etc.) over HTTP and TCP, stores them in SQLite, and broadcasts to connected WebSocket clients in real time.
Startup & Wiring
Entry point is cmd/buggregator/main.go. It creates all modules, registers them with a module.Registry, builds an
EventService, injects it into TCP modules via SetEventService(), then passes everything to app.New() which
orchestrates startup in app.Run().
Two EventService instances exist: one in main.go (for TCP modules) and one in app.go (for the HTTP ingestion
pipeline). Both share the same store and hub.
Module System
Every module implements module.Module (internal/module/module.go). Use BaseModule for no-op defaults. Modules are
either HTTP-based or TCP-based:
- HTTP modules return an
HTTPIngestionHandlerwithPriority(),Match(*http.Request), andHandle(*http.Request). Lower priority runs first. The http-dump module has priority 9999 as the catch-all. - TCP modules return
[]tcp.ServerConfigwith either aConnectionHandler(generic accept loop) or aStarter( self-managed, like SMTP's go-smtp server).
Registration order matters: http-dump must be registered last.
Ingestion Pipeline
internal/server/http/ingestion.go — the pipeline for HTTP events:
- Detect (
detect.go): Extract event type/project from URI userinfo (sentry@host), headers (X-Buggregator-Event), or Basic Auth - Match: Try handlers in priority order; first match wins
- Handle: Parse request body → return
event.Incoming - Store & Broadcast (
event_service.go): Store in SQLite → build preview → broadcast via WebSocket hub → notify modules (OnEventStored)
Unmatched requests fall through to the embedded frontend SPA.
WebSocket Protocol
The hub (internal/server/ws/hub.go) implements the Centrifugo v5 JSON protocol. Clients auto-subscribe to
events.project.{key} channels. RPC calls are bridged to HTTP handlers via MuxRPCHandler.
Storage
event.Store interface in internal/event/store.go. Single implementation: SQLiteStore in
internal/storage/sqlite.go (pure Go SQLite via modernc.org/sqlite, single-writer mode).
Migrations live in each module and run via storage.Migrator. Attachments use a pluggable AttachmentStore (in-memory
or filesystem).
Metrics
internal/metrics/ provides optional Prometheus instrumentation. Enabled via config (metrics.enabled: true).
InstrumentedStore decorates event.Store. HTTP middleware captures request metrics. The hub and TCP manager report
connection gauges.
Config Priority
CLI flags > environment variables > buggregator.yaml > defaults. YAML supports ${VAR:default} substitution. See
buggregator.yaml.example.
Test Patterns
Tests use storage.Open(":memory:") for in-memory SQLite, t.Helper() setup functions, t.Cleanup() for teardown, and
table-driven subtests. Handler tests call module methods directly with httptest.NewRequest() and check the returned
*event.Incoming.
Pass nil for optional dependencies like *metrics.Collector in tests.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

