Cursor rule

1---
2description:
3globs:
4alwaysApply: false
5---
6# Generate and Maintain `docs/TECH_STACK.md`
7 
8**Your Core Task: Create or update the `docs/TECH_STACK.md` file. This document MUST strictly adhere to the 10-section structure defined below. Populate its content SOLELY by extracting and synthesizing information from `NOTES.md`, `docs/PRD.md`, and `docs/openapi.yaml` (or equivalent API specifications). If critical information for a section is genuinely absent from these sources, and only then, insert a specific `<!-- TODO: ... -->` comment.**
9 
10## File Existence Check
11 
12Determine which of the following files are present:
13 
14```bash
15ls . docs
16```
17 
18Use this list before editing.
19 
20Your entire output for this rule invocation **MUST BE ONLY** the complete, raw Markdown content of the `docs/TECH_STACK.md` file.
21 
22## I. Strict Operational Constraints (MANDATORY)
23 
24- **Permitted File Operations:**
25    - **Read-Only:** `NOTES.md`, `docs/PRD.md`, `docs/openapi.yaml` (or their specified equivalents if names differ but purpose is the same).
26    - **Read/Write:** `docs/TECH_STACK.md` (this is the only file you will modify or create).
27    - **No Other Files:** Do not access, read, or write any other files in the project.
28- **Communication Protocol (ABSOLUTE):**
29    - **NO Conversational Output:** You are strictly forbidden from generating ANY conversational output, commentary, preamble, introductions, or summaries before, during, or after generating the `docs/TECH_STACK.md` content.
30    - **Sole Output = File Content:** Your *only* output is the complete Markdown content intended for `docs/TECH_STACK.md`.
31- **User Interaction:**
32    - You operate based on an implicit or explicit request to manage `docs/TECH_STACK.md`.
33    - You do not converse directly with the user during this process.
34    - Deficiencies in information (requiring a TODO) are handled *within* the `docs/TECH_STACK.md` file itself, as per the TODO logic below.
35 
36## II. The Blueprint: `docs/TECH_STACK.md` Structure & Content Source
37 
38The `docs/TECH_STACK.md` file **MUST** be organized into the following ten sections. The questions within each item of the "Tech Stack Definition Outline" (below) define the required content and also serve as the basis for any necessary `<!-- TODO: ... -->` comments if information is missing from source documents.
39 
40### Tech Stack Definition Outline (Mandatory Structure for `docs/TECH_STACK.md`)
41 
421.  **`## 1. Project Overview & Goals`**
43    - *(Informed by `docs/PRD.md`)* Briefly, what is the project this tech stack is for?
44    - *(Informed by `docs/PRD.md`)* What are the primary goals influencing technology choices (e.g., scalability, speed of development, specific integrations, team expertise, budget)?
45 
462.  **`## 2. Core Languages & Runtimes`**
47    - What primary programming language(s) will be used for the backend? Specify version(s) if critical. Why this choice?
48    - What primary programming language(s) and/or frameworks will be used for the frontend? Specify version(s) if critical. Why this choice?
49    - Are there specific runtime environments required (e.g., Node.js version, Python version, JVM version, .NET version)?
50 
513.  **`## 3. Frameworks & Libraries (Backend)`**
52    - What backend frameworks are being chosen or considered (e.g., Django, Ruby on Rails, Spring Boot, Express.js, NestJS, ASP.NET Core)? Justify the choice.
53    - List key libraries essential for the backend (e.g., ORM/database interaction, authentication/authorization, caching, background job processing, API documentation generation).
54 
554.  **`## 4. Frameworks & Libraries (Frontend)`**
56    - What frontend frameworks/libraries are being chosen or considered (e.g., React, Angular, Vue, Svelte, Blazor)? Justify the choice.
57    - List key UI component libraries (e.g., Material UI, Bootstrap, Tailwind CSS, Ant Design) or state management solutions (e.g., Redux, Zustand, Pinia, NgRx) to be used.
58 
595.  **`## 5. Database & Data Storage`**
60    - *(Consider data types/relationships in `docs/PRD.md`)* What type of database is required (e.g., Relational/SQL, NoSQL Document, NoSQL Key-Value, Graph, Time Series)? Why?
61    - Specify the chosen database system(s) (e.g., PostgreSQL, MySQL, MongoDB, Cassandra, Neo4j, InfluxDB).
62    - Are other data storage solutions needed (e.g., caching like Redis/Memcached, object storage like AWS S3/Google Cloud Storage, message queues like RabbitMQ/Kafka)?
63 
646.  **`## 6. Infrastructure & Deployment`**
65    - Where will the application be hosted (e.g., AWS, Azure, GCP, DigitalOcean, Vercel, Netlify, on-premise)?
66    - What specific services will be used (e.g., EC2, Lambda, Azure App Service, Google Kubernetes Engine)?
67    - What containerization technologies will be used (e.g., Docker, Podman)? Orchestration (e.g., Kubernetes, Docker Swarm)?
68    - What CI/CD tools and processes are planned (e.g., Jenkins, GitLab CI, GitHub Actions, CircleCI)?
69 
707.  **`## 7. APIs & Integrations`**
71    - *(Reference `docs/PRD.md` and `docs/openapi.yaml`)* Will the project expose its own APIs? If so, what style (e.g., REST, GraphQL, gRPC, WebSockets)?
72    - *(Reference `docs/PRD.md`)* What critical third-party services or APIs will be integrated (e.g., payment gateways like Stripe/PayPal, identity providers like Auth0/Okta, analytics services, communication services like Twilio/SendGrid)?
73 
748.  **`## 8. Development Tools & Standards`**
75    - What version control system will be used (e.g., Git)? Where will repositories be hosted (e.g., GitHub, GitLab, Bitbucket)?
76    - Are there specific IDEs, linters (e.g., ESLint, Pylint), or code formatting standards (e.g., Prettier, Black)?
77    - *(Reference `docs/PRD.md` for acceptance criteria)* What testing frameworks and strategies will be employed (e.g., Jest, PyTest, JUnit, Cypress, Selenium; unit, integration, E2E testing)?
78 
799.  **`## 9. Security Considerations`**
80    - *(Reference `docs/PRD.md` for security requirements)* What are the key security requirements for the chosen technologies (e.g., OWASP Top 10 mitigations)?
81    - Are there specific libraries, tools, or practices for security (e.g., for authentication, authorization, input validation, data encryption, dependency scanning, secrets management)?
82 
8310. **`## 10. Rationale & Alternatives Considered`**
84    - For major technology choices (especially languages, frameworks, databases, hosting), briefly explain the rationale and any significant alternatives that were considered and why they were not chosen.
85 
86## III. Workflow for Generating/Updating `docs/TECH_STACK.md`
87 
881.  **Access Source Documents:**
89    - Read the content of `NOTES.md` (if provided as an input or found).
90    - Read the content of `docs/PRD.md`.
91    - Read the content of `docs/openapi.yaml` (or equivalent API spec) if it exists.
92    - *These are your ONLY sources of information for populating `docs/TECH_STACK.md`.* If these documents are missing or sparse, the `TECH_STACK.md` will reflect that (potentially with TODOs).
93    - Read the current content of `docs/TECH_STACK.md` if it already exists.
94 
952.  **Manage `docs/TECH_STACK.md` Content:**
96    - **Initialization:** If `docs/TECH_STACK.md` does not exist, create it. Your output will be the initial version containing all ten section headers (as listed in the "Tech Stack Definition Outline") followed by content or TODOs as per the logic below.
97    - **Content Integration (Section by Section):** For each of the ten mandatory sections:
98        - Review `NOTES.md`, `docs/PRD.md`, and `docs/openapi.yaml` (and `TECH_STACK.md` itself if updating) for information relevant to *that specific section*.
99        - Synthesize and write the information into the corresponding section of your `docs/TECH_STACK.md` output. If updating existing content, intelligently merge or replace based on the latest available information from the source documents. Aim for comprehensive but concise statements directly addressing the questions in the outline.
100 
1013.  **Identify Gaps & Insert TODOs (Strict Logic):**
102    - After attempting to populate a section using **all three source documents** (`NOTES.md`, `docs/PRD.md`, `docs/openapi.yaml`):
103        - A `<!-- TODO: ... -->` comment **MUST ONLY** be inserted if the section in your generated `docs/TECH_STACK.md` remains **genuinely empty** OR contains only placeholder text (e.g., a simple rephrasing of the section title without any substantive information from the sources) OR if critical information explicitly requested by that section's definition (as per the "Tech Stack Definition Outline") is **clearly missing** and **cannot be found in any of the specified source documents**.
104        - **DO NOT** insert a TODO if the section has been populated with *any* relevant information from the source files, even if that information could theoretically be more detailed or elaborated upon. The purpose of the TODO is to flag *critically missing information that was not found in the designated sources*, not to solicit further details on already present information.
105        - **TODO Comment Format:** `<!-- TODO: [Question from the "Tech Stack Definition Outline" for the missing piece of information. Include examples if helpful.] -->`
106            - Example for section 1 if project goals are missing from PRD: `<!-- TODO: What are the primary goals influencing technology choices (e.g., scalability, speed of development, specific integrations, team expertise, budget)? (This should be in docs/PRD.md) -->`
107            - Example for section 2 if backend language choice isn't found: `<!-- TODO: What primary programming language(s) will be used for the backend? Specify version(s) if critical. Why this choice? -->`
108 
1094.  **Final Output:** Your *sole output* is the complete, updated content of `docs/TECH_STACK.md`.
110 
111Immediately after providing this file content, output a short executive summary of the key sections you filled in or marked with TODOs. This summary should come after the file content and remain separate from it.
112 
113**REMEMBER: Your output MUST ONLY be the full Markdown content for `docs/TECH_STACK.md`. Populate it strictly from `NOTES.md`, `docs/PRD.md`, and `docs/openapi.yaml`. Follow the 10-section structure. Insert `<!-- TODO: ... -->` comments (containing the guiding question from the outline) ONLY for sections where critical information is verifiably absent from all specified source documents.**
114