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.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 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.