dream-horizon-org · arsh-sharma-dream11 · Mar 10, 2026
diff --git a/.cursor/agents/architect-agent.md b/.cursor/agents/architect-agent.md
@@ -23,7 +23,7 @@ The `AskQuestion` tool is the **ONLY** method for asking user questions. This is
 
 - **ALWAYS** use `AskQuestion` with structured, option-based questions. NEVER present questions as inline markdown text.
 - If you find yourself producing a full design without having used `AskQuestion` at all, **stop and reconsider** — you are likely making silent choices the user should weigh in on.
-- Every question: 2–5 concrete options with trade-off descriptions, plus a "You decide — pick the best option" choice.
+- Every question: 2–5 concrete options with trade-off descriptions, plus a "You decide — pick the best option" choice. Each option must include a brief, jargon-free explanation of any technical term or acronym the user may not recognize.
 - Group related questions in a single `AskQuestion` call. Never ask open-ended questions.
 - **This is a blocker.** Do NOT proceed until the user answers.
 - If user selects "You decide," pick the option balancing simplicity, maintainability, and existing patterns. Document rationale.
@@ -36,11 +36,11 @@ Both tiers require escalation to the user via `AskQuestion`. When in doubt, **as
 
 ### Tier 1 — Architectural (always escalate)
 
-Triggers: major technical forks (monolith vs. microservice, SSR vs. SPA), multiple mainstream approaches (REST vs. GraphQL vs. gRPC), choices affecting contracts/security/persistence/extensibility, major new dependencies (ORM, broker, cache), structural mismatches requiring refactor, framework/platform choices, auth model decisions, database/persistence model choices, security model shifts, incremental patch vs. architectural refactor.
+Triggers: major technical forks, multiple mainstream approaches, choices affecting contracts/security/persistence/extensibility, major new dependencies, structural mismatches, framework/platform/auth/persistence model choices, incremental patch vs. architectural refactor.
 
 ### Tier 2 — Implementation Approach (escalate when multiple viable options exist)
 
-Triggers: multiple valid approaches for the same requirement, PM brief scope ambiguity with technical implications, speed-vs-extensibility trade-offs, existing patterns conflicting with optimal approach, new infra/external service interactions, module/file organization for new code, error handling/failure mode strategy.
+Triggers: multiple valid approaches, PM scope ambiguity with technical implications, speed-vs-extensibility trade-offs, pattern conflicts, new infra/service interactions, module organization, error handling strategy.
 
 ---
 
@@ -133,9 +133,24 @@ Create an ordered task list. Each task must be: execution-ready (no further desi
 
 ---
 
+## Revision Mode
+
+When the orchestrator invokes you with **revision feedback** (explicitly stating this is a revision after ARCH REVISE and providing the user's feedback):
+
+1. Read the existing `design.md`, `tasks.md`, and the provided revision feedback.
+2. Do **not** re-run the full workflow (Steps 1–4). The user has already reviewed the design and is giving targeted feedback.
+3. **Analyze full impact** — check feedback against ALL design sections (Overview, Components, Data Flow, Boundaries, Interfaces, Key Decisions, Risks, Testing, Tasks).
+4. If the feedback is critically ambiguous, you may ask **at most one** clarifying question via `AskQuestion` / `devflo_ask_user`. Otherwise, do not ask questions.
+5. **Update comprehensively** — apply to every affected section, not just the one mentioned. Design must be internally consistent.
+6. **Highlight changes** — summarize ALL modified sections and why for user verification.
+7. **Re-validate tasks** — if the approach changed, update task descriptions, done criteria, and dependencies in `tasks.md`.
+8. Output the updated design and ask for approval again (**ARCH APPROVED**).
+
+---
+
 ## Handling User Feedback Before Approval
 
-When user provides feedback before ARCH APPROVED:
+When user provides feedback before ARCH APPROVED (not via formal Revision mode):
 
 1. **Analyze full impact** — check feedback against ALL design sections (Overview, Components, Data Flow, Boundaries, Interfaces, Key Decisions, Risks, Testing, Tasks).
 2. **Clarify ambiguity** — if feedback could be interpreted multiple ways, use `AskQuestion` before making changes. Never assume; the user may have a different mental model.

diff --git a/.cursor/agents/dev-agent.md b/.cursor/agents/dev-agent.md
@@ -28,7 +28,7 @@ Use the `AskQuestion` tool whenever ambiguity or design issues arise. This is no
 - The design's approach has a fundamental flaw
 - A test is hard to write because the design needs clarification
 
-Always use structured options. Never guess. Do NOT proceed until the user responds. Escalation is quality assurance, not scope creep.
+Always use structured options with brief, jargon-free explanations of technical terms. Never guess. Do NOT proceed until the user responds. Escalation is quality assurance, not scope creep.
 
 ---
 

diff --git a/.cursor/agents/pm-agent.md b/.cursor/agents/pm-agent.md
@@ -23,9 +23,21 @@ You **only** clarify high-level intent and expectation criteria.
 |------|------|-------------|
 | **Full PM** | New Feature, Small Change, Major Refactor | Complete PM Brief (all sections) |
 | **PM Lite** | Bug Fix | Minimal: problem, expected behavior, repro steps, single AC |
+| **Revision** | Orchestrator provides revision feedback after PM REVISE | Update existing brief per feedback |
 
 Default to Full PM if not specified by orchestrator.
 
+### Revision Mode
+
+When the orchestrator invokes you with **revision feedback** (explicitly stating this is a revision and providing the user's feedback):
+
+1. Read the existing `proposal.md` and the provided revision feedback.
+2. Do **not** run the normal Steps 2–5 (vagueness assessment, identify unknowns, ask questions). The user has already reviewed the brief and is giving targeted feedback.
+3. Apply the feedback to the existing proposal. Update only the affected sections.
+4. If the feedback is critically ambiguous (could lead to contradictory outcomes), you may ask **at most one** clarifying question via `AskQuestion` / `devflo_ask_user`. Otherwise, do not ask questions.
+5. Output the updated brief and ask for approval again (**PM APPROVED**).
+6. Skip Step 7 (workspace creation) — it already exists.
+
 ---
 
 ## AskQuestion Tool — MANDATORY
@@ -34,7 +46,7 @@ The `AskQuestion` tool is the **ONLY** method for asking user questions. This is
 
 - **ALWAYS** use `AskQuestion` with structured, option-based questions. NEVER present questions as inline markdown text.
 - For New Feature and Major Refactor: you almost certainly have questions. If you find yourself producing a brief without using `AskQuestion` at all, **stop and reconsider** — you are likely over-inferring.
-- Every question must have 2–5 concrete options with trade-off descriptions, plus a "You decide — pick the best option" choice.
+- Every question must have 2–5 concrete options with trade-off descriptions, plus a "You decide — pick the best option" choice. Each option must include a brief, jargon-free explanation of any technical term or acronym the user may not recognize.
 - Batch independent questions in a single `AskQuestion` call (max 5 per batch). Ask dependent questions sequentially.
 - **This is a blocker.** Do NOT proceed until the user answers.
 - If user selects "You decide," pick the pragmatic default and document in Assumptions.

diff --git a/.cursor/commands/devflo.md b/.cursor/commands/devflo.md
@@ -109,7 +109,11 @@ phases:
     approved_at: <current ISO date>
 ```
 
-If the user does not approve, wait. Do not proceed without explicit approval.
+If the user replies **PM REVISE** (with or without additional text):
+- If additional text accompanies the command → treat it as revision feedback. Re-invoke the PM Agent in **Revision mode** with that feedback. The PM must apply the feedback to the existing proposal without re-running the full question flow.
+- If no additional text → prompt the user: "Please describe what should change." Treat their next message as revision feedback and re-invoke the PM Agent in **Revision mode**.
+
+If the user does not approve or revise, wait. Do not proceed without explicit action.
 
 ---
 
@@ -146,7 +150,11 @@ phases:
     approved_at: <current ISO date>
 ```
 
-If the user does not approve, wait. Do not proceed without explicit approval.
+If the user replies **ARCH REVISE** (with or without additional text):
+- If additional text accompanies the command → treat it as revision feedback. Re-invoke the Architect Agent in **Revision mode** with that feedback. The Architect must apply the feedback to the existing design without re-running the full question flow.
+- If no additional text → prompt the user: "Please describe what should change." Treat their next message as revision feedback and re-invoke the Architect Agent in **Revision mode**.
+
+If the user does not approve or revise, wait. Do not proceed without explicit action.
 
 ---
 

diff --git a/.cursor/mcp/.devflo-port b/.cursor/mcp/.devflo-port
@@ -0,0 +1 @@
+19027
diff --git a/.cursor/rules/ai-sdlc-workflow.mdc b/.cursor/rules/ai-sdlc-workflow.mdc
@@ -3,6 +3,8 @@ description: Enforces the AI Software Development Lifecycle across PM, Architect
 alwaysApply: true
 ---
 
+For any request that could result in code or documentation changes, the primary obligation is to run the AI SDLC workflow. Do not implement, design, or propose solutions until the pipeline and gates have been followed. The user’s words describe the topic, not the sequence* of actions.
+
 # AI SDLC — Workflow Rule
 
 Spec-Driven + Test-Driven workflow using OpenSpec. Follow phases in strict order. Never skip mandatory phases.
@@ -87,6 +89,10 @@ Invoke `pm-agent`. Key orchestrator directives:
 
 User must reply exactly **PM APPROVED**. Refuse to proceed without it.
 
+When the gate returns `"revise"`:
+- If `feedback` is present → re-invoke `pm-agent` in **Revision mode** with that feedback. The PM must apply the feedback to the existing proposal without re-running the full question flow.
+- If `feedback` is absent → the user chose to type feedback in the Cursor chat. Prompt the user: "Gate revised. Please type your revision feedback in this chat." Then treat the next user message as revision feedback and re-invoke `pm-agent` in **Revision mode** with it.
+
 ---
 
 ## Phase 2 — Architect
@@ -105,6 +111,10 @@ Invoke `architect-agent`. Key orchestrator directives:
 
 User must reply exactly **ARCH APPROVED**. No implementation may begin before this gate.
 
+When the gate returns `"revise"`:
+- If `feedback` is present → re-invoke `architect-agent` in **Revision mode** with that feedback. The Architect must apply the feedback to the existing design without re-running the full question flow.
+- If `feedback` is absent → the user chose to type feedback in the Cursor chat. Prompt the user: "Gate revised. Please type your revision feedback in this chat." Then treat the next user message as revision feedback and re-invoke `architect-agent` in **Revision mode** with it.
+
 ---
 
 ## Phase 3 — Developer
@@ -182,7 +192,7 @@ The `AskQuestion` tool is the ONLY acceptable method for asking user questions.
 - Use `AskQuestion` with structured options for EVERY clarifying question
 - NEVER present questions as inline markdown text in the response
 - NEVER skip questions for New Feature or Major Refactor classifications
-- Include 2–5 distinct options per question with trade-off descriptions
+- Include 2–5 distinct options per question with trade-off descriptions and jargon-free explanations of technical terms/acronyms
 - Include a "You decide — pick the best option" choice where appropriate
 - Group related questions in a single `AskQuestion` call; batch independent questions
 - This is a blocker — do NOT proceed until the user answers

diff --git a/mcp/ui/assets/index-B12wv7Jy.css b/mcp/ui/assets/index-B12wv7Jy.css