📝 docs: add copilot instructions and update config wizard readme

- Create `copilot-instructions.md` for Hugo site documentation.
- Update `CONFIG_WIZARD_README.md` with detailed design constraints and user/technical features.
- Improve documentation with structured content and detailed examples.

🔧 chore: restructure and clean documentation files

- Move `CONFIG_WIZARD_README.md` to `_site-docs` folder.
- Delete `class-options.html` shortcode file from partials directory.
- Create empty `copilot-instructions.md` and `.vscode/copilot-instructions.md` files.

Author: MrHinsh

.vscode/copilot-instructions.md

@@ -1,5 +1,48 @@
 # Interactive Configuration Tool Implementation
 
+## Design Constraints
+
+### 🎯 **Migration Type Architecture**
+
+The wizard is built around three primary migration types with specific endpoint and processor constraints:
+
+#### **1. WorkItems Migration**
+
+- **Required Endpoint**: `TfsWorkItemEndpoint`
+- **Required Processor**: `TfsWorkItemMigrationProcessor`
+- **Behavior**: Endpoint and processor are locked/pre-selected. Only processor options are configurable.
+- **Use Case**: Standard work item migration between Azure DevOps organizations or TFS instances.
+
+#### **2. Pipelines Migration**
+
+- **Required Endpoint**: `AzureDevOpsEndpoint`
+- **Required Processor**: `AzureDevOpsPipelineProcessor`
+- **Behavior**: Endpoint and processor are locked/pre-selected. Only processor options are configurable.
+- **Use Case**: Migration of build and release pipelines between Azure DevOps organizations.
+
+#### **3. Custom Migration**
+
+- **Endpoints**: User can add multiple named endpoints of any valid type
+- **Processors**: User can select any number of processors with full configuration flexibility
+- **Behavior**: Complete freedom to configure complex migration scenarios
+- **Constraints**: Type validation ensures only compatible named endpoints are available for each processor type
+- **Use Case**: Advanced scenarios requiring multiple processors, custom field mapping, or specialized migration patterns.
+
+### 🔧 **Processor Configuration Behavior**
+
+#### **Constrained Modes (WorkItems & Pipelines)**
+
+- Processor selection is **locked** based on migration type
+- Only processor-specific **options** are editable (e.g., WIQL queries, field mappings, performance settings)
+- Simplified UI focuses on configuration rather than selection
+
+#### **Custom Mode**
+
+- **Full processor selection**: Choose from all available processors
+- **Multiple processor support**: Add/remove processors as needed
+- **Named endpoint association**: Each processor can reference named endpoints by name
+- **Type validation**: Only compatible endpoints appear in dropdown for each processor
+
 ## Overview
 
 This implementation provides a **comprehensive interactive configuration wizard** for the Azure DevOps Migration Tools. The wizard guides users through a step-by-step process to build their migration configuration without requiring deep knowledge of the underlying JSON structure.
@@ -17,22 +60,24 @@ This implementation provides a **comprehensive interactive configuration wizard*
 ### 🚀 **Key Features Implemented**
 
 #### **Multi-Step Wizard Flow**
-```
+
+```text
 Step 1: Migration Type Selection
-├── Work Items Only
-├── Work Items + Test Plans  
-├── Work Items + Pipelines
-└── Full Migration
+├── WorkItems (TfsWorkItemEndpoint + TfsWorkItemMigrationProcessor)
+├── Pipelines (AzureDevOpsEndpoint + AzureDevOpsPipelineProcessor)
+└── Custom (User-defined endpoints and processors)
 
-Step 2: Source & Target Endpoints
-├── Organization URLs
+Step 2: Endpoint Configuration
+├── Pre-configured endpoints (WorkItems/Pipelines modes)
+├── Named endpoint creation (Custom mode)
 ├── Authentication (PAT tokens)
-└── Project names
+└── Connection validation
 
-Step 3: Processor Selection
-├── Required processors (auto-selected)
-├── Optional processors (user choice)
-└── Processor-specific configuration
+Step 3: Processor Configuration
+├── Locked processor options (WorkItems/Pipelines modes)
+├── Processor selection and addition (Custom mode)
+├── Processor-specific configuration
+└── Named endpoint assignment per processor
 
 Step 4: Field Mapping Strategy
 ├── Automatic mapping
@@ -51,6 +96,7 @@ Step 6: Review & Export
 ```
 
 #### **User Experience Features**
+
 - **Visual Progress Indicator**: Shows completion percentage and current step
 - **Step Navigation**: Previous/Next buttons with validation
 - **Smart Selections**: Migration type determines available processors
@@ -60,6 +106,7 @@ Step 6: Review & Export
 - **Dark/Light Theme Support**: Integrates with existing theme system
 
 #### **Technical Features**
+
 - **Hugo Integration**: Leverages existing YAML data files
 - **Client-side Processing**: No server-side dependencies
 - **Security Conscious**: Credentials only used for config generation
@@ -69,6 +116,7 @@ Step 6: Review & Export
 ## Implementation Details
 
 ### **File Structure**
+
 ```
 docs/
 ├── content/docs/config-wizard.md          # Wizard page content
@@ -78,13 +126,16 @@ docs/
 ```
 
 ### **Data Integration**
+
 The wizard dynamically loads configuration data from the existing YAML files:
+
 - `reference.processors.*.yaml` - Processor configurations
-- `reference.endpoints.*.yaml` - Endpoint options  
+- `reference.endpoints.*.yaml` - Endpoint options
 - `reference.fieldmaps.*.yaml` - Field mapping options
 - `reference.tools.*.yaml` - Tool configurations
 
 ### **Technology Stack**
+
 - **Frontend**: Vanilla JavaScript (ES6+), HTML5, CSS3
 - **Styling**: Bootstrap 5.3.6, Custom CSS with CSS Variables
 - **Icons**: Font Awesome 6
@@ -94,31 +145,36 @@ The wizard dynamically loads configuration data from the existing YAML files:
 ## Usage Examples
 
 ### **For Beginners**
+
 1. Visit `/docs/config-wizard/`
-2. Select "Work Items Only" migration type
-3. Enter source and target organization URLs
-4. Accept default processor selections
+2. Select "WorkItems" migration type
+3. Configure TfsWorkItemEndpoint with source and target organization URLs
+4. Accept default TfsWorkItemMigrationProcessor settings
 5. Choose "Automatic Mapping" for field mapping
 6. Use default advanced settings
 7. Download generated `configuration.json`
 
-### **For Advanced Users**  
-1. Select "Full Migration" for comprehensive setup
-2. Configure multiple processors with custom settings
-3. Define manual field mapping strategies
-4. Tune performance and error handling parameters
-5. Generate complex configurations with custom WIQL queries
+### **For Advanced Users**
+
+1. Select "Custom" migration type for comprehensive setup
+2. Add multiple named endpoints (TfsWorkItemEndpoint, AzureDevOpsEndpoint, etc.)
+3. Configure multiple processors with custom settings
+4. Define manual field mapping strategies
+5. Tune performance and error handling parameters
+6. Generate complex configurations with custom WIQL queries and processor combinations
 
 ## Benefits
 
 ### **User Benefits**
+
 - **Reduced Learning Curve**: No need to understand complex JSON structure
 - **Faster Setup**: 5-10 minutes vs hours of manual configuration
 - **Error Prevention**: Validation prevents common configuration mistakes
 - **Educational**: Learn about available options through guided explanations
 - **Confidence Building**: Visual progress and validation provide reassurance
 
 ### **Project Benefits**
+
 - **Lower Support Burden**: Fewer configuration-related support requests
 - **Better Adoption**: Easier onboarding leads to higher tool adoption
 - **Documentation Synergy**: Leverages existing documentation infrastructure
@@ -127,13 +183,15 @@ The wizard dynamically loads configuration data from the existing YAML files:
 ## Future Enhancements
 
 ### **Phase 2 Features**
+
 - **Configuration Templates**: Save and reuse common configurations
 - **Validation Engine**: Real-time connection testing
 - **WIQL Query Builder**: Visual query construction interface
 - **Batch Operations**: Configure multiple migration jobs
 - **Import/Export**: Load existing configurations for modification
 
 ### **Advanced Features**
+
 - **Migration Scenarios**: Pre-built configurations for common patterns
 - **Performance Estimator**: Predict migration time based on data size
 - **Dependency Checker**: Validate prerequisites and permissions
@@ -146,41 +204,58 @@ The wizard dynamically loads configuration data from the existing YAML files:
 Based on this implementation, here's the recommended approach for similar tools:
 
 #### **1. Data Architecture**
+
 ```javascript
 // Leverage existing structured data
 const configData = {
   processors: loadFromYAML(),
-  endpoints: loadFromYAML(), 
+  endpoints: loadFromYAML(),
   fieldMaps: loadFromYAML(),
-  templates: loadFromYAML()
+  templates: loadFromYAML(),
 };
 ```
 
 #### **2. Progressive UI Design**
+
 ```javascript
 class ConfigWizard {
   constructor() {
     this.steps = [
-      { id: 'type', title: 'Choose Type', validator: this.validateType },
-      { id: 'endpoints', title: 'Configure Endpoints', validator: this.validateEndpoints },
+      { id: "type", title: "Choose Type", validator: this.validateType },
+      { id: "endpoints", title: "Configure Endpoints", validator: this.validateEndpoints },
       // ... more steps
     ];
   }
 }
 ```
 
 #### **3. Smart Defaults System**
+
 ```javascript
 getProcessorsForType(migrationType) {
   const mapping = {
-    'work-items-only': ['WorkItemMigration'],
-    'full-migration': ['WorkItemMigration', 'TestPlans', 'Pipelines']
+    'workitems': {
+      processors: ['TfsWorkItemMigrationProcessor'],
+      endpoints: ['TfsWorkItemEndpoint'],
+      locked: true
+    },
+    'pipelines': {
+      processors: ['AzureDevOpsPipelineProcessor'],
+      endpoints: ['AzureDevOpsEndpoint'],
+      locked: true
+    },
+    'custom': {
+      processors: [], // User selectable
+      endpoints: [], // User configurable
+      locked: false
+    }
   };
-  return mapping[migrationType] || [];
+  return mapping[migrationType] || { processors: [], endpoints: [], locked: false };
 }
 ```
 
 #### **4. Real-time Validation**
+
 ```javascript
 validateStep(stepData) {
   const validators = {
@@ -192,6 +267,7 @@ validateStep(stepData) {
 ```
 
 #### **5. Configuration Generation**
+
 ```javascript
 generateConfig() {
   return {
@@ -210,7 +286,7 @@ generateConfig() {
 The wizard integrates seamlessly with the existing documentation:
 
 - **Navigation**: Linked from main docs page and getting started guide
-- **Styling**: Uses existing Bootstrap theme and color schemes  
+- **Styling**: Uses existing Bootstrap theme and color schemes
 - **Data**: Leverages auto-generated YAML configuration data
 - **Comments**: Supports Giscus comments for user feedback
 - **Editing**: "Edit this page" links to GitHub for improvements

docs/CONFIG_WIZARD_README.md renamed to docs/_site-docs/CONFIG_WIZARD_README.md

@@ -0,0 +1,126 @@
+# Copilot Instructions for `docs` (Hugo Site for Azure DevOps Migration Tools)
+
+## Purpose
+
+This `docs` folder contains the Hugo static site for Azure DevOps Migration Tools documentation. The site is deployed to Azure Static Web Apps and relies on YAML/Markdown data generated by `src/MigrationTools.ConsoleDataGenerator`.
+
+## Features
+
+### Config wizard
+
+This site includes a configuration wizard that guides users through setting up their migration configurations interactively.
+The wizard is designed to simplify the process of creating complex migration configurations by providing step-by-step instructions and examples.
+Its documentation is in [config-wizard.md](_site-docs/CONFIG_WIZARD_README.md).
+
+- **Key Features**:
+  - Interactive step-by-step configuration setup
+  - Example configurations for common scenarios
+  - Validation of user inputs against the schema
+
+## Docs & Reference
+
+The `docs\content\docs` directory contains the main documentation sections, including:
+
+- **Getting Started**: Guides for new users to set up and use the migration tools.
+- **How-To Guides**: Step-by-step tutorials for common tasks.
+- **Reference Documentation**: Detailed information on configuration options, processors. Each page loads its data from YAML files in `docs/data/reference/`, and should be validated against the schema in `docs\static\schema`.
+- **Setup Guides**: Instructions for installing and configuring the tools.
+
+## Key Patterns & Requirements
+
+### 1. Hugo Site Structure
+
+- Use [Hugo](https://gohugo.io/) v0.146+ conventions for content, layouts, and data.
+- **IMPORTANT**: This site uses Hugo's [new template system](https://gohugo.io/templates/new-templatesystem-overview/) (v0.146+) - ensure all template code follows the new patterns and syntax.
+- Content lives in `content/`, layouts in `layouts/`, static assets in `static/`, and data in `data/`.
+- All documentation pages should use Markdown with YAML front matter.
+- Use shortcodes and partials for reusable content blocks.
+- Follow the new template system's improved performance and syntax when creating layouts.
+
+#### Folder Structure
+
+```
+docs/
+├── _site-docs            # Contains additional documentation about features in the site itself
+├── content/              # Documentation content (Markdown with YAML front matter)
+│   ├── docs/             # Main documentation sections
+│   │   ├── get-started/  # Getting started guides
+│   │   ├── how-to/       # How-to guides and tutorials
+│   │   ├── reference/    # Reference documentation
+│   │   ├── setup/        # Setup and installation guides
+│   │   ├── config-wizard.md # Configuration wizard page
+│   │   └── _index.md     # Documentation section index
+│   ├── download/         # Download pages and resources
+│   ├── support/          # Support and community pages
+│   ├── schema/           # JSON schema documentation
+│   ├── 404.md            # Custom 404 error page
+│   └── _index.md         # Site homepage
+├── layouts/              # Hugo templates (HTML with Go templating - v0.146+ new system)
+│   ├── docs/             # Section-specific layouts for docs
+│   ├── _partials/        # Reusable template components (v0.146+ naming)
+│   │   ├── components/   # UI component partials
+│   │   ├── docs/         # Documentation-specific partials
+│   │   ├── functions/    # Template functions and utilities, they return HTML or data
+│   │   ├── JSON-LD/      # Structured data partials
+│   ├── _shortcodes/      # Custom Hugo shortcodes (v0.146+ naming)
+│   ├── _markup/          # Custom markup renderers
+│   ├── baseof.html       # Base template for all pages
+│   ├── index.html        # Homepage template
+│   ├── single.html       # Single page template
+│   ├── list.html         # List page template
+│   └── *.html            # Other page-specific templates
+├── static/               # Static assets (images, CSS, JS, PDFs)
+│   ├── images/           # Documentation images and diagrams
+│   ├── css/              # Custom stylesheets
+│   └── js/               # JavaScript files
+├── data/                 # Generated YAML/JSON data files
+│   ├── reference/        # Auto-generated reference docs
+│   └── samples/          # Configuration samples
+├── hugo.yaml             # Main Hugo configuration
+├── hugo.local.yaml       # Local development config
+├── hugo.preview.yaml     # Preview environment config
+├── hugo.production.yaml  # Production environment config
+├── hugo.canary.yaml      # Canary deployment config
+└── .hugo_build.lock      # Hugo build lock file
+```
+
+### 2. Data-Driven Documentation
+
+- Reference YAML data files in `/docs/_data/` generated by `MigrationTools.ConsoleDataGenerator` for configuration samples, processor options, and reference docs.
+- Do not manually edit files in `/docs/_data/`; always regenerate using the ConsoleDataGenerator after code changes.
+- Use Hugo's `data` templates to render configuration samples and reference tables from YAML.
+
+### 3. Documentation Generation Workflow
+
+- When processor/option classes change, run the ConsoleDataGenerator to update YAML and Markdown docs.
+- Validate that generated docs match the current codebase (see root copilot-instructions for checklist).
+- Use the `GenerateDocs.ps1` script at the repo root for consistent doc generation.
+
+### 4. Azure Static Web Apps Deployment
+
+- The Hugo site is deployed to Azure Static Web Apps.
+- Ensure all output is static and compatible with Azure SWA (no server-side code).
+- Use the `staticwebapp.config.json` for SWA routing and configuration.
+- Follow [Azure SWA best practices](https://learn.microsoft.com/azure/static-web-apps/) for performance and security.
+
+### 5. Content & Style Guidelines
+
+- Use clear, concise language and consistent formatting.
+- Prefer code samples and configuration snippets sourced from generated YAML.
+- Test all configuration samples against the schema documentation to ensure accuracy.
+- Keep navigation and sidebar structure in sync with generated reference docs.
+
+### 6. Maintenance
+
+- Regenerate docs after any code or configuration option changes.
+- Review generated Markdown and YAML for accuracy and completeness.
+- Keep this instruction file up to date with any changes to the documentation workflow or deployment process.
+
+---
+
+## References
+
+- [Hugo Documentation](https://gohugo.io/documentation/)
+- [Azure Static Web Apps Docs](https://learn.microsoft.com/azure/static-web-apps/)
+- [MigrationTools.ConsoleDataGenerator](../../src/MigrationTools.ConsoleDataGenerator/)
+- [GenerateDocs.ps1](../../GenerateDocs.ps1)