docs: replace 'provider context' with 'provider profile' terminology

- Replace all instances of 'provider_context' with 'provider_profile' across redesign documentation
- Update directory structure references (provider_contexts/ → provider_profiles/)
- Update YAML configuration examples and field names
- Update section headers and terminology descriptions
- Improve clarity and professionalism of cloud provider configuration concept
- Affects: core concepts, environment naming, configuration management, deployment workflow, and project goals

Resolves terminology inconsistency identified in Issue #31 redesign documentation.

Author: josecelano

docs/redesign/phase0-goals/project-goals-and-scope.md

@@ -111,7 +111,7 @@ visible and potentially accessible to each other within the provider account sco
 
 - **Hetzner Cloud**: Use separate projects with project-specific API tokens for true isolation
 - **AWS**: Use separate accounts or strict IAM policies per environment
-- **Application Perspective**: The installer treats each provider context (token/credentials)
+- **Application Perspective**: The installer treats each provider profile (token/credentials)
   as a completely isolated infrastructure boundary, regardless of actual provider-level separation
 
 **Alternative**: Manual provider account management and project separation by users who

docs/redesign/phase1-requirements/core-concepts-and-terminology.md

@@ -3,7 +3,8 @@
 ## Overview
 
 This document defines the fundamental concepts used throughout the Torrust Tracker
-installer project. These definitions establish clear terminology for technical
+installer project. These definitions es1. **Create Environment**: Define new environment with goal and provider profile 2. **Configure Application**: Set tracker-specific settings for environment  
+3. **Deploy Infrastructure**: Provision resources using provider profilelish clear terminology for technical
 contributors and eliminate ambiguity in design discussions.
 
 ## Core Concepts
@@ -86,31 +87,29 @@ for deploying infrastructure.
 implementation details, allowing environments to be portable across different
 providers with minimal configuration changes.
 
-### Provider Context
+### Provider Profile
 
-**Definition**: The complete set of provider-specific configuration, credentials,
-and resource specifications needed to deploy to a specific provider account.
+A Provider Profile represents a complete set of provider-specific configuration,
+authentication credentials, and resource specifications for deploying
+infrastructure to a particular cloud provider or virtualization platform.
 
-**Purpose**: Contains all provider-specific details required for actual
-deployment while keeping environment definitions provider-agnostic.
+**Key Components:**
 
-**Components**:
+- **Authentication**: API tokens, service account keys, access credentials
+- **Configuration**: Provider-specific settings (regions, instance types, networking)
+- **Resource Specifications**: Default values for compute, storage, networking resources
+- **Account Boundaries**: Billing and access control scope
 
-- **Authentication**: API tokens, credentials, access keys
-- **Resource Specifications**: VM sizes, storage types, network configurations
-- **Regional Settings**: Data center locations, availability zones
-- **Account-Specific**: Quotas, limits, billing preferences
+**Examples:**
 
-**Examples**:
-
-- `hetzner-personal` - Personal Hetzner account with CPX31 servers in Nuremberg
-- `hetzner-company` - Company Hetzner account with dedicated servers in Helsinki
-- `libvirt-workstation` - Local development machine with 8GB RAM allocation
+- `hetzner-staging`: Hetzner Cloud staging account with specific API tokens
+- `hetzner-production`: Hetzner Cloud production account with different credentials
+- `aws-development`: AWS development account with development-specific settings
+- `libvirt-local`: Local KVM/libvirt configuration for development testing
 
-**Isolation Scope**: Provider contexts represent individual cloud accounts or
-infrastructure boundaries. Multiple environments can share a provider context,
-but isolation between environments within the same account is limited to
-resource naming and network separation.
+**Isolation Scope**: Provider profiles represent individual cloud accounts or
+infrastructure boundaries. Multiple environments can share a provider profile,
+but each profile maintains its own authentication and resource scope.
 
 ### Deployment Locality
 
@@ -153,7 +152,7 @@ providers of both types.
 ```text
 Environment
 ├── Environment Goal (development|testing|staging|production)
-├── Provider Context
+├── Provider Profile
 │   ├── Provider (libvirt|hetzner|aws)
 │   ├── Authentication (API tokens, credentials)
 │   ├── Resource Specs (VM size, storage, network)
@@ -168,9 +167,9 @@ Environment
 
 ### Development Workflow
 
-1. **Create Environment**: Define new environment with goal and provider context
+1. **Create Environment**: Define new environment with goal and provider profile
 2. **Configure Application**: Set tracker-specific settings for the environment
-3. **Deploy Infrastructure**: Provision resources using provider context
+3. **Deploy Infrastructure**: Provision resources using provider profile
 4. **Deploy Application**: Install and configure tracker software
 5. **Validate Deployment**: Test functionality and performance
 6. **Iterate**: Update configuration and redeploy as needed
@@ -192,7 +191,7 @@ Environment
 
 1. Environment-specific configuration
 2. Environment goal defaults
-3. Provider context defaults
+3. Provider profile defaults
 4. Global system defaults
 
 This hierarchy allows environments to inherit sensible defaults while
@@ -210,7 +209,7 @@ is implementation-dependent and not specified at this conceptual level.
 environment registries or namespacing to prevent conflicts and improve
 management.
 
-### Provider Context Isolation
+### Provider Profile Isolation
 
 **Current Limitation**: No built-in mechanism for isolating multiple
 environments within a single provider account beyond resource naming
@@ -222,16 +221,16 @@ considered for future versions.
 
 ### Security Considerations
 
-**Credential Management**: Provider contexts contain sensitive authentication
+**Credential Management**: Provider profiles contain sensitive authentication
 information that must be handled securely:
 
 - Never commit credentials to version control
 - Use environment variables or secure credential stores
 - Implement proper access controls and audit logging
 - Support credential rotation and expiration
 
-**Environment Isolation**: While environments can share provider contexts,
-security-sensitive deployments should use dedicated provider contexts
+**Environment Isolation**: While environments can share provider profiles,
+security-sensitive deployments should use dedicated provider profiles
 to minimize blast radius and improve access control.
 
 ## Related Documentation

docs/redesign/phase1-requirements/deployment-stages-and-workflow.md

@@ -107,7 +107,7 @@ These stages execute for each individual environment with environment-specific c
    - Storage allocation and backup setup
    - DNS record creation (if applicable)
 
-**Environment Variables**: Provider context, resource specifications, regional settings
+**Environment Variables**: Provider profile, resource specifications, regional settings
 
 **Output**: Running virtual machine with base system ready for application deployment
 
@@ -285,7 +285,7 @@ version     infrastructure deployment validation
 
 **Infrastructure Efficiency**:
 
-- Shared provider contexts for cost optimization
+- Shared provider profiles for cost optimization
 - Resource scheduling for non-production environments
 - Automatic cleanup of temporary/expired environments
 

docs/redesign/phase3-design/configuration-management-implementation.md

@@ -3,7 +3,7 @@
 ## Overview
 
 This document describes an advanced configuration management system implementation
-that can handle multi-environment, multi-provider_context deployments with proper defaults, validation,
+that can handle multi-environment, multi-provider_profile deployments with proper defaults, validation,
 and secret management.
 
 ## Advanced Configuration Management System
@@ -28,11 +28,11 @@ config/
 │   ├── development.yaml    # Development-specific defaults
 │   ├── staging.yaml        # Staging-specific defaults
 │   └── production.yaml     # Production-specific defaults
-├── provider_contexts/      # Provider context definitions
-│   ├── libvirt.yaml        # Local development provider context
-│   ├── hetzner-staging.yaml # Hetzner Cloud staging provider context
-│   ├── hetzner-production.yaml # Hetzner Cloud production provider context
-│   └── aws.yaml            # AWS provider context
+├── provider_profiles/      # Provider profile definitions
+│   ├── libvirt.yaml        # Local development provider profile
+│   ├── hetzner-staging.yaml # Hetzner Cloud staging provider profile
+│   ├── hetzner-production.yaml # Hetzner Cloud production provider profile
+│   └── aws.yaml            # AWS provider profile
 └── environments/           # User environment configurations
     ├── dev-alice.yaml      # Alice's personal dev environment
     ├── staging-main.yaml   # Main staging environment
@@ -46,7 +46,7 @@ config/
 ```yaml
 # Environment identification
 environment_type: staging
-provider_context: hetzner
+provider_profile: hetzner
 
 # General configuration
 general:
@@ -71,14 +71,14 @@ secrets:
   grafana_admin_password: ${GF_SECURITY_ADMIN_PASSWORD}
 ```
 
-**Provider Context** (`provider_contexts/hetzner-staging.yaml`):
+**Provider Profile** (`provider_profiles/hetzner-staging.yaml`):
 
 ```yaml
 # Provider identification
 provider_name: hetzner
 provider_type: cloud
 
-# Concrete provisioning values for this provider context
+# Concrete provisioning values for this provider profile
 provisioning:
   server_type: cx31 # Hetzner-specific server type
   location: fsn1 # Hetzner datacenter location
@@ -99,14 +99,14 @@ api:
   dns_token_env_var: HDNS_TOKEN
 ```
 
-**Provider Context** (`provider_contexts/libvirt.yaml`):
+**Provider Profile** (`provider_profiles/libvirt.yaml`):
 
 ```yaml
 # Provider identification
 provider_name: libvirt
 provider_type: local
 
-# Concrete provisioning values for this provider context
+# Concrete provisioning values for this provider profile
 provisioning:
   memory: 2048 # Memory in MB
   vcpus: 2 # Number of virtual CPUs
@@ -146,7 +146,7 @@ applies variable substitution with conditional logic.
 #### 4. File Merging with Priority System
 
 A configuration merging system that combines multiple configuration layers (base,
-defaults, environment, provider_context) according to priority rules and inheritance
+defaults, environment, provider profiles) according to priority rules and inheritance
 patterns.
 
 ### Pros and Cons Analysis
@@ -158,7 +158,7 @@ patterns.
    - Supports complex nested configurations
    - Rich template system with conditional logic
    - Proper inheritance and composition patterns
-   - Provider context abstraction enables multi-cloud
+   - Provider profile abstraction enables multi-cloud
 
 2. **Robust Validation**
 
@@ -170,13 +170,13 @@ patterns.
 3. **Professional Configuration Management**
 
    - Follows enterprise configuration management patterns
-   - Separates concerns clearly (environment vs provider_context vs defaults)
+   - Separates concerns clearly (environment vs provider_profile vs defaults)
    - Enables configuration reuse and DRY principles
    - Supports complex deployment scenarios
 
 4. **Extensible Architecture**
 
-   - Easy to add new provider contexts
+   - Easy to add new provider profiles
    - Template system supports custom logic
    - Schema-driven validation allows evolution
    - Plugin architecture for custom processors
@@ -228,7 +228,7 @@ patterns.
 #### 1. File Merging with Priorities
 
 **Challenge**: Need to merge multiple YAML files with complex inheritance rules.
-**Reality**: No standard library exists that can handle conditional merging with provider context resolution.
+**Reality**: No standard library exists that can handle conditional merging with provider profile resolution.
 
 #### 2. Secret Injection from Environment Variables
 
@@ -238,17 +238,17 @@ patterns.
 #### 3. Multi-layer Validation
 
 **Challenge**: Validate configurations across multiple file layers with
-provider_context-specific rules.
+provider_profile-specific rules.
 
 #### 3. Multi-layer Validation
 
 **Challenge**: Validate configurations that have common parts and conditional/extensible parts.
 **Reality**: JSON Schema with conditional validation becomes unwieldy and hard to maintain.
 
-#### 4. Provider Context Resolution
+#### 4. Provider Profile Resolution
 
-**Challenge**: Map abstract configuration to provider_context-specific implementations.
-**Reality**: Building abstraction layers that work across different cloud provider contexts
+**Challenge**: Map abstract configuration to provider_profile-specific implementations.
+**Reality**: Building abstraction layers that work across different cloud provider profiles
 is a massive undertaking.
 
 ### Conclusion
@@ -266,28 +266,28 @@ require significant development resources to implement properly.
 
 ### Phase 1: Core Configuration System
 
-1. **Schema Definition**: Create base environment and provider context schemas
+1. **Schema Definition**: Create base environment and provider profile schemas
 2. **Configuration Parser**: Implement YAML loading and validation
-3. **Provider Context Resolution**: Build reference resolution system
+3. **Provider Profile Resolution**: Build reference resolution system
 4. **Basic Templates**: Implement simple template resolution
 
-### Phase 2: Provider_context Integration
+### Phase 2: Provider Profile Integration
 
-1. **Hetzner Provider Context**: Implement Hetzner-specific mappings and capabilities
-2. **Libvirt Provider Context**: Implement local development provider context
+1. **Hetzner Provider Profile**: Implement Hetzner-specific mappings and capabilities
+2. **Libvirt Provider Profile**: Implement local development provider profile
 3. **Validation Integration**: Add composite schema validation
 4. **Error Handling**: Comprehensive error reporting and validation messages
 
 ### Phase 3: Advanced Features
 
 1. **Template Engine**: Full template resolution with conditional logic
-2. **Multiple Provider Contexts**: Support for multiple accounts per provider
+2. **Multiple Provider Profiles**: Support for multiple accounts per provider
 3. **Configuration Inheritance**: Implement goal-based defaults and inheritance
 4. **CLI Integration**: Command-line tools for configuration management
 
 ### Phase 4: Production Features
 
-1. **Credential Management**: Secure handling of provider context authentication
+1. **Credential Management**: Secure handling of provider profile authentication
 2. **Configuration Validation**: Pre-deployment validation and dry-run capabilities
-3. **Migration Tools**: Tools for migrating between provider contexts
+3. **Migration Tools**: Tools for migrating between provider profiles
 4. **Documentation**: Complete configuration reference and examples

docs/redesign/phase3-design/environment-naming-and-configuration.md

@@ -8,7 +8,7 @@ This naming convention aligns with the core concepts defined in Phase 1:
 
 - **Goal**: The Environment Goal (development, testing, staging, production)
 - **Provider**: The Provider type (libvirt, hetzner, aws)
-- **Identifier**: Unique identifier for the specific context or use case
+- **Identifier**: Unique identifier for the specific provider profile or use case
 
 **Examples**:
 
@@ -17,12 +17,12 @@ This naming convention aligns with the core concepts defined in Phase 1:
 - `prod-aws-primary` - Primary production environment on AWS
 - `e2e-libvirt-ci` - CI/CD end-to-end testing environment
 
-### Provider Context Naming
+### Provider Profile Naming
 
-Since multiple Provider Contexts can exist for each Provider type, provider
-contexts use a separate naming pattern:
+Since multiple Provider Profiles can exist for each Provider type, provider
+profiles use a separate naming pattern:
 
-**Pattern**: `{provider}-{context-identifier}`
+**Pattern**: `{provider}-{profile-identifier}`
 
 **Examples**:
 
@@ -32,22 +32,22 @@ contexts use a separate naming pattern:
 - `aws-production` - Production AWS account
 - `aws-development` - Development AWS account
 
-### Relationship Between Environment and Provider Context
+### Relationship Between Environment and Provider Profile
 
-An Environment references a Provider Context by name:
+An Environment references a Provider Profile by name:
 
 ```yaml
 # environments/staging-hetzner-main.yaml
 environment:
   name: "staging-hetzner-main"
   goal: "staging"
-  provider_context: "hetzner-company" # References providers/hetzner-company.yaml
+  provider_profile: "hetzner-company" # References providers/hetzner-company.yaml
 ```
 
 This allows:
 
-- **Multiple Environments per Provider Context**: Several environments can use the same provider account
-- **Provider Context Reuse**: Same provider context used across different environment goals
+- **Multiple Environments per Provider Profile**: Several environments can use the same provider account
+- **Provider Profile Reuse**: Same provider profile used across different environment goals
 - **Flexible Deployment**: Easy switching between personal and company accounts
 
 ## Configuration Inheritance
@@ -56,7 +56,7 @@ This allows:
 
 1. Environment-specific configuration
 2. Environment goal defaults
-3. Provider context defaults
+3. Provider profile defaults
 4. Global system defaults
 
 This hierarchy allows environments to inherit sensible defaults while
@@ -80,7 +80,7 @@ backup:
   retention_days: 7
 ```
 
-#### Provider Context Defaults
+#### Provider Profile Defaults
 
 ```yaml
 # providers/hetzner-company.yaml
@@ -98,7 +98,7 @@ defaults:
 #### Configuration Resolution Process
 
 1. **Load Global Defaults**: System-wide default configuration
-2. **Apply Provider Context Defaults**: Merge provider-specific defaults
+2. **Apply Provider Profile Defaults**: Merge provider-specific defaults
 3. **Apply Goal Defaults**: Merge environment goal-specific defaults
 4. **Apply Environment Config**: Merge environment-specific configuration
 5. **Validate Final Config**: Ensure all required values are present