# 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:

| Tool | Why | Check |
| --- | --- | --- |
| **.NET 10 SDK** | builds and runs the solution | `dotnet --version` → `10.*` |
| **Git** | gets the code and switches checkpoints | `git --version` |
| **An IDE** | reading/editing C# — VS Code (+ **C# Dev Kit**), Visual Studio, or JetBrains Rider | opens the folder |

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

```bash
# 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

```bash
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

```bash
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

```bash
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):

```bash
# 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:

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

| Project | What's inside |
| --- | --- |
| **BookTracker.Core** | Entities (`Book`, `Author`), DTOs (`Core/Dtos`), service interfaces + logic (`Core/Services`), and **persistence *ports*** (`Core/Interfaces`, e.g. `IBookRepository`). Depends on nothing — it stays free of EF Core. |
| **BookTracker.Data** | EF Core `BookTrackerDbContext`, the **repository implementations** (`Data/Repositories`), migrations, and seed data. → Core. |
| **BookTracker.Api** | Minimal API endpoints (`Api/Endpoints`, wired in `Program.cs`), DI, request/response mapping. → Core, Data. |
| **BookTracker.Tests** | xUnit tests (sparse, on purpose). → all of the above. |

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.