We work on one application for the whole course. It is called Repair Desk, and it is a small back office for a bike repair shop.
The shop has customers, and customers bring in bikes. Each visit becomes a repair job. A job has lines (a part, a labour charge), a status that moves from received to ready, and a promised date.
Every morning the shop prints a pickup list: the jobs that are ready and promised for today, with the customer’s phone number, so somebody can call them.
Repair Desk does nothing more, and it is small on purpose. It builds in seconds, it needs no Docker and no front end, and it is still real enough to have real problems in it.
The Solution and Its Projects
The solution file is RepairDesk.slnx. That is the newer XML (Extensible Markup Language) solution format. We mention it now because not every tool looks for that name yet, and in module 1 we check what the agent says about the solution against the folder. It holds five projects:
- RepairDesk.Api is the web API. It uses minimal APIs, so every endpoint is written in
Program.cs. This is where the pickup list lives. - RepairDesk.Data holds the entities, the Entity Framework Core context, and the seed data. The database is a SQLite file, created on the first run, through the
Microsoft.EntityFrameworkCore.Sqlitepackage. - RepairDesk.Billing is a second, older web project that produces invoices. It is written with controllers and
Microsoft.AspNetCore.Mvc.NewtonsoftJson, it has no tests, and it runs its database queries in a way we would not write today. We keep it as it is on purpose. It plays the role of legacy code, and in module 8 we refactor it with Claude Code without breaking it. - RepairDesk.UnitTests holds the unit tests.
- RepairDesk.IntegrationTests starts the API in memory with
Microsoft.AspNetCore.Mvc.Testingand calls it over HTTP (Hypertext Transfer Protocol).
Figure 0.1 shows the six classes and the one enum behind those projects, and how they connect. Keep it nearby. Every module from here on touches at least one of them.
Running the API
Let’s run the API once, so you have seen it work. Open a terminal in your module-01 folder and start it with dotnet run --project src/RepairDesk.Api.
The first run creates the SQLite file and seeds it with a few customers, bikes and jobs. It prints every database command it runs, about two hundred lines of CREATE TABLE and INSERT. That is normal.
Then it listens on port 5273. Near the end, look for these four lines:
info: Microsoft.Hosting.Lifetime[14]
Now listening on: http://localhost:5273
info: Microsoft.Hosting.Lifetime[0]
Application started. Press Ctrl+C to shut down.
Leave it running and open a second terminal in the same folder. Now let’s ask for today’s pickup list:
Invoke-RestMethod http://localhost:5273/jobs/pickup-list | Format-Table -AutoSize
curl -s http://localhost:5273/jobs/pickup-list
Two bikes are ready today. PowerShell shows the result as a table:
jobId customer phone description
----- -------- ----- -----------
1 Marta Nowak 011 555 0142 Brakes squeal, rear pads worn
3 Priya Menon 011 555 0119 Flat front tyre
The bash command prints the same two rows as JSON (JavaScript Object Notation). When you are done, press Ctrl+C in the first terminal to stop the API.
Known Problems in the Code
Repair Desk is not perfect, and that is deliberate. We left a few real problems in it, the kind you find in any codebase, so that later modules have something real to fix.
For example, the pickup list you called a moment ago reads the current date in a way that gives a wrong answer around midnight, and no test catches it.
Parts are tracked in stock, but never reserved when a job starts. Package versions are pinned in every project file separately. The Billing project blocks on database calls.
We do not fix any of that now. Each problem has a module waiting for it, and we tell you when we get there. For now, it is enough to know that when Claude Code finds something odd in this code, it is probably one of ours.
In the next lesson, we look at how the course is organized and how to get the most out of it.