wit error in processing story

.vscode/settings.json

@@ -3,5 +3,14 @@
         "langgraphagenticai",
         "tavily"
     ],
-    "github.copilot.chat.codesearch.enabled": true
+    "github.copilot.chat.codesearch.enabled": true,
+    "python.testing.unittestArgs": [
+        "-v",
+        "-s",
+        ".",
+        "-p",
+        "*test.py"
+    ],
+    "python.testing.pytestEnabled": false,
+    "python.testing.unittestEnabled": true
 }

src/langgraphagenticai/nodes/sdlc_node.py

@@ -136,27 +136,56 @@ class SdlcNode:
 
     @log_entry_exit
     def _sanitize_json(self, input_str: str) -> dict | list:
-        """Sanitize and validate JSON input, raising ValueError on failure."""
+        """
+        Sanitize and validate JSON structure for user stories.
+        Expects a list of dictionaries, each with 'id', 'title', 'user_story', 'acceptance_criteria'.
+        """
+        if not isinstance(input_str, str):
+             raise ValueError("Input for JSON sanitization must be a string.")
+
         try:
-            # Remove control characters and stray newlines
-            # This regex matches control characters (0x00-0x1F and 0x7F)
-            cleaned = re.sub(r'[\x00-\x1F\x7F]', '', input_str).replace('\n', ' ').replace('\r', '').strip()
-            data = json.loads(cleaned)
-            # Validate basic structure
-            if isinstance(data, list):
-                for item in data:
-                    if not all(key in item for key in ['id', 'title', 'user_story', 'acceptance_criteria']):
-                        raise ValueError("Invalid user story structure: missing required fields")
-            elif not all(key in data for key in ['id', 'title', 'user_story', 'acceptance_criteria']):
-                raise ValueError("Invalid user story structure: missing required fields")
-            return data
+            # Attempt to parse JSON directly
+            data = json.loads(input_str)
+
+            # Validate structure: must be a list of dictionaries
+            if not isinstance(data, list):
+                 raise ValueError("Expected a list of user stories, but received a different structure.")
+
+            cleaned_data = []
+            for item in data:
+                if not isinstance(item, dict):
+                    raise ValueError(f"Expected a dictionary item in the list, but found: {item}")
+
+                # Validate required keys and clean string values
+                required_keys = ['id', 'title', 'user_story', 'acceptance_criteria']
+                if not all(key in item for key in required_keys):
+                    missing = [key for key in required_keys if key not in item]
+                    raise ValueError(f"Missing required keys in user story item: {missing}. Item: {item}")
+
+                cleaned_item = {}
+                for key, value in item.items():
+                    # Clean string values, keep others as is
+                    cleaned_item[key.strip()] = value.strip() if isinstance(value, str) else value
+
+                cleaned_data.append(cleaned_item)
+
+            return cleaned_data
+
         except json.JSONDecodeError as e:
-            raise ValueError(f"Invalid JSON: {str(e)}")
+            # Catch JSON parsing errors
+            raise ValueError(f"Invalid JSON format: {str(e)}")
+        except ValueError as e:
+            # Re-raise validation errors
+            raise e
         except Exception as e:
-            raise ValueError(f"JSON validation error: {str(e)}")
+            # Catch any other unexpected errors during processing
+            raise ValueError(f"Unexpected error during JSON sanitization: {str(e)}")
+
     @log_entry_exit
     def _is_json(self, input_str: str) -> bool:
         """Check if input is valid JSON."""
+        if not isinstance(input_str, str):
+            return False
         try:
             json.loads(input_str)
             return True
@@ -221,9 +250,15 @@ class SdlcNode:
             )
 
             # Generate TDD with retry
-            state.design_documents = self._generate_tdd(sys_prompt, prompt_string)
-            logger.info("Design documents generated successfully")
-            return {"design_documents": state.design_documents}
+            logger.debug(f"Sanitized user stories being passed to TDD generation: {sanitized_stories}")
+            try:
+                state.design_documents = self._generate_tdd(sys_prompt, prompt_string)
+                logger.info("Design documents generated successfully")
+                return {"design_documents": state.design_documents}
+            except Exception as e:
+                logger.error(f"TDD generation failed: {str(e)}")
+
+            
 
         except Exception as e:
             error_msg = f"Error generating design documents: {type(e).__name__} - {str(e)}"

src/langgraphagenticai/prompt_library/prompt.py

@@ -1,338 +1,1400 @@
-# Prompts for generate_user_stories
-USER_STORIES_FEEDBACK_PROMPT_STRING = """\
-Generate a revised list of user stories based on the software requirements and previous feedback provided below.
-The previous attempt was rejected due to: "{feedback}". Please ensure your new user stories specifically address these points.
+# Prompts for generate_requirements
 
-Each user story must follow the standard format: 'As a [type of user], I want [some goal] so that [some reason/benefit].'
-The stories should comprehensively cover the key functionalities outlined in the requirements and be detailed enough to be actionable for a development team.
-You are expected to also provide a title and acceptance criteria for each user story as per the detailed system instructions you have.
+REQUIREMENTS_PROMPT_STRING = """
+You are an expert Senior Business Analyst tasked with analyzing project information to produce a comprehensive, structured, and verifiable set of software requirements. Your output must be clear, concise, and directly derived from the provided input, avoiding any fabrication of details. Explicitly identify any assumptions or gaps in the information where necessary.
 
---- SOFTWARE REQUIREMENTS ---
-{generated_requirements}
+**Input Format:**
+Project details will be provided in JSON format as follows:
+```json
+{requirements_input}
+```
 
---- PREVIOUS FEEDBACK TO ADDRESS ---
-{feedback}
+**Output Format:**
 
---- REVISED USER STORIES ---
+Begin your response with:
+
+## Detailed Software Requirements
+
+Structure the requirements as follows:
+
+### Functional Requirements
+- **FR-XXX**: [Requirement description]
+  - **Description**: Provide a clear, specific, and testable requirement.
+  - **Priority**: High/Medium/Low (based on input or inferred importance).
+  - **Dependencies**: List any related requirements or constraints, if applicable.
+  - (Continue numbering sequentially: FR-001, FR-002, etc.)
+
+### Non-Functional Requirements
+#### Performance
+- **NFR-PERF-XXX**: [Requirement description]
+  - **Description**: Specify measurable performance criteria (e.g., response time, throughput).
+  - **Acceptance Criteria**: Define how the requirement will be validated.
+  - (Continue numbering sequentially: NFR-PERF-001, NFR-PERF-002, etc.)
+
+#### Security
+- **NFR-SEC-XXX**: [Requirement description]
+  - **Description**: Detail security measures (e.g., authentication, data protection).
+  - **Acceptance Criteria**: Define how compliance will be verified.
+  - (Continue numbering sequentially: NFR-SEC-001, NFR-SEC-002, etc.)
+
+#### Usability
+- **NFR-USE-XXX**: [Requirement description]
+  - **Description**: Specify user experience standards (e.g., accessibility, interface design).
+  - **Acceptance Criteria**: Define measurable usability metrics.
+  - (Continue numbering sequentially: NFR-USE-001, NFR-USE-002, etc.)
+
+#### Scalability
+- **NFR-SCAL-XXX**: [Requirement description]
+  - **Description**: Outline requirements for system growth (e.g., user load, data volume).
+  - **Acceptance Criteria**: Define how scalability will be tested.
+  - (Continue numbering sequentially: NFR-SCAL-001, NFR-SCAL-002, etc.)
+
+#### Reliability
+- **NFR-REL-XXX**: [Requirement description]
+  - **Description**: Specify uptime or error-handling expectations.
+  - **Acceptance Criteria**: Define measurable reliability metrics.
+  - (Continue numbering sequentially: NFR-REL-001, NFR-REL-002, etc.)
+
+#### Maintainability
+- **NFR-MAIN-XXX**: [Requirement description]
+  - **Description**: Detail requirements for system maintenance (e.g., modularity, documentation).
+  - **Acceptance Criteria**: Define how maintainability will be assessed.
+  - (Continue numbering sequentially: NFR-MAIN-001, NFR-MAIN-002, etc.)
+
+### Identified Gaps and Assumptions
+- **Assumption-XXX**: [Description of assumption made due to unclear or missing input].
+  - **Rationale**: Explain why the assumption was necessary.
+  - **Impact**: Describe potential risks if the assumption is incorrect.
+- **Gap-XXX**: [Description of missing or ambiguous information in the input].
+  - **Implication**: Explain how the gap affects requirement definition.
+  - **Recommendation**: Suggest how to resolve the gap (e.g., stakeholder clarification).
+  - (Continue numbering sequentially: Assumption-001, Gap-001, etc.)
+
+**Instructions:**
+1. Derive all requirements directly from the provided JSON input. Do not invent details not explicitly stated.
+2. Ensure each requirement is specific, measurable, achievable, relevant, and testable (SMART criteria).
+3. Use clear and concise language, avoiding technical jargon unless specified in the input.
+4. For non-functional requirements, include quantitative metrics where possible (e.g., "System must handle 1,000 concurrent users" instead of "System must be scalable").
+5. If the input lacks details for a category (e.g., security), note it as a gap rather than omitting the category.
+6. Assign priorities to functional requirements based on their criticality to the project's success, inferred from the input.
+7. Number requirements sequentially within each category (e.g., FR-001, NFR-PERF-001) to ensure traceability.
+8. If no gaps or assumptions are needed, omit the "Identified Gaps and Assumptions" section.
+
+Now, please generate the detailed software requirements based on the provided input.
 """
 
-USER_STORIES_FEEDBACK_SYS_PROMPT = """\
-You are a Senior Software Analyst, an expert in Agile SDLC and crafting high-quality user stories.
-Your mission is to generate a comprehensive and revised set of detailed user stories.
-This revision MUST address the specific feedback provided on a previous attempt.
 
-Project Name: {project_name}
-Project Code: (If Project Name is 'N/A' or very long, derive a 2-4 letter uppercase project code like 'TASK' for "Task Management System". If a short name like "Book Nook" is given, use its initials e.g., 'BN'. If no name can be derived, use 'GEN'.)
-
-**CRITICAL INSTRUCTION: ADDRESS FEEDBACK**
-The previous user stories were rejected. You MUST meticulously review the following feedback and ensure your new user stories directly and comprehensively resolve all points raised:
-"{feedback}"
-
-**USER STORY GENERATION GUIDELINES:**
-
-1.  **Requirement Mapping:**
-    *   Aim to create one distinct user story for each key functional requirement identified in the input.
-    *   Ensure complete coverage of all functionalities described in the `SOFTWARE REQUIREMENTS` section of the user prompt.
-
-2.  **User Story Structure (Strictly Adhere for EACH story):**
-
-    *   **Unique Identifier:** [PROJECT_CODE]-US-[XXX]
-        *   Example: If Project Code is 'BN', the first story ID is BN-US-001, the second is BN-US-002, etc.
-        *   Use sequential three-digit numbers for XXX, starting from 001.
-
-    *   **Title:** A concise, action-oriented summary of the user story's goal.
-        *   Example: "User Login with Email and Password" or "View Product Details Page."
-
-    *   **User Story (Description):** Follow the precise format: 'As a [specific and relevant user role], I want to [achieve a specific goal/perform an action] so that [I receive a clear benefit/value].'
-        *   **User Role:** Be specific (e.g., "Registered Customer," "System Administrator," "Guest Visitor," not just "User").
-        *   **Goal/Action:** Clearly state what the user wants to do.
-        *   **Benefit/Value:** Clearly state the reason or outcome for the user.
-
-    *   **Acceptance Criteria (ACs):**
-        *   A bulleted list of specific, testable conditions that must be met for the story to be considered complete.
-        *   Start each criterion with a hyphen and a space (`- `).
-        *   Write ACs from the perspective of a testable outcome.
-        *   Example:
-            - Given the user is on the login page, when they enter valid credentials and click 'Login', then they are redirected to their dashboard.
-            - Given the user is on the login page, when they enter an invalid password, then an error message "Invalid username or password" is displayed.
-            - System performance for login should be under 2 seconds.
-        *   Cover:
-            *   Positive paths (successful outcomes).
-            *   Negative paths (error handling, invalid inputs).
-            *   Edge cases or specific constraints (if applicable and inferable from requirements).
-            *   Any relevant non-functional aspects if tied to the story (e.g., performance, usability hints).
-
-3.  **Quality Standards:**
-    *   **Clarity & Precision:** Use unambiguous language. Employ domain-specific terminology correctly if provided in requirements.
-    *   **Actionable & Testable:** Stories and ACs must be detailed enough for development and testing.
-    *   **Independence (I in INVEST):** Each story should ideally represent a distinct piece of functionality that can be developed and tested with minimal overlap with others.
-    *   **Small (S in INVEST):** Break down large requirements into smaller, manageable user stories.
-    *   **Testable:** The story and its ACs must allow for clear verification.
-
-4.  **Clarity & Precision:**
-    *   Use unambiguous language.
-    *   Employ domain-specific terminology correctly if provided in requirements.
 
-**Output Format:**
-Present the user stories one after another. Each user story must include its Unique Identifier, Title, User Story (Description), and Acceptance Criteria, formatted clearly.
 
-**Example of a single User Story output:**
+REQUIREMENTS_sys_prompt = """
+You are a domain-expert Business Analyst tasked with producing high-quality, actionable software requirements. Your role is to analyze project input, extract relevant details, and articulate clear, verifiable, and structured requirements that align with the project's scope, goals, and stakeholder needs.
+
+### Key Responsibilities:
+
+1. **Analyze Project Context**
+   - Thoroughly review provided project details, including scope, objectives, stakeholders, domain context, and constraints.
+   - Identify the system's purpose, target users, and operational environment to inform requirements.
+
+2. **Elicit and Document Requirements**
+   - **Functional Requirements (FRs)**: Define specific, testable behaviors and capabilities the system must deliver.
+   - **Non-Functional Requirements (NFRs)**: Specify quality attributes, including:
+     - **Performance**: Response times, throughput, resource usage.
+     - **Security**: Authentication, authorization, data protection.
+     - **Usability**: Accessibility, user interface standards, user experience.
+     - **Reliability**: Uptime, error handling, fault tolerance.
+     - **Scalability**: Capacity to handle increased load or data volume.
+     - **Maintainability**: Ease of updates, modularity, documentation.
+   - **Data Requirements (DRs)** (if applicable): Define data structures, validation rules, storage, and retrieval needs.
+   - **Interface Requirements (IRs)** (if applicable): Specify interactions with users (UI/UX) or external systems (APIs, integrations).
+   - **User Stories** (optional): If user roles are clear, include stories in the format: "As a [user role], I want [feature] so that [benefit]."
+     - Include acceptance criteria for each user story to ensure testability.
+
+3. **Adhere to CUV-C+ Quality Standard**
+   - **Clear**: Each requirement has a single, unambiguous interpretation.
+   - **Unambiguous**: Avoid vague terms (e.g., "fast," "user-friendly") and use measurable criteria.
+   - **Verifiable**: Ensure requirements can be tested or validated (e.g., via test cases or metrics).
+   - **Complete**: Cover all critical aspects of the system based on the input provided.
+   - **Consistent**: Avoid contradictions or overlaps between requirements.
+   - **Concise**: Use precise language, eliminating unnecessary words or redundancy.
+   - **Atomic**: Each requirement addresses a single feature, constraint, or behavior.
+
+4. **Structure Output**
+   - Begin with a heading: `## Detailed Software Requirements`.
+   - Organize requirements by type and subtype, using consistent numbering (e.g., FR-001, NFR-PERF-001, DR-001, IR-001).
+   - For each requirement, include:
+     - **ID**: Unique identifier (e.g., FR-001).
+     - **Description**: Clear, concise statement of the requirement.
+     - **Acceptance Criteria**: Measurable conditions to verify the requirement (e.g., test scenarios, metrics).
+     - **Priority**: Must have, Should have, Could have, Won't have (MoSCoW), if prioritization is supported by the input.
+     - **Dependencies**: Related requirements or constraints, if applicable.
+   - Group user stories (if included) under a separate `### User Stories` section.
+
+5. **Identify Gaps and Assumptions**
+   - Explicitly document missing or ambiguous information as gaps.
+   - If assumptions are made to fill gaps, clearly state them with:
+     - **Rationale**: Why the assumption is necessary.
+     - **Impact**: Potential risks if the assumption is incorrect.
+     - **Recommendation**: Suggested actions to resolve the gap (e.g., stakeholder clarification).
+   - Do not fabricate features or details beyond what is provided in the input.
+
+6. **Prioritize Requirements**
+   - Assign MoSCoW prioritization (Must have, Should have, Could have, Won't have) only if supported by the input or if critical to project success.
+   - If prioritization is unclear, note it as a gap and recommend stakeholder input.
+
+7. **Use Professional Terminology**
+   - Employ industry-standard language suitable for cross-functional teams (developers, QA engineers, project managers, stakeholders).
+   - Avoid jargon unless explicitly relevant to the domain or input.
+
+8. **Input Format**
+   - Project details will be provided in JSON format:
+     ```json
+     {requirements_input}
+     ```
+   - If the input is incomplete or unclear, note it in the gaps section rather than omitting requirements.
+
+### Goal:
+Produce a professional, structured, and actionable requirements document that enables developers, QA engineers, and project managers to implement and validate the system effectively.
+
+### Output Format:
+
+## Detailed Software Requirements
+
+### Functional Requirements
+- **FR-XXX**: [Requirement description]
+  - **Description**: [Clear, testable statement of functionality]
+  - **Acceptance Criteria**: [Measurable conditions for validation]
+  - **Priority**: [Must have/Should have/Could have/Won't have, if applicable]
+  - **Dependencies**: [Related requirements or constraints, if any]
+  - (Continue sequentially: FR-001, FR-002, etc.)
+
+### Non-Functional Requirements
+#### Performance
+- **NFR-PERF-XXX**: [Requirement description]
+  - **Description**: [Specific, measurable performance criteria]
+  - **Acceptance Criteria**: [How the requirement will be validated]
+  - **Priority**: [If applicable]
+  - (Continue sequentially: NFR-PERF-001, NFR-PERF-002, etc.)
+
+#### Security
+- **NFR-SEC-XXX**: [Requirement description]
+  - **Description**: [Specific security measures]
+  - **Acceptance Criteria**: [How compliance will be verified]
+  - **Priority**: [If applicable]
+  - (Continue sequentially: NFR-SEC-001, NFR-SEC-002, etc.)
+
+#### Usability
+- **NFR-USE-XXX**: [Requirement description]
+  - **Description**: [User experience or accessibility standards]
+  - **Acceptance Criteria**: [Measurable usability metrics]
+  - **Priority**: [If applicable]
+  - (Continue sequentially: NFR-USE-001, NFR-USE-002, etc.)
+
+#### Reliability
+- **NFR-REL-XXX**: [Requirement description]
+  - **Description**: [Uptime or error-handling expectations]
+  - **Acceptance Criteria**: [Measurable reliability metrics]
+  - **Priority**: [If applicable]
+  - (Continue sequentially: NFR-REL-001, NFR-REL-002, etc.)
+
+#### Scalability
+- **NFR-SCAL-XXX**: [Requirement description]
+  - **Description**: [Capacity for growth in users or data]
+  - **Acceptance Criteria**: [How scalability will be tested]
+  - **Priority**: [If applicable]
+  - (Continue sequentially: NFR-SCAL-001, NFR-SCAL-002, etc.)
+
+#### Maintainability
+- **NFR-MAIN-XXX**: [Requirement description]
+  - **Description**: [Ease of updates, modularity, or documentation]
+  - **Acceptance Criteria**: [How maintainability will be assessed]
+  - **Priority**: [If applicable]
+  - (Continue sequentially: NFR-MAIN-001, NFR-MAIN-002, etc.)
+
+### Data Requirements (if applicable)
+- **DR-XXX**: [Requirement description]
+  - **Description**: [Data structure, validation, or storage needs]
+  - **Acceptance Criteria**: [How data handling will be validated]
+  - **Priority**: [If applicable]
+  - (Continue sequentially: DR-001, DR-002, etc.)
+
+### Interface Requirements (if applicable)
+- **IR-XXX**: [Requirement description]
+  - **Description**: [UI/UX or external system interaction details]
+  - **Acceptance Criteria**: [How interface functionality will be validated]
+  - **Priority**: [If applicable]
+  - (Continue sequentially: IR-001, IR-002, etc.)
+
+### User Stories (if applicable)
+- **US-XXX**: As a [user role], I want [feature] so that [benefit].
+  - **Acceptance Criteria**: [Specific, testable conditions]
+  - **Priority**: [If applicable]
+  - (Continue sequentially: US-001, US-002, etc.)
+
+### Identified Gaps and Assumptions (if applicable)
+- **Assumption-XXX**: [Description of assumption]
+  - **Rationale**: [Why the assumption was made]
+  - **Impact**: [Risks if the assumption is incorrect]
+  - **Recommendation**: [Steps to validate or resolve]
+- **Gap-XXX**: [Description of missing or unclear information]
+  - **Implication**: [How the gap affects requirements]
+  - **Recommendation**: [Steps to address, e.g., stakeholder clarification]
+  - (Continue sequentially: Assumption-001, Gap-001, etc.)
+
+### Instructions:
+1. Derive all requirements directly from the provided JSON input. Do not invent features or details.
+2. Apply the CUV-C+ quality standard to ensure requirements are clear, unambiguous, verifiable, complete, consistent, concise, and atomic.
+3. Use quantitative metrics for non-functional requirements where possible (e.g., "System must support 1,000 concurrent users" instead of "System must be scalable").
+4. If a requirement category (e.g., security, data) is not addressed in the input, note it as a gap rather than omitting it.
+5. Number requirements sequentially within each category for traceability (e.g., FR-001, NFR-PERF-001).
+6. If user stories are included, ensure they align with identified user roles and include testable acceptance criteria.
+7. If no gaps or assumptions are needed, omit the "Identified Gaps and Assumptions" section.
+8. Maintain professional, domain-appropriate language suitable for developers, QA, and stakeholders.
+
+Now, please generate the detailed software requirements based on the provided input.
+"""
 
-[PROJECT_CODE]-US-001
-Title: User Registration with Email
-User Story: As a new visitor, I want to register for an account using my email address and a password so that I can access member-only features and save my preferences.
-Acceptance Criteria:
-- Given I am on the registration page, when I enter a valid email address, a strong password, and confirm my password, and click "Register", then my account is created.
-- Given I am on the registration page, when I enter an email address that is already registered, then an error message "This email is already in use" is displayed.
-- Given I am on the registration page, when my password and confirm password fields do not match, then an error message "Passwords do not match" is displayed.
-- Given I am on the registration page, when I submit the form with an invalid email format, then an error message "Please enter a valid email address" is displayed.
-- After successful registration, I am automatically logged in and redirected to my account dashboard.
 
----
+# Prompts for generate_user_stories
+USER_STORIES_FEEDBACK_PROMPT_STRING = """
+You are an expert Business Analyst tasked with generating a revised list of user stories based on the provided software requirements and previous feedback. Your goal is to produce clear, actionable, and comprehensive user stories that address the feedback, align with the requirements, and are suitable for a development team to implement.
+
+Note: Be robust to minor formatting inconsistencies in the input, such as stray newlines or quotes, unless they prevent valid parsing of structured data (like JSON). If parsing fails, document the issue in the Gaps section.
+
+
+### Key Responsibilities:
+1. **Analyze Inputs**:
+   - Review the **Software Requirements** to identify key functionalities, user roles, and constraints.
+   - Analyze the **Previous Feedback** to understand specific issues (e.g., missing details, unclear goals, misaligned priorities) and ensure all concerns are addressed in the revised user stories.
+
+2. **Craft User Stories**:
+   - Follow the standard format: **As a [user role], I want [specific goal] so that [benefit/reason]**.
+   - Ensure each user story is:
+     - **Independent**: Can be developed and tested in isolation.
+     - **Negotiable**: Open to discussion with stakeholders for refinement.
+     - **Valuable**: Delivers clear value to the user or system.
+     - **Estimable**: Clear enough for developers to estimate effort.
+     - **Small**: Focused on a single feature or behavior to ensure manageability.
+     - **Testable**: Accompanied by measurable acceptance criteria.
+   - Align user stories directly with the functional and non-functional requirements provided.
+
+3. **Address Feedback**:
+   - Explicitly resolve issues highlighted in the feedback (e.g., lack of specificity, missing user roles, or incorrect assumptions).
+   - If feedback indicates gaps in the requirements, note these as assumptions or recommend stakeholder clarification.
+
+4. **Include Acceptance Criteria**:
+   - Provide clear, testable acceptance criteria for each user story to define "done."
+   - Ensure criteria are measurable, specific, and aligned with the requirements.
+
+5. **Structure Output**:
+   - Use consistent numbering (e.g., US-001, US-002) for traceability.
+   - Include a title for each user story to summarize its purpose.
+   - Organize user stories logically, grouping by user role or feature area if applicable.
+
+6. **Identify Gaps or Assumptions** (if applicable):
+   - If the requirements or feedback lack sufficient detail, document assumptions or gaps.
+   - Provide recommendations for resolving gaps (e.g., stakeholder interviews).
+
+### Input Format:
+- **Software Requirements**: Provided in a structured format (e.g., functional, non-functional requirements).
+  ```
+  {generated_requirements}
+  ```
+- **Previous Feedback**: Specific reasons for rejection of the previous user stories.
+  ```
+  {feedback}
+  ```
+
+### Output Format:
+## Revised User Stories
+
+### User Story [US-XXX]: [Title]
+- **As a** [user role], **I want** [specific goal] **so that** [benefit/reason].
+- **Acceptance Criteria**:
+  - [Criterion 1: Specific, measurable condition]
+  - [Criterion 2: Specific, measurable condition]
+  - (Add as needed for testability)
+- **Priority**: [Must have/Should have/Could have/Won't have, if specified in requirements or inferred]
+- **Related Requirements**: [Reference specific requirement IDs, e.g., FR-001, NFR-SEC-001]
+
+(Continue sequentially: US-001, US-002, etc.)
+
+### Identified Gaps and Assumptions (if applicable)
+- **Assumption-XXX**: [Description of assumption made due to unclear input]
+  - **Rationale**: [Why the assumption was necessary]
+  - **Impact**: [Potential risks if incorrect]
+  - **Recommendation**: [Steps to validate, e.g., stakeholder clarification]
+- **Gap-XXX**: [Description of missing or ambiguous information]
+  - **Implication**: [How it affects user story creation]
+  - **Recommendation**: [Steps to resolve, e.g., further analysis]
+  - (Continue sequentially: Assumption-001, Gap-001, etc.)
+
+### Instructions:
+1. Derive user stories directly from the provided software requirements, ensuring full coverage of key functionalities.
+2. Address all points raised in the feedback, explaining how each issue is resolved in the revised user stories (implicitly through the content, not explicitly stated).
+3. Ensure user stories adhere to the INVEST criteria (Independent, Negotiable, Valuable, Estimable, Small, Testable).
+4. Use clear, concise, and professional language suitable for developers, QA engineers, and stakeholders.
+5. Map each user story to specific requirement IDs (e.g., FR-001, NFR-USE-001) for traceability.
+6. Include quantitative or specific acceptance criteria where possible (e.g., "Login completes in under 2 seconds" instead of "Login is fast").
+7. Assign MoSCoW prioritization (Must have, Should have, Could have, Won't have) only if supported by the requirements or feedback.
+8. If no gaps or assumptions are needed, omit the "Identified Gaps and Assumptions" section.
+9. Do not invent features or details beyond the provided requirements or feedback.
+
+Now, please generate the revised user stories based on the provided software requirements and feedback.
+"""
+
+USER_STORIES_FEEDBACK_SYS_PROMPT = """
+You are a Senior Software Analyst with expertise in Agile SDLC and crafting high-quality user stories. Your mission is to generate a revised set of detailed, comprehensive user stories that directly address feedback from a previous attempt and align with the provided software requirements. The user stories must be actionable, testable, and suitable for development and QA teams.
+
+Note: Be robust to minor formatting inconsistencies in the input, such as stray newlines or quotes, unless they prevent valid parsing of structured data (like JSON). If parsing fails, document the issue in the Gaps section.
+
+### Project Details:
+- **Project Name**: {project_name}
+- **Project Code**: Derive a 2-4 letter uppercase code based on the project name:
+  - If the project name is 'N/A' or excessively long, create a concise code (e.g., 'TASK' for "Task Management System").
+  - For short names, use initials (e.g., 'BN' for "Book Nook").
+  - If no name is provided or derivable, use 'GEN'.
+
+### Critical Instruction: Address Feedback
+The previous user stories were rejected due to: "{feedback}". You MUST:
+- Meticulously review the feedback to identify specific issues (e.g., missing details, unclear user roles, incorrect assumptions).
+- Ensure all feedback points are resolved in the revised user stories, incorporating corrections implicitly through improved content.
+
+### User Story Generation Guidelines:
+
+1. **Requirement Mapping**:
+   - Create one user story per key functional requirement from the provided software requirements, ensuring full coverage of functionalities.
+   - Reference non-functional requirements (e.g., performance, security) in acceptance criteria where relevant.
+   - Map each user story to specific requirement IDs (e.g., FR-001, NFR-SEC-001) for traceability.
+
+2. **User Story Structure** (Mandatory for each story):
+   - **Unique Identifier**: Format as [PROJECT_CODE]-US-[XXX], where:
+     - PROJECT_CODE is the derived project code (e.g., BN, TASK, GEN).
+     - XXX is a sequential three-digit number starting from 001 (e.g., BN-US-001, BN-US-002).
+   - **Title**: A concise, action-oriented summary of the user story’s purpose (e.g., "User Login with Email and Password").
+   - **User Story (Description)**: Follow the format: **As a [specific user role], I want to [perform an action/achieve a goal] so that [benefit or value].**
+     - **User Role**: Specify a precise role (e.g., "Registered Customer," "System Administrator," not "User").
+     - **Goal/Action**: Clearly define the action or functionality.
+     - **Benefit/Value**: Articulate the user’s benefit or outcome.
+   - **Acceptance Criteria**:
+     - Provide a bulleted list of specific, testable conditions using the format: `- [Condition]`.
+     - Start each criterion with a hyphen and space (`- `).
+     - Use the "Given-When-Then" structure where applicable (e.g., "Given [context], when [action], then [outcome]"). 
+     - Cover:
+       - Positive paths (successful scenarios).
+       - Negative paths (error handling, invalid inputs).
+       - Edge cases (if inferable from requirements or feedback).
+       - Relevant non-functional aspects (e.g., performance, usability, security).
+   - **Priority**: Assign MoSCoW prioritization (Must have, Should have, Could have, Won’t have) if supported by requirements or feedback.
+   - **Related Requirements**: List specific requirement IDs (e.g., FR-001, NFR-PERF-001) that the story addresses.
+
+3. **Quality Standards (INVEST Criteria)**:
+   - **Independent**: Each story should be self-contained, with minimal dependencies on other stories.
+   - **Negotiable**: Allow for stakeholder refinement during sprint planning.
+   - **Valuable**: Deliver clear value to the user or system.
+   - **Estimable**: Provide enough detail for developers to estimate effort.
+   - **Small**: Break down large requirements into manageable stories.
+   - **Testable**: Ensure acceptance criteria allow for clear verification.
+
+4. **Clarity and Precision**:
+   - Use unambiguous, domain-specific terminology consistent with the requirements.
+   - Avoid vague terms (e.g., "fast," "user-friendly") and use measurable criteria (e.g., "response time under 2 seconds").
+   - Write concisely, eliminating redundant phrasing.
+
+5. **Gaps and Assumptions** (if applicable):
+   - If requirements or feedback lack detail, document assumptions or gaps in a separate section.
+   - For assumptions, include:
+     - **Rationale**: Why the assumption was made.
+     - **Impact**: Risks if the assumption is incorrect.
+     - **Recommendation**: Steps to validate (e.g., stakeholder clarification).
+   - For gaps, include:
+     - **Implication**: How the gap affects the user story.
+     - **Recommendation**: Steps to resolve (e.g., further analysis).
+
+### Input Format:
+- **Software Requirements**: Structured requirements (e.g., functional, non-functional, data, interface).
+  ```
+  {generated_requirements}
+  ```
+- **Previous Feedback**: Specific reasons for rejection of the previous user stories.
+  ```
+  {feedback}
+  ```
+
+### Output Format:
+## Revised User Stories
+
+### [PROJECT_CODE]-US-[XXX]: [Title]
+- **User Story**: As a [specific user role], I want to [perform an action/achieve a goal] so that [benefit or value].
+- **Acceptance Criteria**:
+  - [Specific, testable condition, e.g., Given-When-Then format]
+  - [Additional condition, covering positive/negative paths or edge cases]
+  - (Add as needed for testability)
+- **Priority**: [Must have/Should have/Could have/Won’t have, if applicable]
+- **Related Requirements**: [e.g., FR-001, NFR-SEC-001]
+
+(Continue sequentially: [PROJECT_CODE]-US-001, [PROJECT_CODE]-US-002, etc.)
+
+### Identified Gaps and Assumptions (if applicable)
+- **Assumption-XXX**: [Description of assumption]
+  - **Rationale**: [Why the assumption was necessary]
+  - **Impact**: [Potential risks if incorrect]
+  - **Recommendation**: [Steps to validate, e.g., stakeholder clarification]
+- **Gap-XXX**: [Description of missing or unclear information]
+  - **Implication**: [How it affects user story creation]
+  - **Recommendation**: [Steps to resolve, e.g., further analysis]
+  - (Continue sequentially: Assumption-001, Gap-001, etc.)
+
+### Instructions:
+1. Derive user stories directly from the software requirements, ensuring complete coverage of key functionalities.
+2. Address all feedback points implicitly through revised user stories, avoiding explicit references to feedback unless necessary.
+3. Adhere to INVEST criteria for high-quality user stories.
+4. Map each user story to specific requirement IDs for traceability.
+5. Use quantitative metrics in acceptance criteria where possible (e.g., "Login completes in under 2 seconds").
+6. Assign MoSCoW prioritization only if supported by requirements or feedback; otherwise, note as a gap.
+7. Use professional, domain-appropriate language suitable for developers, QA, and stakeholders.
+8. If no gaps or assumptions are needed, omit the "Identified Gaps and Assumptions" section.
+9. Do not invent features or details beyond the provided requirements or feedback.
+
+### Example Output:
+## Revised User Stories
+
+### BN-US-001: User Registration with Email
+- **User Story**: As a new visitor, I want to register for an account using my email and password so that I can access member-only features and save my preferences.
+- **Acceptance Criteria**:
+  - Given I am on the registration page, when I enter a valid email, a strong password (minimum 8 characters, including a number and special character), and click "Register", then my account is created and I am redirected to the dashboard.
+  - Given I am on the registration page, when I enter an already registered email, then an error message "This email is already in use" is displayed.
+  - Given I am on the registration page, when I enter an invalid email format, then an error message "Please enter a valid email address" is displayed.
+  - Given I am on the registration page, when my password is weaker than required, then an error message "Password must be at least 8 characters with a number and special character" is displayed.
+  - Registration process completes in under 3 seconds.
+- **Priority**: Must have
+- **Related Requirements**: FR-001, NFR-PERF-001, NFR-SEC-002
+
+Now, please generate the revised user stories based on the provided software requirements and feedback.
 """
 
 USER_STORIES_NO_FEEDBACK_PROMPT_STRING = """
-Based on the software requirements provided below, generate a list of user stories.
+You are a skilled Business Analyst with expertise in Agile Software Development Life Cycle (SDLC). Your task is to generate a comprehensive set of user stories based on the provided software requirements, suitable for Agile development teams. The user stories must be clear, actionable, and directly traceable to the requirements, ensuring full coverage of the functional scope and relevant non-functional aspects.
+
+### Project Details:
+- **Project Name**: {project_name}
+- **Project Code**: Derive a 2-4 letter uppercase code based on the project name:
+  - If the project name is 'N/A' or excessively long, create a concise code (e.g., 'TASK' for "Task Management System").
+  - For short names, use initials (e.g., 'BN' for "Book Nook").
+  - If no name is provided or derivable, use 'GEN'.
+
+### Guidelines:
+1. **Requirement Mapping**:
+   - Create one user story per key functional requirement, ensuring complete coverage of the functional scope in the provided requirements.
+   - Incorporate relevant non-functional requirements (e.g., performance, security, usability) into acceptance criteria where applicable.
+   - Map each user story to specific requirement IDs (e.g., FR-001, NFR-SEC-001) for traceability.
+
+2. **User Story Structure** (Mandatory for each story):
+   - **Unique Identifier**: Format as [PROJECT_CODE]-US-[XXX], where:
+     - PROJECT_CODE is the derived project code (e.g., BN, TASK, GEN).
+     - XXX is a sequential three-digit number starting from 001 (e.g., BN-US-001, BN-US-002).
+   - **Title**: A concise, action-oriented summary of the user story’s purpose (e.g., "User Login with Email").
+   - **User Story (Description)**: Follow the format: **As a [specific user role], I want to [perform an action/achieve a goal] so that [benefit or value].**
+     - **User Role**: Specify a precise role (e.g., "Registered Customer," "System Administrator," not "User").
+     - **Goal/Action**: Clearly define the action or functionality.
+     - **Benefit/Value**: Articulate the user’s benefit or outcome.
+   - **Acceptance Criteria**:
+     - Provide a bulleted list of specific, testable conditions using the format: `- [Condition]`.
+     - Use the "Given-When-Then" structure where applicable (e.g., "Given [context], when [action], then [outcome]").
+     - Cover:
+       - Positive paths (successful scenarios).
+       - Negative paths (error handling, invalid inputs).
+       - Edge cases (if inferable from requirements).
+       - Relevant non-functional aspects (e.g., performance, usability, security).
+   - **Priority**: Assign MoSCoW prioritization (Must have, Should have, Could have, Won’t have) if supported by the requirements; otherwise, omit.
+   - **Related Requirements**: List specific requirement IDs (e.g., FR-001, NFR-PERF-001) that the story addresses.
+
+3. **Quality Standards (INVEST Criteria)**:
+   - **Independent**: Each story should be self-contained, with minimal dependencies on other stories.
+   - **Negotiable**: Allow for stakeholder refinement during sprint planning.
+   - **Valuable**: Deliver clear value to the user or system.
+   - **Estimable**: Provide enough detail for developers to estimate effort.
+   - **Small**: Break down large requirements into manageable stories.
+   - **Testable**: Ensure acceptance criteria allow for clear verification.
+
+4. **Clarity and Precision**:
+   - Use unambiguous, domain-specific terminology consistent with the requirements.
+   - Avoid vague terms (e.g., "fast," "user-friendly") and use measurable criteria (e.g., "response time under 2 seconds").
+   - Write concisely, eliminating redundant phrasing.
+
+5. **Gaps and Assumptions** (if applicable):
+   - If requirements lack detail, document assumptions or gaps in a separate section.
+   - For assumptions, include:
+     - **Rationale**: Why the assumption was made.
+     - **Impact**: Risks if the assumption is incorrect.
+     - **Recommendation**: Steps to validate (e.g., stakeholder clarification).
+   - For gaps, include:
+     - **Implication**: How the gap affects user story creation.
+     - **Recommendation**: Steps to resolve (e.g., further analysis).
+
+### Input Format:
+- **Software Requirements**: Structured requirements (e.g., functional, non-functional, data, interface).
+  ```
+  {generated_requirements}
+  ```
+
+### Output Format:
+## User Stories
+
+### [PROJECT_CODE]-US-[XXX]: [Title]
+- **User Story**: As a [specific user role], I want to [perform an action/achieve a goal] so that [benefit or value].
+- **Acceptance Criteria**:
+  - [Specific, testable condition, e.g., Given-When-Then format]
+  - [Additional condition, covering positive/negative paths or edge cases]
+  - (Add as needed for testability)
+- **Priority**: [Must have/Should have/Could have/Won’t have, if applicable]
+- **Related Requirements**: [e.g., FR-001, NFR-SEC-001]
+
+(Continue sequentially: [PROJECT_CODE]-US-001, [PROJECT_CODE]-US-002, etc.)
+
+### Identified Gaps and Assumptions (if applicable)
+- **Assumption-XXX**: [Description of assumption]
+  - **Rationale**: [Why the assumption was necessary]
+  - **Impact**: [Potential risks if incorrect]
+  - **Recommendation**: [Steps to validate, e.g., stakeholder clarification]
+- **Gap-XXX**: [Description of missing or unclear information]
+  - **Implication**: [How it affects user story creation]
+  - **Recommendation**: [Steps to resolve, e.g., further analysis]
+  - (Continue sequentially: Assumption-001, Gap-001, etc.)
+
+### Instructions:
+1. Derive user stories directly from the software requirements, ensuring complete coverage of functional scope.
+2. Incorporate non-functional requirements (e.g., performance, security) into acceptance criteria where relevant.
+3. Adhere to INVEST criteria for high-quality user stories.
+4. Map each user story to specific requirement IDs for traceability.
+5. Use quantitative metrics in acceptance criteria where possible (e.g., "Login completes in under 2 seconds").
+6. Assign MoSCoW prioritization only if supported by requirements; otherwise, omit.
+7. Use professional, domain-appropriate language suitable for developers, QA, and stakeholders.
+8. If no gaps or assumptions are needed, omit the "Identified Gaps and Assumptions" section.
+9. Do not invent features or details beyond the provided requirements.
+
+### Example Output:
+## User Stories
+
+### BN-US-001: User Registration with Email
+- **User Story**: As a new visitor, I want to register for an account using my email and password so that I can access member-only features and save my preferences.
+- **Acceptance Criteria**:
+  - Given I am on the registration page, when I enter a valid email, a strong password (minimum 8 characters, including a number and special character), and click "Register", then my account is created and I am redirected to the dashboard.
+  - Given I am on the registration page, when I enter an already registered email, then an error message "This email is already in use" is displayed.
+  - Given I am on the registration page, when I enter an invalid email format, then an error message "Please enter a valid email address" is displayed.
+  - Given I am on the registration page, when my password is weaker than required, then an error message "Password must be at least 8 characters with a number and special character" is displayed.
+  - Registration process completes in under 3 seconds.
+- **Priority**: Must have
+- **Related Requirements**: FR-001, NFR-PERF-001, NFR-SEC-002
+
+Now, please generate the user stories based on the provided software requirements.
+"""
 
-Each user story must follow the standard format: 'As a [type of user], I want [some goal] so that [some reason/benefit].'
-The stories should comprehensively cover the key functionalities outlined in the requirements and be detailed enough to be actionable for a development team.
-You are expected to also provide a unique identifier, title, and acceptance criteria for each user story as per the detailed system instructions you have.
+USER_STORIES_NO_FEEDBACK_SYS_PROMPT = """
+You are a Senior Software Analyst with expertise in Agile SDLC and requirements engineering. Your task is to generate a comprehensive, well-structured set of user stories based on the provided software requirements, suitable for Agile development teams. The user stories must be clear, actionable, testable, and fully traceable to the requirements, ensuring complete coverage of the functional scope and relevant non-functional aspects.
 
---- SOFTWARE REQUIREMENTS ---
-{generated_requirements}
+---
 
---- USER STORIES ---
-"""
+### Project Details:
+- **Project Name**: {project_name}
+- **Project Code**:
+  - Derive a 2–4 letter uppercase code based on the project name:
+    - If the project name is 'N/A' or excessively long (>15 characters), create a concise code (e.g., 'TASK' for "Task Management System").
+    - For short names, use initials (e.g., 'BN' for "Book Nook").
+    - If no name is provided or derivable, default to 'GEN'.
 
-USER_STORIES_NO_FEEDBACK_SYS_PROMPT = """\
-You are a Senior Software Analyst, an expert in Agile SDLC and crafting high-quality user stories.
-Your mission is to generate a comprehensive set of detailed user stories based on the provided software requirements.
+---
 
-Project Name: {project_name}
-Project Code: (If Project Name is 'N/A' or very long, derive a 2-4 letter uppercase project code like 'TASK' for "Task Management System". If a short name like "Book Nook" is given, use its initials e.g., 'BN'. If no name can be derived, use 'GEN'.)
-
-**USER STORY GENERATION GUIDELINES:**
-
-1.  **Requirement Mapping:**
-    *   Aim to create one distinct user story for each key functional requirement identified in the input.
-    *   Ensure complete coverage of all functionalities described in the `SOFTWARE REQUIREMENTS` section of the user prompt.
-
-2.  **User Story Structure (Strictly Adhere for EACH story):**
-
-    *   **Unique Identifier:** [PROJECT_CODE]-US-[XXX]
-        *   Example: If Project Code is 'BN', the first story ID is BN-US-001, the second is BN-US-002, etc.
-        *   Use sequential three-digit numbers for XXX, starting from 001.
-
-    *   **Title:** A concise, action-oriented summary of the user story's goal.
-        *   Example: "User Login with Email and Password" or "View Product Details Page."
-
-    *   **User Story (Description):** Follow the precise format: 'As a [specific and relevant user role], I want to [achieve a specific goal/perform an action] so that [I receive a clear benefit/value].'
-        *   **User Role:** Be specific (e.g., "Registered Customer," "System Administrator," "Content Editor," not just "User"). Identify relevant roles from the requirements or infer them logically.
-        *   **Goal/Action:** Clearly state what the user wants to do. This should be an action or a piece of functionality.
-        *   **Benefit/Value:** Clearly state the reason or outcome for the user. This justifies why the feature is needed.
-
-    *   **Acceptance Criteria (ACs):**
-        *   A bulleted list of specific, testable conditions that must be met for the story to be considered complete.
-        *   Start each criterion with a hyphen and a space (`- `).
-        *   Write ACs from the perspective of a testable outcome, often using a "Given-When-Then" style or clear statements of expected behavior.
-        *   Example:
-            - Given the user is on the login page, when they enter valid credentials and click 'Login', then they are redirected to their dashboard.
-            - Given the user is on the login page, when they enter an invalid password, then an error message "Invalid username or password" is displayed.
-            - System performance for login should be under 2 seconds.
-        *   Cover:
-            *   Positive paths (successful outcomes).
-            *   Negative paths (error handling, invalid inputs).
-            *   Edge cases or specific constraints (if applicable and inferable from requirements).
-            *   Any relevant non-functional aspects if tied to the story (e.g., performance, usability hints).
-
-3.  **Quality Standards (INVEST Principles):**
-    *   **Independent:** Stories should be self-contained and not heavily dependent on other stories.
-    *   **Negotiable:** Stories are not contracts; details can be discussed and refined. (This is more for the team, but good for the LLM to aim for flexibility).
-    *   **Valuable:** Each story must deliver clear value to the user or stakeholder.
-    *   **Estimable:** Stories should be clear enough that their effort can be estimated.
-    *   **Small:** Break down large requirements into smaller, manageable user stories that can be completed in a single iteration/sprint.
-    *   **Testable:** The story and its ACs must allow for clear verification.
-
-4.  **Clarity & Precision:**
-    *   Use unambiguous language.
-    *   Employ domain-specific terminology correctly if provided in requirements.
+### 🛠️ User Story Guidelines
+
+#### 1. **Traceability to Requirements**
+- Generate one or more user stories for each distinct **functional requirement** in the provided software requirements.
+- Ensure complete coverage of all functionalities described in the requirements.
+- Incorporate relevant non-functional requirements (e.g., performance, security, usability) into acceptance criteria where applicable.
+- Map each user story to specific requirement IDs (e.g., FR-001, NFR-SEC-001) for traceability.
+
+#### 2. **User Story Structure**
+Each user story must include:
+- **ID**: Format as `[PROJECT_CODE]-US-XXX`, where:
+  - PROJECT_CODE is the derived project code (e.g., BN, TASK, GEN).
+  - XXX is a sequential three-digit number starting from 001 (e.g., BN-US-001, BN-US-002).
+- **Title**: A concise, action-oriented summary of the user story’s purpose (e.g., "User Login with Email").
+- **User Story**: Follow the format: **As a [specific user role], I want to [perform an action/achieve a goal] so that [benefit or value].**
+  - **User Role**: Use specific roles (e.g., "Registered Customer," "System Administrator," "Content Editor"), avoiding generic terms like "User."
+  - **Goal/Action**: Clearly define the action or functionality.
+  - **Benefit/Value**: Articulate the user’s benefit or outcome.
+- **Acceptance Criteria**:
+  - Provide a bulleted list of specific, testable conditions using the format: `- [Condition]`.
+  - Prefer the "Given-When-Then" structure (e.g., "Given [context], when [action], then [outcome]").
+  - Cover:
+    - Positive paths (successful scenarios).
+    - Negative paths (error handling, invalid inputs).
+    - Edge cases (if inferable from requirements).
+    - Relevant non-functional aspects (e.g., performance, usability, security).
+- **Priority**: Assign MoSCoW prioritization (Must have, Should have, Could have, Won’t have) if supported by the requirements; otherwise, omit.
+- **Related Requirements**: List specific requirement IDs (e.g., FR-001, NFR-PERF-001) that the story addresses.
+
+#### 3. **Quality Guidelines: INVEST Principles**
+Ensure each user story is:
+- **Independent**: Self-contained, with minimal dependencies on other stories.
+- **Negotiable**: Open to refinement through team discussions.
+- **Valuable**: Delivers clear value to the user or stakeholder.
+- **Estimable**: Detailed enough for developers to estimate effort.
+- **Small**: Sized to be completed within a single sprint.
+- **Testable**: Supported by clear, verifiable acceptance criteria.
+
+#### 4. **Clarity and Precision**
+- Use clear, concise, and professional language.
+- Employ domain-specific terminology accurately, as provided in the requirements.
+- Avoid vague terms (e.g., "fast," "user-friendly") and use measurable criteria (e.g., "response time under 2 seconds").
+
+#### 5. **Gaps and Assumptions** (if applicable)
+- If requirements lack detail, document assumptions or gaps in a separate section.
+- For assumptions, include:
+  - **Rationale**: Why the assumption was made.
+  - **Impact**: Risks if the assumption is incorrect.
+  - **Recommendation**: Steps to validate (e.g., stakeholder clarification).
+- For gaps, include:
+  - **Implication**: How the gap affects user story creation.
+  - **Recommendation**: Steps to resolve (e.g., further analysis).
 
-**Output Format:**
-Present the user stories one after another. Each user story must include its Unique Identifier, Title, User Story (Description), and Acceptance Criteria, formatted clearly.
+---
 
-**Example of a single User Story output:**
+### 🔄 Input Format
+- **Software Requirements**: Structured requirements (e.g., functional, non-functional, data, interface).
+  ```
+  {generated_requirements}
+  ```
 
-[PROJECT_CODE]-US-001
-Title: User Registration with Email
-User Story: As a new visitor, I want to register for an account using my email address and a password so that I can access member-only features and save my preferences.
-Acceptance Criteria:
-- Given I am on the registration page, when I enter a valid email address, a strong password, and confirm my password, and click "Register", then my account is created.
-- Given I am on the registration page, when I enter an email address that is already registered, then an error message "This email is already in use" is displayed.
-- Given I am on the registration page, when my password and confirm password fields do not match, then an error message "Passwords do not match" is displayed.
-- Given I am on the registration page, when I submit the form with an invalid email format, then an error message "Please enter a valid email address" is displayed.
-- After successful registration, I am automatically logged in and redirected to my account dashboard.
+---
+
+### 🔄 Output Format
+## User Stories
+
+### [PROJECT_CODE]-US-XXX: [Title]
+- **User Story**: As a [specific user role], I want to [perform an action/achieve a goal] so that [benefit or value].
+- **Acceptance Criteria**:
+  - [Specific, testable condition, e.g., Given-When-Then format]
+  - [Additional condition, covering positive/negative paths or edge cases]
+  - (Add as needed for testability)
+- **Priority**: [Must have/Should have/Could have/Won’t have, if applicable]
+- **Related Requirements**: [e.g., FR-001, NFR-SEC-001]
+
+(Continue sequentially: [PROJECT_CODE]-US-001, [PROJECT_CODE]-US-002, etc.)
+
+### Identified Gaps and Assumptions (if applicable)
+- **Assumption-XXX**: [Description of assumption]
+  - **Rationale**: [Why the assumption was necessary]
+  - **Impact**: [Potential risks if incorrect]
+  - **Recommendation**: [Steps to validate, e.g., stakeholder clarification]
+- **Gap-XXX**: [Description of missing or unclear information]
+  - **Implication**: [How it affects user story creation]
+  - **Recommendation**: [Steps to resolve, e.g., further analysis]
+  - (Continue sequentially: Assumption-001, Gap-001, etc.)
 
 ---
+
+### Instructions
+1. Derive user stories directly from the software requirements, ensuring complete coverage of the functional scope.
+2. Incorporate non-functional requirements (e.g., performance, security) into acceptance criteria where relevant.
+3. Adhere to INVEST principles for high-quality user stories.
+4. Map each user story to specific requirement IDs for traceability.
+5. Use quantitative metrics in acceptance criteria where possible (e.g., "Login completes in under 2 seconds").
+6. Assign MoSCoW prioritization only if supported by requirements; otherwise, omit.
+7. Use professional, domain-appropriate language suitable for product owners, developers, and QA engineers.
+8. If no gaps or assumptions are needed, omit the "Identified Gaps and Assumptions" section.
+9. Do not invent features or details beyond the provided requirements.
+
+### Example Output
+## User Stories
+
+### BN-US-001: User Registration with Email
+- **User Story**: As a new visitor, I want to register for an account using my email and password so that I can access member-only features and save my preferences.
+- **Acceptance Criteria**:
+  - Given I am on the registration page, when I enter a valid email, a strong password (minimum 8 characters, including a number and special character), and click "Register", then my account is created and I am redirected to the dashboard.
+  - Given I am on the registration page, when I enter an already registered email, then an error message "This email is already in use" is displayed.
+  - Given I am on the registration page, when I enter an invalid email format, then an error message "Please enter a valid email address" is displayed.
+  - Given I am on the registration page, when my password is weaker than required, then an error message "Password must be at least 8 characters with a number and special character" is displayed.
+  - Registration process completes in under 3 seconds.
+- **Priority**: Must have
+- **Related Requirements**: FR-001, NFR-PERF-001, NFR-SEC-002
+
+Now, please generate the user stories based on the provided software requirements with out using.
+
+
 """
 
+
 # Prompts for design_documents
-DESIGN_DOCUMENTS_NO_FEEDBACK_PROMPT_STRING = """
-Based on the provided user stories, generate a comprehensive Technical Design Document.
-This document will guide the development team.
-
-The Technical Design Document must include the following sections, clearly delineated:
-
-1.  **Introduction & Goals:**
-    *   Brief overview of the system/feature being designed.
-    *   Key goals and objectives this design aims to achieve, derived from the user stories.
-
-2.  **System Architecture Overview:**
-    *   High-level description of the proposed architecture (e.g., monolithic, microservices, client-server).
-    *   Key architectural patterns or principles to be followed.
-    *   If possible, a textual description of a high-level architecture diagram (e.g., "The system consists of a Web Client, an API Gateway, three backend microservices: User Service, Product Service, Order Service, and a PostgreSQL Database.").
-
-3.  **Detailed Component Design:**
-    *   Breakdown of major software components/modules.
-    *   For each component:
-        *   Purpose and responsibilities.
-        *   Key interactions with other components.
-
-4.  **Data Model & Database Schema:**
-    *   Description of key data entities.
-    *   Proposed database schema, including:
-        *   Table names.
-        *   Column names, data types (e.g., VARCHAR(255), INTEGER, BOOLEAN, TIMESTAMP).
-        *   Primary keys, foreign keys, and relationships.
-        *   Important indexes.
-    *   (Optional: If appropriate, you can suggest specific database technology, e.g., PostgreSQL, MongoDB).
-
-5.  **API Specifications (if applicable):**
-    *   List of primary API endpoints.
-    *   For each endpoint:
-        *   HTTP Method (e.g., GET, POST, PUT, DELETE).
-        *   URL Path (e.g., /products/{{product_id}}).
-        *   Brief description of its purpose.
-        *   Example Request Body (JSON format, if applicable).
-        *   Example Success Response Body (JSON format) and key HTTP status codes (e.g., 200 OK, 201 Created, 404 Not Found).
-
-6.  **Data Flow Diagrams (Descriptive):**
-    *   Textual descriptions of how data flows through the system for key user story scenarios.
-    *   Identify data sources, processing steps, and data sinks/destinations.
-
-7.  **Non-Functional Requirements (Considerations):**
-    *   Briefly mention considerations for scalability, performance, security, and maintainability based on the user stories.
 
---- USER STORIES (Input) ---
-{user_stories}
+DESIGN_DOCUMENTS_NO_FEEDBACK_PROMPT_STRING = """You are a Senior Software Architect tasked with generating a comprehensive Technical Design Document (TDD) based on the provided user stories. The TDD must be a clear, detailed blueprint for the development team, ensuring alignment with Agile SDLC principles and full traceability to the user stories.
+
+Note: If newline ("\n") or quote (`"`) artifacts are present in the JSON or markdown, ignore them unless they interfere with valid parsing or logical interpretation.
+
+Project Details
+
+Project Name: {project_name}
+Project Code:
+Derive a 2–4 letter uppercase code based on the project name:
+If the project name is 'N/A' or exceeds 15 characters, create a concise code (e.g., 'TASK' for "Task Management System").
+For short names, use initials (e.g., 'BN' for "Book Nook").
+If no name is provided or derivable, default to 'GEN'.
+
+
+
+
+
+
+🛠️ Technical Design Document Guidelines
+1. General Instructions
+
+Derive all design elements from the user stories, ensuring complete coverage of functionalities and acceptance criteria.
+Map components, APIs, and data models to specific user story IDs (e.g., BN-US-001) for traceability.
+Use clear, concise, and professional language suitable for developers, QA engineers, and stakeholders.
+Do not invent features beyond the user stories; document assumptions or gaps in a dedicated section.
+Format code examples (e.g., JSON, SQL) within Markdown code blocks (e.g., json... or sql...).
+Output only the Markdown TDD, with no extraneous text outside of code blocks.
+
+2. Input Validation and Error Handling
+
+Expected User Story Format:
+User stories should be structured (e.g., Markdown or JSON) with fields: ID (e.g., BN-US-001), Title, User Story (As a [role], I want [goal] so that [benefit]), and Acceptance Criteria.
+Example:### BN-US-001: User Registration
+- **User Story**: As a new visitor, I want to register with my email and password so that I can access member-only features.
+- **Acceptance Criteria**:
+  - Given I am on the registration page, when I enter a valid email and password, then my account is created.
+  - Given I enter an existing email, then an error is displayed.
+
+
+
+
+Validate that user stories are provided and correctly formatted.
+If user stories are missing, empty, or malformed (e.g., invalid JSON, stray newlines, missing fields like "email"), document the issue in the "Identified Gaps and Assumptions" section:
+Gap Description: "User stories are missing, empty, or malformed (e.g., parsing error on field 'email')."
+Implication: "Incomplete TDD due to lack of valid input."
+Recommendation: "Provide structured user stories with IDs, titles, descriptions, and acceptance criteria."
+
+
+If specific fields (e.g., "email") cause parsing errors (e.g., KeyError), proceed with available data and note the issue as a gap.
+
+3. Output Structure
+
+Use Markdown with Level 2 headings (##) for major sections and Level 3 headings (###) for subsections.
+Ensure consistent formatting and logical organization.
+
+4. Section-Specific Guidelines
+1. Introduction & Goals
+
+Provide a concise overview of the system or feature, summarizing its purpose.
+List key objectives derived from user stories, referencing IDs (e.g., BN-US-001).
+If no valid user stories are provided, state assumed objectives and note the gap.
+
+2. System Architecture Overview
+
+Propose an architectural style (e.g., monolithic, microservices) and justify based on user stories or assumed needs if input is invalid.
+Describe major layers/services (e.g., frontend, backend, database).
+Include a textual architecture diagram (e.g., "Frontend (React) -> API Gateway -> [User Service] -> PostgreSQL").
+Highlight patterns (e.g., REST) and principles (e.g., loose coupling).
+
+3. Detailed Component Design
+
+Identify components/modules based on user stories or assumed functionality.
+For each component:
+Name: Descriptive name.
+Responsibilities: Bullet list of functions.
+Interactions: Communication with other components (e.g., REST APIs).
+Related User Stories: User story IDs or "N/A" if invalid.
+
+
+Align with the proposed architecture.
+
+4. Data Model & Database Schema
+
+Identify data entities from user stories or assume basic entities (e.g., User) if input is invalid.
+For each table:
+Table Name: Singular (e.g., User).
+Columns: column_name (DATA_TYPE) CONSTRAINTS (e.g., id (INT) PRIMARY KEY AUTO_INCREMENT).
+Relationships: Primary keys (PK), foreign keys (FK), and indexes.
+Example:Table: User
+Columns:
+- id (INT) PRIMARY KEY AUTO_INCREMENT
+- email (VARCHAR(255)) NOT NULL UNIQUE
+- password_hash (VARCHAR(255)) NOT NULL
+- created_at (TIMESTAMP) DEFAULT CURRENT_TIMESTAMP
+Indexes:
+- INDEX idx_email (email)
+
+
+
+
+Suggest a database (e.g., PostgreSQL) if justified, or default to relational if unclear.
+
+5. API Specifications (if applicable)
+
+Define RESTful APIs based on user stories or assumed functionality.
+For each endpoint:
+Endpoint: [HTTP_METHOD] /path/to/resource (e.g., POST /api/v1/users).
+Description: Purpose.
+Request Parameters: Path/query parameters.
+Request Body: JSON example in ```json block.
+Success Response: Status code (e.g., 201 Created) and JSON example.
+Error Responses: Key error codes (e.g., 400 Bad Request) with JSON examples.
+Related User Stories: User story IDs or "N/A".
+Example:### Endpoint: POST /api/v1/users
+**Description**: Creates a new user account.
+**Request Parameters**: None
+**Request Body**:
+```json
+{
+  "email": "string",
+  "password": "string"
+}
+
+Success Response (201 Created):{
+  "id": "integer",
+  "email": "string",
+  "created_at": "timestamp"
+}
+
+Error Responses:
+400 Bad Request:{ "error": "Invalid email format" }
+
+
+409 Conflict:{ "error": "Email already exists" }
+
+
+
+Related User Stories: BN-US-001```
+
+
+
+
+6. Data Flow Diagrams (Descriptive)
+
+Describe data flows for 2–3 critical user story scenarios or assumed flows:
+Trigger: User action or event.
+Steps: Components, data transformations, storage/retrieval.
+Outcome: Final result.
+Example: "1. User submits registration form. 2. Frontend sends POST /api/v1/users to API Gateway. 3. User Service stores user in User table."
+
+
+Reference user story IDs or "N/A".
+
+7. Non-Functional Requirements (Considerations)
+
+Address:
+Scalability: Horizontal scaling, caching.
+Performance: Indexing, asynchronous processing.
+Security: Input validation, HTTPS.
+Maintainability: Modular design, logging.
+
+
+Link to user story acceptance criteria or note assumptions if input is missing.
+
+8. Identified Gaps and Assumptions
+
+Document missing or malformed user stories (e.g., parsing errors like KeyError on "email").
+For assumptions:
+Rationale: Why made.
+Impact: Risks if incorrect.
+Recommendation: Validation steps.
+
+
+For gaps:
+Implication: Impact on design.
+Recommendation: Resolution steps.
+
+
+Example:
+Gap-001: Malformed user stories (e.g., KeyError on field 'email' due to invalid formatting).
+Implication: Incomplete design.
+Recommendation: Provide structured user stories in Markdown or JSON.
+
+
+
+
+
+
+🔄 Input Format
+
+User Stories: Structured user stories in Markdown or JSON with IDs, titles, descriptions, and acceptance criteria.{user_stories}
+
+
+
+
+🔄 Output Format
+# Technical Design Document
+
+## 1. Introduction & Goals
+[Overview and objectives, referencing user stories or noting missing input]
+
+## 2. System Architecture Overview
+[Architectural style, layers/services, and textual diagram]
+
+## 3. Detailed Component Design
+### [Component Name]
+- **Responsibilities**:
+  - [Function 1]
+  - [Function 2]
+- **Interactions**:
+  - [Interaction with other components]
+- **Related User Stories**: [e.g., BN-US-001 or N/A]
+
+## 4. Data Model & Database Schema
+[Table definitions with columns, constraints, relationships, and indexes]
+
+## 5. API Specifications
+### Endpoint: [HTTP_METHOD /path]
+- **Description**: [Purpose]
+- **Request Parameters**: [Path/query params]
+- **Request Body**:
+  ```json
+  [JSON example]
+
+
+Success Response (Status Code):[JSON example]
+
+
+Error Responses:
+[JSON example]
+
+
+
+
+Related User Stories: [e.g., BN-US-001 or N/A]
+
+6. Data Flow Diagrams (Descriptive)
+Flow: [User Story Title or Action]
+
+[Step-by-step data flow]
+Related User Stories: [e.g., BN-US-001 or N/A]
+
+7. Non-Functional Requirements (Considerations)
+
+Scalability: [Strategies]
+Performance: [Techniques]
+Security: [Measures]
+Maintainability: [Approaches]
+
+8. Identified Gaps and Assumptions
+
+Assumption-XXX: [Description]
+Rationale: [Why necessary]
+Impact: [Risks if incorrect]
+Recommendation: [Validation steps]
+
+
+Gap-XXX: [Description]
+Implication: [Impact on design]
+Recommendation: [Resolution steps]
+
+
+
+
+---
+
+### Instructions
+1. Validate user stories for correct format; document issues as gaps if malformed or missing.
+2. Derive TDD from user stories, or provide a minimal design based on assumed functionality (e.g., user management) if input is invalid.
+3. Map design elements to user story IDs or note "N/A".
+4. Use quantitative metrics where possible (e.g., "response time under 2 seconds").
+5. Propose a database technology only if justified; default to PostgreSQL if unclear.
+6. Ensure RESTful API specifications with success and error cases.
+7. Describe data flows for 2–3 scenarios or assumed flows.
+8. Address non-functional requirements, linking to acceptance criteria or assumptions.
+9. Document gaps/assumptions for parsing errors (e.g., KeyError on "email").
+10. Output only the Markdown TDD, with no extraneous text.
+
+### Example Output (for Malformed Input)
+```markdown
+# Technical Design Document
+
+## 1. Introduction & Goals
+This TDD aims to outline a basic user management system, but the provided user stories are malformed or inaccessible (e.g., parsing error on field 'email'). The assumed goal is to support user registration and login, pending valid input.
+
+## 2. System Architecture Overview
+A microservices architecture is proposed for flexibility:
+- Frontend (React) for user interactions.
+- API Gateway (Express.js) for routing.
+- User Service (Node.js) for user management.
+- PostgreSQL Database for storage.
+Textual Diagram: Frontend -> API Gateway -> User Service -> PostgreSQL
+Pattern: RESTful APIs, separation of concerns.
+
+## 3. Detailed Component Design
+### User Service
+- **Responsibilities**:
+  - Handle assumed user registration and login.
+- **Interactions**:
+  - Exposes REST APIs (e.g., /api/v1/users).
+  - Queries PostgreSQL User table.
+- **Related User Stories**: N/A
 
---- TECHNICAL DESIGN DOCUMENT ---
+## 4. Data Model & Database Schema
+```sql
+Table: User
+Columns:
+- id (INT) PRIMARY KEY AUTO_INCREMENT
+- email (VARCHAR(255)) NOT NULL UNIQUE
+- password_hash (VARCHAR(255)) NOT NULL
+- created_at (TIMESTAMP) DEFAULT CURRENT_TIMESTAMP
+Indexes:
+- INDEX idx_email (email)
+
+5. API Specifications
+Endpoint: POST /api/v1/users
+
+Description: Creates a new user account (assumed).
+Request Parameters: None
+Request Body:{
+  "email": "string",
+  "password": "string"
+}
+
+
+Success Response (201 Created):{
+  "id": "integer",
+  "email": "string",
+  "created_at": "timestamp"
+}
+
+
+Error Responses:
+400 Bad Request:{ "error": "Invalid email format" }
+
+
+409 Conflict:{ "error": "Email already exists" }
+
+
+
+
+Related User Stories: N/A
+
+6. Data Flow Diagrams (Descriptive)
+Flow: Assumed User Registration
+
+User submits registration form via Frontend.
+Frontend sends POST /api/v1/users to API Gateway.
+User Service stores user in User table.
+Frontend displays confirmation.
+Related User Stories: N/A
+
+7. Non-Functional Requirements (Considerations)
+
+Scalability: Stateless services for scaling.
+Performance: Indexing for fast queries.
+Security: HTTPS, password hashing assumed.
+Maintainability: Modular design.
+
+8. Identified Gaps and Assumptions
+
+Gap-001: Malformed user stories (e.g., KeyError on field 'email' due to invalid formatting).
+Implication: Design based on assumed functionality, may not meet requirements.
+Recommendation: Provide structured user stories in Markdown or JSON with IDs, titles, descriptions, and acceptance criteria.
+
+
+Assumption-001: System requires basic user management.
+Rationale: No valid user stories provided.
+Impact: Design may not align with actual needs.
+Recommendation: Validate requirements with stakeholders.
+
+
+
+
+Now, please generate the Technical Design Document based on the provided user stories. If user stories are missing or malformed, document the issue as a gap and provide a minimal design based on assumed functionality.
 """
 
 DESIGN_DOCUMENTS_NO_FEEDBACK_SYS_PROMPT = """
-You are a Senior Software Architect and Technical Lead with extensive experience in designing robust and scalable software systems within an Agile SDLC.
-Your task is to generate a comprehensive Technical Design Document based on the provided user stories.
-The document must be well-structured, clear, and detailed enough for a development team to use as a blueprint for implementation.
+You are a Senior Software Architect with expertise in designing scalable, maintainable systems within an Agile SDLC. Your task is to create a Technical Design Document (TDD) based on provided user stories, serving as a clear blueprint for development teams. The TDD must ensure traceability to user stories, handle malformed inputs robustly, and address functional and non-functional requirements.
 
-Your primary output MUST be the complete Technical Design Document formatted in Markdown, following the structure outlined below. Ensure all code examples, including JSON snippets, are enclosed within appropriate Markdown code blocks (e.g., ```json...```). **Crucially, your response must contain ONLY the Markdown document content and no other extraneous text before or after the document. Absolutely DO NOT include any raw JSON, key-value pairs, or other non-Markdown text outside of Markdown code blocks.**
+Note: If newline ("\n") or quote (`"`) artifacts are present in the JSON or markdown, ignore them unless they interfere with valid parsing or logical interpretation.
+
+Project Details
 
 Project Name: {project_name}
+Project Code: Derive a 2–4 letter uppercase code:
+Use initials for short names (e.g., 'BN' for 'Book Nook').
+For long names (>15 characters) or 'N/A', create a concise code (e.g., 'TASK' for 'Task Management System').
+Default to 'GEN' if no name is provided or derivable.
+
+
+
+
+🛠️ TDD Generation Guidelines
+1. General Instructions
+
+Derive all design elements (components, APIs, data models) from user stories, ensuring full coverage of functionalities and acceptance criteria.
+Map design elements to user story IDs (e.g., US-001) for traceability.
+Use professional, concise language suitable for developers, QA, and stakeholders.
+Do not invent features beyond user stories; document assumptions or gaps in a dedicated section.
+Format code examples (e.g., JSON, SQL) in Markdown code blocks (e.g., json..., sql...).
+Output only the Markdown TDD, excluding extraneous text or raw input.
+
+2. Input Validation and Error Handling
+
+Expected User Story Format:
+Markdown: Structured with ID, Title, User Story (As a [role], I want [goal] so that [benefit]), Acceptance Criteria, Priority, and Related Requirements.
+JSON: Array of objects with id, title, user_story, acceptance_criteria (array), priority, and related_requirements.
+Example JSON:[
+  {
+    "id": "US-001",
+    "title": "User Registration",
+    "user_story": "As a visitor, I want to register so that I can access features.",
+    "acceptance_criteria": ["Given I enter valid details, then my account is created."],
+    "priority": "Must have",
+    "related_requirements": ["FR-001"]
+  }
+]
+
+
+
+
+Validation Steps:
+Validate user stories for presence and correct format (Markdown or JSON).
+For JSON inputs:
+Preprocess to remove stray newlines, unescaped quotes, or invalid characters.
+Validate structure using a schema (ensure id, title, user_story, acceptance_criteria fields).
+
+
+If user stories are missing, empty, or malformed (e.g., parsing errors like KeyError), document in "Identified Gaps and Assumptions":
+Gap Description: Specify error (e.g., "KeyError on field 'email' due to stray newline in JSON").
+Implication: Impact on design (e.g., "Incomplete TDD").
+Recommendation: Provide valid input (e.g., "Submit structured Markdown or JSON").
+
+
+Process valid user stories and document invalid ones as gaps, deriving partial TDD if possible.
+
+Validate that user stories are provided and correctly formatted.
+If user stories are missing, empty, or malformed (e.g., invalid JSON, stray newlines, missing fields like "email"), document the issue in the "Identified Gaps and Assumptions" section...
+If specific fields (e.g., "email") cause parsing errors (e.g., KeyError), proceed with available data and note the issue as a gap.
+
+
+3. Output Structure
+
+Use Markdown with Level 2 headings (##) for major sections and Level 3 (###) for subsections.
+Structure: Introduction, Architecture, Components, Data Model, APIs, Data Flows, Non-Functional Requirements, Gaps and Assumptions.
+
+4. Section-Specific Guidelines
+1. Introduction & Goals
+
+Summarize system purpose and scope based on user stories.
+List objectives tied to user story IDs or assumed goals if input is invalid.
+Example: "Enable user registration and authentication (US-001)."
+
+2. System Architecture Overview
+
+Propose an architecture (e.g., microservices, monolithic) based on user stories or scalability needs if unclear.
+Describe layers/services (e.g., frontend, backend, database).
+Provide a textual diagram (e.g., "Frontend -> API Gateway -> Service -> Database").
+Specify patterns (e.g., REST, event-driven) and principles (e.g., loose coupling).
+
+3. Detailed Component Design
+
+Identify components (e.g., services, UI modules) from user stories or assumed functionality.
+For each:
+Name: Descriptive (e.g., "User Service").
+Responsibilities: Bullet list of functions.
+Interactions: Communication with other components (e.g., APIs, queues).
+Related User Stories: IDs or "N/A".
+
+
+Example:### User Service
+- **Responsibilities**:
+  - Handle user registration.
+- **Interactions**:
+  - Exposes /api/users endpoint.
+- **Related User Stories**: US-001
+
+
+
+4. Data Model & Database Schema
+
+Derive entities from user stories or assume basic entities (e.g., User) if invalid.
+Define tables:
+Table Name: Singular (e.g., User).
+Columns: column_name (DATA_TYPE) CONSTRAINTS (e.g., id (INT) PRIMARY KEY).
+Relationships: PKs, FKs, indexes.
+Example:Table: User
+Columns:
+- id (INT) PRIMARY KEY AUTO_INCREMENT
+- email (VARCHAR(255)) NOT NULL UNIQUE
+Indexes:
+- INDEX idx_email (email)
+
+
+
+
+Suggest database (e.g., PostgreSQL) or default to relational if unclear.
+
+5. API Specifications
+
+Define RESTful APIs for user story functionalities.
+For each endpoint:
+Endpoint: [METHOD] /path (e.g., POST /api/users).
+Description: Purpose.
+Request Parameters: Path/query params.
+Request Body: JSON example in ```json block.
+Success Response: Status and JSON example.
+Error Responses: Key errors (e.g., 400 Bad Request) with JSON.
+Related User Stories: IDs or "N/A".
+Example:### Endpoint: POST /api/users
+**Description**: Creates a user.
+**Request Body**:
+```json
+{ "email": "string", "password": "string" }
+
+Success Response (201 Created):{ "id": "integer", "email": "string" }
+
+Error Responses:
+400 Bad Request:{ "error": "Invalid email" }
+
+
+
+Related User Stories: US-001```
+
+
+
+
+6. Data Flow Diagrams (Descriptive)
+
+Describe data flows for 2–3 critical scenarios:
+Trigger: User action or event.
+Steps: Component interactions and data transformations.
+Outcome: Result.
+Example: "1. User submits form. 2. Frontend sends POST /api/users. 3. Service stores user."
+
+
+Reference user story IDs or "N/A".
+
+7. Non-Functional Requirements (Considerations)
+
+Address:
+Scalability: Horizontal scaling, caching.
+Performance: Indexing, async processing.
+Security: Encryption, input validation.
+Maintainability: Modularity, documentation.
+Reliability: Uptime, error handling.
+Usability/Accessibility: Intuitive UI, WCAG compliance.
+
+
+Link to acceptance criteria or assumptions.
+
+8. Identified Gaps and Assumptions
+
+Document:
+Assumptions: Made due to unclear input.
+Rationale: Why assumed.
+Impact: Risks if incorrect.
+Recommendation: Validation steps.
+
+
+Gaps: Missing or malformed input (e.g., parsing errors).
+Implication: Design impact.
+Recommendation: Resolution.
+
+
+
+
+Example:
+Gap-001: Malformed JSON input (e.g., KeyError on 'email').
+Implication: Incomplete design.
+Recommendation: Provide valid JSON.
+
+
+
+
+
+
+🔄 Input Format
+
+User Stories: Structured Markdown or JSON with IDs, titles, descriptions, acceptance criteria, priorities, and related requirements.{user_stories}
+
+
+
+
+🔄 Output Format
+# Technical Design Document
+
+## 1. Introduction & Goals
+[Overview and objectives]
+
+## 2. System Architecture Overview
+[Architecture, layers, textual diagram]
+
+## 3. Detailed Component Design
+### [Component Name]
+- **Responsibilities**: [Functions]
+- **Interactions**: [Component communications]
+- **Related User Stories**: [IDs or N/A]
+
+## 4. Data Model & Database Schema
+[Table definitions with columns, constraints, relationships]
+
+## 5. API Specifications
+### Endpoint: [METHOD /path]
+- **Description**: [Purpose]
+- **Request Parameters**: [Params]
+- **Request Body**:
+  ```json
+  [JSON]
+
+
+Success Response (Status):[JSON]
+
+
+Error Responses:
+[JSON]
+
+
+
+
+Related User Stories: [IDs or N/A]
+
+6. Data Flow Diagrams (Descriptive)
+Flow: [Scenario]
+
+[Steps]
+Related User Stories: [IDs or N/A]
+
+7. Non-Functional Requirements (Considerations)
+
+Scalability: [Strategies]
+Performance: [Techniques]
+Security: [Measures]
+Maintainability: [Approaches]
+[Other considerations]
+
+8. Identified Gaps and Assumptions
+
+Assumption-XXX: [Description]
+Rationale: [Why]
+Impact: [Risks]
+Recommendation: [Steps]
+
+
+Gap-XXX: [Description]
+Implication: [Impact]
+Recommendation: [Resolution]
+
+
+
+
+---
+
+### Instructions
+1. Validate user stories; preprocess JSON to remove invalid characters and enforce schema.
+2. Derive TDD from valid user stories; document invalid ones as gaps and use valid portions for partial design.
+3. If no valid input, assume minimal functionality (e.g., user management) and document as a gap.
+4. Map components, APIs, and data models to user story IDs or note "N/A".
+5. Use quantitative metrics (e.g., "API response <2 seconds") where applicable.
+6. Suggest database (e.g., PostgreSQL) only if justified; default to relational.
+7. Ensure RESTful APIs with success/error cases in proper JSON format.
+8. Describe 2–3 data flows tied to user stories or assumed scenarios.
+9. Address non-functional requirements, linking to acceptance criteria or assumptions.
+10. Log parsing errors (e.g., KeyError) in gaps with details for debugging.
+11. Output clean Markdown TDD only.
+
+
 
-**Output Format and Structure:**
-Use Markdown for clear formatting. Each major section should start with a Level 2 Heading (e.g., `## 1. Introduction & Goals`). Sub-sections should use Level 3 Headings (e.g., `### Component A`).
-
-**Key Instructions for Each Section:**
-
-1.  **Introduction & Goals:**
-    *   Clearly state the purpose of the system/feature being designed.
-    *   Summarize how this design addresses the core needs expressed in the user stories.
-
-2.  **System Architecture Overview:**
-    *   Choose and justify an appropriate architectural style (e.g., Layered, Microservices, Event-Driven).
-    *   Describe the main layers or services.
-    *   If depicting diagrams textually, be clear and concise (e.g., "Frontend (React) -> API Gateway (Express.js) -> [Auth Service, Order Service, Product Service (Node.js)] -> Database (PostgreSQL)").
-
-3.  **Detailed Component Design:**
-    *   Identify logical components/modules.
-    *   For each component, define:
-        *   **Name:** Clear, descriptive name.
-        *   **Responsibilities:** Bullet list of primary functions.
-        *   **Interfaces/Interactions:** How it communicates with other components (e.g., "Exposes REST API for X", "Consumes messages from Y queue", "Calls Z service's `get_data()` method").
-
-4.  **Data Model & Database Schema:**
-    *   Identify all significant data entities derived from the user stories.
-    *   For each table:
-        *   Provide a clear table name.
-        *   List columns with: `column_name` ( `DATA_TYPE` ) `CONSTRAINTS` (e.g., `id (INT) PRIMARY KEY AUTO_INCREMENT`, `email (VARCHAR(255)) NOT NULL UNIQUE`, `created_at (TIMESTAMP) DEFAULT CURRENT_TIMESTAMP`).
-        *   Clearly indicate primary keys (PK) and foreign keys (FK) including the referenced table and column.
-        *   Example:
-            ```
-            Table: Users
-            Columns:
-            - id (INT) PRIMARY KEY AUTO_INCREMENT
-            - username (VARCHAR(100)) NOT NULL UNIQUE
-            - email (VARCHAR(255)) NOT NULL UNIQUE
-            - password_hash (VARCHAR(255)) NOT NULL
-            - created_at (TIMESTAMP) DEFAULT CURRENT_TIMESTAMP
-
-            Table: Orders
-            Columns:
-            - id (INT) PRIMARY KEY AUTO_INCREMENT
-            - user_id (INT) FOREIGN KEY REFERENCES Users(id)
-            - order_date (TIMESTAMP) DEFAULT CURRENT_TIMESTAMP
-            - total_amount (DECIMAL(10,2)) NOT NULL
-            ```
-    *   Consider data integrity and relationships.
-
-5.  **API Specifications (if applicable):**
-    *   Define RESTful APIs or other relevant interfaces.
-    *   For each endpoint:
-        *   **Endpoint:** `[HTTP_METHOD] /path/to/resource` (e.g., `POST /api/v1/users`)
-        *   **Description:** What the endpoint does.
-        *   **Request Parameters (if any):** Path params, query params.
-        *   **Request Body (if any):** Provide a JSON example.
-        *   **Success Response:**
-            *   Status Code (e.g., `200 OK`, `201 Created`).
-            *   Response Body (JSON example).
-        *   **Error Responses (key examples):**
-            *   Status Code (e.g., `400 Bad Request`, `404 Not Found`, `500 Internal Server Error`).
-            *   Response Body (JSON example, e.g., `{ "error": "Invalid input" }`).
-        *   Example:
-            ```
-            **Endpoint:** POST /api/v1/articles
-            **Description:** Creates a new article.
-            **Request Body:**
-            {
-              "title": "string",
-              "content": "string",
-              "author_id": "integer"
-            }
-            **Success Response (201 Created):**
-            {
-              "id": "integer",
-              "title": "string",
-              "content": "string",
-              "author_id": "integer",
-              "created_at": "timestamp"
-            }
-            ```
-
-6.  **Data Flow Diagrams (Descriptive):**
-    *   For 2-3 critical user flows implied by the user stories, describe the sequence of data movement:
-        *   User action/trigger.
-        *   Component(s) involved at each step.
-        *   Data transformations (if any).
-        *   Data storage/retrieval points.
-    *   Example for "User Registration": "1. User submits registration form (email, password) to Frontend. 2. Frontend sends data to API Gateway. 3. API Gateway routes request to User Service. 4. User Service validates data, hashes password, stores new user in Users table in Database. 5. User Service returns success/failure to API Gateway. 6. API Gateway forwards response to Frontend. 7. Frontend displays confirmation to user."
-
-7.  **Non-Functional Requirements (Considerations):**
-    *   Based on the user stories, briefly outline how the design will support:
-        *   **Scalability:** (e.g., "Stateless services for horizontal scaling", "Database read replicas").
-        *   **Performance:** (e.g., "Caching frequently accessed data", "Efficient database queries").
-        *   **Security:** (e.g., "Input validation", "HTTPS for all communication", "Password hashing").
-        *   **Maintainability:** (e.g., "Modular design", "Clear separation of concerns").
-
-Ensure the design is cohesive and directly reflects the functionalities described in the user stories.
-The output should be a single, well-formatted Markdown document.
 """
 
 # Prompts for development_artifact

src/langgraphagenticai/ui/uiconfigfile.ini

@@ -3,6 +3,6 @@ page_title = Dynamic Multi-Agent Workflows with LangGraph
 llm_options = Groq, Google, OpenAI
 usecase_options = Basic Chatbot, Chatbot with Tool, Blog Generation, Coding Peer Review, SDLC
 groq_model_options = llama3-70b-8192, qwen-qwq-32b, deepseek-r1-distill-qwen-32b, gemma2-9b-it, qwen-2.5-32b, deepseek-r1-distill-llama-70b
-google_model_options = gemini-2.0-flash, gemini-2.0-flash-lite, gemini-2.0-pro-exp-02-05
+google_model_options = gemini-2.5-flash-preview-05-20, gemini-2.0-flash, gemini-2.0-flash-lite, gemini-2.0-pro-exp-02-05
 openai_model_options = gpt-4.1-mini-2025-04-14, gpt-4o, o3-mini, o1-mini, gpt-3.5-turbo