diff --git a/.kiro/specs/applescript-calendar-sync/design.md b/.kiro/specs/applescript-calendar-sync/design.md
deleted file mode 100644
index c302a2f..0000000
--- a/.kiro/specs/applescript-calendar-sync/design.md
+++ /dev/null
@@ -1,209 +0,0 @@
-# Design Document
-
-## Overview
-
-The AppleScript Calendar Sync system is designed as a standalone AppleScript application that synchronizes calendar events between two calendar accounts for the current day only. The system uses macOS Calendar app's AppleScript interface to read events from a source calendar and mirror them to a destination calendar, including removal of events that no longer exist in the source.
-
-## Architecture
-
-The system follows a simple pipeline architecture:
-
-```
-[Source Calendar] → [Event Reader] → [Event Processor] → [Destination Calendar]
-                                          ↓
-                                   [Duplicate Detector]
-                                          ↓
-                                   [Cleanup Manager]
-```
-
-### Core Components
-
-1. **Calendar Manager**: Handles calendar account and calendar selection/validation
-2. **Event Reader**: Retrieves events from source calendar for current day
-3. **Event Processor**: Processes and transforms events for destination calendar
-4. **Sync Engine**: Coordinates the synchronization process including cleanup
-5. **Logger**: Provides user feedback and error reporting
-
-## Components and Interfaces
-
-### Calendar Manager
-```applescript
--- Validates and retrieves calendar references
-on getCalendar(accountName, calendarName)
-on validateCalendarAccess(calendar)
-on listAvailableCalendars()
-```
-
-**Responsibilities:**
-- Validate calendar account and calendar names exist
-- Return calendar object references for AppleScript operations
-- Handle calendar access permissions and errors
-
-### Event Reader
-```applescript
--- Reads events from source calendar for current day
-on getEventsForToday(sourceCalendar)
-on parseEventProperties(event)
-```
-
-**Responsibilities:**
-- Query source calendar for events occurring on current date
-- Extract event properties (title, start time, end time, description, etc.)
-- Handle different event types (all-day, timed, recurring)
-
-### Event Processor
-```applescript
--- Processes events for destination calendar
-on createEventInDestination(eventData, destinationCalendar)
-on updateExistingEvent(existingEvent, newEventData)
-on compareEvents(event1, event2)
-```
-
-**Responsibilities:**
-- Create new events in destination calendar
-- Update modified events
-- Compare events for duplicate detection
-
-### Sync Engine
-```applescript
--- Main synchronization coordinator
-on performSync(sourceCalendar, destinationCalendar)
-on cleanupRemovedEvents(sourceEvents, destinationEvents, destinationCalendar)
-on generateSyncReport(results)
-```
-
-**Responsibilities:**
-- Coordinate the entire sync process
-- Manage event cleanup (removal of events not in source)
-- Generate sync reports and statistics
-
-### Logger
-```applescript
--- Logging and user feedback
-on logMessage(message, level)
-on displayProgress(current, total)
-on showSyncSummary(summary)
-```
-
-**Responsibilities:**
-- Display progress information to user
-- Log errors and warnings
-- Show final sync summary
-
-## Data Models
-
-### Event Data Structure
-```applescript
-record EventData
-    title: string
-    startDate: date
-    endDate: date
-    isAllDay: boolean
-    description: string
-    location: string
-    uid: string (for duplicate detection)
-end record
-```
-
-### Sync Result Structure
-```applescript
-record SyncResult
-    eventsCreated: integer
-    eventsUpdated: integer
-    eventsRemoved: integer
-    eventsSkipped: integer
-    errors: list of strings
-end record
-```
-
-## Error Handling
-
-### Error Categories
-1. **Calendar Access Errors**: Invalid calendar names, permission issues
-2. **Event Processing Errors**: Malformed events, property access failures
-3. **Sync Operation Errors**: Network issues, calendar service unavailable
-
-### Error Handling Strategy
-- Graceful degradation: Continue processing other events when individual events fail
-- Detailed error logging with specific error messages
-- User-friendly error reporting with suggested solutions
-- Rollback capability for critical failures
-
-### Error Recovery
-```applescript
-on handleCalendarError(errorMessage)
-    -- Log error details
-    -- Provide user-friendly error message
-    -- Suggest corrective actions
-end handleCalendarError
-```
-
-## Testing Strategy
-
-### Unit Testing Approach
-Since AppleScript has limited testing frameworks, testing will focus on:
-
-1. **Manual Testing Scenarios**:
-   - Test with empty source calendar
-   - Test with events spanning multiple days
-   - Test with all-day events
-   - Test with recurring events
-   - Test calendar access errors
-
-2. **Integration Testing**:
-   - Test full sync workflow with real calendar data
-   - Test cleanup functionality (event removal)
-   - Test duplicate detection accuracy
-   - Test error handling with invalid inputs
-
-3. **Edge Case Testing**:
-   - Very long event titles and descriptions
-   - Events with special characters
-   - Overlapping events
-   - Events created/modified during sync
-
-### Test Data Requirements
-- Test calendars with known event sets
-- Events with various properties (all-day, timed, recurring)
-- Events with special characters and long descriptions
-- Calendar accounts with different permission levels
-
-## Implementation Considerations
-
-### AppleScript Calendar Integration
-- Use `Calendar` application's AppleScript dictionary
-- Handle calendar app launch and focus management
-- Manage calendar selection and event creation timing
-
-### Performance Optimization
-- Batch event operations where possible
-- Minimize calendar app UI interactions
-- Cache calendar references to avoid repeated lookups
-
-### User Experience
-- Provide clear progress indicators
-- Show meaningful error messages
-- Allow user to cancel long-running operations
-- Display comprehensive sync results
-
-### Security and Privacy
-- Request calendar access permissions appropriately
-- Handle sensitive calendar data securely
-- Provide clear information about what data is accessed
-
-## Configuration Management
-
-### User Configuration
-```applescript
--- Configuration properties
-property sourceAccountName : "Work Account"
-property sourceCalendarName : "Main Calendar"
-property destinationAccountName : "Personal Account"
-property destinationCalendarName : "Synced Events"
-property enableLogging : true
-```
-
-### Runtime Configuration
-- Allow users to modify calendar names without editing script
-- Provide configuration validation before sync starts
-- Save user preferences for repeated use
\ No newline at end of file
diff --git a/.kiro/specs/applescript-calendar-sync/requirements.md b/.kiro/specs/applescript-calendar-sync/requirements.md
deleted file mode 100644
index cdd3a65..0000000
--- a/.kiro/specs/applescript-calendar-sync/requirements.md
+++ /dev/null
@@ -1,73 +0,0 @@
-# Requirements Document
-
-## Introduction
-
-This feature enables automatic synchronization of calendar entries between two different calendar accounts using AppleScript. The system will copy events from a source calendar account to a destination calendar account, maintaining event details while avoiding duplicates and providing configurable sync options.
-
-## Requirements
-
-### Requirement 1
-
-**User Story:** As a user with multiple calendar accounts, I want to sync events from one account to another, so that I can maintain consistent scheduling across different calendar systems.
-
-#### Acceptance Criteria
-
-1. WHEN the sync script is executed THEN the system SHALL read all events from the specified source calendar
-2. WHEN events are found in the source calendar THEN the system SHALL copy them to the specified destination calendar
-3. WHEN copying events THEN the system SHALL preserve event title, date, time, duration, and description
-4. IF an event already exists in the destination calendar THEN the system SHALL skip creating a duplicate
-
-### Requirement 2
-
-**User Story:** As a user, I want to configure which calendars to sync between, so that I can control the data flow between my accounts.
-
-#### Acceptance Criteria
-
-1. WHEN configuring the sync THEN the system SHALL allow selection of source calendar account and specific calendar
-2. WHEN configuring the sync THEN the system SHALL allow selection of destination calendar account and specific calendar
-3. WHEN invalid calendar names are provided THEN the system SHALL display an error message and exit gracefully
-4. WHEN calendar accounts are not accessible THEN the system SHALL provide clear error messaging
-
-### Requirement 3
-
-**User Story:** As a user, I want the sync to focus on today's events only, so that I maintain current day synchronization without overwhelming the destination calendar.
-
-#### Acceptance Criteria
-
-1. WHEN the sync runs THEN the system SHALL only process events occurring on the current day
-2. WHEN determining current day THEN the system SHALL use the local system date
-3. WHEN events span multiple days THEN the system SHALL include events that start or occur on the current day
-4. WHEN no events exist for the current day THEN the system SHALL complete successfully with appropriate messaging
-
-### Requirement 4
-
-**User Story:** As a user, I want the destination calendar to mirror the source calendar for the current day, so that removed events are also cleaned up automatically.
-
-#### Acceptance Criteria
-
-1. WHEN checking for duplicates THEN the system SHALL compare event title, start date, and start time
-2. WHEN a matching event is found in the destination THEN the system SHALL skip creating the duplicate
-3. WHEN an event exists in the destination but not in the source for the current day THEN the system SHALL remove it from the destination
-4. WHEN an event has been modified in the source THEN the system SHALL update the corresponding event in the destination
-
-### Requirement 5
-
-**User Story:** As a user, I want to see progress and results of the sync operation, so that I can verify the synchronization was successful.
-
-#### Acceptance Criteria
-
-1. WHEN the sync starts THEN the system SHALL display the source and destination calendar information
-2. WHEN processing events THEN the system SHALL show progress indicators for each event processed
-3. WHEN the sync completes THEN the system SHALL display a summary of events copied, skipped, and any errors
-4. WHEN errors occur THEN the system SHALL log detailed error information for troubleshooting
-
-### Requirement 6
-
-**User Story:** As a user, I want the sync to handle different event types and properties, so that all my calendar data is accurately transferred.
-
-#### Acceptance Criteria
-
-1. WHEN syncing events THEN the system SHALL handle all-day events correctly
-2. WHEN syncing events THEN the system SHALL preserve recurring event patterns when possible
-3. WHEN syncing events THEN the system SHALL handle events with attendees and meeting details
-4. WHEN event properties cannot be transferred THEN the system SHALL log which properties were skipped
\ No newline at end of file
diff --git a/.kiro/specs/applescript-calendar-sync/tasks.md b/.kiro/specs/applescript-calendar-sync/tasks.md
deleted file mode 100644
index 8fc43ef..0000000
--- a/.kiro/specs/applescript-calendar-sync/tasks.md
+++ /dev/null
@@ -1,125 +0,0 @@
-# Implementation Plan
-
-- [x] 1. Set up project structure and configuration
-  - Create main AppleScript file with basic structure and configuration properties
-  - Define configuration properties for source and destination calendars
-  - Set up logging and error handling framework
-  - _Requirements: 2.1, 2.2, 5.1_
-
-- [ ] 2. Implement Calendar Manager component
-  - [ ] 2.1 Create calendar validation and access functions
-    - Write functions to validate calendar account and calendar names exist
-    - Implement calendar object retrieval with error handling
-    - Create function to list available calendars for debugging
-    - _Requirements: 2.1, 2.2, 2.3, 2.4_
-
-  - [ ]* 2.2 Write unit tests for calendar access
-    - Create test scenarios for invalid calendar names
-    - Test calendar access permission handling
-    - _Requirements: 2.3, 2.4_
-
-- [ ] 3. Implement Event Reader component
-  - [ ] 3.1 Create current day event retrieval function
-    - Write function to get today's date and create date range
-    - Implement event query for current day from source calendar
-    - Handle different event types (all-day, timed events)
-    - _Requirements: 1.1, 3.1, 3.2, 3.3_
-
-  - [ ] 3.2 Implement event property extraction
-    - Create function to extract event title, dates, description, location
-    - Handle event property access errors gracefully
-    - Parse recurring events for current day occurrences
-    - _Requirements: 1.3, 6.1, 6.2, 6.3_
-
-  - [ ]* 3.3 Write tests for event reading functionality
-    - Test event retrieval with various event types
-    - Test property extraction accuracy
-    - _Requirements: 1.1, 1.3_
-
-- [ ] 4. Implement Event Processor component
-  - [ ] 4.1 Create event comparison and duplicate detection
-    - Write function to compare events by title, start date, and start time
-    - Implement duplicate detection logic for existing events
-    - Handle event matching edge cases
-    - _Requirements: 4.1, 4.2_
-
-  - [ ] 4.2 Implement event creation and update functions
-    - Create function to add new events to destination calendar
-    - Implement event update functionality for modified events
-    - Handle event creation errors and property limitations
-    - _Requirements: 1.2, 1.3, 4.4, 6.4_
-
-  - [ ]* 4.3 Write tests for event processing
-    - Test duplicate detection accuracy
-    - Test event creation with various properties
-    - _Requirements: 4.1, 4.2, 4.4_
-
-- [ ] 5. Implement Sync Engine component
-  - [ ] 5.1 Create main synchronization workflow
-    - Implement the main sync function that coordinates all components
-    - Add progress tracking and user feedback during sync
-    - Handle sync workflow errors and recovery
-    - _Requirements: 1.1, 1.2, 5.2, 5.3_
-
-  - [ ] 5.2 Implement cleanup functionality for removed events
-    - Create function to identify events in destination not in source
-    - Implement event removal from destination calendar
-    - Add safety checks to prevent accidental deletions
-    - _Requirements: 4.3_
-
-  - [ ] 5.3 Create sync reporting and statistics
-    - Implement sync result tracking (created, updated, removed, skipped)
-    - Create summary display function with detailed results
-    - Add error reporting and logging
-    - _Requirements: 5.3, 5.4_
-
-  - [ ]* 5.4 Write integration tests for sync engine
-    - Test complete sync workflow with test data
-    - Test cleanup functionality accuracy
-    - Test error handling and recovery
-    - _Requirements: 4.3, 5.3_
-
-- [ ] 6. Implement Logger component
-  - [ ] 6.1 Create logging and progress display functions
-    - Implement message logging with different severity levels
-    - Create progress indicator for sync operations
-    - Add user-friendly error message formatting
-    - _Requirements: 5.1, 5.2, 5.4_
-
-  - [ ] 6.2 Implement sync summary display
-    - Create formatted summary of sync results
-    - Display statistics for events processed
-    - Show any errors or warnings encountered
-    - _Requirements: 5.3, 5.4_
-
-- [ ] 7. Integrate all components and create main script
-  - [ ] 7.1 Wire together all components in main execution flow
-    - Create main script entry point that calls all components
-    - Implement proper error handling and user feedback flow
-    - Add configuration validation before sync starts
-    - _Requirements: 2.3, 2.4, 5.1_
-
-  - [ ] 7.2 Add user interaction and configuration management
-    - Implement user prompts for calendar selection if needed
-    - Add configuration validation and error messaging
-    - Create user-friendly script execution experience
-    - _Requirements: 2.1, 2.2, 2.3, 2.4_
-
-  - [ ]* 7.3 Create comprehensive end-to-end tests
-    - Test complete sync workflow with real calendar data
-    - Test all error scenarios and edge cases
-    - Validate sync accuracy and cleanup functionality
-    - _Requirements: 1.1, 1.2, 4.3, 5.3_
-
-- [ ] 8. Finalize and optimize the script
-  - [ ] 8.1 Add performance optimizations and error recovery
-    - Optimize calendar access and event processing performance
-    - Add robust error recovery and rollback capabilities
-    - Implement proper resource cleanup and calendar app management
-    - _Requirements: 5.4_
-
-  - [ ] 8.2 Create user documentation and usage instructions
-    - Write clear instructions for script configuration and usage
-    - Document calendar permission requirements
-    - Create troubleshooting guide for common issues
-    - _Requirements: 2.3, 2.4, 5.4_
\ No newline at end of file
diff --git a/.kiro/specs/fastpass-additional-control-plane/design.md b/.kiro/specs/fastpass-additional-control-plane/design.md
deleted file mode 100644
index 5aaa6b9..0000000
--- a/.kiro/specs/fastpass-additional-control-plane/design.md
+++ /dev/null
@@ -1,165 +0,0 @@
-# Design Document
-
-## Overview
-
-The `fastpass-additional-control-plane` Ansible role will enable the deployment of additional control plane nodes to an existing FastPass Kubernetes cluster. This role follows the established patterns from `fastpass-first-control-plane` but focuses on joining nodes to an already initialized cluster rather than initializing a new one. The role ensures high availability by creating redundant master nodes that can handle API requests, scheduling, and cluster management tasks.
-
-The key difference from the first control plane role is that this role will use `kubeadm join` with control plane flags instead of `kubeadm init`, and it will need to retrieve join tokens and certificate keys from the existing cluster.
-
-## Architecture
-
-### Role Structure
-The role will follow the standard Ansible role structure:
-```
-ansible/playbooks/roles/fastpass-additional-control-plane/
-├── defaults/
-│   └── main.yml
-├── tasks/
-│   └── main.yml
-├── handlers/
-│   └── main.yml (if needed)
-└── meta/
-    └── main.yml (if needed)
-```
-
-### Integration Points
-- **DNS Management**: Uses the existing `dns-manager` role for consistent DNS record creation
-- **Kubeconfig Management**: Uses the existing `kubeconfig-manager` role for local kubeconfig setup
-- **Firewall Configuration**: Reuses firewall service definitions from the first control plane role
-- **Cluster Integration**: Coordinates with the first control plane node to obtain join credentials
-
-### Dependencies
-- The first control plane node must be fully initialized and running
-- The `dns-manager` role must be available for DNS record creation
-- The `kubeconfig-manager` role must be available for kubeconfig setup
-- Required Kubernetes prerequisites must be installed on target nodes
-
-## Components and Interfaces
-
-### Main Task Flow
-1. **Pre-flight Checks**: Verify cluster readiness and node prerequisites
-2. **DNS Configuration**: Set up DNS records for the new control plane node
-3. **Firewall Configuration**: Open required ports for control plane services
-4. **Kubelet Configuration**: Create initial kubelet configuration
-5. **Join Token Retrieval**: Get join token and certificate key from first control plane
-6. **Cluster Join**: Execute kubeadm join with control plane flags
-7. **Service Management**: Ensure kubelet is enabled and running
-8. **Kubeconfig Setup**: Configure local kubeconfig access
-9. **Verification**: Validate successful cluster join
-
-### Key Variables
-- `cluster_name`: Name of the Kubernetes cluster
-- `ip_address`: IP address of the current control plane node
-- `first_control_plane_host`: Hostname/IP of the first control plane node
-- `kubernetes_services_control_plane`: List of firewall services to open
-- `join_token_ttl`: TTL for join tokens (default: 24h)
-- `certificate_key_ttl`: TTL for certificate keys (default: 2h)
-
-### External Role Interfaces
-- **dns-manager**: Provides DNS record creation with `host_name` variable
-- **kubeconfig-manager**: Handles kubeconfig merging with `cluster_name` variable
-- **First Control Plane**: Source for join tokens and certificate keys
-
-## Data Models
-
-### Join Credentials Structure
-```yaml
-join_credentials:
-  token: "abcdef.1234567890abcdef"
-  discovery_token_ca_cert_hash: "sha256:..."
-  certificate_key: "..."
-  api_server_endpoint: "cluster-name:6443"
-```
-
-### Firewall Services
-```yaml
-kubernetes_services_control_plane:
-  - kubernetes_API      # Port 6443
-  - etcd               # Ports 2379-2380
-  - kubelet            # Port 10250
-  - kube-scheduler     # Port 10259
-  - kube-controller-manager  # Port 10257
-```
-
-### Node Status Tracking
-```yaml
-node_status:
-  joined: false
-  kubelet_running: false
-  dns_configured: false
-  kubeconfig_ready: false
-```
-
-## Error Handling
-
-### Join Token Management
-- **Token Expiration**: Automatically generate new tokens if existing ones are expired
-- **Certificate Key Rotation**: Handle certificate key expiration gracefully
-- **Network Connectivity**: Retry join operations with exponential backoff
-- **API Server Availability**: Wait for API server readiness before attempting join
-
-### Idempotency Checks
-- **Already Joined Nodes**: Skip join process if node is already part of the cluster
-- **Existing Configuration**: Preserve existing kubelet configuration if valid
-- **DNS Records**: Update existing DNS records instead of creating duplicates
-- **Service Status**: Only restart services if configuration changes
-
-### Failure Recovery
-- **Partial Join Failures**: Clean up partial configurations and retry
-- **Network Issues**: Provide clear error messages for connectivity problems
-- **Permission Errors**: Validate sudo/root access before attempting operations
-- **Resource Constraints**: Check system resources before proceeding
-
-## Testing Strategy
-
-### Unit Testing Approach
-- **Task Validation**: Test individual tasks with mock data
-- **Variable Validation**: Ensure required variables are properly defined
-- **Conditional Logic**: Test all conditional branches in tasks
-- **Error Scenarios**: Validate error handling for common failure cases
-
-### Integration Testing
-- **Multi-Node Clusters**: Test with 3 and 5 control plane node configurations
-- **Network Scenarios**: Test across different network topologies
-- **OS Compatibility**: Validate on supported operating systems (Ubuntu/Debian)
-- **Version Compatibility**: Test with different Kubernetes versions
-
-### Validation Checks
-- **Cluster Health**: Verify all control plane nodes are healthy after join
-- **API Availability**: Confirm API server is accessible from all nodes
-- **Etcd Cluster**: Validate etcd cluster membership and health
-- **Scheduling**: Test pod scheduling across all control plane nodes
-- **Failover**: Verify cluster continues operating if one control plane fails
-
-### Test Scenarios
-1. **Fresh Join**: Join additional control plane to newly created cluster
-2. **Existing Cluster**: Add control plane to cluster with existing workloads
-3. **Network Partitions**: Test behavior during temporary network issues
-4. **Token Expiration**: Handle expired join tokens gracefully
-5. **Retry Operations**: Validate retry logic for transient failures
-
-## Implementation Considerations
-
-### Security
-- **Token Security**: Ensure join tokens are handled securely and not logged
-- **Certificate Management**: Properly manage and rotate certificate keys
-- **Network Security**: Validate firewall rules don't expose unnecessary ports
-- **Access Control**: Ensure proper RBAC is maintained after node joins
-
-### Performance
-- **Parallel Execution**: Support joining multiple control plane nodes simultaneously
-- **Resource Usage**: Monitor CPU and memory usage during join process
-- **Network Bandwidth**: Optimize data transfer during cluster join
-- **Startup Time**: Minimize time to achieve cluster readiness
-
-### Monitoring and Observability
-- **Join Progress**: Provide clear progress indicators during join process
-- **Health Checks**: Implement comprehensive health validation
-- **Logging**: Ensure adequate logging for troubleshooting
-- **Metrics**: Expose relevant metrics for monitoring cluster growth
-
-### Compatibility
-- **Kubernetes Versions**: Support current and previous Kubernetes versions
-- **Operating Systems**: Maintain compatibility with Ubuntu and Debian
-- **Container Runtimes**: Work with containerd runtime configuration
-- **Network Plugins**: Compatible with Flannel CNI configuration
\ No newline at end of file
diff --git a/.kiro/specs/fastpass-additional-control-plane/requirements.md b/.kiro/specs/fastpass-additional-control-plane/requirements.md
deleted file mode 100644
index 6dcfd9f..0000000
--- a/.kiro/specs/fastpass-additional-control-plane/requirements.md
+++ /dev/null
@@ -1,77 +0,0 @@
-# Requirements Document
-
-## Introduction
-
-This feature involves creating an Ansible role called `fastpass-additional-control-plane` that will deploy additional control plane nodes to an existing FastPass Kubernetes cluster. The role will follow the same pattern as the existing `fastpass-first-control-plane` role but will focus on joining nodes to an already initialized cluster rather than initializing a new cluster. This ensures high availability for the Kubernetes control plane by adding redundant master nodes.
-
-## Requirements
-
-### Requirement 1
-
-**User Story:** As a DevOps engineer, I want to deploy additional control plane nodes to my FastPass Kubernetes cluster, so that I can achieve high availability and fault tolerance for the cluster control plane.
-
-#### Acceptance Criteria
-
-1. WHEN the role is executed on a node THEN the system SHALL join the node to the existing Kubernetes cluster as a control plane node
-2. WHEN the role runs THEN the system SHALL configure the necessary firewall rules for control plane services
-3. WHEN the role executes THEN the system SHALL ensure the kubelet service is properly configured and running
-4. WHEN joining the cluster THEN the system SHALL use the correct join token and certificate key from the first control plane node
-5. WHEN the role completes THEN the system SHALL verify the node has successfully joined as a control plane node
-
-### Requirement 2
-
-**User Story:** As a system administrator, I want the additional control plane role to follow the same patterns as the first control plane role, so that the codebase remains consistent and maintainable.
-
-#### Acceptance Criteria
-
-1. WHEN the role is created THEN the system SHALL follow the same directory structure as fastpass-first-control-plane
-2. WHEN the role is implemented THEN the system SHALL use similar variable naming conventions and task organization
-3. WHEN the role runs THEN the system SHALL include proper error handling and idempotency checks
-4. WHEN the role executes THEN the system SHALL use the same firewall service definitions as the first control plane role
-5. WHEN the role is documented THEN the system SHALL include proper metadata headers with author, version, and description
-
-### Requirement 3
-
-**User Story:** As a cluster operator, I want the additional control plane nodes to have proper DNS configuration, so that they can be reached by their cluster names and participate in load balancing.
-
-#### Acceptance Criteria
-
-1. WHEN the role runs THEN the system SHALL configure DNS records for the additional control plane nodes
-2. WHEN DNS is configured THEN the system SHALL use the dns-manager role for consistency
-3. WHEN the role executes THEN the system SHALL ensure the node can resolve the cluster endpoint
-4. WHEN DNS setup completes THEN the system SHALL verify connectivity to the cluster API endpoint
-
-### Requirement 4
-
-**User Story:** As a DevOps engineer, I want the role to handle kubeconfig management for additional control plane nodes, so that I can manage the cluster from any control plane node.
-
-#### Acceptance Criteria
-
-1. WHEN the role completes THEN the system SHALL configure kubeconfig for the new control plane node
-2. WHEN kubeconfig is set up THEN the system SHALL use the kubeconfig-manager role for consistency
-3. WHEN the role runs THEN the system SHALL ensure proper permissions are set on kubeconfig files
-4. WHEN kubeconfig is configured THEN the system SHALL verify kubectl access works from the new node
-
-### Requirement 5
-
-**User Story:** As a system administrator, I want the role to be idempotent and handle edge cases, so that I can run it multiple times safely without causing issues.
-
-#### Acceptance Criteria
-
-1. WHEN the role is run multiple times THEN the system SHALL not attempt to rejoin an already joined node
-2. WHEN a node is already part of the cluster THEN the system SHALL skip the join process gracefully
-3. WHEN the role encounters errors THEN the system SHALL provide clear error messages and fail gracefully
-4. WHEN prerequisites are missing THEN the system SHALL report what needs to be configured first
-5. WHEN the role runs THEN the system SHALL validate that required variables are defined
-
-### Requirement 6
-
-**User Story:** As a cluster administrator, I want the role to integrate seamlessly with the existing FastPass deployment workflow, so that it can be used in the 4-step deployment process.
-
-#### Acceptance Criteria
-
-1. WHEN the role is created THEN the system SHALL be compatible with the deploy-fastpass-4step.yml playbook
-2. WHEN the role runs THEN the system SHALL work with the fastpass_control_plane[1:] host group
-3. WHEN integrated THEN the system SHALL not interfere with the first control plane initialization
-4. WHEN the role executes THEN the system SHALL depend on the first control plane node being ready
-5. WHEN deployment completes THEN the system SHALL allow worker nodes to join the cluster successfully
\ No newline at end of file
diff --git a/.kiro/specs/fastpass-additional-control-plane/tasks.md b/.kiro/specs/fastpass-additional-control-plane/tasks.md
deleted file mode 100644
index 9784429..0000000
--- a/.kiro/specs/fastpass-additional-control-plane/tasks.md
+++ /dev/null
@@ -1,118 +0,0 @@
-# Implementation Plan
-
-- [ ] 1. Create role directory structure and basic configuration
-  - Create the fastpass-additional-control-plane role directory structure
-  - Set up defaults/main.yml with required variables and firewall services
-  - Create meta/main.yml with role metadata and dependencies
-  - _Requirements: 2.1, 2.2, 2.4_
-
-- [ ] 2. Implement join token and certificate key retrieval
-  - [ ] 2.1 Create tasks to generate new join tokens from first control plane
-    - Write Ansible tasks to execute kubeadm token create on first control plane node
-    - Implement token validation and expiration checking
-    - Add error handling for token generation failures
-    - _Requirements: 1.4, 5.4_
-
-  - [ ] 2.2 Implement certificate key retrieval and management
-    - Create tasks to upload and retrieve certificate keys from first control plane
-    - Add certificate key expiration handling and rotation
-    - Implement secure handling of certificate keys in variables
-    - _Requirements: 1.4, 5.1_
-
-  - [ ] 2.3 Create discovery token CA certificate hash retrieval
-    - Write tasks to extract CA certificate hash from first control plane
-    - Implement validation of certificate hash format
-    - Add error handling for certificate retrieval failures
-    - _Requirements: 1.4, 5.4_
-
-- [ ] 3. Implement DNS configuration and firewall setup
-  - [ ] 3.1 Configure DNS records for additional control plane nodes
-    - Integrate dns-manager role for consistent DNS record creation
-    - Pass appropriate host_name variable to dns-manager
-    - Add DNS propagation wait and validation
-    - _Requirements: 3.1, 3.2, 3.4_
-
-  - [ ] 3.2 Set up firewall rules for control plane services
-    - Reuse kubernetes_services_control_plane from defaults
-    - Implement UFW firewall rule creation for Debian/Ubuntu systems
-    - Add conditional logic for different operating systems
-    - _Requirements: 1.2, 2.4_
-
-- [ ] 4. Implement kubelet configuration and cluster join
-  - [ ] 4.1 Create initial kubelet configuration
-    - Write kubelet config.yaml with systemd cgroup driver
-    - Set containerd socket endpoint configuration
-    - Ensure proper file permissions and ownership
-    - _Requirements: 1.3, 2.3_
-
-  - [ ] 4.2 Execute kubeadm join for control plane
-    - Implement kubeadm join command with control-plane flag
-    - Use retrieved join token, certificate key, and CA cert hash
-    - Add proper command argument construction and validation
-    - Include idempotency checks to prevent duplicate joins
-    - _Requirements: 1.1, 1.4, 5.1, 5.2_
-
-  - [ ] 4.3 Ensure kubelet service management
-    - Enable and start kubelet systemd service
-    - Add service status validation and error handling
-    - Implement service restart logic if needed
-    - _Requirements: 1.3, 1.5_
-
-- [ ] 5. Implement kubeconfig management and validation
-  - [ ] 5.1 Configure kubeconfig for additional control plane nodes
-    - Integrate kubeconfig-manager role for consistent configuration
-    - Pass cluster_name variable to kubeconfig-manager
-    - Ensure proper kubeconfig merging with existing configurations
-    - _Requirements: 4.1, 4.2, 4.3_
-
-  - [ ] 5.2 Implement cluster join validation
-    - Create tasks to verify node successfully joined as control plane
-    - Add kubectl commands to check node status and roles
-    - Implement cluster health validation checks
-    - _Requirements: 1.5, 4.4_
-
-- [ ] 6. Add comprehensive error handling and idempotency
-  - [ ] 6.1 Implement pre-flight validation checks
-    - Check if node is already joined to cluster
-    - Validate required variables are defined
-    - Verify first control plane node accessibility
-    - Add system resource and prerequisite checks
-    - _Requirements: 5.1, 5.2, 5.4, 5.5_
-
-  - [ ] 6.2 Add retry logic and failure recovery
-    - Implement retry mechanisms for transient failures
-    - Add exponential backoff for network-related operations
-    - Create cleanup tasks for partial join failures
-    - _Requirements: 5.3, 5.4_
-
-- [ ] 7. Integration with FastPass deployment workflow
-  - [ ] 7.1 Ensure compatibility with deploy-fastpass-4step.yml
-    - Verify role works with fastpass_control_plane[1:] host group
-    - Test integration with existing playbook structure
-    - Validate dependency on first control plane completion
-    - _Requirements: 6.1, 6.2, 6.3, 6.4_
-
-  - [ ] 7.2 Add proper task documentation and metadata
-    - Include role header with author, version, and description
-    - Add inline comments for complex task logic
-    - Document required variables and their purposes
-    - _Requirements: 2.2, 2.5_
-
-- [ ]* 8. Create comprehensive testing and validation
-  - [ ]* 8.1 Write unit tests for individual tasks
-    - Create test cases for token retrieval logic
-    - Test kubeadm join command construction
-    - Validate error handling scenarios
-    - _Requirements: 1.1, 1.4, 5.1_
-
-  - [ ]* 8.2 Implement integration tests
-    - Test multi-node control plane deployment
-    - Validate cluster health after additional nodes join
-    - Test failover scenarios and cluster resilience
-    - _Requirements: 1.5, 6.5_
-
-  - [ ]* 8.3 Add validation scripts and health checks
-    - Create scripts to verify cluster state after deployment
-    - Implement automated health validation
-    - Add performance and resource usage monitoring
-    - _Requirements: 1.5, 4.4_
\ No newline at end of file
diff --git a/.kiro/specs/fastpass-dns-loadbalancer-fix/requirements.md b/.kiro/specs/fastpass-dns-loadbalancer-fix/requirements.md
deleted file mode 100644
index 7ca1b52..0000000
--- a/.kiro/specs/fastpass-dns-loadbalancer-fix/requirements.md
+++ /dev/null
@@ -1,51 +0,0 @@
-# Requirements Document
-
-## Introduction
-
-The FastPass Kubernetes cluster deployment currently has critical DNS and load balancing configuration issues that prevent proper high availability setup. While the cluster endpoint `fastpass.local.mk-labs.cloud` is defined in the group variables, the `cluster_vip` variable required by the DNS manager role is missing, and the Traefik load balancer configuration is commented out. This means the cluster endpoint cannot resolve properly and there's no load balancing for the control plane API. This feature will fix these configuration gaps to enable true HA functionality.
-
-## Requirements
-
-### Requirement 1: DNS CNAME Record for Load Balancer
-
-**User Story:** As a DevOps engineer, I want the DNS manager to create a CNAME record for the cluster endpoint pointing to the load balancer, so that the cluster endpoint resolves through the load balancer rather than directly to node IPs.
-
-#### Acceptance Criteria
-
-1. WHEN the dns-manager role is called for a load-balanced cluster THEN the system SHALL create a CNAME record instead of an A record
-2. WHEN the CNAME record is created THEN the system SHALL point fastpass.local.mk-labs.cloud to the traefik_server (lightning_lane.local.mk-labs.cloud)
-3. WHEN the DNS record type is determined THEN the system SHALL use CNAME for load-balanced endpoints and A records for direct node access
-4. WHEN DNS propagation occurs THEN the system SHALL verify that the CNAME resolution works correctly
-
-### Requirement 2: Complete Traefik Integration
-
-**User Story:** As a DevOps engineer, I want the Traefik load balancer to be fully integrated with the FastPass deployment, so that the cluster VIP is properly load balanced across all control plane nodes.
-
-#### Acceptance Criteria
-
-1. WHEN the traefik-manager role is called THEN the system SHALL use the traefik_server variable (lightning_lane) as the target host
-2. WHEN Traefik configuration is generated THEN the system SHALL create proper TCP routing for the cluster endpoint to all control plane nodes
-3. WHEN the cluster VIP is accessed THEN the system SHALL distribute requests across space-mountain, big-thunder-mountain, and splash-mountain
-4. WHEN Traefik configuration is applied THEN the system SHALL reload the Traefik service to activate the new configuration
-
-### Requirement 3: High Availability Validation
-
-**User Story:** As a DevOps engineer, I want to validate that the HA setup is working correctly, so that I can be confident the cluster will survive node failures.
-
-#### Acceptance Criteria
-
-1. WHEN the deployment completes THEN the system SHALL test connectivity to the cluster endpoint
-2. WHEN connectivity tests run THEN the system SHALL verify that the endpoint resolves through the CNAME to the load balancer
-3. WHEN load balancer tests run THEN the system SHALL verify that requests are being distributed across control plane nodes
-4. WHEN a control plane node is stopped THEN the system SHALL continue to serve API requests through the remaining nodes
-
-### Requirement 4: Backward Compatibility
-
-**User Story:** As a DevOps engineer, I want the DNS fixes to be backward compatible with existing deployments, so that current clusters continue to function during the transition.
-
-#### Acceptance Criteria
-
-1. WHEN existing clusters are updated THEN the system SHALL not break existing DNS configurations
-2. WHEN new variables are introduced THEN the system SHALL provide sensible defaults for existing deployments
-3. WHEN the update is applied THEN the system SHALL preserve existing kubeconfig files and cluster access
-4. IF migration issues occur THEN the system SHALL provide rollback procedures and documentation
\ No newline at end of file
diff --git a/calendar-sync.applescript b/calendar-sync.applescript
deleted file mode 100644
index f813893..0000000
--- a/calendar-sync.applescript
+++ /dev/null
@@ -1,161 +0,0 @@
-(*
-	Calendar Sync Script
-	
-	Synchronizes calendar events between two calendar accounts for the current day.
-	Reads events from a source calendar and mirrors them to a destination calendar,
-	including removal of events that no longer exist in the source.
-*)
-
--- Configuration Properties
-property sourceAccountName : "Work Account"
-property sourceCalendarName : "Main Calendar"
-property destinationAccountName : "Personal Account"
-property destinationCalendarName : "Synced Events"
-property enableLogging : true
-property enableDebugMode : false
-
--- Logging levels
-property LOG_ERROR : 1
-property LOG_WARNING : 2
-property LOG_INFO : 3
-property LOG_DEBUG : 4
-
--- Global variables for tracking sync state
-global syncResults
-global errorList
-
--- Initialize sync results record
-on initializeSyncResults()
-	set syncResults to {eventsCreated:0, eventsUpdated:0, eventsRemoved:0, eventsSkipped:0, errors:{}}
-	set errorList to {}
-end initializeSyncResults
-
--- Main entry point
-on run
-	try
-		-- Initialize logging and sync tracking
-		initializeSyncResults()
-		logMessage("Starting Calendar Sync", LOG_INFO)
-		
-		-- Display configuration
-		logMessage("Source: " & sourceAccountName & " -> " & sourceCalendarName, LOG_INFO)
-		logMessage("Destination: " & destinationAccountName & " -> " & destinationCalendarName, LOG_INFO)
-		
-		-- TODO: Implement main sync workflow
-		logMessage("Calendar sync setup complete", LOG_INFO)
-		
-	on error errorMessage number errorNumber
-		handleError("Main execution error: " & errorMessage, errorNumber)
-	end try
-end run
-
--- Logging and Error Handling Framework
-
--- Log a message with specified level
-on logMessage(message, level)
-	if not enableLogging then return
-	
-	set levelText to getLevelText(level)
-	set timestamp to (current date) as string
-	set logEntry to "[" & timestamp & "] " & levelText & ": " & message
-	
-	-- Display to user (can be modified to write to file if needed)
-	if level ≤ LOG_WARNING or enableDebugMode then
-		display notification message with title "Calendar Sync " & levelText
-	end if
-	
-	-- Always log errors and warnings to console
-	if level ≤ LOG_WARNING then
-		log logEntry
-	else if enableDebugMode then
-		log logEntry
-	end if
-end logMessage
-
--- Get text representation of log level
-on getLevelText(level)
-	if level = LOG_ERROR then
-		return "ERROR"
-	else if level = LOG_WARNING then
-		return "WARNING"
-	else if level = LOG_INFO then
-		return "INFO"
-	else if level = LOG_DEBUG then
-		return "DEBUG"
-	else
-		return "UNKNOWN"
-	end if
-end getLevelText
-
--- Handle errors with logging and user feedback
-on handleError(errorMessage, errorNumber)
-	set fullErrorMessage to errorMessage & " (Error " & errorNumber & ")"
-	
-	-- Log the error
-	logMessage(fullErrorMessage, LOG_ERROR)
-	
-	-- Add to error list for reporting
-	set end of errorList to fullErrorMessage
-	
-	-- Display user-friendly error dialog
-	display dialog "Calendar Sync Error: " & errorMessage buttons {"OK"} default button "OK" with icon stop
-end handleError
-
--- Display progress to user
-on displayProgress(currentItem, totalItems, itemDescription)
-	if not enableLogging then return
-	
-	set progressPercent to round ((currentItem / totalItems) * 100)
-	set progressMessage to "Processing " & itemDescription & " (" & currentItem & " of " & totalItems & " - " & progressPercent & "%)"
-	
-	logMessage(progressMessage, LOG_INFO)
-end displayProgress
-
--- Display final sync summary
-on showSyncSummary()
-	set summaryMessage to "Sync Complete!" & return & return
-	set summaryMessage to summaryMessage & "Events Created: " & (eventsCreated of syncResults) & return
-	set summaryMessage to summaryMessage & "Events Updated: " & (eventsUpdated of syncResults) & return
-	set summaryMessage to summaryMessage & "Events Removed: " & (eventsRemoved of syncResults) & return
-	set summaryMessage to summaryMessage & "Events Skipped: " & (eventsSkipped of syncResults) & return
-	
-	if (count of errorList) > 0 then
-		set summaryMessage to summaryMessage & return & "Errors encountered: " & (count of errorList)
-	end if
-	
-	logMessage(summaryMessage, LOG_INFO)
-	display dialog summaryMessage buttons {"OK"} default button "OK" with icon note
-end showSyncSummary
-
--- Validate configuration before starting sync
-on validateConfiguration()
-	logMessage("Validating configuration...", LOG_DEBUG)
-	
-	-- Check that required properties are set
-	if sourceAccountName = "" or sourceCalendarName = "" then
-		handleError("Source calendar configuration is incomplete", -1)
-		return false
-	end if
-	
-	if destinationAccountName = "" or destinationCalendarName = "" then
-		handleError("Destination calendar configuration is incomplete", -2)
-		return false
-	end if
-	
-	logMessage("Configuration validation passed", LOG_DEBUG)
-	return true
-end validateConfiguration
-
--- Utility function to get current date for today's events
-on getCurrentDate()
-	return current date
-end getCurrentDate
-
--- Utility function to create date range for current day
-on getCurrentDayRange()
-	set today to getCurrentDate()
-	set startOfDay to date (short date string of today)
-	set endOfDay to startOfDay + (24 * hours) - 1
-	
-	return {startDate:startOfDay, endDate:endOfDay}
-end getCurrentDayRange
\ No newline at end of file
diff --git a/~/Documents/git/applescript-calendar-sync/.gitignore b/~/Documents/git/applescript-calendar-sync/.gitignore
deleted file mode 100644
index 15575cf..0000000
--- a/~/Documents/git/applescript-calendar-sync/.gitignore
+++ /dev/null
@@ -1,40 +0,0 @@
-# macOS
-.DS_Store
-.AppleDouble
-.LSOverride
-
-# Icon must end with two \r
-Icon
-
-# Thumbnails
-._*
-
-# Files that might appear in the root of a volume
-.DocumentRevisions-V100
-.fseventsd
-.Spotlight-V100
-.TemporaryItems
-.Trashes
-.VolumeIcon.icns
-.com.apple.timemachine.donotpresent
-
-# Directories potentially created on remote AFP share
-.AppleDB
-.AppleDesktop
-Network Trash Folder
-Temporary Items
-.apdisk
-
-# AppleScript compiled files
-*.scpt
-
-# Logs
-*.log
-
-# IDE files
-.vscode/
-.idea/
-
-# Backup files
-*.backup
-*~
\ No newline at end of file
diff --git a/~/Documents/git/applescript-calendar-sync/README.md b/~/Documents/git/applescript-calendar-sync/README.md
deleted file mode 100644
index 37f9af8..0000000
--- a/~/Documents/git/applescript-calendar-sync/README.md
+++ /dev/null
@@ -1,52 +0,0 @@
-# AppleScript Calendar Sync
-
-An AppleScript utility that synchronizes calendar events between two calendar accounts for the current day.
-
-## Overview
-
-This script reads events from a source calendar and mirrors them to a destination calendar, including removal of events that no longer exist in the source. It's designed to keep two calendars in sync automatically.
-
-## Features
-
-- Synchronizes events for the current day only
-- Configurable source and destination calendars
-- Comprehensive logging and error handling
-- Progress tracking and user notifications
-- Handles event creation, updates, and removal
-
-## Configuration
-
-Edit the configuration properties at the top of `calendar-sync.applescript`:
-
-```applescript
-property sourceAccountName : "Work Account"
-property sourceCalendarName : "Main Calendar"
-property destinationAccountName : "Personal Account"
-property destinationCalendarName : "Synced Events"
-property enableLogging : true
-property enableDebugMode : false
-```
-
-## Usage
-
-1. Configure the source and destination calendar settings
-2. Run the script using Script Editor or from the command line with `osascript`
-3. The script will sync today's events and display a summary
-
-## Documentation
-
-The `docs/` directory contains the complete specification:
-
-- `requirements.md` - Detailed requirements and user stories
-- `design.md` - Technical design and architecture
-- `tasks.md` - Implementation plan and task breakdown
-
-## Development Status
-
-This project is currently in development. See `docs/tasks.md` for the current implementation progress.
-
-## Requirements
-
-- macOS with Calendar app
-- AppleScript support
-- Access to both source and destination calendar accounts
\ No newline at end of file