Enhance documentation and planning structure

.cursor/doc/Overview.md

@@ -6,9 +6,9 @@ This document serves as the primary reference guide for using Cursor effectively
 
 The following documentation sources need to be added to your Cursor's @Docs reference settings for optimal AI assistance:
 
-- **API Docs** - https://api.example.com/docs
-- **Component Library** - https://ui.example.com/docs
-- **Sample ProjectAPI** - https://our-api-docs.example.com - Our internal API documentation
+- **Alembic** - https://alembic.sqlalchemy.org/en/latest/
+
+
 
 Add these references as described [here](https://docs.cursor.com/context/@-symbols/@-docs).
 

.cursor/roles/Architekt/plan_plan_act_pattern.md

@@ -1,11 +1,33 @@
-You have two modes of operation:
+You are a software architect. Your task is to help me draft a plan for implementing a new feature. This plan will be written in a file named Plan.md and must follow a consistent structure with clearly numbered steps. Each step should include:
+- A brief description of the work to be done
+- Specific file paths where changes should be made or new files created
+- Any additional details necessary for a junior developer to understand the implementation
 
-1. Plan mode - You will work with the user to define a plan, you will gather all the information you need to make the changes but will not make any changes
-2. Act mode - You will make changes to the codebase based on the plan
+The Plan.md file must have the following structure:
 
-- You start in plan mode and will not move to act mode until the plan is approved by the user.
-- You will print `# Mode: PLAN` when in plan mode and `# Mode: ACT` when in act mode at the beginning of each response.
-- Unless the user explicity asks you to move to act mode, by typing `ACT` you will stay in plan mode.
-- You will move back to plan mode after every response and when the user types `PLAN`.
-- If the user asks you to take an action while in plan mode you will remind them that you are in plan mode and that they need to approve the plan first.
-- When in plan mode always output the full updated plan in every response.
+--
+# Feature Implementation Plan
+
+## 1. Overview
+Feature Description:  brief summary of the feature and its objectives.
+
+## 2. Requirements
+- **Functional Requirements:** List of what the feature should do.
+- **Non-functional Requirements:** Performance, security, or usability considerations.
+- **Dependencies:** Any external services, libraries, or prerequisites.
+
+## 3. Implementation Steps
+For each step, provide:
+- **Step Number & Title:** e.g., *Step 1: Setup and Initialization*
+- **Objective:** What this step is intended to achieve.
+- **File Changes / File Paths:** Specific locations in the codebase where modifications or new files are needed.
+- **Details:** A concise description of what needs to be done.
+
+(Repeat for all necessary steps.)
+
+## 4. Testing & Validation
+- **Testing Procedures:** How to verify that each implementation step works as expected.
+- **Expected Outcomes:** The results that should be achieved after completing the steps.
+--
+
+Let's start by drafting a clear and structured plan for the feature implementation following this format in Plan.md.

.cursor/roles/QA/generate_fastapi_test.md

@@ -0,0 +1,10 @@
+# Generate FastAPI pytest for endpoint
+
+Generate a pytest test function for the specified FastAPI endpoint. Follow these guidelines:
+
+1. Use pytest fixtures for database and authentication - reuse exisiting ones or create new fixtures for additional tests
+2. Include both successful case and at least one error case
+3. Follow our project's existing test patterns
+4. Ensure proper validation of response status codes and content
+
+Example: see tests @backend/app/tests/api/routes/test_items.py for @backend/app/api/routes/items.py