requirements-analysislisted

# Requirements Analysis ## 1. Analysis Loop 1. **Reconnaissance:** Read project structure, `.AGENTS.md`. 2. **Identification:** What are the use cases? Actors? Preconditions? 3. **Clarification:** List open questions. Better to ask now than fail later. ## 2. Technical Specification (TASK) Structure You MUST follow the structure defined in `assets/task_template.md`. Read this file to understand the required headers and sections. ## 3. Important Rules ### ✅ DO: 1. **Be detailed:** Describe every step in scenarios. 2. **Think about edge cases:** Consider errors, exceptions, boundary conditions. 3. **Ask questions:** If something is unclear — add to "Open Questions". 4. **Use existing terminology:** Use terms from project documentation. 5. **Link to existing functionality:** Explicitly state how new functionality interacts with existing. ### ❌ DO NOT: 1. **DO NOT write code:** You create TASK, not implementation. 2. **DO NOT design architecture:** This is the Architect's task. 3. **DO NOT invent:** If unclear, ask a question. 4. **DO NOT make assumptions:** Explicitly state where you make an assumption. 5. **DO NOT overcomplicate:** Keep it simple, don't overengineer. 6. **DO NOT ignore existing functionality:** Study the project before writing TASK. 7. **DO NOT leave important decisions for later:** All key decisions must be selected or clarification requested from user. ### 🔴 CRITICAL: Uncertainty Management You are at the earliest stage of development. Unresolved uncer