# Project structure

> A tour of the repository: the API, the frontend, infrastructure, docs and CI.

## 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](/docs/architecture) 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](/docs/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](https://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`.