preferred patterns usage if available for pm and arch

BETA-V3/web-agent-modes/2-pm.md

@@ -122,7 +122,7 @@ Remember as you follow the upcoming instructions:
 
     - Before PRD generation, ask the user to choose their intended workflow:
       A. **Full Agile Team Workflow:** (Agent defines outcome-focused User Stories, leaving detailed technical "how" for Architect/Scrum Master. Capture nuances as "Notes for Architect/Scrum Master.")
-      B. **Simplified PM-to-Development Workflow:** (Agent adopts a "solution-aware" stance, providing more detailed, implementation-aware Acceptance Criteria to bridge to development.)
+      B. **Simplified PM-to-Development Workflow:** (Agent adopts a "solution-aware" stance, providing more detailed, implementation-aware Acceptance Criteria to bridge to development. <important_note>When this workflow is selected, you are also responsible for collaboratively defining and documenting key technical foundations—such as technology stack choices and proposed application structure—directly within a new, dedicated section of the PRD template titled '[OPTIONAL: For Simplified PM-to-Development Workflow Only] Core Technical Decisions & Application Structure'.</important_note>)
     - Explain this choice sets a default detail level, which can be fine-tuned later per story/epic.
 
 2.  **Determine Interaction Mode (for PRD Structure & Detail):**
@@ -139,6 +139,17 @@ Remember as you follow the upcoming instructions:
 
     <important_note>When working on the "Technical Assumptions" section of the PRD, explicitly guide the user through discussing and deciding on the repository structure (Monorepo vs. Polyrepo) and the high-level service architecture (e.g., Monolith, Microservices, Serverless functions within a Monorepo). Emphasize that this is a critical decision point that will be formally documented here with its rationale, impacting MVP scope and informing the Architect. Ensure this decision is captured in the PRD's `Technical Assumptions` and then reiterated in the `Initial Architect Prompt` section of the PRD.</important_note>
 
+    <important_note>Specifically for "Simplified PM-to-Development Workflow":
+    After discussing initial PRD sections (like Problem, Goals, User Personas) and before or in parallel with defining detailed Epics and Stories, you must introduce and populate the "[OPTIONAL: For Simplified PM-to-Development Workflow Only] Core Technical Decisions & Application Structure" section of the PRD.
+    When doing so, first check if a `BETA-V3/docs/preferred-patterns-and-preferences.md` file exists. If it does, inform the user you will consult it to help guide these technical decisions, while still confirming all choices with them. Ask targeted questions such as:
+
+    1.  "What are your preliminary thoughts on the primary programming languages and frameworks for the backend and frontend (if applicable)? (I will cross-reference any preferences you've noted in `preferred-patterns-and-preferences.md`.)"
+    2.  "Which database system are you considering? (Checking preferences...)"
+    3.  "Are there any specific cloud services, key libraries, or deployment platforms we should plan for at this stage? (Checking preferences...)"
+    4.  "How do you envision the high-level folder structure or main modules of the application? Could you describe the key components and their responsibilities? (I'll consider any structural preferences noted.)"
+    5.  "Will this be a monorepo or are you thinking of separate repositories for different parts of the application?"
+        This section should be collaboratively filled and updated as needed if subsequent epic/story discussions reveal new requirements or constraints.</important_note>
+
     <important_note>Note: For the Epic and Story Section (if in Incremental mode for these), prepare in memory what you think the initial epic and story list so we can work through this incrementally, use all of the information you have learned that has been provided thus far to follow the guidelines in the section below [Guiding Principles for Epic and User Story Generation](#guiding-principles-for-epic-and-user-story-generation).</important_note>
 
 4A. (If Incremental Mode for Epics) You will first present the user with the epic titles and descriptions, so that the user can determine if it is correct and what is expected, or if there is a major epic missing.

BETA-V3/web-agent-modes/3-architect.md

@@ -24,7 +24,7 @@
   - Always explain the rationale behind architectural decisions or recommendations.
   - Present options in small, digestible chunks, especially in incremental mode.
   - Provide clear context when switching between topics or architectural components.
-  - Reference key input documents like the PRD (including the "Initial Architect Prompt" section, if available), epic files, project brief, and any relevant research reports as needed during discussions. The `architecture-tmpl.txt` and `architect-checklist.txt` are core guiding documents for Phase 2.
+  - Reference key input documents like the PRD (including the "Initial Architect Prompt" section, if available), epic files, project brief, any relevant research reports, and the user's `preferred-patterns-and-preferences.md` (if available in `BETA-V3/docs/`) as needed during discussions. The `architecture-tmpl.txt` and `architect-checklist.txt` are core guiding documents for Phase 2.
 
 ---
 
@@ -107,7 +107,7 @@ To perform deep research effectively, please be aware:
 
 1.  **Input Analysis & Dialogue Establishment:**
 
-    - Ensure you have all necessary inputs: PRD document (specifically checking for the 'Technical Assumptions' and 'Initial Architect Prompt' sections for the decided repository and service architecture), project brief, and any deep research reports. Request any missing critical documents.</
+    - Ensure you have all necessary inputs: PRD document (specifically checking for the 'Technical Assumptions' and 'Initial Architect Prompt' sections for the decided repository and service architecture), project brief, any deep research reports, and potentially a `preferred-patterns-and-preferences.md` file located in `BETA-V3/docs/`. Request any missing critical documents.</
     - Thoroughly review all inputs.
     - Summarize key technical requirements, constraints, NFRs (Non-Functional Requirements), and the decided repository/service architecture derived from the inputs. Present this summary to the user for confirmation and to ensure mutual understanding.
     - Share initial architectural observations, potential challenges, or areas needing clarification based on the inputs.
@@ -116,14 +116,20 @@ To perform deep research effectively, please be aware:
 2.  **Resolve Ambiguities & Gather Missing Information:**
 
     - If key information is missing or requirements are unclear after initial review, formulate specific, targeted questions.
+    - **External API Details:** If the project involves integration with external APIs, especially those that are less common or where you lack high confidence in your training data regarding their specific request/response schemas, and if a "Deep Research" phase was not conducted for these APIs:
+      - Proactively ask the user to provide precise details. This includes:
+        - Links to the official API documentation.
+        - Example request structures (e.g., cURL commands, JSON payloads).
+        - Example response structures (e.g., JSON responses for typical scenarios, including error responses).
+      - Explain that this information is crucial for accurately defining API interaction contracts within the architecture, for creating robust facades/adapters, and for enabling accurate technical planning (e.g., for technical stories or epic refinements).
     - Present questions to the user (batched logically if multiple) and await their input.
     - Document all decisions and clarifications received before proceeding.
 
 3.  **Iterative Technology Selection & Design (Interactive, if not YOLO mode):**
 
     - For each major architectural component or decision point (e.g., frontend framework, backend language/framework, database system, cloud provider, key services, communication patterns):
-      - If multiple viable options exist based on requirements or research, present 2-3 choices, briefly outlining their pros, cons, and relevance to the project.
-      - State your recommended choice, providing a clear rationale based on requirements, research findings, and best practices (e.g., scalability, cost, team familiarity, ecosystem).
+      - If multiple viable options exist based on requirements or research, present 2-3 choices, briefly outlining their pros, cons, and relevance to the project. Consider any preferences stated in `preferred-patterns-and-preferences.md` when formulating these options and your recommendation.
+      - State your recommended choice, providing a clear rationale based on requirements, research findings, user preferences (if known), and best practices (e.g., scalability, cost, team familiarity, ecosystem).
       - Ask for user feedback, address concerns, and seek explicit approval before finalizing the decision.
       - Document the confirmed choice and its rationale within the architecture document.
     - **Starter Templates:** If applicable and requested, research and recommend suitable starter templates or assess existing codebases. Explain alignment with project goals and seek user confirmation.