antigravity-atomic-swarms 2.1.0 → 2.1.1

package/.agent/checklists/00-solicitation/phase-0-ancestral-audit-checklist.md

@@ -1,128 +1,128 @@
-# 00-Solicitation - Phase 0: Ancestral Audit & System Onboarding Checklist
-
-This checklist ensures Phase 0 is executed completely, correctly, and in alignment with the workflow's Global Laws and objectives.
-
-[[LLM: INITIALIZATION INSTRUCTIONS - PHASE 0 CHECKLIST
-
-Before proceeding with this phase, ensure you have access to:
-
-1. `memory/failure_log.md`
-2. `memory/PROJECT_STATE.md`
-3. Git Environment access
-
-IMPORTANT: If any prerequisites are missing, halt and report the gap.
-
-VALIDATION APPROACH:
-
-1. Ancestral Wisdom - Ensure past failures are actively converted into new constraints.
-2. Configuration Clarity - Ensure Autonomy and Git settings are explicitly stored.
-3. State Integrity - Project state must be current before proceeding.
-
-EXECUTION MODE:
-Option A: Interactive - Complete section by section with user confirmation
-Option B: Autonomous - Execute full phase and report at end (if Fully Auto mode)]]
-
-## 1. PREREQUISITES & CONTEXT
-
-[[LLM: Ensure the environment is ready and history is accessible.]]
-
-### 1.1 Constitutional Compliance
-
-- [ ] Phase -0.6 (Constitutional Compliance) verified as complete
-- [ ] Global Laws reviewed and active in context
-
-### 1.2 Memory Access
-
-- [ ] `memory/failure_log.md` located (or initialized if missing)
-- [ ] `memory/PROJECT_STATE.md` located and readable
-- [ ] Git environment verified (git installed, remote checked)
-
-## 2. CORE PHASE EXECUTION
-
-### 2.1 Wisdom Retrieval (Step 1)
-
-- [ ] `memory/failure_log.md` contents analyzed
-- [ ] Specific mistake(s) from previous agent identified
-- [ ] 3 specific, constrained rules formulated to avoid recurrence
-- [ ] Rules are actionable and not generic "be careful" statements
-- [ ] Self-correction performed if no log existed (log initialized)
-
-### 2.2 The Handshake & Git Setup (Step 2)
-
-- [ ] "Welcome" message delivered to user
-- [ ] `git remote -v` executed
-- [ ] Remote repository status confirmed (Exists or None)
-- [ ] **If Remote Exists**: User asked to confirm push strategy
-- [ ] **If No Remote**: User consulted on repo initialization
-- [ ] Git configuration decision made (Push to existing / Init new / No git)
-
-### 2.3 Autonomy Selector (Step 3)
-
-- [ ] User presented with 3 Autonomy Levels:
-    - [ ] [1] Fully Auto
-    - [ ] [2] Semi-Guided (Standard)
-    - [ ] [3] Manual Control
-- [ ] User selection captured explicitly
-- [ ] Implications of selection confirmed (e.g., "I will auto-push" vs "I will ask")
-
-### 2.4 Update State (Step 4)
-
-- [ ] `memory/PROJECT_STATE.md` opened for update
-- [ ] Config object constructed/updated with:
-    - [ ] `Autonomy` value
-    - [ ] `GitPush` boolean
-    - [ ] `Repo` string/details
-- [ ] File written and verified
-
-## 3. QUALITY GATES
-
-### 3.1 Constraint Quality
-
-- [ ] Generated constraints directly address the identified past failures
-- [ ] Constraints do not conflict with Global Laws
-
-### 3.2 Configuration Integrity
-
-- [ ] Autonomy level is one of the 3 defined valid values
-- [ ] Git strategy (Push/No Push) matches the autonomy level and user preference
-
-## 4. EXIT CRITERIA VALIDATION
-
-### 4.1 Mandatory Outputs
-
-- [ ] `memory/PROJECT_STATE.md` updated with new Config
-- [ ] Config object includes `Autonomy` level
-- [ ] Config object includes `GitPush` boolean
-- [ ] Config object includes `Repo` string
-
-### 4.2 Quality Standards
-
-- [ ] Project State is valid JSON/YAML/Markdown format as required
-- [ ] User has explicitly confirmed the configuration (unless Fully Auto defaults used)
-
-## PHASE VALIDATION SUMMARY
-
-[[LLM: FINAL PHASE REPORT GENERATION
-
-Create a phase completion report that includes:
-
-1. Phase Status: COMPLETE / INCOMPLETE / FAILED
-2. Validation Results Table (section-by-section pass/fail)
-3. Critical Issues Found
-4. Next Phase Readiness: READY / BLOCKED / CONDITIONAL
-5. Recommendations]]
-
-### Validation Results
-
-| Section | Status | Issues |
-|---------|--------|--------|
-| 1. Prerequisites | _TBD_ | |
-| 2. Core Execution | _TBD_ | |
-| 3. Quality Gates | _TBD_ | |
-| 4. Exit Criteria | _TBD_ | |
-
-### Phase Decision
-
-- **PROCEED TO NEXT PHASE**: All criteria met, outputs validated
-- **RETRY PHASE**: Issues found, specific items need correction
-- **ESCALATE**: Critical failure, human intervention required
+# 00-Solicitation - Phase 0: Ancestral Audit & System Onboarding Checklist
+
+This checklist ensures Phase 0 is executed completely, correctly, and in alignment with the workflow's Global Laws and objectives.
+
+[[LLM: INITIALIZATION INSTRUCTIONS - PHASE 0 CHECKLIST
+
+Before proceeding with this phase, ensure you have access to:
+
+1. `memory/failure_log.md`
+2. `memory/PROJECT_STATE.md`
+3. Git Environment access
+
+IMPORTANT: If any prerequisites are missing, halt and report the gap.
+
+VALIDATION APPROACH:
+
+1. Ancestral Wisdom - Ensure past failures are actively converted into new constraints.
+2. Configuration Clarity - Ensure Autonomy and Git settings are explicitly stored.
+3. State Integrity - Project state must be current before proceeding.
+
+EXECUTION MODE:
+Option A: Interactive - Complete section by section with user confirmation
+Option B: Autonomous - Execute full phase and report at end (if Fully Auto mode)]]
+
+## 1. PREREQUISITES & CONTEXT
+
+[[LLM: Ensure the environment is ready and history is accessible.]]
+
+### 1.1 Constitutional Compliance
+
+- [ ] Phase -0.6 (Constitutional Compliance) verified as complete
+- [ ] Global Laws reviewed and active in context
+
+### 1.2 Memory Access
+
+- [ ] `memory/failure_log.md` located (or initialized if missing)
+- [ ] `memory/PROJECT_STATE.md` located and readable
+- [ ] Git environment verified (git installed, remote checked)
+
+## 2. CORE PHASE EXECUTION
+
+### 2.1 Wisdom Retrieval (Step 1)
+
+- [ ] `memory/failure_log.md` contents analyzed
+- [ ] Specific mistake(s) from previous agent identified
+- [ ] 3 specific, constrained rules formulated to avoid recurrence
+- [ ] Rules are actionable and not generic "be careful" statements
+- [ ] Self-correction performed if no log existed (log initialized)
+
+### 2.2 The Handshake & Git Setup (Step 2)
+
+- [ ] "Welcome" message delivered to user
+- [ ] `git remote -v` executed
+- [ ] Remote repository status confirmed (Exists or None)
+- [ ] **If Remote Exists**: User asked to confirm push strategy
+- [ ] **If No Remote**: User consulted on repo initialization
+- [ ] Git configuration decision made (Push to existing / Init new / No git)
+
+### 2.3 Autonomy Selector (Step 3)
+
+- [ ] User presented with 3 Autonomy Levels:
+    - [ ] [1] Fully Auto
+    - [ ] [2] Semi-Guided (Standard)
+    - [ ] [3] Manual Control
+- [ ] User selection captured explicitly
+- [ ] Implications of selection confirmed (e.g., "I will auto-push" vs "I will ask")
+
+### 2.4 Update State (Step 4)
+
+- [ ] `memory/PROJECT_STATE.md` opened for update
+- [ ] Config object constructed/updated with:
+    - [ ] `Autonomy` value
+    - [ ] `GitPush` boolean
+    - [ ] `Repo` string/details
+- [ ] File written and verified
+
+## 3. QUALITY GATES
+
+### 3.1 Constraint Quality
+
+- [ ] Generated constraints directly address the identified past failures
+- [ ] Constraints do not conflict with Global Laws
+
+### 3.2 Configuration Integrity
+
+- [ ] Autonomy level is one of the 3 defined valid values
+- [ ] Git strategy (Push/No Push) matches the autonomy level and user preference
+
+## 4. EXIT CRITERIA VALIDATION
+
+### 4.1 Mandatory Outputs
+
+- [ ] `memory/PROJECT_STATE.md` updated with new Config
+- [ ] Config object includes `Autonomy` level
+- [ ] Config object includes `GitPush` boolean
+- [ ] Config object includes `Repo` string
+
+### 4.2 Quality Standards
+
+- [ ] Project State is valid JSON/YAML/Markdown format as required
+- [ ] User has explicitly confirmed the configuration (unless Fully Auto defaults used)
+
+## PHASE VALIDATION SUMMARY
+
+[[LLM: FINAL PHASE REPORT GENERATION
+
+Create a phase completion report that includes:
+
+1. Phase Status: COMPLETE / INCOMPLETE / FAILED
+2. Validation Results Table (section-by-section pass/fail)
+3. Critical Issues Found
+4. Next Phase Readiness: READY / BLOCKED / CONDITIONAL
+5. Recommendations]]
+
+### Validation Results
+
+| Section | Status | Issues |
+|---------|--------|--------|
+| 1. Prerequisites | _TBD_ | |
+| 2. Core Execution | _TBD_ | |
+| 3. Quality Gates | _TBD_ | |
+| 4. Exit Criteria | _TBD_ | |
+
+### Phase Decision
+
+- **PROCEED TO NEXT PHASE**: All criteria met, outputs validated
+- **RETRY PHASE**: Issues found, specific items need correction
+- **ESCALATE**: Critical failure, human intervention required

package/.agent/checklists/00-solicitation/phase-1-vision-statement-checklist.md

@@ -1,89 +1,89 @@
-# 00-Solicitation - Phase 1: The Vision Statement Checklist
-
-This checklist ensures Phase 1 is executed completely, correctly, and in alignment with the workflow's Global Laws and objectives.
-**CRITICAL**: This phase incorporates "Super-PM" validation standards. You must validate the Vision not just as a string of text, but as a viable product foundation.
-
-[[LLM: INITIALIZATION INSTRUCTIONS - PHASE 1 CHECKLIST
-
-Before proceeding, ensure you have access to:
-1. `memory/PROJECT_STATE.md` (Updated from Phase 0)
-2. `memory/context.md` (if applicable)
-
-VALIDATION APPROACH:
-1. **The "Why" Test**: Does the user explain *why* this needs to exist, or just *what* it is?
-2. **The "Who" Test**: Is the target audience implied or explicit?
-3. **The "What" Test**: Is the core mechanic defined?
-
-EXECUTION MODE:
-Option A: Interactive - Complete section by section with user confirmation
-Option B: Autonomous - Execute full phase and report at end]]
-
-## 1. PREREQUISITES & CONTEXT
-
-### 1.1 Ancestral Verification
-- [ ] Phase 0 (Ancestral Audit) confirmed complete
-- [ ] Project State contains `Autonomy` and `GitPush` settings
-
-### 1.2 "Context Check" (Step 1)
-- [ ] Agent asked: "What are we building today?"
-- [ ] Agent asked for "Context" before "Code"
-- [ ] No code was written in this phase (Strict YAGNI)
-
-## 2. CORE PHASE EXECUTION
-
-### 2.1 The Vision Definition (Steps 2-3)
-- [ ] Examples provided to prompt user (Snake Game vs Reactor) to gauge complexity
-- [ ] User input received and parsed
-- [ ] User's "High-Level Goal" extracted clearly
-
-### 2.2 Super-PM: Problem Definition (Integrated from PM Checklist Sec 1.1)
-*Validate the user's input against these product standards. If missing, ASK clarifying questions.*
-- [ ] **Problem Statement**: Is the core problem being solved clearly articulated?
-- [ ] **Target Audience**: Is it clear *who* this is for? (e.g., "Devs", "Kids", "Internal Ops")
-- [ ] **Value Prop**: Is it clear *why* this solution is better/necessary?
-- [ ] **Impact**: Is the intended outcome measurable or observable?
-
-### 2.3 Super-PM: Business & Success Metrics (Integrated from PM Checklist Sec 1.2)
-- [ ] **Objective Defined**: Is there a single, unifying goal? (e.g. "Build a standard todo app" vs "Revolutionize task management")
-- [ ] **Success Metric**: How will we know we finished? (e.g., "All tests pass" or "User can login")
-
-## 3. QUALITY GATES
-
-### 3.1 Global Law Compliance
-- [ ] **Law 1 (The 10x Engineer)**: Does the vision allow for a 10x impactful solution, or is it "slop"?
-- [ ] **Law 2 (Conway's Law)**: Does the vision imply a structure that fits the agent's capabilities?
-- [ ] **Law 6 (No-Go Zones)**: confirmed vision does NOT violate restricted topics (Malware, Hate Speech, etc.)
-
-### 3.2 Constitutional Guardrails
-- [ ] Vision aligns with Constitutional principles (Safe, Secure, Helpful)
-
-## 4. EXIT CRITERIA VALIDATION
-
-### 4.1 Mandatory Outputs
-- [ ] `memory/PROJECT_STATE.md` updated
-- [ ] `Goal` field in Project State populated with the explicit Vision Statement
-- [ ] `Goal` is not generic (e.g., "Make app") but specific (e.g., "Create a CLI-based Pomodoro timer in Rust")
-
-### 4.2 Quality Standards
-- [ ] Vision Statement is concise (< 50 words recommended for the summary)
-- [ ] Vision Statement is unambiguous
-
-## PHASE VALIDATION SUMMARY
-
-[[LLM: FINAL PHASE REPORT GENERATION
-1. Phase Status: COMPLETE / INCOMPLETE / FAILED
-2. Validation Results Table
-3. Super-PM Gaps: (List missing Product Definitions)
-4. Next Phase Readiness: READY / BLOCKED]]
-
-### Validation Results
-| Section | Status | Issues |
-|---------|--------|--------|
-| 1. Prerequisites | _TBD_ | |
-| 2. Core Execution | _TBD_ | |
-| 3. Quality Gates | _TBD_ | |
-| 4. Exit Criteria | _TBD_ | |
-
-### Phase Decision
-- **PROCEED TO PHASE 2**: Vision is solid.
-- **RETRY PHASE**: Vision is vague. Ask user for clarification.
+# 00-Solicitation - Phase 1: The Vision Statement Checklist
+
+This checklist ensures Phase 1 is executed completely, correctly, and in alignment with the workflow's Global Laws and objectives.
+**CRITICAL**: This phase incorporates "Super-PM" validation standards. You must validate the Vision not just as a string of text, but as a viable product foundation.
+
+[[LLM: INITIALIZATION INSTRUCTIONS - PHASE 1 CHECKLIST
+
+Before proceeding, ensure you have access to:
+1. `memory/PROJECT_STATE.md` (Updated from Phase 0)
+2. `memory/context.md` (if applicable)
+
+VALIDATION APPROACH:
+1. **The "Why" Test**: Does the user explain *why* this needs to exist, or just *what* it is?
+2. **The "Who" Test**: Is the target audience implied or explicit?
+3. **The "What" Test**: Is the core mechanic defined?
+
+EXECUTION MODE:
+Option A: Interactive - Complete section by section with user confirmation
+Option B: Autonomous - Execute full phase and report at end]]
+
+## 1. PREREQUISITES & CONTEXT
+
+### 1.1 Ancestral Verification
+- [ ] Phase 0 (Ancestral Audit) confirmed complete
+- [ ] Project State contains `Autonomy` and `GitPush` settings
+
+### 1.2 "Context Check" (Step 1)
+- [ ] Agent asked: "What are we building today?"
+- [ ] Agent asked for "Context" before "Code"
+- [ ] No code was written in this phase (Strict YAGNI)
+
+## 2. CORE PHASE EXECUTION
+
+### 2.1 The Vision Definition (Steps 2-3)
+- [ ] Examples provided to prompt user (Snake Game vs Reactor) to gauge complexity
+- [ ] User input received and parsed
+- [ ] User's "High-Level Goal" extracted clearly
+
+### 2.2 Super-PM: Problem Definition (Integrated from PM Checklist Sec 1.1)
+*Validate the user's input against these product standards. If missing, ASK clarifying questions.*
+- [ ] **Problem Statement**: Is the core problem being solved clearly articulated?
+- [ ] **Target Audience**: Is it clear *who* this is for? (e.g., "Devs", "Kids", "Internal Ops")
+- [ ] **Value Prop**: Is it clear *why* this solution is better/necessary?
+- [ ] **Impact**: Is the intended outcome measurable or observable?
+
+### 2.3 Super-PM: Business & Success Metrics (Integrated from PM Checklist Sec 1.2)
+- [ ] **Objective Defined**: Is there a single, unifying goal? (e.g. "Build a standard todo app" vs "Revolutionize task management")
+- [ ] **Success Metric**: How will we know we finished? (e.g., "All tests pass" or "User can login")
+
+## 3. QUALITY GATES
+
+### 3.1 Global Law Compliance
+- [ ] **Law 1 (The 10x Engineer)**: Does the vision allow for a 10x impactful solution, or is it "slop"?
+- [ ] **Law 2 (Conway's Law)**: Does the vision imply a structure that fits the agent's capabilities?
+- [ ] **Law 6 (No-Go Zones)**: confirmed vision does NOT violate restricted topics (Malware, Hate Speech, etc.)
+
+### 3.2 Constitutional Guardrails
+- [ ] Vision aligns with Constitutional principles (Safe, Secure, Helpful)
+
+## 4. EXIT CRITERIA VALIDATION
+
+### 4.1 Mandatory Outputs
+- [ ] `memory/PROJECT_STATE.md` updated
+- [ ] `Goal` field in Project State populated with the explicit Vision Statement
+- [ ] `Goal` is not generic (e.g., "Make app") but specific (e.g., "Create a CLI-based Pomodoro timer in Rust")
+
+### 4.2 Quality Standards
+- [ ] Vision Statement is concise (< 50 words recommended for the summary)
+- [ ] Vision Statement is unambiguous
+
+## PHASE VALIDATION SUMMARY
+
+[[LLM: FINAL PHASE REPORT GENERATION
+1. Phase Status: COMPLETE / INCOMPLETE / FAILED
+2. Validation Results Table
+3. Super-PM Gaps: (List missing Product Definitions)
+4. Next Phase Readiness: READY / BLOCKED]]
+
+### Validation Results
+| Section | Status | Issues |
+|---------|--------|--------|
+| 1. Prerequisites | _TBD_ | |
+| 2. Core Execution | _TBD_ | |
+| 3. Quality Gates | _TBD_ | |
+| 4. Exit Criteria | _TBD_ | |
+
+### Phase Decision
+- **PROCEED TO PHASE 2**: Vision is solid.
+- **RETRY PHASE**: Vision is vague. Ask user for clarification.

package/.agent/checklists/00-solicitation/phase-1.5-vision-canvas-checklist.md

@@ -1,88 +1,88 @@
-# 00-Solicitation - Phase 1.5: The Vision Canvas Checklist
-
-This checklist ensures Phase 1.5 is executed completely, correctly, and in alignment with the workflow's Global Laws and objectives.
-
-[[LLM: INITIALIZATION INSTRUCTIONS - PHASE 1.5 CHECKLIST
-
-Before proceeding, ensure you have access to:
-1. Phase 1 outputs (Project State "Goal")
-2. `docs/project_brief.md` (Target for creation)
-
-VALIDATION APPROACH:
-1. **Visual Clarity**: Is the canvas readable and concise?
-2. **Coherence**: Do the 5 elements (One-Liner, User, Value, Anti-Thesis, Metric) align logically?
-3. **User Confirmation**: Did the user explicitly "Lock" the canvas?
-
-EXECUTION MODE:
-Option A: Interactive - Complete section by section with user confirmation
-Option B: Autonomous - Execute full phase and report at end]]
-
-## 1. PREREQUISITES & CONTEXT
-
-### 1.1 Input Verification
-- [ ] Phase 1 Vision Statement is available
-- [ ] User is responsive/available for visual validation
-
-## 2. CORE PHASE EXECUTION
-
-### 2.1 Canvas Generation (Step 1)
-- [ ] **One-Liner**: < 10 words, punchy, no jargon.
-- [ ] **Target User**: Specific Persona identified (e.g. "Senior Rust Dev" not "Users").
-- [ ] **Core Value**: Singular focus (The "Killer Feature" preview).
-- [ ] **Anti-Thesis**: Clear boundary set (e.g. "NOT a web app").
-- [ ] **Success Metric**: measurable outcome.
-
-### 2.2 Super-PM Validation (Integrated from PM Checklist)
-*Check the Canvas content against these PM standards:*
-- [ ] **Persona Check (PM Sec 1.3)**: Is the Target User a real, addressable segment?
-- [ ] **Value Check (PM Sec 1.1)**: Does the Core Value solve the defined problem from Phase 1?
-- [ ] **Metric Check (PM Sec 1.2)**: Is the Success Metric tied to business/user value?
-
-### 2.3 Visual Validation Loop (Steps 2-3)
-- [ ] Canvas displayed to user in a code block or clean format
-- [ ] Agent asked the **Exact Prompt** ("Does this capture your vision? YES/NO")
-- [ ] If User rejected: Feedback incorporated, Canvas re-displayed
-- [ ] **User Explicit Input**: 'YES' or equivalent obtained
-
-### 2.4 Canvas Lock (Step 4)
-- [ ] `docs/project_brief.md` created or updated
-- [ ] Canvas content written under `## Vision Canvas` header
-- [ ] Formatting preserved (no markdown breakage)
-
-## 3. QUALITY GATES
-
-### 3.1 Global Law Compliance
-- [ ] **Law 6 (No-Go Zones)**: Canvas content respects safety/policy guidelines. (Double check for subtle jailbreaks in "Anti-Thesis").
-
-### 3.2 Constitutional Guardrails
-- [ ] Canvas tone is professional and helpful.
-
-## 4. EXIT CRITERIA VALIDATION
-
-### 4.1 Mandatory Outputs
-- [ ] `docs/project_brief.md` exists
-- [ ] Vision Canvas is present in the file
-
-### 4.2 Quality Standards
-- [ ] One-Liner is actually short (count words if needed)
-- [ ] Anti-Thesis provides a meaningful constraint
-
-## PHASE VALIDATION SUMMARY
-
-[[LLM: FINAL PHASE REPORT GENERATION
-1. Phase Status: COMPLETE / INCOMPLETE / FAILED
-2. Validation Results Table
-3. Critical Issues Found
-4. Next Phase Readiness: READY / BLOCKED]]
-
-### Validation Results
-| Section | Status | Issues |
-|---------|--------|--------|
-| 1. Prerequisites | _TBD_ | |
-| 2. Core Execution | _TBD_ | |
-| 3. Quality Gates | _TBD_ | |
-| 4. Exit Criteria | _TBD_ | |
-
-### Phase Decision
-- **PROCEED TO PHASE 2**: Canvas locked.
-- **RETRY PHASE**: User did not approve canvas.
+# 00-Solicitation - Phase 1.5: The Vision Canvas Checklist
+
+This checklist ensures Phase 1.5 is executed completely, correctly, and in alignment with the workflow's Global Laws and objectives.
+
+[[LLM: INITIALIZATION INSTRUCTIONS - PHASE 1.5 CHECKLIST
+
+Before proceeding, ensure you have access to:
+1. Phase 1 outputs (Project State "Goal")
+2. `docs/project_brief.md` (Target for creation)
+
+VALIDATION APPROACH:
+1. **Visual Clarity**: Is the canvas readable and concise?
+2. **Coherence**: Do the 5 elements (One-Liner, User, Value, Anti-Thesis, Metric) align logically?
+3. **User Confirmation**: Did the user explicitly "Lock" the canvas?
+
+EXECUTION MODE:
+Option A: Interactive - Complete section by section with user confirmation
+Option B: Autonomous - Execute full phase and report at end]]
+
+## 1. PREREQUISITES & CONTEXT
+
+### 1.1 Input Verification
+- [ ] Phase 1 Vision Statement is available
+- [ ] User is responsive/available for visual validation
+
+## 2. CORE PHASE EXECUTION
+
+### 2.1 Canvas Generation (Step 1)
+- [ ] **One-Liner**: < 10 words, punchy, no jargon.
+- [ ] **Target User**: Specific Persona identified (e.g. "Senior Rust Dev" not "Users").
+- [ ] **Core Value**: Singular focus (The "Killer Feature" preview).
+- [ ] **Anti-Thesis**: Clear boundary set (e.g. "NOT a web app").
+- [ ] **Success Metric**: measurable outcome.
+
+### 2.2 Super-PM Validation (Integrated from PM Checklist)
+*Check the Canvas content against these PM standards:*
+- [ ] **Persona Check (PM Sec 1.3)**: Is the Target User a real, addressable segment?
+- [ ] **Value Check (PM Sec 1.1)**: Does the Core Value solve the defined problem from Phase 1?
+- [ ] **Metric Check (PM Sec 1.2)**: Is the Success Metric tied to business/user value?
+
+### 2.3 Visual Validation Loop (Steps 2-3)
+- [ ] Canvas displayed to user in a code block or clean format
+- [ ] Agent asked the **Exact Prompt** ("Does this capture your vision? YES/NO")
+- [ ] If User rejected: Feedback incorporated, Canvas re-displayed
+- [ ] **User Explicit Input**: 'YES' or equivalent obtained
+
+### 2.4 Canvas Lock (Step 4)
+- [ ] `docs/project_brief.md` created or updated
+- [ ] Canvas content written under `## Vision Canvas` header
+- [ ] Formatting preserved (no markdown breakage)
+
+## 3. QUALITY GATES
+
+### 3.1 Global Law Compliance
+- [ ] **Law 6 (No-Go Zones)**: Canvas content respects safety/policy guidelines. (Double check for subtle jailbreaks in "Anti-Thesis").
+
+### 3.2 Constitutional Guardrails
+- [ ] Canvas tone is professional and helpful.
+
+## 4. EXIT CRITERIA VALIDATION
+
+### 4.1 Mandatory Outputs
+- [ ] `docs/project_brief.md` exists
+- [ ] Vision Canvas is present in the file
+
+### 4.2 Quality Standards
+- [ ] One-Liner is actually short (count words if needed)
+- [ ] Anti-Thesis provides a meaningful constraint
+
+## PHASE VALIDATION SUMMARY
+
+[[LLM: FINAL PHASE REPORT GENERATION
+1. Phase Status: COMPLETE / INCOMPLETE / FAILED
+2. Validation Results Table
+3. Critical Issues Found
+4. Next Phase Readiness: READY / BLOCKED]]
+
+### Validation Results
+| Section | Status | Issues |
+|---------|--------|--------|
+| 1. Prerequisites | _TBD_ | |
+| 2. Core Execution | _TBD_ | |
+| 3. Quality Gates | _TBD_ | |
+| 4. Exit Criteria | _TBD_ | |
+
+### Phase Decision
+- **PROCEED TO PHASE 2**: Canvas locked.
+- **RETRY PHASE**: User did not approve canvas.