feat: Refactor backend architecture to utilize Pydantic for type safety and validation

- Updated requirements to include Pydantic and MCP libraries.
- Removed empty __init__.py file from backend/tasks.
- Added comprehensive Copilot instructions for architecture and workflows.
- Introduced Pydantic-based architecture documentation for task management.
- Created Unified Architecture documentation to eliminate duplication between REST and MCP.
- Implemented api_decorators.py for unified operation handling with automatic schema generation.
- Consolidated task management logic into tasks.py with Pydantic models for validation and serialization.
- Enhanced TaskService with consolidated methods for task operations, avoiding overly granular functions.

Signed-off-by: Andre Bossard <anbossar@microsoft.com>

Author: abossard

.claude/settings.local.json

@@ -14,7 +14,9 @@
       "Bash(python3:*)",
       "Bash(npx playwright install chromium)",
       "Bash(npx playwright test --project=chromium --reporter=line)",
-      "Bash(npx playwright test:*)"
+      "Bash(npx playwright test:*)",
+      "Bash(find:*)",
+      "Bash(python:*)"
     ],
     "deny": [],
     "ask": []

.github/copilot-instructions.md

@@ -0,0 +1,40 @@
+# Copilot Instructions
+
+## Architecture
+
+- `backend/app.py` hosts both REST (`/api/*`) and MCP JSON-RPC (`/mcp`) on port 5001; every new capability should be exposed via the shared `@operation` decorator so both interfaces stay in sync.
+- Business logic lives in `backend/tasks.py` (`TaskService` plus Pydantic models) backed by an in-memory `_tasks_db`; keep it the single source of truth and seed demo data via `TaskService.initialize_sample_data()`.
+- The React side is feature-first: `frontend/src/App.jsx` just switches tabs while each folder under `frontend/src/features` owns its state, calculations, and FluentUI layout; `frontend/src/services/api.js` is the only place that should issue network calls.
+
+## Backend Patterns
+
+- Define operations with `@operation` (see `op_create_task`, `op_get_task`): annotate parameters with Pydantic models or enums so MCP schemas and REST validation are generated automatically, then build thin Quart wrappers that only handle HTTP concerns.
+- Keep methods like `TaskService.create_task` and `TaskService.update_task` “deep”: they already validate, mutate `_tasks_db`, and return `Task` models, so avoid splitting them into tiny helpers or duplicating validation elsewhere.
+- Use the provided Pydantic models (`TaskCreate`, `TaskUpdate`, `TaskStats`, `TaskFilter`) for all inputs/outputs; MCP tooling and REST serializers expect `.model_dump()` objects with these exact field names (`created_at`, `completed`, etc.).
+- The SSE endpoint `time_stream` streams `{"time","date","timestamp"}` JSON strings; if you change its shape, also update `connectToTimeStream` consumers and the Dashboard expectations.
+
+## Frontend Patterns
+
+- Feature components isolate **calculations** (pure helpers like `getTaskStats`), **actions** (API calls, event handlers), and **data** (React state) in that order; preserve that structure when extending `TaskList` or `Dashboard`.
+- Stick to FluentUI v9 primitives with `makeStyles`/`tokens`; prefer adjusting the `useStyles` definitions over inline styles to maintain theming consistency.
+- Always go through `frontend/src/services/api.js` (`fetchJSON`, `createTask`, `updateTask`, etc.); components expect rejected promises to carry friendly `Error.message`, so don’t bypass these helpers.
+- Task UI and tests rely on deterministic `data-testid` attributes (`task-menu-${id}`, `filter-completed`, etc.); keep them stable or update the Playwright suite alongside UI changes.
+- Real-time widgets follow the `connectToTimeStream` contract (subscribe in `useEffect`, capture cleanup function, surface errors via component state); reuse that approach for any new SSE sources.
+
+## Workflows
+
+- One-time setup: run `./setup.sh` from the repo root to create the backend venv, install frontend deps, and provision Playwright browsers.
+- Dev loop: `cd backend && source venv/bin/activate && python app.py` (serves on 5001) plus `cd frontend && npm run dev`; `./start-dev.sh` or the VS Code “Full Stack: Backend + Frontend” launch config will start both for you.
+- MCP testing uses JSON-RPC POSTs to `http://localhost:5001/mcp` (`tools/list`, `tools/call`); no extra process is required because the Quart server already exposes it.
+
+## Testing
+
+- E2E coverage lives in `tests/e2e/app.spec.js`; from the repo root run `npm run test:e2e` (`:ui` for interactive, `:report` to inspect results). Start both servers first to avoid cold-start delays.
+- The suite assumes sample tasks exist (created by `TaskService.initialize_sample_data()`), tabs are labeled via `data-testid`, and SSE data matches the backend format; keep those invariants or update the tests deliberately.
+- For deterministic assertions, prefer editing helpers like `waitForAppToLoad` or the shared selector strings instead of scattering hard-coded waits.
+
+## Conventions
+
+- Follow “Grokking Simplicity”: keep actions (I/O) in services or event handlers, calculations pure (formatting, stats), and data as plain objects/React state; this is enforced heavily in docs and existing code.
+- Follow “A Philosophy of Software Design”: favor deep modules (e.g., extend `TaskService` instead of sprinkling logic across routes/components) and hide complexity behind simple interfaces.
+- When you touch the architecture (operation decorators, unified REST/MCP flow, feature structure), update `README.md` and `UNIFIED_ARCHITECTURE.md` so future agents inherit the correct mental model.

PROJECT_STRUCTURE.md

@@ -6,7 +6,11 @@ Complete overview of all files and directories in this project.
 python-quart-vite-react/
 │
 ├── backend/                      # Python Quart Backend
-│   ├── app.py                   # Main application file
+│   ├── app.py                   # REST API endpoints (uses tasks.service)
+│   ├── mcp_server.py            # MCP server (uses tasks.service)
+│   ├── tasks/                   # Reusable task management module
+│   │   ├── __init__.py         # Module initialization
+│   │   └── service.py          # Core business logic (deep module)
 │   ├── requirements.txt         # Python dependencies
 │   └── venv/                    # Virtual environment (created during setup)
 │
@@ -63,8 +67,11 @@ python-quart-vite-react/
 
 | File | Purpose |
 |------|---------|
-| `backend/app.py` | Main Quart application with all API endpoints and SSE |
-| `backend/requirements.txt` | Python package dependencies |
+| `backend/app.py` | REST API endpoints using tasks.service module |
+| `backend/mcp_server.py` | MCP server using tasks.service module |
+| `backend/tasks/service.py` | Core business logic - deep module with simple interface |
+| `backend/tasks/__init__.py` | Module initialization file |
+| `backend/requirements.txt` | Python package dependencies (Quart, MCP, etc.) |
 | `backend/venv/` | Isolated Python environment (gitignored) |
 
 ### Frontend Files
@@ -119,12 +126,20 @@ python-quart-vite-react/
 ## Key Directories Explained
 
 ### `/backend`
-Contains the Python Quart web server. This is completely independent of the frontend and provides a RESTful API.
+Contains the Python backend with multiple interfaces sharing the same business logic.
+
+**Architecture Pattern - Deep Modules:**
+- `tasks/service.py` - Core business logic (calculations, actions, data)
+- `app.py` - REST API interface (uses tasks.service)
+- `mcp_server.py` - MCP interface (uses tasks.service)
 
 **Main responsibilities:**
 - Serve API endpoints (`/api/*`)
 - Handle Server-Sent Events for real-time updates
 - Manage task data (in-memory for demo)
+- Demonstrate code reusability across different interfaces
+
+**Key Benefit:** Business logic is written once in `tasks.service` and reused by both REST API and MCP server. Adding a new interface (CLI, GraphQL, etc.) requires zero changes to business logic!
 
 ### `/frontend/src/features`
 Feature-based organization. Each feature is self-contained:
@@ -157,6 +172,14 @@ VSCode-specific configuration for a better development experience:
 
 When adding a new feature, follow this structure:
 
+**Backend (modular approach):**
+```
+backend/my-feature/
+├── __init__.py           # Module initialization
+└── service.py            # Business logic (calculations, actions, data)
+```
+
+**Frontend:**
 ```
 frontend/src/features/my-feature/
 ├── MyFeature.jsx          # Main component
@@ -165,10 +188,14 @@ frontend/src/features/my-feature/
 ```
 
 Then:
-1. Add API endpoints in `backend/app.py`
-2. Add API client functions in `frontend/src/services/api.js`
-3. Import and use in `frontend/src/App.jsx`
-4. Add tests in `tests/e2e/`
+1. Create business logic in `backend/my-feature/service.py`
+2. Add REST API endpoints in `backend/app.py` that use `my-feature.service`
+3. (Optional) Add MCP tools in `backend/mcp_server.py` that use `my-feature.service`
+4. Add API client functions in `frontend/src/services/api.js`
+5. Import and use in `frontend/src/App.jsx`
+6. Add tests in `tests/e2e/`
+
+**Key Principle:** Keep business logic separate from interface concerns. This allows the same code to be used by REST API, MCP, CLI, or any other interface!
 
 ## Development Workflow