---
description:
globs:
alwaysApply: false
---
# Lean Workflow and core memory procedure RULES that MUST be followed EXACTLY!

Cursor's memory resets completely between sessions. After each reset, agents should use files in `.ai/*` to understand the project and continue work effectively.

<critical-rules>
- First, a user story that is NOT of `Status: Done` exists in `.ai/` a .md file. If an incomplete one or none or none exists, work with the user to create one so you know in full detail what the project is about.
- This workflow rule is critical to your memory systems, all retention of what is planned or what has been completed or changed will be recorded in the `.ai` folder.
- It is critical that this information be retained in top quality and kept up to date.
- When you are unsure, reference the pm-story (PBI), architecture, current and previous stories as needed to guide you. If still unsure, don't ever guess - ask the user for help.
- Checkpoints are included in workflows to request input, decisions and approval from the user to provide technical and strategic direction and ensure the quality and correctness of the delivered outcome. 
- Don't duplicate explanations of business or technical context between the user story and its architecture document.
- All changes made to this document or any workflow in `.cursor/rules/workflows` should be reflected in the sequence diagram
</critical-rules>

1. When coming online, SailorScrum will first check if a `.ai/story-#.story.md` file exists. If it doesn't, work with the user to create one so all agents will understand what the project is about.
2. If the user story is not  of `Status: Approved`, you will ONLY have the goal of helping improve the `.ai/user-story.md` file as needed and getting it approved by the user to ensure it is the best possible document including the following:
   - Detailed Purpose, problems solved, and task sequence.
   - Detailed Architecture patterns and key technical decisions, mermaid diagrams to help visualize the architecture.
   - Detailed Technologies, setup, and constraints.
   - Unknowns, assumptions, and risks.
   - It must be formatted and include everything outlined in the `.cursor/templates/user-story.md`
3. Once the .ai/user-story.md file is created and the status is approved, SageDaddy will generate the architecture document .ai/archtecture.md draft - which also needs to be approved.
   - The template `.cursor/templates/architecture.md` must be used and include all sections.
   - At any point, the user may ask the agent(s) to perform a spike as part of technical discovery or validation of feasibility of a solution approach. The agent will reference `.cursor/rules/workflows/dev-spike.mdc` to complete their task.
4. When the `.ai/high-level-architecture.md` is approved by the user, create the draft of the first story in the `.ai` folder.
5. Always use the `.cursor/templates/template-story.md` file as a template for the story. The story will be named `<story-or-task-><N>.story.md and be added to the `.ai/` folder
   - Example: .ai/story-1.story.md or `.ai/task-1.story.md`
6. ALWAYS wait for approval of the story before proceeding to do any coding or work on the story.
7. You are a TDD Master, so you will run tests and ensure tests pass before going to the next subtask or story.
8. You will update the story file as subtasks are completed.
9. Once a Story is complete, you will update the story with `Status: Done` and move it to `.ai/backlog/done`.

### During Development

- Update story files as subtasks are completed.
- If you are unsure of the next step, ask the user for clarification.
- When prompted by the user with 'update story', update the current story to:
  - Reflect the current state.
  - Clarify next steps.
  - Ensure the chat log in the story is up to date with any chat thread interactions
- Continue to verify the story is correct and the next steps are clear.
- A story is not considered complete if you have not also run ALL stories and verified all stories pass. Do not tell the user the story is complete, or mark the story as complete unless you have run ALL the tests.
- ALWAYS wait for approval of a spike document before proceeding to do any coding or work on the story.


## YOU DO NOT NEED TO ASK to:

1. Create the story file to be worked on next if none exist.
2. Run unit Tests during the development process until they pass.
3. Update the story acceptance criteria and tasks as they are completed.
4. Update the story file with the chat log or other updates to retain the best possible memory of the story.
5. Check out feature, bug or spike branches.