AI SummaryA layered backend architecture ruleset for Go/TypeScript projects that enforces clean dependency patterns (core → infra → database/permission → server) to maintain code organization and testability in internal tools. Ideal for teams building admin dashboards and CRUD applications who need consistent architectural guidance.
Install
Copy this and paste it into Claude Code, Cursor, or any AI assistant:
I want to add the "sourcetool — Windsurf Rules" prompt rules to my project. Repository: https://github.com/trysourcetool/sourcetool Please read the repo to find the rules/prompt file, then: 1. Download it to the correct location (.cursorrules, .windsurfrules, .github/prompts/, or project root — based on the file type) 2. If there's an existing rules file, merge the new rules in rather than overwriting 3. Confirm what was added
Description
Build internal agents with just backend code.
Backend architecture (/backend)
These rules reflect the current package layout (server → {database, pubsub, mail, permission} → infra → core). Use them for all new code reviews and CI checks. ---
Layer map & allowed imports
| Layer & path | Purpose | May import | |------------------------------------------------|------------------------------------------------------|------------------------------------------------------| | core internal/core/ | Pure domain entities & helpers – no I/O | stdlib**, tiny 3rd‑party (uuid, errors) | | database internal/database/ | Database interfaces & query builders | core**, stdlib, sqlx | | infra internal/{postgres,mail,pubsub,ws}/ | Concrete adapters (DB, SMTP, Redis, WS) | core, database**, support pkgs, stdlib, 3rd‑party | | permission internal/permission/ | Authorization & RBAC implementation | core, database**, support pkgs, stdlib | | server internal/server/ | HTTP/WS routers, handlers, DTOs, middleware | core, database, infra, permission**, support pkgs, stdlib, 3rd‑party | | support internal/{config,logger,jwt,google,errdefs}, internal/context.go, internal/url.go, internal/pb/go/** | Cross‑cutting util & generated code | usable from any layer (never import internal/server from support pkgs) |
Dependency direction
` server → {database, pubsub, mail, permission} → infra → core ` • core never depends on adapters or HTTP. • database defines interfaces and query builders for data persistence. • infra implements concrete adapters (DB, Redis, SMTP) and depends on core. • pubsub, mail, and permission provide high-level services using infra implementations. • server wires everything; it can depend on any layer below. ---
Directory conventions
• Core package per model (apikey, user, …) containing structs and small helper methods. • Database package contains: • Model interfaces and base types (internal/database/<model>.go) • Common database utilities and interfaces (internal/database/database.go) • Infra adapter per tech: • internal/postgres/<model>.go (concrete SQL implementations) • internal/postgres/<model>_ce.go and <model>_ee.go (edition-specific implementations) • internal/pubsub/redis.go • internal/mail/smtp.go • internal/ws/manager.go • internal/permission/checker.go • Server keeps CE/EE variations with build‑tag files inside the same directory tree (e.g. group_ee.go, websocket_ee.go). There is no separate ee/internal directory. • internal/server/middleware.go, validate.go, etc. • Composition root: cmd/server/main.go (sets up config, DB, Redis, SMTP, WS manager, router). Tests live next to code (_test.go) and cross layers only via exported interfaces. ---
Discussion
Health Signals
My Fox Den
Community Rating
Sign in to rate this booster
Works With
Any AI assistant that accepts custom rules or system prompts