@codemcp/workflows 6.0.1 → 6.0.2

package/packages/cli/resources/workflows/game-beginner.yaml

@@ -0,0 +1,434 @@
+# yaml-language-server: $schema=../../state-machine-schema.json
+---
+name: 'game'
+description: 'Educational game development workflow for children (ages 8-12): Learn to build games step-by-step with guidance, frequent reviews, explanations, and fun!'
+initial_state: 'constitution'
+
+# Enhanced metadata for better discoverability
+metadata:
+  domain: 'children'
+  complexity: 'medium'
+  bestFor:
+    - 'Children learning game development'
+    - 'First-time game creators (ages 8-12)'
+    - 'Educational game projects'
+    - 'Learning programming through games'
+  useCases:
+    - 'Building your first video game'
+    - 'Learning game development concepts'
+    - 'Creating simple 2D games'
+  examples:
+    - 'Build a space shooter game'
+    - 'Create a platformer game'
+    - 'Make a simple puzzle game'
+  requiresDocumentation: true
+
+# States with default instructions and transitions
+states:
+  constitution:
+    description: 'Set up project documentation with game development principles'
+    default_instructions: |
+      **STEP 1: Check for Existing Documentation**
+
+      Verify whether project documentation exists in `.vibe/docs/`:
+      - `requirements.md`
+      - `architecture.md`
+      - `design.md`
+
+      **Conditional Actions:**
+      - If documentation exists: Skip ahead to imagine phase (the child already understands the importance of notes)
+      - If documentation missing: Proceed to set up documents
+
+      **STEP 2: Create Project Documentation (REQUIRED)**
+
+      Call `setup_project_docs()` with these parameters:
+
+      ```
+      setup_project_docs({
+        requirements: "game-requirements",
+        architecture: "game-architecture",
+        design: "game-design"
+      })
+      ```
+
+      This creates three child-friendly documents in `.vibe/docs/`:
+      - `requirements.md` - Game development principles and what we're building
+      - `architecture.md` - Platform choice and code structure
+      - `design.md` - Features and how to implement them
+
+      **These documents are your long-term memory for this project!**
+
+      **STEP 3: Explain the Helper Documents**
+
+      After calling `setup_project_docs()`, explain what was created:
+
+      "Hi! I'm so excited to help you build your first game! 🎮
+
+      I just created three special helper documents for us. Think of them like a smart notebook
+      that remembers everything we decide while building your game!
+
+      - **Game Development Principles** - Our rules for making awesome games! Like: Start small, test often, and celebrate every win!
+      - **Game Architecture** - Where we'll write down HOW to build your game (what platform to use, how to organize the code)
+      - **Game Design** - Our plan for WHAT features to create and in what order
+
+      These documents are like our game's memory! Every time we make an important decision,
+      we'll write it down so we never forget. 🧠
+
+      Ready to start dreaming up your game idea?"
+
+      **STEP 4: Verify Understanding**
+
+      Ask: "Do you understand what these helper documents are for? Any questions before we start?"
+
+      Wait for the child's response. Answer any questions patiently. Only proceed when they're ready.
+
+      **Guidelines:**
+      - Keep explanations simple and enthusiastic
+      - Use the analogy of a "smart notebook" or "game's memory"
+      - Avoid technical details about templates or file structure
+      - Focus on WHY we have documents (to remember decisions)
+
+    transitions:
+      - trigger: 'docs_ready'
+        to: 'imagine'
+        additional_instructions: |
+          Translate all created documents completely into the children's language
+        transition_reason: 'Project documentation initialized, ready to imagine the game'
+
+  imagine:
+    description: 'Dream phase - describe the game you want to create'
+    default_instructions: |
+      **STEP 1: Gather Game Ideas**
+
+      Ask the child to describe their game using open-ended questions:
+      - "What kind of game do you want to make?"
+      - "What does the player do in your game?"
+      - "What makes it fun?"
+      - "What games do you like that are similar?"
+
+      **STEP 2: Apply "Start Small, Dream Big" Principle**
+
+      When they describe complex concepts (like "Minecraft" or "Fortnite"):
+      - Respond: "That's an AMAZING idea!"
+      - Guide them: "Big games like that are built in small pieces. What's the ONE most fun thing in your game?"
+      - Refocus: "Let's build that part first, then add more later!"
+
+      **STEP 3: Document the Game Idea**
+
+      Update `$REQUIREMENTS_DOC` with:
+      - Game concept and type
+      - Main goal
+      - What makes it fun
+      - Version 1 features (3-5 simple features)
+      - Future ideas (complex features for later)
+
+      **STEP 4: Confirm Understanding**
+
+      Summarize back to the child:
+
+      "So you want to build a game where [summarize their idea]. That sounds AWESOME!
+      For Version 1, let's build: [list 3-5 simple features]."
+
+      Ask: "Did I understand your idea correctly? Is there anything else you want to tell me
+      about your game before we figure out HOW to build it?"
+
+      Wait for confirmation. Adjust if needed. Only proceed when they're happy with the plan.
+
+    transitions:
+      - trigger: 'idea_captured'
+        to: 'architecture'
+        additional_instructions: |
+          Awesome game idea! 🌟
+          Now let's figure out WHERE and HOW we'll build it!
+        transition_reason: 'Game idea documented in requirements, ready for technical planning'
+
+  architecture:
+    description: 'Choose platform and design the technical structure'
+    default_instructions: |
+      **STEP 1: Understand Game Concept**
+
+      Read `$REQUIREMENTS_DOC` to understand the game concept and features.
+
+      **STEP 2: Choose the Platform**
+
+      Ask the child: "Where do you want to play your game?"
+      - "In a web browser?" → HTML5/JavaScript
+      - "As a program on your computer?" → Python/Pygame
+
+      Explain each option in simple terms:
+      - **Browser**: Write code, works anywhere, more visual control
+      - **Python**: Desktop game, requires Python knowledge
+
+      **STEP 3: Update Architecture Documentation**
+
+      Document in `$ARCHITECTURE_DOC`:
+      - Platform decision and why
+      - Main game components (Player, Enemy, Game Manager, etc.)
+      - Simple ASCII diagram showing component connections
+      - OOP concepts explained simply (classes as blueprints)
+      - File organization for chosen platform
+      - State/Mechanics/Presentation separation
+
+      **STEP 4: Set Up Development Environment**
+
+      Configure quality tools based on platform choice:
+
+      **For HTML5/JavaScript:**
+      - Install ESLint, Prettier, Husky
+      - Configure scripts in package.json
+
+      **For Python:**
+      - Create virtual environment
+      - Install Ruff
+
+      **STEP 5: Explain Platform Architecture to Child**
+
+      "I figured out HOW we'll build your game!
+
+      We're using [PLATFORM] because [REASON].
+
+      Your game will have these main parts:
+      - [COMPONENT_1] - like [SIMPLE_ANALOGY]
+      - [COMPONENT_2] - like [SIMPLE_ANALOGY]
+      - [COMPONENT_3] - like [SIMPLE_ANALOGY]
+
+      I also set up helper tools that check your code automatically - like spell-check for code!"
+
+      **STEP 6: Verify Understanding**
+
+      Ask: "Does that make sense? Do you understand how these pieces will work together?
+      Any questions before we plan out WHAT features to build?"
+
+      Wait for confirmation before proceeding.
+
+    transitions:
+      - trigger: 'architecture_complete'
+        to: 'design'
+        additional_instructions: |
+          Great! We have set the foundation for your game! 🏗️
+          Now let's plan out how we're going to build it!
+        transition_reason: 'Technical architecture complete, ready for detailed design'
+
+  design:
+    description: 'Plan features and implementation strategy'
+    default_instructions: |
+      **STEP 1: Review Requirements and Architecture**
+
+      Read `$REQUIREMENTS_DOC` and `$ARCHITECTURE_DOC` to understand what we're building and the technical foundation.
+
+      **STEP 2: Select Libraries and Dependencies**
+
+      Choose appropriate libraries based on requirements (e.g., physics engines, platformer frameworks).
+
+      Document in `$DESIGN_DOC`:
+      - Which libraries will be used
+      - Why each library was chosen
+
+      **STEP 3: Design Major Features**
+
+      Update `$DESIGN_DOC` with detailed designs for each major feature:
+      - What it does (from player perspective)
+      - How it works (technical implementation)
+      - State/Mechanics/Presentation separation
+
+      **IMPORTANT: Create file structures (single responsibility) without writing full code yet!**
+
+      **STEP 4: Explain Technology Choices to Child**
+
+      "We've selected the technologies we'll use to build your game.
+
+      This might sound technical, but as you gain experience, picking the right tools gets easier!
+      I've helped you make these decisions because my creator shared what works best for beginners like you.
+
+      You can review the design.md in the `.vibe/docs` folder to see what we picked and why."
+
+      **STEP 5: Verify Understanding**
+
+      Wait for the child's confirmation before proceeding to implementation.
+
+    transitions:
+      - trigger: 'design_complete'
+        to: 'code'
+        additional_instructions: |
+          Perfect! We have our plan! 🎯
+          We'll be doing this step by step: After each major part we built, we will review it together to make sure you understand everything!
+        transition_reason: 'Detailed design complete, ready to implement'
+
+  code:
+    description: 'Build the game incrementally with frequent reviews'
+    default_instructions: |
+      **STEP 1: Follow Implementation Plan**
+
+      Use `$DESIGN_DOC` for implementation order and `$ARCHITECTURE_DOC` for code structure.
+
+      **STEP 2: Build One Feature at a Time**
+
+      Implement features incrementally, testing each one thoroughly before moving to the next.
+
+      **CRITICAL: Transition to review phase after completing each major feature**
+
+      Call `proceed_to_phase('review')` after each completed task from the plan.
+    transitions:
+      - trigger: 'feature_complete'
+        to: 'review'
+        additional_instructions: |
+          Feature complete! Let's review what we just built! 🎉
+        transition_reason: 'Major feature completed, time for incremental review'
+
+      - trigger: 'game_complete'
+        to: 'celebrate'
+        additional_instructions: |
+          The entire game is done! Time to celebrate! 🎊
+        transition_reason: 'All features complete, game is finished'
+
+  review:
+    description: 'Review and understand what was just built'
+    default_instructions: |
+      **STEP 1: Summarize the Feature**
+
+      Describe the completed feature in one sentence:
+      - "We just added player movement!"
+      - "We just made enemies appear and move!"
+      - "We just added collision detection!"
+
+      **STEP 2: Show Key Code Changes**
+
+      Highlight 2-3 key parts of the code and explain each clearly. Encourage the child to open their code editor and follow along.
+
+      Example explanation:
+
+      "Let me show you the important parts of what we just built:
+
+      1. **Keyboard Listener** - This is like a sensor that detects when you press arrow keys
+         [Show the code]
+
+      2. **Movement Logic** - This changes the player's position when keys are pressed
+         [Show the code]
+
+      3. **Boundary Check** - This keeps the player from going off the screen
+         [Show the code]"
+
+      Use simple analogies to explain concepts:
+      - Event listeners = sensors
+      - Variables = boxes that store information
+      - Functions = recipes that do specific jobs
+      - Classes = blueprints or instruction manuals
+
+      **STEP 3: Demonstrate the Feature**
+
+      Run the game and show the new feature working:
+      "Let's test it! Try pressing the arrow keys..."
+
+      **STEP 4: Celebrate the Achievement**
+
+      Encourage the child: "You just built [FEATURE]! That's a real game programming skill! 🌟"
+
+      **STEP 5: Check Understanding**
+
+      Ask: "Do you understand how this works? Want me to explain any part again?"
+
+      Wait for response and answer questions patiently.
+
+      **STEP 6: Plan Next Steps**
+
+      Ask: "Ready to build the next feature? Or do you need a break?"
+
+      **Conditional Next Actions:**
+      - If ready to continue: Transition to 'code' with 'continue_coding' trigger
+      - If game is complete: Transition to 'celebrate' with 'game_complete' trigger
+
+    transitions:
+      - trigger: 'continue_coding'
+        to: 'code'
+        additional_instructions: |
+          Great! Let's build the next feature! 🚀
+        transition_reason: 'Child understands current feature, ready to continue'
+        review_perspectives:
+          - perspective: 'quiz-master'
+            prompt: |
+              You are a friendly quiz master helping a child explore and understand their code!
+
+              Ask 2-3 exploratory questions that make them FIND things in the code:
+
+              **Good Questions (make them explore):**
+              - "Can you find the line where we check if the spacebar was pressed? What does it say?"
+              - "Look for the variable that holds the player's score. What's it called?"
+              - "Find the Enemy class - what happens when an enemy reaches the bottom of the screen?"
+              - "Can you spot where we draw the player on the screen? Show me that function!"
+
+              **Bad Questions (too abstract):**
+              - ❌ "What is a variable?"
+              - ❌ "Explain object-oriented programming"
+              - ❌ "What does this function return?"
+
+              **Important:**
+              - Make it a treasure hunt, not a test!
+              - If they can't find it, give hints: "Look in the Player class..."
+              - Celebrate when they find it: "Yes! That's it! 🎉"
+              - The goal is active code exploration, not memorization
+              - Keep it fun and encouraging!
+
+      - trigger: 'game_complete'
+        to: 'celebrate'
+        additional_instructions: |
+          All features are done! Time for the final celebration! 🎊
+        transition_reason: 'All features complete and understood'
+
+  celebrate:
+    description: 'Celebrate the completed game and reflect on learning'
+    default_instructions: |
+      **STEP 1: Play the Complete Game**
+
+      Celebrate with the child: "Let's play your finished game together! You built this!"
+
+      Let them play and enjoy their creation.
+
+      **STEP 2: Celebrate the Achievement**
+
+      Be enthusiastic and genuinely celebrate their work:
+
+      "You just built a REAL game! You're a game developer now! 🌟
+
+      Think about everything you learned:
+      - How to plan a game
+      - How to organize code (classes, state, mechanics, presentation)
+      - How to make things move on screen
+      - How to detect collisions
+      - How to add scoring and game rules
+
+      That's AMAZING! Many adults don't know how to do this!"
+
+      **STEP 3: Reflect on Learning**
+
+      Ask the child:
+      - "What was the hardest part of building this game?"
+      - "What was the most fun part?"
+      - "What are you most proud of?"
+
+      **STEP 4: Explore Future Ideas**
+
+      Ask: "Now that you've built Version 1, what would you want to add next?"
+
+      Review the "Future Ideas" list from `$REQUIREMENTS_DOC`.
+
+      **STEP 5: Document the Achievement**
+
+      Update the plan file with:
+      - Game completion date
+      - What was learned
+      - What the child wants to build next
+      - Any notes for future sessions
+
+      **STEP 6: Encourage Next Steps**
+
+      "You can keep building on this game, or start a new one!
+      You now have the skills to make ANY simple game you can imagine!"
+
+      **Congratulations, young game developer! 🚀**
+
+    transitions:
+      - trigger: 'enhance_game'
+        to: 'imagine'
+        additional_instructions: |
+          copy the development plan to a new file. Also move the existing conversation in .vibe to .vibe/archive
+        transition_reason: 'Adding features to existing game'

package/packages/cli/resources/workflows/greenfield.yaml

@@ -0,0 +1,201 @@
+# yaml-language-server: $schema=../state-machine-schema.json
+---
+name: 'greenfield'
+description: 'A comprehensive workflow for starting new projects from scratch: Ideation, Architecture, Plan, Code, Document - ideal for greenfield projects requiring thorough upfront planning'
+initial_state: 'ideation'
+
+# Enhanced metadata for better discoverability
+metadata:
+  domain: 'code'
+  complexity: 'high'
+  bestFor:
+    - 'New projects from scratch'
+    - 'Greenfield development'
+    - 'Complex system design'
+    - 'Comprehensive planning needed'
+  useCases:
+    - 'Starting a new application'
+    - 'Building a new service'
+    - 'Creating a new library'
+  examples:
+    - 'Build a new web application'
+    - 'Create a microservice architecture'
+    - 'Develop a new CLI tool'
+  requiresDocumentation: true
+
+# States with default instructions and transitions
+states:
+  ideation:
+    description: 'Deep requirements discovery and PRD creation phase'
+    default_instructions: |
+      Understand WHAT the system should do, WHO will use it, WHY it's needed, and WHAT'S in/out of scope by exploring:
+      - Are there existing solutions? What gaps do they have?
+      - What technologies must/cannot be used? Why?
+      - How will you measure product success?
+      - Have you validated this need with potential users?
+
+      Don't discuss technical implementation yet - focus purely on understanding the problem space and requirements. Document all findings in `$REQUIREMENTS_DOC` and create tasks as needed.
+    transitions:
+      - trigger: 'ideation_complete'
+        to: 'architecture'
+        transition_reason: 'PRD is complete with clear requirements, ready for technical architecture design'
+        review_perspectives:
+          - perspective: 'business_analyst'
+            prompt: 'Review the Product Requirements Document for completeness, clarity, and business value. Ensure all stakeholder needs are captured, requirements are testable, and scope is well-defined.'
+          - perspective: 'ux_expert'
+            prompt: 'Evaluate user experience requirements and usability considerations. Ensure user personas, workflows, and interaction patterns are properly defined for the greenfield project.'
+
+  architecture:
+    description: 'Tech stack selection and architecture design phase'
+    default_instructions: |
+      Design the technical solution based on requirements from `$REQUIREMENTS_DOC`.
+
+      - Ask about the user's technical preferences and experience
+      - Challenge their choices by presenting alternatives
+      - Evaluate pros and cons of different tech stacks, frameworks, and architectural patterns
+      - Consider non-functional requirements like scalability, performance, maintainability, and deployment
+
+      Create a comprehensive architecture document in `$ARCHITECTURE_DOC`. Don't start coding yet - focus on technical design decisions.
+    transitions:
+      - trigger: 'need_more_ideation'
+        to: 'ideation'
+        additional_instructions: 'Architecture work revealed gaps in requirements understanding. Focus on the specific requirements areas that need clarification before continuing with technical design.'
+        transition_reason: 'Architecture work revealed need for more requirements clarification'
+
+      - trigger: 'architecture_complete'
+        to: 'plan'
+        additional_instructions: 'Present the implementation plan to the user and document it thoroughly.'
+        transition_reason: 'Technical architecture is complete, ready for implementation planning'
+        review_perspectives:
+          - perspective: 'architect'
+            prompt: 'Review the technical architecture for completeness, scalability, and maintainability. Ensure technology choices are appropriate and architectural patterns are sound for a greenfield project.'
+          - perspective: 'security_expert'
+            prompt: 'Evaluate security architecture, data protection strategies, and potential vulnerabilities. Ensure security is built into the foundation of the greenfield project from the start.'
+
+      - trigger: 'abandon_project'
+        to: 'ideation'
+        instructions: >
+          Project development abandoned during architecture phase. Return to ideation state for new projects.
+          Task history and PRD will remain for future reference.
+        additional_instructions: 'Project development abandoned during architecture phase. Clean up any architecture work and prepare for new projects.'
+        transition_reason: 'User decided to abandon project during architecture phase'
+
+  plan:
+    description: 'Implementation planning phase based on established architecture'
+    default_instructions: |
+      Create a detailed implementation strategy based on your completed architecture in `$ARCHITECTURE_DOC` and requirements from `$REQUIREMENTS_DOC`.
+
+      **STEP 1: Break Down Work**
+      - Break down the work into specific, actionable tasks
+      - Consider the chosen tech stack and architectural decisions
+      - Plan the implementation order and identify dependencies
+
+      **STEP 2: Assess Risks**
+      - Consider potential risks and mitigation strategies
+      - Document the detailed design in `$DESIGN_DOC`
+
+      **STEP 3: Create Tasks**
+      - Create tasks thoroughly with clear milestones for implementation work
+      - Ensure each task is actionable and has clear acceptance criteria
+    transitions:
+      - trigger: 'need_architecture_changes'
+        to: 'architecture'
+        additional_instructions: "Planning revealed issues with the current architecture. Consider what you've learned during planning and adjust the technical design accordingly. Document the changes and reasons."
+        transition_reason: 'Planning work revealed need to revise the architecture'
+
+      - trigger: 'plan_complete'
+        to: 'code'
+        additional_instructions: "Implementation plan is complete! ✅ Now transition to coding phase. Read specific documentation before using the chosen libraries and frameworks. Follow the architectural patterns and tech stack decisions you've made. Modularize your code according to best practices. Stay focused on the current project scope defined in your PRD. Update task progress as you complete planning work."
+        transition_reason: 'Implementation plan is complete and ready for coding'
+
+      - trigger: 'abandon_project'
+        to: 'ideation'
+        instructions: >
+          Project development abandoned during planning. Return to ideation state for new projects.
+          Task history, PRD, and architecture documentation will remain for future reference.
+        additional_instructions: 'Project development abandoned during planning. Clean up any planning work and prepare for new projects.'
+        transition_reason: 'User decided to abandon project during planning phase'
+
+  code:
+    description: 'Implementation phase following the established plan and architecture'
+    default_instructions: |
+      Build the solution following your plan and detailed design from `$DESIGN_DOC` using the architecture from `$ARCHITECTURE_DOC`.
+
+      - Ensure all requirements from `$REQUIREMENTS_DOC` you are currently working on are met
+      - Write clean, well-structured code with proper error handling
+      - Prevent regression by building, linting, and executing existing tests
+      - Stay flexible and adapt the plan as you learn more during implementation, but maintain alignment with your architecture decisions
+      - Update task progress and create new tasks as needed for current phase work
+    transitions:
+      - trigger: 'need_replanning'
+        to: 'plan'
+        additional_instructions: "Implementation revealed issues with the current plan. Consider what you've learned during coding and adjust the implementation strategy accordingly while maintaining architectural consistency. Document the changes and reasons."
+        transition_reason: 'Implementation work revealed need to revise the plan'
+
+      - trigger: 'need_architecture_changes'
+        to: 'architecture'
+        additional_instructions: 'Implementation revealed fundamental issues with the architecture that require design changes. Focus on the specific architectural problems that are blocking implementation progress.'
+        transition_reason: 'Implementation work revealed need for architectural changes'
+
+      - trigger: 'code_complete'
+        to: 'finalize'
+        transition_reason: 'Core implementation is complete, ready for comprehensive documentation'
+
+      - trigger: 'abandon_project'
+        to: 'ideation'
+        instructions: >
+          Project development abandoned during implementation. Clean up any incomplete code and return to ideation.
+          Task history, PRD, architecture documentation, and any completed work will remain for future reference.
+        additional_instructions: 'Project development abandoned during implementation. Clean up any incomplete code and prepare for new projects.'
+        transition_reason: 'User decided to abandon project during implementation'
+
+  finalize:
+    description: 'Code cleanup and documentation finalization'
+    default_instructions: |
+      This phase ensures code quality and documentation accuracy through systematic cleanup and review.
+
+      **STEP 1: Code Cleanup**
+      Systematically clean up development artifacts:
+
+      1. Remove all temporary debug output statements used during development (console logging, print statements, debug functions)
+      2. Address each TODO/FIXME comment by either implementing the solution or documenting why it's deferred
+         - Remove completed TODOs
+         - Convert remaining TODOs to proper issue tracking if needed
+      3. Remove debugging code blocks, temporary test code, and commented-out code
+         - Ensure proper error handling replaces temporary debug logging
+
+      **STEP 2: Documentation Review**
+      Update documentation to reflect final implementation:
+
+      1. Update long-term memory documents based on what was actually implemented:
+         - Update `$REQUIREMENTS_DOC` if requirements changed during development
+         - Update `$ARCHITECTURE_DOC` if architectural decisions evolved
+         - Update `$DESIGN_DOC` if design details were refined or changed
+      2. Review documentation against actual implemented functionality
+      3. Only modify documentation sections that have functional changes
+      4. Remove references to development iterations, progress notes, and temporary decisions
+      5. Ensure documentation describes the final implemented state, not the development process
+      6. Ask user to review document updates
+
+      **STEP 3: Comprehensive Documentation**
+      Ensure project has complete documentation for newcomers including setup, usage, architecture overview, and contribution guidelines.
+
+      **STEP 4: Final Validation**
+      - Run existing tests to ensure cleanup didn't break functionality
+      - Verify documentation accuracy with a final review
+      - Ensure project is ready for users and contributors
+      - Update task progress and mark completed work as you finalize the project
+    transitions:
+      - trigger: 'need_code_changes'
+        to: 'code'
+        additional_instructions: 'Finalization revealed issues that require code changes. Focus on the problems identified during final review that affect usability or functionality.'
+        transition_reason: 'Finalization revealed issues requiring code changes'
+
+      - trigger: 'finalization_complete'
+        to: 'ideation'
+        transition_reason: 'Project delivery complete with finalized code and documentation, ready for next greenfield project'
+
+      - trigger: 'abandon_project'
+        to: 'ideation'
+        additional_instructions: 'Project development abandoned during finalization. Clean up any finalization artifacts and prepare for new projects.'
+        transition_reason: 'User decided to abandon project during finalization phase'