# The BookTracker Sample Application

> **Summary — what this page covers**
> A short tour of the app every lab builds on. Describe what BookTracker is, its four-project
> structure, the stack, and the fact that its CLAUDE.md starts minimal so attendees configure
> it themselves in Lab 1. Keep it to orientation — the real work happens in the labs.

## What it is

**BookTracker** is an ASP.NET Core 10 Minimal API for tracking books and reading progress, backed
by EF Core and SQL Server. You [clone it once](01-before-you-begin.md#clone-booktracker) and evolve
the *same* codebase across all four Day 1 labs — exploring it, steering Claude against it,
connecting it to tooling, and finally building a new feature into it.

It's deliberately sized for learning: small enough to hold in your head by mid-morning, but real
enough to exercise everything Claude Code accelerates — architecture, construction, refactoring,
testing, and debugging. You don't need to know the app in advance; **Lab 1 is partly about using
Claude to learn it for you.**

## Solution structure

```text
BookTracker/
  BookTracker.Api/          # ASP.NET Core 10 Minimal API
  BookTracker.Core/         # Domain entities, DTOs, services, interfaces
  BookTracker.Data/         # EF Core DbContext, migrations
  BookTracker.Tests/        # xUnit test project (initially sparse)
  CLAUDE.md                 # Minimal at start — you configure it in Lab 1
  BookTracker.sln
```

Four projects with a deliberate dependency direction:

- **`BookTracker.Core`** is the center and depends on nothing — domain entities, DTOs, service
  interfaces, and business logic live here.
- **`BookTracker.Data`** depends on Core; it holds the EF Core `DbContext` and migrations.
- **`BookTracker.Api`** depends on Core and Data; it wires up DI and exposes the Minimal API
  endpoints — and stays thin.
- **`BookTracker.Tests`** references the others to test them.

> **You'll capture this yourself.** Lab 1 asks you to record the project dependency structure in
> your CLAUDE.md as "architecture notes" — and to *confirm* the direction above by exploring the
> code with Claude rather than taking it on faith.

## Stack

- C# / .NET 10 · ASP.NET Core **Minimal API** (no controllers — less ceremony, endpoints map
  directly to handlers)
- **EF Core 10** · SQL Server
- **xUnit** for tests

## Conventions you'll formalize today

The starter doesn't spell its conventions out — **you do**, by encoding them as CLAUDE.md facts in
Lab 1 and as path-scoped [rules](05-section-2-steering.md) in Lab 2. The ones this codebase expects:

- **DTOs in `BookTracker.Core/Dtos`** — endpoints accept and return DTOs, never raw EF entities.
- **Never return EF entities** across the API boundary; map to a DTO first.
- **Parameterized queries only** — no string-concatenated SQL.
- **Async all the way** — async endpoints, EF async methods, and thread the `CancellationToken`
  through.
- **Keep endpoints thin** — business logic belongs in Core services, not in the endpoint handler.
- **Migrations live in `BookTracker.Data`** — schema changes go through EF Core migrations.

These are exactly the kind of project-specific rules Section 2 teaches you to *steer* Claude with,
so it follows them automatically as you build.

## Deliberate gaps

The starter ships with **intentional teaching gaps** — missing pieces and rough edges you'll
discover by exploring with Claude in Lab 1. Finding them is the exercise, so we don't list them
here.
