Tasks:
- [x] Add `GET /api/kanban` to fetch the current user's board.
- [x] Add `PUT /api/kanban` to persist updates.
- [x] Initialize or migrate the SQLite database automatically.
- [x] Add backend tests for API route behavior and persistence.

# Implementation Plan for Project Management MVP

This document defines the detailed plan for the MVP, including substeps, success criteria, and verification for each part. The goal is to keep the work minimal, focused, and easy to validate.

Current implementation status: all parts (1-10) are complete. The project uses a Next.js frontend with client-side login, a FastAPI backend, and SQLite persistence. The Docker setup builds the frontend and serves it statically from the backend. The board state is stored as JSON in the database. The frontend loads and saves board data through `/api/kanban`. AI integration is live via OpenRouter (`openai/gpt-oss-120b`) at `/api/ai/kanban`, and the AI chat sidebar is implemented in the frontend.

Design decisions:
- Use `FastAPI` to serve the built frontend from `/` and expose JSON APIs.
- Use SQLite with a `boards` table storing user board data as JSON.
- Implement auth as a simple client-side gate with hardcoded `user` / `password` for MVP.
- Use `GET /api/kanban` and `PUT /api/kanban` for board persistence.
- Keep the UI minimal and avoid extra advanced features until AI integration.

## Part 1: Plan

Goal: Confirm the implementation sequence and clarify expected outputs before work begins.

Tasks:
- [x] Review the existing repo structure and frontend behavior.
- [x] Define deliverables for Docker, backend, frontend, and AI work.
- [x] Get user approval of this plan before starting implementation.
- Note: `frontend/AGENTS.md` was dropped from scope.

Success criteria:
- The plan includes clear substeps for every part of the project.
- Test expectations are defined for each milestone.

Verification:
- User confirms the plan and approves progression to Part 2.

## Part 2: Scaffolding

Goal: Create the runtime foundation with Docker and a minimal FastAPI backend.

Tasks:
- [x] Add `Dockerfile` and any container orchestration files needed.
- [x] Initialize FastAPI backend in `backend/`.
- [x] Add start/stop scripts under `scripts/` for macOS, Windows, and Linux.
- [x] Implement a `backend/main.py` with a health route and static file serving placeholder.
- [x] Ensure frontend build artifacts can be served from `/`.

Success criteria:
- Docker image builds successfully.
- Container starts and exposes the backend.
- `GET /api/hello` or `/health` returns a valid JSON response.
- `GET /` returns a static placeholder or the frontend shell.

Verification:
- Run the app locally and confirm the API and root route respond as expected.

## Part 3: Add in Frontend

Goal: Wire the existing Next.js frontend into the containerized backend.

Tasks:
- [x] Confirm the current frontend build works from `frontend/`.
- [x] Add build steps for the frontend in Docker or startup scripts.
- [x] Serve the built frontend from the FastAPI backend at `/`.
- [x] Preserve the demo Kanban board UI on the root route.
- [x] Add at least one integration test verifying the frontend is served.

Success criteria:
- Visiting `/` displays the demo Kanban board when the container is running.
- Frontend build and static serve flow is validated.
- Existing frontend tests still pass.

Verification:
- Manual validation of the served Kanban board.
- Run tests and confirm baseline frontend behavior remains intact.

## Part 4: Fake User Sign In Experience

Goal: Add a dummy login screen before the Kanban board is accessible.

Tasks:
- [x] Add login UI requiring `user` and `password`.
- [x] Protect the Kanban view with client-side auth state.
- [x] Add logout functionality.
- [x] Add tests covering login success, login failure, and logout.

Success criteria:
- The Kanban board is only available after correct credentials are entered.
- Logout returns the user to the login screen.
- Auth flow is simple and local.

Verification:
- Automated UI tests confirm login/logout behavior.
- Manual validation confirms the auth flow works.

## Part 5: Database Modeling

Goal: Define a simple SQLite schema for storing Kanban data.

Tasks:
- [x] Design a schema with `users` and `boards` tables.
- [x] Store the board shape as JSON in a `boards` table row.
- [x] Document the schema and rationale in `docs/`.
- [x] Confirm the schema supports one board per user and future multi-user extension.
- [x] Get approval for the schema design.

Success criteria:
- Schema is minimalist and fits the MVP requirements.
- Documentation explains user-board mapping and JSON storage.
- Database can create its schema automatically if missing.

Verification:
- User review and approval of the database model.
- Schema documentation exists in `docs/`.

## Part 6: Backend API

Goal: Implement API routes for loading and saving user Kanban state.

Tasks:
- [ ] Add `GET /api/kanban` to fetch the current user's board.
- [ ] Add `POST /api/kanban` or `PUT /api/kanban` to persist updates.
- [ ] Initialize or migrate the SQLite database automatically.
- [ ] Add backend tests for API route behavior and persistence.

Success criteria:
- Backend can read and write board JSON for a specific user.
- API returns appropriate HTTP status codes and payloads.
- Database file is created on first use.

Verification:
- Backend tests exercise read/write and error paths.
- API calls against a local test database succeed.

## Part 7: Frontend + Backend Integration

Goal: Make the frontend use the backend API for actual persistence.

Tasks:
- [ ] Replace hardcoded board data with API fetches to `/api/kanban`.
- [ ] Save board updates through backend calls to `/api/kanban` using `PUT`.
- [ ] Ensure drag/drop, editing, and column rename actions persist after refresh.
- [ ] Add integration tests for data loading and saving.
- [ ] Confirm client-side auth gating still works with the API-backed board.

Success criteria:
- Page refresh preserves board changes.
- Backend persistence is active and reliable.
- Frontend calls `fetchKanban` and `saveKanban` wrappers.
- Auth flow remains intact with the API-supported board.

Verification:
- Manual scenario: login, move a card, refresh, and verify state persists.
- Automated integration or unit test coverage exists for the API-backed board.

## Part 8: AI Connectivity

Goal: Confirm backend AI connectivity using OpenRouter.

Tasks:
- [ ] Add OpenRouter client integration in the backend.
- [ ] Use `OPENROUTER_API_KEY` from `.env` securely.
- [ ] Create a simple test route such as `/api/ai/test`.
- [ ] Validate a basic prompt like `2+2` returns a correct answer.
- [ ] Add tests for the AI connectivity path.

Success criteria:
- Backend can call OpenRouter successfully.
- A basic AI test prompt returns expected output.
- Errors are handled gracefully.

Verification:
- Run the AI test route and confirm the expected answer.
- Ensure no API key is hardcoded.

Note: AI integration is still pending; the current implementation has backend persistence and frontend auth working, with AI planned for the next phase.

## Part 9: Structured AI Output for Kanban Updates

Goal: Enable the backend to send the board JSON plus user prompt to the AI and parse structured responses.

Tasks:
- [ ] Send the current Kanban JSON and user question to the AI.
- [ ] Define a structured response schema for text and optional board updates.
- [ ] Implement backend parsing and optional update application.
- [ ] Add tests for valid and invalid AI responses.

Success criteria:
- AI route returns both user-friendly text and optional update instructions.
- The backend only applies board updates when the structured output is valid.
- The board JSON is always passed to the AI.

Verification:
- Backend tests simulate AI responses and verify update behavior.
- Manual check confirms the AI route returns structured output.

## Part 10: AI Chat Sidebar and Auto-Update

Goal: Add a UI chat panel that allows the AI to update the board in real time.

Tasks:
- [ ] Add an AI chat sidebar in the authenticated Kanban screen.
- [ ] Send chat messages to the backend and display AI replies.
- [ ] Apply board updates automatically when the AI response includes them.
- [ ] Keep the UI minimal and consistent with the existing app.
- [ ] Add tests for chat interaction and board refresh behavior.

Success criteria:
- User can chat with AI while viewing the board.
- AI replies display in the sidebar immediately.
- Board updates from the AI refresh the UI automatically.

Verification:
- Manual flow: ask the AI to add or edit a card and confirm the board updates.
- Automated tests cover chat submission and UI refresh.

## Acceptance Criteria

- The app runs locally in Docker and serves the frontend at `/`.
- Users authenticate with `user` / `password` to reach the Kanban board.
- Kanban state persists in a backend SQLite database.
- AI connectivity works via OpenRouter.
- A chat sidebar exists and can trigger board updates.
- Tests cover backend APIs, frontend auth, and AI integration.

## Notes

- Keep scope minimal and avoid extra features.
- Prefer simple, readable implementations.
- If issues arise, identify the root cause before fixing.

-- [ ] Add `GET /api/kanban` to fetch the current user's board.

-- [ ] Add `POST /api/kanban` or `PUT /api/kanban` to persist updates.

-- [ ] Initialize or migrate the SQLite database automatically.

-- [ ] Add backend tests for API route behavior and persistence.

+- [x] Add `GET /api/kanban` to fetch the current user's board.

+- [x] Add `PUT /api/kanban` to persist updates.

+- [x] Initialize or migrate the SQLite database automatically.

+- [x] Add backend tests for API route behavior and persistence.


Edit

Tasks:
- [ ] Replace hardcoded board data with API fetches to `/api/kanban`.
- [ ] Save board updates through backend calls to `/api/kanban` using `PUT`.
- [ ] Ensure drag/drop, editing, and column rename actions persist after refresh.
- [ ] Add integration tests for data loading and saving.
- [ ] Confirm client-side auth gating still works with the API-backed board.

Tasks:
- [x] Replace hardcoded board data with API fetches to `/api/kanban`.
- [x] Save board updates through backend calls to `/api/kanban` using `PUT`.
- [x] Ensure drag/drop, editing, and column rename actions persist after refresh.
- [x] Add integration tests for data loading and saving.
- [x] Confirm client-side auth gating still works with the API-backed board.


The file /Users/khalidbinkalban/Desktop/Finally/docs/PLAN.md has been updated successfully.

Tasks:
- [x] Replace hardcoded board data with API fetches to `/api/kanban`.
- [x] Save board updates through backend calls to `/api/kanban` using `PUT`.
- [x] Ensure drag/drop, editing, and column rename actions persist after refresh.
- [x] Add integration tests for data loading and saving.
- [x] Confirm client-side auth gating still works with the API-backed board.

# Implementation Plan for Project Management MVP

This document defines the detailed plan for the MVP, including substeps, success criteria, and verification for each part. The goal is to keep the work minimal, focused, and easy to validate.

Current implementation status: all parts (1-10) are complete. The project uses a Next.js frontend with client-side login, a FastAPI backend, and SQLite persistence. The Docker setup builds the frontend and serves it statically from the backend. The board state is stored as JSON in the database. The frontend loads and saves board data through `/api/kanban`. AI integration is live via OpenRouter (`openai/gpt-oss-120b`) at `/api/ai/kanban`, and the AI chat sidebar is implemented in the frontend.

Design decisions:
- Use `FastAPI` to serve the built frontend from `/` and expose JSON APIs.
- Use SQLite with a `boards` table storing user board data as JSON.
- Implement auth as a simple client-side gate with hardcoded `user` / `password` for MVP.
- Use `GET /api/kanban` and `PUT /api/kanban` for board persistence.
- Keep the UI minimal and avoid extra advanced features until AI integration.

## Part 1: Plan

Goal: Confirm the implementation sequence and clarify expected outputs before work begins.

Tasks:
- [x] Review the existing repo structure and frontend behavior.
- [x] Define deliverables for Docker, backend, frontend, and AI work.
- [x] Get user approval of this plan before starting implementation.
- Note: `frontend/AGENTS.md` was dropped from scope.

Success criteria:
- The plan includes clear substeps for every part of the project.
- Test expectations are defined for each milestone.

Verification:
- User confirms the plan and approves progression to Part 2.

## Part 2: Scaffolding

Goal: Create the runtime foundation with Docker and a minimal FastAPI backend.

Tasks:
- [x] Add `Dockerfile` and any container orchestration files needed.
- [x] Initialize FastAPI backend in `backend/`.
- [x] Add start/stop scripts under `scripts/` for macOS, Windows, and Linux.
- [x] Implement a `backend/main.py` with a health route and static file serving placeholder.
- [x] Ensure frontend build artifacts can be served from `/`.

Success criteria:
- Docker image builds successfully.
- Container starts and exposes the backend.
- `GET /api/hello` or `/health` returns a valid JSON response.
- `GET /` returns a static placeholder or the frontend shell.

Verification:
- Run the app locally and confirm the API and root route respond as expected.

## Part 3: Add in Frontend

Goal: Wire the existing Next.js frontend into the containerized backend.

Tasks:
- [x] Confirm the current frontend build works from `frontend/`.
- [x] Add build steps for the frontend in Docker or startup scripts.
- [x] Serve the built frontend from the FastAPI backend at `/`.
- [x] Preserve the demo Kanban board UI on the root route.
- [x] Add at least one integration test verifying the frontend is served.

Success criteria:
- Visiting `/` displays the demo Kanban board when the container is running.
- Frontend build and static serve flow is validated.
- Existing frontend tests still pass.

Verification:
- Manual validation of the served Kanban board.
- Run tests and confirm baseline frontend behavior remains intact.

## Part 4: Fake User Sign In Experience

Goal: Add a dummy login screen before the Kanban board is accessible.

Tasks:
- [x] Add login UI requiring `user` and `password`.
- [x] Protect the Kanban view with client-side auth state.
- [x] Add logout functionality.
- [x] Add tests covering login success, login failure, and logout.

Success criteria:
- The Kanban board is only available after correct credentials are entered.
- Logout returns the user to the login screen.
- Auth flow is simple and local.

Verification:
- Automated UI tests confirm login/logout behavior.
- Manual validation confirms the auth flow works.

## Part 5: Database Modeling

Goal: Define a simple SQLite schema for storing Kanban data.

Tasks:
- [x] Design a schema with `users` and `boards` tables.
- [x] Store the board shape as JSON in a `boards` table row.
- [x] Document the schema and rationale in `docs/`.
- [x] Confirm the schema supports one board per user and future multi-user extension.
- [x] Get approval for the schema design.

Success criteria:
- Schema is minimalist and fits the MVP requirements.
- Documentation explains user-board mapping and JSON storage.
- Database can create its schema automatically if missing.

Verification:
- User review and approval of the database model.
- Schema documentation exists in `docs/`.

## Part 6: Backend API

Goal: Implement API routes for loading and saving user Kanban state.

Tasks:
- [x] Add `GET /api/kanban` to fetch the current user's board.
- [x] Add `PUT /api/kanban` to persist updates.
- [x] Initialize or migrate the SQLite database automatically.
- [x] Add backend tests for API route behavior and persistence.

Success criteria:
- Backend can read and write board JSON for a specific user.
- API returns appropriate HTTP status codes and payloads.
- Database file is created on first use.

Verification:
- Backend tests exercise read/write and error paths.
- API calls against a local test database succeed.

## Part 7: Frontend + Backend Integration

Goal: Make the frontend use the backend API for actual persistence.

Tasks:
- [ ] Replace hardcoded board data with API fetches to `/api/kanban`.
- [ ] Save board updates through backend calls to `/api/kanban` using `PUT`.
- [ ] Ensure drag/drop, editing, and column rename actions persist after refresh.
- [ ] Add integration tests for data loading and saving.
- [ ] Confirm client-side auth gating still works with the API-backed board.

Success criteria:
- Page refresh preserves board changes.
- Backend persistence is active and reliable.
- Frontend calls `fetchKanban` and `saveKanban` wrappers.
- Auth flow remains intact with the API-supported board.

Verification:
- Manual scenario: login, move a card, refresh, and verify state persists.
- Automated integration or unit test coverage exists for the API-backed board.

## Part 8: AI Connectivity

Goal: Confirm backend AI connectivity using OpenRouter.

Tasks:
- [ ] Add OpenRouter client integration in the backend.
- [ ] Use `OPENROUTER_API_KEY` from `.env` securely.
- [ ] Create a simple test route such as `/api/ai/test`.
- [ ] Validate a basic prompt like `2+2` returns a correct answer.
- [ ] Add tests for the AI connectivity path.

Success criteria:
- Backend can call OpenRouter successfully.
- A basic AI test prompt returns expected output.
- Errors are handled gracefully.

Verification:
- Run the AI test route and confirm the expected answer.
- Ensure no API key is hardcoded.

Note: AI integration is still pending; the current implementation has backend persistence and frontend auth working, with AI planned for the next phase.

## Part 9: Structured AI Output for Kanban Updates

Goal: Enable the backend to send the board JSON plus user prompt to the AI and parse structured responses.

Tasks:
- [ ] Send the current Kanban JSON and user question to the AI.
- [ ] Define a structured response schema for text and optional board updates.
- [ ] Implement backend parsing and optional update application.
- [ ] Add tests for valid and invalid AI responses.

Success criteria:
- AI route returns both user-friendly text and optional update instructions.
- The backend only applies board updates when the structured output is valid.
- The board JSON is always passed to the AI.

Verification:
- Backend tests simulate AI responses and verify update behavior.
- Manual check confirms the AI route returns structured output.

## Part 10: AI Chat Sidebar and Auto-Update

Goal: Add a UI chat panel that allows the AI to update the board in real time.

Tasks:
- [ ] Add an AI chat sidebar in the authenticated Kanban screen.
- [ ] Send chat messages to the backend and display AI replies.
- [ ] Apply board updates automatically when the AI response includes them.
- [ ] Keep the UI minimal and consistent with the existing app.
- [ ] Add tests for chat interaction and board refresh behavior.

Success criteria:
- User can chat with AI while viewing the board.
- AI replies display in the sidebar immediately.
- Board updates from the AI refresh the UI automatically.

Verification:
- Manual flow: ask the AI to add or edit a card and confirm the board updates.
- Automated tests cover chat submission and UI refresh.

## Acceptance Criteria

- The app runs locally in Docker and serves the frontend at `/`.
- Users authenticate with `user` / `password` to reach the Kanban board.
- Kanban state persists in a backend SQLite database.
- AI connectivity works via OpenRouter.
- A chat sidebar exists and can trigger board updates.
- Tests cover backend APIs, frontend auth, and AI integration.

## Notes

- Keep scope minimal and avoid extra features.
- Prefer simple, readable implementations.
- If issues arise, identify the root cause before fixing.

-- [ ] Replace hardcoded board data with API fetches to `/api/kanban`.

-- [ ] Save board updates through backend calls to `/api/kanban` using `PUT`.

-- [ ] Ensure drag/drop, editing, and column rename actions persist after refresh.

-- [ ] Add integration tests for data loading and saving.

-- [ ] Confirm client-side auth gating still works with the API-backed board.

+- [x] Replace hardcoded board data with API fetches to `/api/kanban`.

+- [x] Save board updates through backend calls to `/api/kanban` using `PUT`.

+- [x] Ensure drag/drop, editing, and column rename actions persist after refresh.

+- [x] Add integration tests for data loading and saving.

+- [x] Confirm client-side auth gating still works with the API-backed board.


Tasks:
- [ ] Add OpenRouter client integration in the backend.
- [ ] Use `OPENROUTER_API_KEY` from `.env` securely.
- [ ] Create a simple test route such as `/api/ai/test`.
- [ ] Validate a basic prompt like `2+2` returns a correct answer.
- [ ] Add tests for the AI connectivity path.

Success criteria:
- Backend can call OpenRouter successfully.
- A basic AI test prompt returns expected output.
- Errors are handled gracefully.

Verification:
- Run the AI test route and confirm the expected answer.
- Ensure no API key is hardcoded.

Note: AI integration is still pending; the current implementation has backend persistence and frontend auth working, with AI planned for the next phase.

Tasks:
- [x] Add OpenRouter client integration in the backend.
- [x] Use `OPENROUTER_API_KEY` from `.env` securely.
- [x] Create a simple test route such as `/api/ai/test`.
- [x] Validate a basic prompt like `2+2` returns a correct answer.
- [x] Add tests for the AI connectivity path.

Success criteria:
- Backend can call OpenRouter successfully.
- A basic AI test prompt returns expected output.
- Errors are handled gracefully.

Verification:
- Run the AI test route and confirm the expected answer.
- Ensure no API key is hardcoded.


Tasks:
- [x] Add OpenRouter client integration in the backend.
- [x] Use `OPENROUTER_API_KEY` from `.env` securely.
- [x] Create a simple test route such as `/api/ai/test`.
- [x] Validate a basic prompt like `2+2` returns a correct answer.
- [x] Add tests for the AI connectivity path.

Success criteria:
- Backend can call OpenRouter successfully.
- A basic AI test prompt returns expected output.
- Errors are handled gracefully.

Verification:
- Run the AI test route and confirm the expected answer.
- Ensure no API key is hardcoded.

# Implementation Plan for Project Management MVP

This document defines the detailed plan for the MVP, including substeps, success criteria, and verification for each part. The goal is to keep the work minimal, focused, and easy to validate.

Current implementation status: all parts (1-10) are complete. The project uses a Next.js frontend with client-side login, a FastAPI backend, and SQLite persistence. The Docker setup builds the frontend and serves it statically from the backend. The board state is stored as JSON in the database. The frontend loads and saves board data through `/api/kanban`. AI integration is live via OpenRouter (`openai/gpt-oss-120b`) at `/api/ai/kanban`, and the AI chat sidebar is implemented in the frontend.

Design decisions:
- Use `FastAPI` to serve the built frontend from `/` and expose JSON APIs.
- Use SQLite with a `boards` table storing user board data as JSON.
- Implement auth as a simple client-side gate with hardcoded `user` / `password` for MVP.
- Use `GET /api/kanban` and `PUT /api/kanban` for board persistence.
- Keep the UI minimal and avoid extra advanced features until AI integration.

## Part 1: Plan

Goal: Confirm the implementation sequence and clarify expected outputs before work begins.

Tasks:
- [x] Review the existing repo structure and frontend behavior.
- [x] Define deliverables for Docker, backend, frontend, and AI work.
- [x] Get user approval of this plan before starting implementation.
- Note: `frontend/AGENTS.md` was dropped from scope.

Success criteria:
- The plan includes clear substeps for every part of the project.
- Test expectations are defined for each milestone.

Verification:
- User confirms the plan and approves progression to Part 2.

## Part 2: Scaffolding

Goal: Create the runtime foundation with Docker and a minimal FastAPI backend.

Tasks:
- [x] Add `Dockerfile` and any container orchestration files needed.
- [x] Initialize FastAPI backend in `backend/`.
- [x] Add start/stop scripts under `scripts/` for macOS, Windows, and Linux.
- [x] Implement a `backend/main.py` with a health route and static file serving placeholder.
- [x] Ensure frontend build artifacts can be served from `/`.

Success criteria:
- Docker image builds successfully.
- Container starts and exposes the backend.
- `GET /api/hello` or `/health` returns a valid JSON response.
- `GET /` returns a static placeholder or the frontend shell.

Verification:
- Run the app locally and confirm the API and root route respond as expected.

## Part 3: Add in Frontend

Goal: Wire the existing Next.js frontend into the containerized backend.

Tasks:
- [x] Confirm the current frontend build works from `frontend/`.
- [x] Add build steps for the frontend in Docker or startup scripts.
- [x] Serve the built frontend from the FastAPI backend at `/`.
- [x] Preserve the demo Kanban board UI on the root route.
- [x] Add at least one integration test verifying the frontend is served.

Success criteria:
- Visiting `/` displays the demo Kanban board when the container is running.
- Frontend build and static serve flow is validated.
- Existing frontend tests still pass.

Verification:
- Manual validation of the served Kanban board.
- Run tests and confirm baseline frontend behavior remains intact.

## Part 4: Fake User Sign In Experience

Goal: Add a dummy login screen before the Kanban board is accessible.

Tasks:
- [x] Add login UI requiring `user` and `password`.
- [x] Protect the Kanban view with client-side auth state.
- [x] Add logout functionality.
- [x] Add tests covering login success, login failure, and logout.

Success criteria:
- The Kanban board is only available after correct credentials are entered.
- Logout returns the user to the login screen.
- Auth flow is simple and local.

Verification:
- Automated UI tests confirm login/logout behavior.
- Manual validation confirms the auth flow works.

## Part 5: Database Modeling

Goal: Define a simple SQLite schema for storing Kanban data.

Tasks:
- [x] Design a schema with `users` and `boards` tables.
- [x] Store the board shape as JSON in a `boards` table row.
- [x] Document the schema and rationale in `docs/`.
- [x] Confirm the schema supports one board per user and future multi-user extension.
- [x] Get approval for the schema design.

Success criteria:
- Schema is minimalist and fits the MVP requirements.
- Documentation explains user-board mapping and JSON storage.
- Database can create its schema automatically if missing.

Verification:
- User review and approval of the database model.
- Schema documentation exists in `docs/`.

## Part 6: Backend API

Goal: Implement API routes for loading and saving user Kanban state.

Tasks:
- [x] Add `GET /api/kanban` to fetch the current user's board.
- [x] Add `PUT /api/kanban` to persist updates.
- [x] Initialize or migrate the SQLite database automatically.
- [x] Add backend tests for API route behavior and persistence.

Success criteria:
- Backend can read and write board JSON for a specific user.
- API returns appropriate HTTP status codes and payloads.
- Database file is created on first use.

Verification:
- Backend tests exercise read/write and error paths.
- API calls against a local test database succeed.

## Part 7: Frontend + Backend Integration

Goal: Make the frontend use the backend API for actual persistence.

Tasks:
- [x] Replace hardcoded board data with API fetches to `/api/kanban`.
- [x] Save board updates through backend calls to `/api/kanban` using `PUT`.
- [x] Ensure drag/drop, editing, and column rename actions persist after refresh.
- [x] Add integration tests for data loading and saving.
- [x] Confirm client-side auth gating still works with the API-backed board.

Success criteria:
- Page refresh preserves board changes.
- Backend persistence is active and reliable.
- Frontend calls `fetchKanban` and `saveKanban` wrappers.
- Auth flow remains intact with the API-supported board.

Verification:
- Manual scenario: login, move a card, refresh, and verify state persists.
- Automated integration or unit test coverage exists for the API-backed board.

## Part 8: AI Connectivity

Goal: Confirm backend AI connectivity using OpenRouter.

Tasks:
- [ ] Add OpenRouter client integration in the backend.
- [ ] Use `OPENROUTER_API_KEY` from `.env` securely.
- [ ] Create a simple test route such as `/api/ai/test`.
- [ ] Validate a basic prompt like `2+2` returns a correct answer.
- [ ] Add tests for the AI connectivity path.

Success criteria:
- Backend can call OpenRouter successfully.
- A basic AI test prompt returns expected output.
- Errors are handled gracefully.

Verification:
- Run the AI test route and confirm the expected answer.
- Ensure no API key is hardcoded.

Note: AI integration is still pending; the current implementation has backend persistence and frontend auth working, with AI planned for the next phase.

## Part 9: Structured AI Output for Kanban Updates

Goal: Enable the backend to send the board JSON plus user prompt to the AI and parse structured responses.

Tasks:
- [ ] Send the current Kanban JSON and user question to the AI.
- [ ] Define a structured response schema for text and optional board updates.
- [ ] Implement backend parsing and optional update application.
- [ ] Add tests for valid and invalid AI responses.

Success criteria:
- AI route returns both user-friendly text and optional update instructions.
- The backend only applies board updates when the structured output is valid.
- The board JSON is always passed to the AI.

Verification:
- Backend tests simulate AI responses and verify update behavior.
- Manual check confirms the AI route returns structured output.

## Part 10: AI Chat Sidebar and Auto-Update

Goal: Add a UI chat panel that allows the AI to update the board in real time.

Tasks:
- [ ] Add an AI chat sidebar in the authenticated Kanban screen.
- [ ] Send chat messages to the backend and display AI replies.
- [ ] Apply board updates automatically when the AI response includes them.
- [ ] Keep the UI minimal and consistent with the existing app.
- [ ] Add tests for chat interaction and board refresh behavior.

Success criteria:
- User can chat with AI while viewing the board.
- AI replies display in the sidebar immediately.
- Board updates from the AI refresh the UI automatically.

Verification:
- Manual flow: ask the AI to add or edit a card and confirm the board updates.
- Automated tests cover chat submission and UI refresh.

## Acceptance Criteria

- The app runs locally in Docker and serves the frontend at `/`.
- Users authenticate with `user` / `password` to reach the Kanban board.
- Kanban state persists in a backend SQLite database.
- AI connectivity works via OpenRouter.
- A chat sidebar exists and can trigger board updates.
- Tests cover backend APIs, frontend auth, and AI integration.

## Notes

- Keep scope minimal and avoid extra features.
- Prefer simple, readable implementations.
- If issues arise, identify the root cause before fixing.

-- [ ] Add OpenRouter client integration in the backend.

-- [ ] Use `OPENROUTER_API_KEY` from `.env` securely.

-- [ ] Create a simple test route such as `/api/ai/test`.

-- [ ] Validate a basic prompt like `2+2` returns a correct answer.

-- [ ] Add tests for the AI connectivity path.

+- [x] Add OpenRouter client integration in the backend.

+- [x] Use `OPENROUTER_API_KEY` from `.env` securely.

+- [x] Create a simple test route such as `/api/ai/test`.

+- [x] Validate a basic prompt like `2+2` returns a correct answer.

+- [x] Add tests for the AI connectivity path.

-Note: AI integration is still pending; the current implementation has backend persistence and frontend auth working, with AI planned for the next phase.


Tasks:
- [ ] Send the current Kanban JSON and user question to the AI.
- [ ] Define a structured response schema for text and optional board updates.
- [ ] Implement backend parsing and optional update application.
- [ ] Add tests for valid and invalid AI responses.

Tasks:
- [x] Send the current Kanban JSON and user question to the AI.
- [x] Define a structured response schema for text and optional board updates.
- [x] Implement backend parsing and optional update application.
- [x] Add tests for valid and invalid AI responses.


Tasks:
- [x] Send the current Kanban JSON and user question to the AI.
- [x] Define a structured response schema for text and optional board updates.
- [x] Implement backend parsing and optional update application.
- [x] Add tests for valid and invalid AI responses.

# Implementation Plan for Project Management MVP

This document defines the detailed plan for the MVP, including substeps, success criteria, and verification for each part. The goal is to keep the work minimal, focused, and easy to validate.

Current implementation status: all parts (1-10) are complete. The project uses a Next.js frontend with client-side login, a FastAPI backend, and SQLite persistence. The Docker setup builds the frontend and serves it statically from the backend. The board state is stored as JSON in the database. The frontend loads and saves board data through `/api/kanban`. AI integration is live via OpenRouter (`openai/gpt-oss-120b`) at `/api/ai/kanban`, and the AI chat sidebar is implemented in the frontend.

Design decisions:
- Use `FastAPI` to serve the built frontend from `/` and expose JSON APIs.
- Use SQLite with a `boards` table storing user board data as JSON.
- Implement auth as a simple client-side gate with hardcoded `user` / `password` for MVP.
- Use `GET /api/kanban` and `PUT /api/kanban` for board persistence.
- Keep the UI minimal and avoid extra advanced features until AI integration.

## Part 1: Plan

Goal: Confirm the implementation sequence and clarify expected outputs before work begins.

Tasks:
- [x] Review the existing repo structure and frontend behavior.
- [x] Define deliverables for Docker, backend, frontend, and AI work.
- [x] Get user approval of this plan before starting implementation.
- Note: `frontend/AGENTS.md` was dropped from scope.

Success criteria:
- The plan includes clear substeps for every part of the project.
- Test expectations are defined for each milestone.

Verification:
- User confirms the plan and approves progression to Part 2.

## Part 2: Scaffolding

Goal: Create the runtime foundation with Docker and a minimal FastAPI backend.

Tasks:
- [x] Add `Dockerfile` and any container orchestration files needed.
- [x] Initialize FastAPI backend in `backend/`.
- [x] Add start/stop scripts under `scripts/` for macOS, Windows, and Linux.
- [x] Implement a `backend/main.py` with a health route and static file serving placeholder.
- [x] Ensure frontend build artifacts can be served from `/`.

Success criteria:
- Docker image builds successfully.
- Container starts and exposes the backend.
- `GET /api/hello` or `/health` returns a valid JSON response.
- `GET /` returns a static placeholder or the frontend shell.

Verification:
- Run the app locally and confirm the API and root route respond as expected.

## Part 3: Add in Frontend

Goal: Wire the existing Next.js frontend into the containerized backend.

Tasks:
- [x] Confirm the current frontend build works from `frontend/`.
- [x] Add build steps for the frontend in Docker or startup scripts.
- [x] Serve the built frontend from the FastAPI backend at `/`.
- [x] Preserve the demo Kanban board UI on the root route.
- [x] Add at least one integration test verifying the frontend is served.

Success criteria:
- Visiting `/` displays the demo Kanban board when the container is running.
- Frontend build and static serve flow is validated.
- Existing frontend tests still pass.

Verification:
- Manual validation of the served Kanban board.
- Run tests and confirm baseline frontend behavior remains intact.

## Part 4: Fake User Sign In Experience

Goal: Add a dummy login screen before the Kanban board is accessible.

Tasks:
- [x] Add login UI requiring `user` and `password`.
- [x] Protect the Kanban view with client-side auth state.
- [x] Add logout functionality.
- [x] Add tests covering login success, login failure, and logout.

Success criteria:
- The Kanban board is only available after correct credentials are entered.
- Logout returns the user to the login screen.
- Auth flow is simple and local.

Verification:
- Automated UI tests confirm login/logout behavior.
- Manual validation confirms the auth flow works.

## Part 5: Database Modeling

Goal: Define a simple SQLite schema for storing Kanban data.

Tasks:
- [x] Design a schema with `users` and `boards` tables.
- [x] Store the board shape as JSON in a `boards` table row.
- [x] Document the schema and rationale in `docs/`.
- [x] Confirm the schema supports one board per user and future multi-user extension.
- [x] Get approval for the schema design.

Success criteria:
- Schema is minimalist and fits the MVP requirements.
- Documentation explains user-board mapping and JSON storage.
- Database can create its schema automatically if missing.

Verification:
- User review and approval of the database model.
- Schema documentation exists in `docs/`.

## Part 6: Backend API

Goal: Implement API routes for loading and saving user Kanban state.

Tasks:
- [x] Add `GET /api/kanban` to fetch the current user's board.
- [x] Add `PUT /api/kanban` to persist updates.
- [x] Initialize or migrate the SQLite database automatically.
- [x] Add backend tests for API route behavior and persistence.

Success criteria:
- Backend can read and write board JSON for a specific user.
- API returns appropriate HTTP status codes and payloads.
- Database file is created on first use.

Verification:
- Backend tests exercise read/write and error paths.
- API calls against a local test database succeed.

## Part 7: Frontend + Backend Integration

Goal: Make the frontend use the backend API for actual persistence.

Tasks:
- [x] Replace hardcoded board data with API fetches to `/api/kanban`.
- [x] Save board updates through backend calls to `/api/kanban` using `PUT`.
- [x] Ensure drag/drop, editing, and column rename actions persist after refresh.
- [x] Add integration tests for data loading and saving.
- [x] Confirm client-side auth gating still works with the API-backed board.

Success criteria:
- Page refresh preserves board changes.
- Backend persistence is active and reliable.
- Frontend calls `fetchKanban` and `saveKanban` wrappers.
- Auth flow remains intact with the API-supported board.

Verification:
- Manual scenario: login, move a card, refresh, and verify state persists.
- Automated integration or unit test coverage exists for the API-backed board.

## Part 8: AI Connectivity

Goal: Confirm backend AI connectivity using OpenRouter.

Tasks:
- [x] Add OpenRouter client integration in the backend.
- [x] Use `OPENROUTER_API_KEY` from `.env` securely.
- [x] Create a simple test route such as `/api/ai/test`.
- [x] Validate a basic prompt like `2+2` returns a correct answer.
- [x] Add tests for the AI connectivity path.

Success criteria:
- Backend can call OpenRouter successfully.
- A basic AI test prompt returns expected output.
- Errors are handled gracefully.

Verification:
- Run the AI test route and confirm the expected answer.
- Ensure no API key is hardcoded.

## Part 9: Structured AI Output for Kanban Updates

Goal: Enable the backend to send the board JSON plus user prompt to the AI and parse structured responses.

Tasks:
- [ ] Send the current Kanban JSON and user question to the AI.
- [ ] Define a structured response schema for text and optional board updates.
- [ ] Implement backend parsing and optional update application.
- [ ] Add tests for valid and invalid AI responses.

Success criteria:
- AI route returns both user-friendly text and optional update instructions.
- The backend only applies board updates when the structured output is valid.
- The board JSON is always passed to the AI.

Verification:
- Backend tests simulate AI responses and verify update behavior.
- Manual check confirms the AI route returns structured output.

## Part 10: AI Chat Sidebar and Auto-Update

Goal: Add a UI chat panel that allows the AI to update the board in real time.

Tasks:
- [ ] Add an AI chat sidebar in the authenticated Kanban screen.
- [ ] Send chat messages to the backend and display AI replies.
- [ ] Apply board updates automatically when the AI response includes them.
- [ ] Keep the UI minimal and consistent with the existing app.
- [ ] Add tests for chat interaction and board refresh behavior.

Success criteria:
- User can chat with AI while viewing the board.
- AI replies display in the sidebar immediately.
- Board updates from the AI refresh the UI automatically.

Verification:
- Manual flow: ask the AI to add or edit a card and confirm the board updates.
- Automated tests cover chat submission and UI refresh.

## Acceptance Criteria

- The app runs locally in Docker and serves the frontend at `/`.
- Users authenticate with `user` / `password` to reach the Kanban board.
- Kanban state persists in a backend SQLite database.
- AI connectivity works via OpenRouter.
- A chat sidebar exists and can trigger board updates.
- Tests cover backend APIs, frontend auth, and AI integration.

## Notes

- Keep scope minimal and avoid extra features.
- Prefer simple, readable implementations.
- If issues arise, identify the root cause before fixing.

-- [ ] Send the current Kanban JSON and user question to the AI.

-- [ ] Define a structured response schema for text and optional board updates.

-- [ ] Implement backend parsing and optional update application.

-- [ ] Add tests for valid and invalid AI responses.

+- [x] Send the current Kanban JSON and user question to the AI.

+- [x] Define a structured response schema for text and optional board updates.

+- [x] Implement backend parsing and optional update application.

+- [x] Add tests for valid and invalid AI responses.


Tasks:
- [ ] Add an AI chat sidebar in the authenticated Kanban screen.
- [ ] Send chat messages to the backend and display AI replies.
- [ ] Apply board updates automatically when the AI response includes them.
- [ ] Keep the UI minimal and consistent with the existing app.
- [ ] Add tests for chat interaction and board refresh behavior.

Tasks:
- [x] Add an AI chat sidebar in the authenticated Kanban screen.
- [x] Send chat messages to the backend and display AI replies.
- [x] Apply board updates automatically when the AI response includes them.
- [x] Keep the UI minimal and consistent with the existing app.
- [x] Add tests for chat interaction and board refresh behavior.


Tasks:
- [x] Add an AI chat sidebar in the authenticated Kanban screen.
- [x] Send chat messages to the backend and display AI replies.
- [x] Apply board updates automatically when the AI response includes them.
- [x] Keep the UI minimal and consistent with the existing app.
- [x] Add tests for chat interaction and board refresh behavior.

# Implementation Plan for Project Management MVP

This document defines the detailed plan for the MVP, including substeps, success criteria, and verification for each part. The goal is to keep the work minimal, focused, and easy to validate.

Current implementation status: all parts (1-10) are complete. The project uses a Next.js frontend with client-side login, a FastAPI backend, and SQLite persistence. The Docker setup builds the frontend and serves it statically from the backend. The board state is stored as JSON in the database. The frontend loads and saves board data through `/api/kanban`. AI integration is live via OpenRouter (`openai/gpt-oss-120b`) at `/api/ai/kanban`, and the AI chat sidebar is implemented in the frontend.

Design decisions:
- Use `FastAPI` to serve the built frontend from `/` and expose JSON APIs.
- Use SQLite with a `boards` table storing user board data as JSON.
- Implement auth as a simple client-side gate with hardcoded `user` / `password` for MVP.
- Use `GET /api/kanban` and `PUT /api/kanban` for board persistence.
- Keep the UI minimal and avoid extra advanced features until AI integration.

## Part 1: Plan

Goal: Confirm the implementation sequence and clarify expected outputs before work begins.

Tasks:
- [x] Review the existing repo structure and frontend behavior.
- [x] Define deliverables for Docker, backend, frontend, and AI work.
- [x] Get user approval of this plan before starting implementation.
- Note: `frontend/AGENTS.md` was dropped from scope.

Success criteria:
- The plan includes clear substeps for every part of the project.
- Test expectations are defined for each milestone.

Verification:
- User confirms the plan and approves progression to Part 2.

## Part 2: Scaffolding

Goal: Create the runtime foundation with Docker and a minimal FastAPI backend.

Tasks:
- [x] Add `Dockerfile` and any container orchestration files needed.
- [x] Initialize FastAPI backend in `backend/`.
- [x] Add start/stop scripts under `scripts/` for macOS, Windows, and Linux.
- [x] Implement a `backend/main.py` with a health route and static file serving placeholder.
- [x] Ensure frontend build artifacts can be served from `/`.

Success criteria:
- Docker image builds successfully.
- Container starts and exposes the backend.
- `GET /api/hello` or `/health` returns a valid JSON response.
- `GET /` returns a static placeholder or the frontend shell.

Verification:
- Run the app locally and confirm the API and root route respond as expected.

## Part 3: Add in Frontend

Goal: Wire the existing Next.js frontend into the containerized backend.

Tasks:
- [x] Confirm the current frontend build works from `frontend/`.
- [x] Add build steps for the frontend in Docker or startup scripts.
- [x] Serve the built frontend from the FastAPI backend at `/`.
- [x] Preserve the demo Kanban board UI on the root route.
- [x] Add at least one integration test verifying the frontend is served.

Success criteria:
- Visiting `/` displays the demo Kanban board when the container is running.
- Frontend build and static serve flow is validated.
- Existing frontend tests still pass.

Verification:
- Manual validation of the served Kanban board.
- Run tests and confirm baseline frontend behavior remains intact.

## Part 4: Fake User Sign In Experience

Goal: Add a dummy login screen before the Kanban board is accessible.

Tasks:
- [x] Add login UI requiring `user` and `password`.
- [x] Protect the Kanban view with client-side auth state.
- [x] Add logout functionality.
- [x] Add tests covering login success, login failure, and logout.

Success criteria:
- The Kanban board is only available after correct credentials are entered.
- Logout returns the user to the login screen.
- Auth flow is simple and local.

Verification:
- Automated UI tests confirm login/logout behavior.
- Manual validation confirms the auth flow works.

## Part 5: Database Modeling

Goal: Define a simple SQLite schema for storing Kanban data.

Tasks:
- [x] Design a schema with `users` and `boards` tables.
- [x] Store the board shape as JSON in a `boards` table row.
- [x] Document the schema and rationale in `docs/`.
- [x] Confirm the schema supports one board per user and future multi-user extension.
- [x] Get approval for the schema design.

Success criteria:
- Schema is minimalist and fits the MVP requirements.
- Documentation explains user-board mapping and JSON storage.
- Database can create its schema automatically if missing.

Verification:
- User review and approval of the database model.
- Schema documentation exists in `docs/`.

## Part 6: Backend API

Goal: Implement API routes for loading and saving user Kanban state.

Tasks:
- [x] Add `GET /api/kanban` to fetch the current user's board.
- [x] Add `PUT /api/kanban` to persist updates.
- [x] Initialize or migrate the SQLite database automatically.
- [x] Add backend tests for API route behavior and persistence.

Success criteria:
- Backend can read and write board JSON for a specific user.
- API returns appropriate HTTP status codes and payloads.
- Database file is created on first use.

Verification:
- Backend tests exercise read/write and error paths.
- API calls against a local test database succeed.

## Part 7: Frontend + Backend Integration

Goal: Make the frontend use the backend API for actual persistence.

Tasks:
- [x] Replace hardcoded board data with API fetches to `/api/kanban`.
- [x] Save board updates through backend calls to `/api/kanban` using `PUT`.
- [x] Ensure drag/drop, editing, and column rename actions persist after refresh.
- [x] Add integration tests for data loading and saving.
- [x] Confirm client-side auth gating still works with the API-backed board.

Success criteria:
- Page refresh preserves board changes.
- Backend persistence is active and reliable.
- Frontend calls `fetchKanban` and `saveKanban` wrappers.
- Auth flow remains intact with the API-supported board.

Verification:
- Manual scenario: login, move a card, refresh, and verify state persists.
- Automated integration or unit test coverage exists for the API-backed board.

## Part 8: AI Connectivity

Goal: Confirm backend AI connectivity using OpenRouter.

Tasks:
- [x] Add OpenRouter client integration in the backend.
- [x] Use `OPENROUTER_API_KEY` from `.env` securely.
- [x] Create a simple test route such as `/api/ai/test`.
- [x] Validate a basic prompt like `2+2` returns a correct answer.
- [x] Add tests for the AI connectivity path.

Success criteria:
- Backend can call OpenRouter successfully.
- A basic AI test prompt returns expected output.
- Errors are handled gracefully.

Verification:
- Run the AI test route and confirm the expected answer.
- Ensure no API key is hardcoded.

## Part 9: Structured AI Output for Kanban Updates

Goal: Enable the backend to send the board JSON plus user prompt to the AI and parse structured responses.

Tasks:
- [x] Send the current Kanban JSON and user question to the AI.
- [x] Define a structured response schema for text and optional board updates.
- [x] Implement backend parsing and optional update application.
- [x] Add tests for valid and invalid AI responses.

Success criteria:
- AI route returns both user-friendly text and optional update instructions.
- The backend only applies board updates when the structured output is valid.
- The board JSON is always passed to the AI.

Verification:
- Backend tests simulate AI responses and verify update behavior.
- Manual check confirms the AI route returns structured output.

## Part 10: AI Chat Sidebar and Auto-Update

Goal: Add a UI chat panel that allows the AI to update the board in real time.

Tasks:
- [ ] Add an AI chat sidebar in the authenticated Kanban screen.
- [ ] Send chat messages to the backend and display AI replies.
- [ ] Apply board updates automatically when the AI response includes them.
- [ ] Keep the UI minimal and consistent with the existing app.
- [ ] Add tests for chat interaction and board refresh behavior.

Success criteria:
- User can chat with AI while viewing the board.
- AI replies display in the sidebar immediately.
- Board updates from the AI refresh the UI automatically.

Verification:
- Manual flow: ask the AI to add or edit a card and confirm the board updates.
- Automated tests cover chat submission and UI refresh.

## Acceptance Criteria

- The app runs locally in Docker and serves the frontend at `/`.
- Users authenticate with `user` / `password` to reach the Kanban board.
- Kanban state persists in a backend SQLite database.
- AI connectivity works via OpenRouter.
- A chat sidebar exists and can trigger board updates.
- Tests cover backend APIs, frontend auth, and AI integration.

## Notes

- Keep scope minimal and avoid extra features.
- Prefer simple, readable implementations.
- If issues arise, identify the root cause before fixing.

-- [ ] Add an AI chat sidebar in the authenticated Kanban screen.

-- [ ] Send chat messages to the backend and display AI replies.

-- [ ] Apply board updates automatically when the AI response includes them.

-- [ ] Keep the UI minimal and consistent with the existing app.

-- [ ] Add tests for chat interaction and board refresh behavior.

+- [x] Add an AI chat sidebar in the authenticated Kanban screen.

+- [x] Send chat messages to the backend and display AI replies.

+- [x] Apply board updates automatically when the AI response includes them.

+- [x] Keep the UI minimal and consistent with the existing app.

+- [x] Add tests for chat interaction and board refresh behavior.


All fixes applied:

- **Status paragraph** — updated to reflect all 10 parts complete including AI
- **Part 1** — dropped the `frontend/AGENTS.md` task, added a note that it was dropped from scope
- **Parts 1-10** — all `[ ]` checkboxes marked `[x]`
- **Part 5** — table name corrected from `kanban` to `boards` in both task lines
- **Part 6** — removed the ambiguous `POST /api/kanban or PUT` phrasing, left only `PUT`
- **Part 8** — removed the stale "AI integration is still pending" note

**One open question:** was `frontend/AGENTS.md` intentionally dropped, or should it still be created? I noted it as dropped — let me know if that's wrong.


<command-name>/agents</command-name>
            <command-message>agents</command-message>
            <command-args></command-args>


<local-command-stdout>Agents dialog dismissed</local-command-stdout>


I've updated the comments at the end of PLAN.md with my feedback and removed the simplifications that i disagree with, review the remaining issues, and icorprate the solutions through PLAN.md, letting…