Project structure

Repository layout

api/         .NET 10 API: slicekit.slnx, src/, tests/, Dockerfile
frontend/    Vite + React + TypeScript SPA
docs/        How-to guides (api/ and frontend/)
deploy/      Observability config (OTel collector, Loki, Tempo, Prometheus, Grafana)
.github/     CI workflows
docker-compose.yml        Local infrastructure
docker-compose.prod.yml   Production stack

The repository is a monorepo with two deployable apps plus the infrastructure and tooling that tie them together.

The API

Under api/src/ the solution is split by responsibility:

• Slicekit.Api is the host: endpoints, composition root, middleware.
• Slicekit.Core holds features, domain, persistence and the AppDbContext.

Features live in vertical slices; the domain follows DDD with aggregates that raise events. The two-project split is deliberate: Slicekit.Core has no dependency on the web host, and handlers are invoked over Wolverine’s message bus, so the API is just one possible host. A CLI tool or a worker can dispatch the same commands without touching HTTP code. See the architecture overview for how these fit together.

Solution and dependencies

The backend uses the current .NET build conventions, so there is one obvious place to change each kind of setting:

• slicekit.slnx is the solution file in the new XML format. It replaces the old .sln: no GUIDs, no duplicated project paths, just a readable list you can diff and merge. The dotnet CLI, EF migrations and the test commands all target it directly (dotnet test api/slicekit.slnx).
• Directory.Packages.props turns on central package management: every NuGet version is declared once here, and the .csproj files reference packages by name only. Bumping a dependency, or keeping every project on the same version, is a one-line edit in one file.
• Directory.Build.props carries the settings shared by all projects: net10.0, nullable reference types, implicit usings and the analyzer rules, so no individual .csproj repeats them.

The frontend

Under frontend/src/ the SPA mirrors the API’s slice-per-feature shape. Each feature owns its route, its data hooks and its components, and talks to the API through one shared typed client. See the frontend overview.

Port map

The local development services and their ports:

Service	Port	Notes
Frontend	3003	Vite dev server
API	5076 / 5077	http / https from Kestrel
Postgres	5432
Redis	6379
RabbitMQ	5672 / 15672	broker / management UI
MinIO	9000 / 9001	S3 API / console
Mailpit	1025 / 8025	SMTP / web UI
Grafana	3010
Prometheus	9090
Loki	3100
Tempo	3200

Agent-tool support

The repository follows the AGENTS.md standard. A root AGENTS.md routes to api/AGENTS.md and frontend/AGENTS.md, each describing the conventions for that side. Claude Code loads it via a one-line @AGENTS.md import from CLAUDE.md.