Build and Ship a Full-Stack App with AI Coding Assistants

1. Spec

• Wrote docs/spec.md: a small Kanban (boards, columns, cards), must-haves, API paths, and the four-step build (mock UI → OpenAPI → FastAPI in-memory → SQLite later).
• Here we define the must-have functionality, the expected API routes, and the planned order of implementation.

2. Frontend + mock backend

• Built a React/Vite app in frontend/. Every API call goes through frontend/src/services. The first client was createMockBoardService() (in-memory + localStorage), so the board ran with no server.
• createMockBoardService() behaved like a backend but stored information locally in the browser using memory and localStorage. It is useful from a product perspective because it enables testing of the UX before database and backend work. We can answer questions like “Does this workflow make sense?” or “Is creating a card intuitive?”

3. Design record

• Captured those choices as completed items in docs/tasks.md (single service layer, camelCase contract, seeded columns, reindex, no auth, and so on).
• This task.md is a lightweight decision log to help distinguish: “We forgot to build this” vs “We deliberately decided not to build this.”

4. .gitignore

• Added a root ignore file (and tightened the frontend one) for node_modules, env files, Python/venv caches, and editor junk.

5. OpenAPI contract

• Read the service interface and wrote openapi.yaml at the repo root: 12 endpoints, camelCase JSON, { "detail": string } errors, no auth, server http://localhost:8091.
• The OpenAPI file formally defines the backend interface. OpenAPI is the contract between teams. For each API endpoint, it says things such as:

“To create a card, send this HTTP request with these fields, and expect a response in this format.”

6. FastAPI backend

Implemented backend/ with models, store, and routers. Startup seeds a Workshop board for this kanban app.

• FastAPI is the Python framework being used to expose those capabilities over HTTP.

The code is separated into things like models, store, and routers so responsibilities stay reasonably clear:

• models describe what the data looks like;
• store manages the data;
• routers define API endpoints.

As of now, the data is in memory, i.e., it exists while the backend is running but disappears when the backend restarts. It lets you validate the API and business logic before introducing SQLite.

7. Repo layout

Confirmed frontend/, backend/, docs/, and openapi.yaml. Added the missing AGENTS.md (uv/make commands, service-layer rule, keep OpenAPI in sync).

AGENTS.md provides instructions for AI coding agents or developers working on the repository. It documents conventions such as:

• how to start the project;
• how to run tests;
• use uv;
• use make;
• keep API calls behind the service layer;
• update OpenAPI when API behavior changes.

8. added make run to start the intended application runtime

make run (and make backend) starts Uvicorn on 8091. make dev is the frontend; make test runs both test suites.

9. /docs vs openapi.yaml

Opened http://localhost:8091/docs. Paths, methods, and operationIds match. Swagger still advertises 422 and FastAPI validation schemas instead of spec 400/404 + Error; the app itself already returns 400/404 at runtime.

10. Connect frontend to backend

Switched the default client to createHttpBoardService() (http://localhost:8091, or VITE_API_URL).