C0 — Set Up & Explore the BookTracker Starter

Summary — what this page covers Get your machine ready, pull the BookTracker starter at the C0 checkpoint, build it, run it, and take a guided tour of the code. C0 is the starting line for the whole two-day workshop — every later lab (C1 → C10) evolves this same solution.

Time: ~30 minutes · Format: hands-on, solo · You end at: checkpoint/c0-base

C0 is the base starter you clone. It compiles and runs, it's small enough to read in one sitting, and it deliberately ships with a few rough edges you'll discover and fix across the two days. Your goal in this lab is simply to get it running and learn your way around — no code changes yet.

1. Prerequisites

Install these before you start:

You'll also need these later (not for C0 — install when the relevant lab says so):

• Day 1 (Claude Code labs): the Claude Code CLI and a paid Claude plan.
• Day 2 (Anthropic C# SDK labs): an Anthropic API key; plus Docker and Ollama for the Day 2 RAG lab.

The two days have different access requirements — Day 1 uses Claude Code (paid Claude plan), Day 2 uses the Anthropic API (a separate API key). You do not need either for C0.

2. Get the starter at the C0 checkpoint

The workshop is one solution that evolves across 11 git tags (checkpoint/c0-base … checkpoint/c10-responsible-ai). You always start a lab from the previous checkpoint. For C0, start at checkpoint/c0-base.

# clone the workshop repository
git clone https://github.com/cwoodruff/dotnet-claude-workshop.git
cd dotnet-claude-workshop

# start a working branch from the C0 checkpoint
git switch -c my-booktracker checkpoint/c0-base

# everything you run happens inside the solution folder
cd src/BookTracker

Working on a branch (my-booktracker) keeps your changes separate and lets you compare against any checkpoint later. If you fall behind during the workshop, you can re-base your branch on a newer checkpoint (e.g. checkpoint/c4-reading-progress) to jump to the Day 2 starting line.

3. Build it

dotnet build BookTracker.sln

Expect Build succeeded with 0 errors. The starter restores its NuGet packages and compiles all four projects.

4. Run the tests

dotnet test BookTracker.sln

A small number of tests pass (the starter's test project is intentionally sparse). As you explore, keep a running question in mind: "what isn't covered here?" — building out tests is part of the journey.

5. Run the API

dotnet run --project BookTracker.Api

On startup the app applies its EF Core migration and seeds the database, so it works straight from a clone (a local SQLite file, booktracker.db, appears). Watch the console for the listening URL — by default:

Now listening on: http://localhost:5255

Open a second terminal and exercise the endpoints (the starter exposes Books and Authors CRUD):

# root sanity check
curl http://localhost:5255/                       # → BookTracker API

# list all books (returns DTOs, newest-style ordering by title)
curl http://localhost:5255/api/books

# one book by id
curl http://localhost:5255/api/books/1

# search books by title
curl "http://localhost:5255/api/books/search?q=clean"

# list authors
curl http://localhost:5255/api/authors

# create a book (note the request shape)
curl -X POST http://localhost:5255/api/books \
  -H "Content-Type: application/json" \
  -d '{"title":"Refactoring","authorId":2,"isbn":"9780134757599","totalPages":448,"genre":"Software"}'

Press Ctrl+C to stop the server when you're done.

The seed data ships a handful of real authors and books (e.g. The Pragmatic Programmer, Clean Code, Domain-Driven Design, Dune, The Name of the Wind), so every call above returns real data.

6. Tour the architecture

The solution is four projects with a deliberate dependency direction — Core depends on nothing, and everything points inward toward it:

BookTracker.Core   ← BookTracker.Data   ← BookTracker.Api
        ▲                  ▲                    ▲
        └──────────────────┴────────────────────┘
                     BookTracker.Tests

Key conventions to notice while you read:

• Repository pattern. Endpoints call Core services; services orchestrate repository ports; the EF Core implementations live in Data/Repositories. This is why Core never references EF.

• DTOs at the boundary. Endpoints return DTOs from Core/Dtos — never EF entities.

• Minimal API, no controllers. Each resource is a MapGroup in Api/Endpoints/*.cs, registered in Program.cs (app.MapBookEndpoints(), app.MapAuthorEndpoints()).

Open these files in your IDE to get oriented:

• BookTracker.Api/Program.cs — startup, DI, migrate + seed, route mapping.
• BookTracker.Api/Endpoints/BookEndpoints.cs — the Books routes.
• BookTracker.Core/Services/BookService.cs — business logic over the repositories.
• BookTracker.Data/Repositories/BookRepository.cs — the EF Core data access.
• BookTracker.Data/SeedData.cs — the seeded authors and books.

7. Notice the rough edges (this sets up Lab 1)

The starter is intentionally imperfect — it carries deliberate, discoverable gaps that you'll analyze and fix across the labs. Don't fix anything yet. Instead, as you read the code, keep a notepad and jot down anything that looks risky, unfinished, or inconsistent.

A few places worth a close look (no spoilers — just where to point your attention):

• How does BookRepository.SearchByTitleAsync build its SQL query?
• What validation happens (or doesn't) when you POST a new book?
• Which behaviors are actually covered by BookTracker.Tests?
• Is anything returned across the API boundary that probably shouldn't be?

You'll turn these observations into a structured gap analysis in Lab 1 (C0 → C1), then start encoding the fixes as project conventions.

✅ Checkpoint — you're done with C0 when:

• dotnet build reports Build succeeded.
• dotnet test runs and the (sparse) tests pass.
• dotnet run --project BookTracker.Api starts and the curl calls above return real data.
• You can find your way around the four projects and explain the dependency direction.
• You've jotted down a few things that look like deliberate gaps.

What's next

Lab 1 (C0 → C1): you'll point Claude Code at this starter, run a gap analysis, and write a project CLAUDE.md that captures the architecture and conventions — the project briefing Claude loads on every session.