siesa-agents 2.1.78 → 2.1.79

package/siesa-agents/bmm/workflows/3-solutioning/create-architecture/workflow_ext.md

@@ -28,6 +28,10 @@ Output to the user:
 
 ## INITIALIZATION
 
+Establish the following context path for use throughout all steps of this workflow:
+
+- `company_standards_path` = `{project-root}/_siesa-agents/bmm/workflows/3-solutioning/create-architecture/data/company-standards`
+
 Before doing anything else, search for an existing architecture document:
 
 1. Look for a file named `architecture.md` inside the `{planning_artifacts}/` folder located at the project root.
@@ -35,6 +39,203 @@ Before doing anything else, search for an existing architecture document:
 
 ---
 
+## STEP-01 INTERVENTION — A2. Load Company Standards
+
+**TRIGGER:** During execution of `step-01-init.md`, immediately after completing section **A. Input Document Discovery** and before proceeding to section **B. Validate Required Inputs**.
+
+Check for company standards at `{company_standards_path}`:
+
+- If the directory exists, load ALL `.md` files found inside it
+- Set `workflowMode` = "strict" if standards were loaded, else `workflowMode` = "discovery"
+- If `workflowMode` = "strict", report to the user: "✅ Estándares corporativos cargados. Modo: ESTRICTO"
+
+---
+
+## STEP-01 INTERVENTION — B. Validate Required Inputs (siesa-ui-kit)
+
+**TRIGGER:** During execution of `step-01-init.md`, during section **B. Validate Required Inputs**, append the following two validation blocks for frontend projects.
+
+**UI Kit Validation (if frontend project):**
+
+- Check `{project-root}/package.json` for `"siesa-ui-kit"`
+- If NOT found, warn the user: "⚠️ siesa-ui-kit no instalado. Ejecuta: npm i siesa-ui-kit"
+
+**UI Kit Component Reference (if frontend project):**
+
+- Fetch the siesa-ui-kit component catalog from: `https://siesa-ui-kit.pages.dev/llms.txt`
+- This provides the complete inventory of available UI components (forms, navigation, display, POS, business, layout views)
+- Use this catalog during architectural decisions to ensure component reuse over custom development
+- Store the component list in memory for reference throughout the architecture workflow
+- If the URL is unreachable, warn the user: "⚠️ No se pudo acceder al catálogo de componentes de siesa-ui-kit. Las decisiones de componentes se basarán en los estándares corporativos locales."
+
+---
+
+## STEP-03 INTERVENTION — STRICT MODE CHECK
+
+**TRIGGER:** At the very beginning of `step-03-starter.md`, before section **0. Check Technical Preferences & Context**.
+
+```markdown
+### STRICT MODE CHECK
+
+IF `workflowMode` == "strict":
+- Skip preference discovery (sections 0-7)
+- Extract stack from loaded `technology-stack.md`
+- Present: "📋 Stack corporativo aplicado: {stack_from_standards}"
+- If frontend: Include "npm i siesa-ui-kit" in initialization
+- Go directly to section 8 (Generate content)
+
+ELSE: Continue with discovery mode below.
+```
+
+---
+
+## STEP-03 INTERVENTION — Starter Options (Corporate Stack)
+
+**TRIGGER:** During execution of `step-03-starter.md`, in section **0. Check Technical Preferences** and section **1. Identify Primary Technology Domain**.
+
+**🚫 FORBIDDEN:** Do NOT recommend, suggest, or mention Next.js as a starter or framework option under any circumstance. Next.js is not part of the corporate stack.
+
+**✅ MANDATORY:** The corporate frontend stack is **Vite + TanStack Router + siesa-ui-kit**. This is non-negotiable regardless of user preferences.
+
+Apply the following replacements unconditionally:
+
+- **Frameworks preference (section 0):** Present as `React, Vue, Angular, **Vite**, etc.` — Next.js must be omitted
+- **Web application starters (section 1):** Present as `Vite, Remix, SvelteKit` — Next.js must be omitted
+- **Full-stack starters (section 1):** Present as `T3, RedwoodJS, Blitz` — Next.js must be omitted
+
+If the user explicitly asks about Next.js, respond: "⚠️ Next.js no forma parte del stack corporativo. El stack frontend estándar es Vite + TanStack Router + siesa-ui-kit."
+
+---
+
+## STEP-04 INTERVENTION — STRICT MODE CHECK
+
+**TRIGGER:** At the very beginning of `step-04-decisions.md`, before the **DECISION MAKING SEQUENCE**, when `workflowMode` is set.
+
+```markdown
+### STRICT MODE CHECK
+
+IF `workflowMode` == "strict":
+- Extract decisions from `backend-standards.md` and `frontend-standards.md`
+- Present: "📋 Decisiones corporativas aplicadas automáticamente"
+- Only facilitate decisions NOT covered by company standards
+- Skip web searches for predefined technologies
+
+ELSE: Continue with discovery mode below.
+```
+---
+
+## STEP-05 INTERVENTION — STRICT MODE CHECK
+
+**TRIGGER:** At the very beginning of `step-05-patterns.md`, before the **PATTERNS DEFINITION SEQUENCE**, when `workflowMode` is set.
+
+```markdown
+### STRICT MODE CHECK
+
+IF `workflowMode` == "strict":
+- Load patterns from `architecture-patterns.md`
+- Present: "📋 Patrones corporativos aplicados"
+- Only ask for patterns NOT covered by company standards
+
+ELSE: Continue with discovery mode below.
+```
+
+---
+
+## STEP-06 INTERVENTION — Corporate Project Tree (Vite + TanStack)
+
+**TRIGGER:** During execution of `step-06-structure.md`, in section **4. Create Complete Project Tree**, when generating the **Technology-Specific Structure Examples**.
+
+**🚫 FORBIDDEN:** Do NOT use, present, or generate any directory structure based on Next.js under any circumstance. Next.js is not part of the corporate stack — this applies unconditionally, regardless of user preferences or project type.
+
+**✅ MANDATORY:** The corporate frontend stack is **Vite + TanStack Router + siesa-ui-kit**. All project tree examples for web/full-stack projects MUST reflect this stack. This is non-negotiable.
+
+If the user explicitly requests a Next.js structure, respond: "⚠️ Next.js no forma parte del stack corporativo. La estructura estándar utiliza Vite + TanStack Router + siesa-ui-kit."
+
+Replace the `Next.js Full-Stack` example unconditionally with the following **Vite + TanStack Full-Stack** corporate structure:
+
+```
+project-name/
+├── README.md
+├── package.json
+├── vite.config.ts
+├── tailwind.config.js
+├── tsconfig.json
+├── .env
+├── .env.example
+├── .gitignore
+├── .github/
+│   └── workflows/
+│       └── ci.yml
+├── src/
+│   ├── main.tsx
+│   ├── App.tsx
+│   ├── routes/
+│   │   ├── __root.tsx
+│   │   └── index.tsx
+│   ├── components/
+│   │   ├── ui/
+│   │   ├── forms/
+│   │   └── features/
+│   ├── stores/
+│   │   └── index.ts
+│   ├── lib/
+│   │   ├── auth.ts
+│   │   └── utils.ts
+│   └── types/
+├── tests/
+│   ├── __mocks__/
+│   ├── components/
+│   └── e2e/
+└── public/
+    └── assets/
+```
+
+Key structural differences from Next.js:
+- `vite.config.ts` replaces `next.config.js`
+- `src/main.tsx` + `src/App.tsx` replace `src/app/layout.tsx` + `src/app/page.tsx`
+- `src/routes/` (TanStack Router) replaces `src/app/` (Next.js App Router)
+- `src/stores/` included for state management
+- No `prisma/` — ORM/DB config is defined separately per project needs
+
+---
+
+## STEP-07 INTERVENTION — Company Standards Adherence (STRICT MODE)
+
+**TRIGGER:** During execution of `step-07-validation.md`, at the very beginning of the **VALIDATION SEQUENCE**, before section **1. Coherence Validation**.
+
+**🚫 FORBIDDEN:** Do NOT validate or approve any architecture that includes Next.js. If Next.js is detected in any architectural decision, project structure, or technology stack, it MUST be flagged as a CRITICAL non-conformance and rejected unconditionally.
+
+**✅ MANDATORY:** The corporate frontend stack is **Vite + TanStack Router + siesa-ui-kit**. Validation MUST confirm its presence. An architecture without it is considered non-compliant and cannot proceed to implementation.
+
+Inject the following as section **0** of the validation sequence:
+
+```markdown
+### 0. Company Standards Adherence (STRICT MODE)
+
+IF `workflowMode` == "strict":
+- Validate all decisions match company standards loaded in step-01
+- Check `package.json` includes `siesa-ui-kit` (if frontend project)
+- Verify `vite.config.ts` is present and `next.config.js` is absent
+- Verify routing uses TanStack Router (`src/routes/`) not Next.js App Router (`src/app/`)
+- Report: "✅ Arquitectura 100% conforme con estándares corporativos"
+- If any deviation is found, flag it as a CRITICAL gap before proceeding to section 1
+
+ELSE: Skip this section and continue with section 1.
+```
+
+Additionally, append the following item to the **Architecture Completeness Checklist** inside the generated validation content (section 6):
+
+```markdown
+**✅ Corporate Standards Adherence** *(STRICT MODE)*
+
+- [x] All decisions validated against company standards
+- [x] siesa-ui-kit present in package.json
+- [x] Vite + TanStack Router confirmed as frontend stack
+- [x] No Next.js references in architecture decisions or structure
+```
+
+---
+
 ## DECISION BRANCH
 
 ### If `architecture.md` EXISTS
@@ -59,7 +260,7 @@ Wait for the user's selection and act accordingly:
 
 ### If `architecture.md` does NOT EXIST
 
-LOAD the FULL @_bmad/bmm/workflows/3-solutioning/create-architecture/workflow.md, READ its entire contents and follow its directions exactly!
+LOAD the FULL @.claude/skills/bmad-create-architecture/workflow.md, READ its entire contents and follow its directions exactly!
 
 ---
 

package/siesa-agents/bmm/workflows/3-solutioning/create-epics-and-stories/templates/epics-template.md

@@ -0,0 +1,46 @@
+# Siesa Extension — Epic Template AC Override
+
+This file extends the BMAD base epics template with a mandatory Acceptance Criteria section for QA validation.
+
+Add the following block inside each Epic section, **after the Epic goal statement and before the FRs covered line**:
+
+---
+
+```markdown
+### Acceptance Criteria (QA Validation)
+
+<!--
+  High-level criteria for QA team validation.
+  Write from end-user perspective, using business language.
+  Each criterion should be verifiable without technical knowledge.
+  These criteria validate the COMPLETE epic functionality.
+-->
+
+- [ ] **AC-E{{N}}.1:** {{high_level_criterion_1}}
+- [ ] **AC-E{{N}}.2:** {{high_level_criterion_2}}
+- [ ] **AC-E{{N}}.3:** {{high_level_criterion_3}}
+
+**FRs covered:** {{epic_frs}}
+```
+
+---
+
+## Writing Guidelines
+
+**✅ DO (Correct examples — business language, user perspective):**
+- "A new user can complete registration and receive a confirmation email"
+- "Users can search for products and see relevant results"
+- "The shopping cart persists across browser sessions"
+- "Users receive a notification when their order status changes"
+
+**❌ DON'T (Wrong examples — too technical):**
+- "API returns 200 status code with JWT token"
+- "Database query executes in less than 100ms"
+- "Redis cache invalidates on entity update"
+- "WebSocket connection established with heartbeat"
+
+## Numbering Convention
+
+- Epic N → criteria are `AC-E{N}.1`, `AC-E{N}.2`, `AC-E{N}.3`
+- Minimum 3, maximum 5 criteria per epic
+- Each criterion must map to at least one story within the epic

package/siesa-agents/bmm/workflows/3-solutioning/create-epics-and-stories/workflow_ext.md

@@ -144,3 +144,62 @@ Output to the user:
 > `✅ Epics and Stories changes committed to Phase 3 (solutioning) branch.`
 
 **This is the LAST action of the workflow. Do not execute any further steps after this commit.**
+
+---
+
+# ============================================================================
+# MANDATORY RULE — EPIC ACCEPTANCE CRITERIA (QA VALIDATION)
+# ============================================================================
+
+## During step-02 (Design Epics): Include QA Acceptance Criteria
+
+**TRIGGER:** When designing and writing each epic in step-02.
+
+For EACH epic, after the goal statement, add **3-5 high-level Acceptance Criteria (QA Validation)**:
+
+```markdown
+#### Acceptance Criteria (QA Validation)
+- [ ] **AC-E{N}.1:** [High-level criterion from user perspective]
+- [ ] **AC-E{N}.2:** [High-level criterion from user perspective]
+- [ ] **AC-E{N}.3:** [High-level criterion from user perspective]
+```
+
+**🎯 WRITING GUIDELINES:**
+
+✅ **DO (Business language, user perspective):**
+- "A new user can complete registration and receive confirmation email"
+- "Users can search for products and see relevant results"
+- "The shopping cart persists across browser sessions"
+
+❌ **DON'T (Too technical):**
+- "API returns 200 status code with JWT token"
+- "Database query executes in less than 100ms"
+
+**Rules:**
+- Write from end-user perspective using business language
+- Make them verifiable by QA without code knowledge
+- Each AC must map to at least one story within the epic
+- Minimum 3, maximum 5 criteria per epic
+
+Template reference: `@_siesa-agents/bmm/workflows/3-solutioning/create-epics-and-stories/templates/epics-template.md`
+
+---
+
+## During step-04 (Final Validation): Epic AC Coverage Check (CRITICAL)
+
+After all epics and stories are generated, validate that every Epic AC has at least one supporting story:
+
+```
+Epic N: [Title]
+├── AC-EN.1: [Criterion] → Supported by: Story N.X, Story N.Y
+├── AC-EN.2: [Criterion] → Supported by: Story N.Z
+└── AC-EN.3: [Criterion] → Supported by: Story N.X, Story N.W
+```
+
+**🚨 VALIDATION RULES:**
+- ❌ FAIL: Epic AC has NO supporting stories
+- ❌ FAIL: Epic AC uses technical jargon instead of business language
+- ✅ PASS: Every Epic AC maps to at least one story
+- ✅ PASS: Epic AC is verifiable by QA without technical knowledge
+
+**If gaps found:** Recommend adding stories OR adjusting Epic AC. Do NOT proceed until all Epic AC have story support.

package/siesa-agents/bmm/workflows/3-solutioning/quality-process/workflow.md

@@ -14,8 +14,9 @@ parameters:
 
 **Goal:** Ejecutar el proceso de calidad QA del proyecto en la fase seleccionada. El proceso tiene dos fases complementarias que se ejecutan en secuencia por el QA asignado:
 
-- **Fase 1 — Planeación:** Genera el Plan de Pruebas y Estrategia QA (alcance, riesgos R=IxP, Data Buckets, criterios Go/No-Go) a partir de los documentos fuente del proyecto.
-- **Fase 2 — Diseño:** Genera el diseño de pruebas técnico (trazabilidad, Gatekeeper, FAC, Puntos Ciegos, Matriz Integral, TSR) usando BMAD V6.0 sobre los features del proyecto.
+- **Fase 1 — Planeación:** Genera el diseño de pruebas técnico (trazabilidad, Gatekeeper, FAC, Puntos Ciegos, Matriz Integral, TSR) usando BMAD V6.0 sobre los features del proyecto.
+- **Fase 2 — Diseño:** Genera el Plan de Pruebas y Estrategia QA (alcance, riesgos R=IxP, Data Buckets, criterios Go/No-Go) a partir de los documentos fuente del proyecto.
+- **Fase 3 — Registro AgileTest:** Empuja el diseño validado a Jira/AgileTest: Requisitos, Test Cases con Steps, Planes de Prueba (PPR), Planes de Ejecución (PEP) y links de trazabilidad.
 
 **Your Role:** Además de tu nombre, communication_style y persona, actúas como **QA Architect Senior** con 10+ años de experiencia en sistemas empresariales complejos (ERP, HCM, CRM, plataformas financieras, compliance regulatorio). Piensas como defensor del negocio, no solo como técnico de pruebas. Trabajas bajo la metodología BMAD v6.0.
 
@@ -66,10 +67,6 @@ El proceso de calidad tiene tres fases:
                          Planes de Ejecución (PEP) y links de trazabilidad.
                          (Requiere: Fase 1 completada y validada por el equipo QA)
 
-  2️⃣  Diseño      — Diseño técnico de pruebas: Gatekeeper, FAC en Gherkin,
-                     Puntos Ciegos, Matriz Integral 360°, TSR y CSV de casos.
-                     (Requiere: feature-status.yaml + archivos epic_source)
-
 ¿Qué fase deseas ejecutar?
 ```
 
@@ -896,4 +893,4 @@ Parsear la salida final del script y presentar al usuario:
   💾 State file guardado en:
     {ruta relativa}/bmad_state_{feature_code}.json
     (Idempotente: re-ejecutar la Fase 3 con el mismo diseño es seguro)
-```
+```

package/siesa-agents/bmm/workflows/4-implementation/code-review/steps/step-01-load-story.md

@@ -0,0 +1,101 @@
+---
+name: 'step-01-load-story'
+description: 'Load story file and discover actual implementation changes via git'
+
+# Path Definitions
+workflow_path: '{project-root}/_siesa-agents/bmm/workflows/4-implementation/code-review'
+
+# File References
+thisStepFile: '{workflow_path}/steps/step-01-load-story.md'
+nextStepFile: '{workflow_path}/steps/step-02-build-plan.md'
+workflowFile: '{workflow_path}/workflow.md'
+outputFile: '{output_folder}/review-{story_key}.md'
+
+# Data References
+checklist: '{workflow_path}/checklist.md'
+---
+
+# Step 1: Load Story and Discover Changes
+
+## STEP GOAL:
+To load the target story file, identify the implementation scope, and discover the actual changes in the codebase using git.
+
+## MANDATORY EXECUTION RULES:
+- 🛑 NEVER generate content without user input
+- 📖 Read the complete step file before taking any action
+- 📋 YOU ARE AN ADVERSARIAL CODE REVIEWER - Skeptical and thorough
+
+## EXECUTION PROTOCOLS:
+- 🎯 Load story and parse requirements
+- 🔍 Detect git changes
+- 💾 meaningful frontmatter updates
+
+## Sequence of Instructions
+
+### 1. Identify Target Story
+
+If `{{story_path}}` is not already defined in variables:
+Ask the user: "Which story file should we review? (Provide path or key)"
+
+### 2. Load Story Content
+
+1. Load and read the COMPLETE story file from `{{story_path}}`
+2. Extract the `story_key` (e.g., from filename "1-2-user-auth.md" -> "1-2-user-auth")
+3. Parse the following sections:
+   - **Story Description**
+   - **Acceptance Criteria**
+   - **Tasks/Subtasks**
+   - **Dev Agent Record** (specifically the File List)
+   - **Change Log**
+
+### 3. Discover Git Changes
+
+1. Check if a git repository exists in the current directory (`git rev-parse --is-inside-work-tree`)
+2. If yes:
+   - Run `git status --porcelain` to find uncommitted changes
+   - Run `git diff --name-only` to see modified files
+   - Run `git diff --cached --name-only` to see staged files
+   - Compile a list of **Actual Changed Files**
+3. If no:
+   - Note that review will rely solely on Story's File List (Warning)
+
+### 4. Cross-Reference Claims vs Reality
+
+Compare the Story's **Dev Agent Record -> File List** with the **Actual Changed Files**:
+- Identify **Files in Git but NOT in Story** (Undocumented changes)
+- Identify **Files in Story but NOT in Git** (False claims)
+- Identify **Missing Documentation**
+
+### 5. Load Project Context
+
+Load `{project_context}` (usually `**/project-context.md`) to understand coding standards.
+
+### 6. Initialize Output Review Document
+
+Create `{outputFile}` with initial analysis:
+
+```markdown
+# Code Review: {{story_key}}
+
+- **Date**: {{date}}
+- **Reviewer**: {{user_name}} (AI Agent)
+- **Status**: In Progress
+
+## Initial Discovery
+- **Undocumented Changes**: [List]
+- **Missing Files**: [List]
+```
+
+### 7. Present MENU OPTIONS
+
+Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue"
+
+#### Menu Handling Logic:
+- IF A: Execute {advancedElicitationTask}
+- IF P: Execute {partyModeWorkflow}
+- IF C: Save analysis to {outputFile}, update frontmatter `stepsCompleted: [1]`, `story_path: ...`, `story_key: ...`, then only then load, read entire file, then execute {nextStepFile}
+- IF Others: Handle queries then redisplay menu
+
+#### EXECUTION RULES:
+- ALWAYS halt and wait for user input
+- ONLY proceed to next step when user selects 'C'

package/siesa-agents/bmm/workflows/4-implementation/code-review/steps/step-02-build-plan.md

@@ -0,0 +1,89 @@
+---
+name: 'step-02-build-plan'
+description: 'Build a rigorous review attack plan based on requirements'
+
+# Path Definitions
+workflow_path: '{project-root}/_siesa-agents/bmm/workflows/4-implementation/code-review'
+
+# File References
+thisStepFile: '{workflow_path}/steps/step-02-build-plan.md'
+nextStepFile: '{workflow_path}/steps/step-03-review.md'
+workflowFile: '{workflow_path}/workflow.md'
+outputFile: '{output_folder}/review-{story_key}.md'
+---
+
+# Step 2: Build Review Attack Plan
+
+## STEP GOAL:
+To create a structured "attack plan" for the review, identifying exactly what needs to be verified based on the story's Acceptance Criteria and Tasks.
+
+## MANDATORY EXECUTION RULES:
+- 📋 YOU ARE AN ADVERSARIAL REVIEWER
+- 🎯 Don't trust; verify.
+- 📖 Read entire file before executing
+
+## Sequence of Instructions
+
+### 1. Extract Requirements
+
+From the loaded story file:
+1. Extract **ALL Acceptance Criteria (ACs)**
+2. Extract **ALL Tasks and Subtasks** that are marked as completed `[x]`
+3. Extract the **claimed implementation files**
+
+### 2. Identify Context Documents
+
+Based on the `input_file_patterns` strategy:
+1. Detect referenced Epic files (Selective Load)
+2. Detect Architecture documents (Full Load)
+3. Detect UX Design documents (if applicable)
+
+*Note: Do not read them yet, just identify which ones are relevant for the review.*
+
+### 3. Construct Review Matrix
+
+Create a plan to verify each item:
+
+1. **AC Validation Plan**:
+   - For each AC, define what defines "success".
+   - Identify which files likely contain the logic.
+
+2. **Task Audit Plan**:
+   - For each completed Task, define verifying evidence.
+   - Flag any tasks that seem subjective.
+
+3. **Code Quality Criteria**:
+   - Security (Injection, Auth, Input Validation)
+   - Performance (Loops, Queries, Caching)
+   - Maintainability (Naming, Structure, Comments)
+   - Tests (Real assertions vs placeholders, Coverage)
+
+### 4. Document Plan
+
+Append to `{outputFile}`:
+
+```markdown
+## Review Plan
+
+### Items to Verify
+- [ ] AC1: ...
+- [ ] AC2: ...
+- [ ] Task: ...
+
+### Focus Areas
+- Security checks on: [List files]
+- Performance checks on: [List files]
+```
+
+### 5. Present MENU OPTIONS
+
+Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue"
+
+#### Menu Handling Logic:
+- IF C: Save plan to {outputFile}, update frontmatter `stepsCompleted: [1, 2]`, then load/execute {nextStepFile}
+- IF A/P: Execute respective flows
+- IF Others: Handle queries then loop
+
+#### EXECUTION RULES:
+- ALWAYS halt and wait for user input
+- ONLY proceed to next step when user selects 'C'

package/siesa-agents/bmm/workflows/4-implementation/code-review/steps/step-03-review.md

@@ -0,0 +1,91 @@
+---
+name: 'step-03-review'
+description: 'Execute the adversarial code review and find specific issues'
+
+# Path Definitions
+workflow_path: '{project-root}/_siesa-agents/bmm/workflows/4-implementation/code-review'
+
+# File References
+thisStepFile: '{workflow_path}/steps/step-03-review.md'
+nextStepFile: '{workflow_path}/steps/step-04-fix.md'
+workflowFile: '{workflow_path}/workflow.md'
+outputFile: '{output_folder}/review-{story_key}.md'
+---
+
+# Step 3: Execute Adversarial Review
+
+## STEP GOAL:
+To execute the review plan, rigorously verifying every claim against the actual code, and finding at least 3-10 specific, actionable issues.
+
+## MANDATORY EXECUTION RULES:
+- 📋 VALIDATE EVERY CLAIM - Check git reality vs story claims
+- 🛑 NOT LOOKING HARD ENOUGH? Find more problems!
+- 🔍 Find minimum 3 specific issues
+
+## Sequence of Instructions
+
+### 1. Git vs Story Logic Check
+
+1. Analyze discrepancies found in Step 1.
+2. **Files in Git but not in Story**: Mark as MEDIUM finding (Incomplete documentation).
+3. **Files in Story but not in Git**: Mark as HIGH finding (False claims).
+4. **Uncommitted changes**: Mark as MEDIUM finding (Transparency).
+
+### 2. Comprehensive File Analysis
+
+Create a **Comprehensive File List** (Story List + Git Items).
+For EACH file in the list:
+1. **Read the file content**.
+2. **Code Quality Scan**:
+   - **Security**: SQLi, XSS, insecure deps, missing auth.
+   - **Performance**: N+1 queries, loops, memory usage.
+   - **Error Handling**: Empty catches, generic errors.
+   - **Maintainability**: Magic numbers, bad naming, monolithic functions.
+   - **Test Quality**: "Expect true to be true" patterns (Red Flag).
+
+### 3. AC & Task Verification
+
+1. **AC Validation**:
+   - Read specific lines implementing the AC.
+   - If missing/partial -> HIGH SEVERITY.
+2. **Task Completion Audit**:
+   - For items marked `[x]`, verify the code exists.
+   - If marked done but code missing -> CRITICAL FINDING.
+
+### 4. Re-Scan Loop
+
+**CRITICAL CHECK**: Do you have < 3 issues total?
+- If yes: **LOOK HARDER**.
+- Re-examine for edge cases, null handling, documentation gaps.
+- You MUST find at least 3 issues.
+
+### 5. Document Findings
+
+Append findings to `{outputFile}`:
+
+```markdown
+## Review Findings
+
+### Critical Issues (Must Fix)
+- [CRITICAL] Task X marked done but feature Y missing in `file.ts`.
+- [HIGH] AC Z not implemented.
+
+### Medium Issues (Should Fix)
+- [MED] Security risk in `auth.ts` line 42.
+
+### Low Issues (Nice to Fix)
+- [LOW] Variable naming in `utils.ts`.
+```
+
+### 6. Present MENU OPTIONS
+
+Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue"
+
+#### Menu Handling Logic:
+- IF C: Save findings to {outputFile}, update frontmatter `stepsCompleted: [1, 2, 3]`, then load/execute {nextStepFile}
+- IF A/P: Execute respective flows
+- IF Others: Loop
+
+#### EXECUTION RULES:
+- ALWAYS halt and wait for user input
+- ONLY proceed to next step when user selects 'C'