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 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
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.Coreis the center and depends on nothing — domain entities, DTOs, service interfaces, and business logic live here. -
BookTracker.Datadepends on Core; it holds the EF CoreDbContextand migrations. -
BookTracker.Apidepends on Core and Data; it wires up DI and exposes the Minimal API endpoints — and stays thin. -
BookTracker.Testsreferences 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 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
CancellationTokenthrough. -
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.