Retask

Author: alvagante

.kiro/specs/sai-cli-application/design.md

@@ -126,4 +126,87 @@ The SAI CLI application is a lightweight command-line tool for executing softwar
 2. WHEN multiple providers are used THEN the system SHALL display the provider name with a configurable background color
 3. WHEN a command is executed THEN the system SHALL show the output in normal text followed by highlighted exit status (Green for success, Red for failure)
 4. WHEN any executed command fails THEN the sai command exit code SHALL be 1 AND WHEN all commands succeed THEN the exit code SHALL be 0
-5. WHEN validating commands THEN the system SHALL only show and execute commands that can be executed AND SHALL NOT attempt to run commands with unavailable providers or on non-existent software
+5. WHEN validating commands THEN the system SHALL only show and execute commands that can be executed AND SHALL NOT attempt to run commands with unavailable providers or on non-existent software
+
+### Requirement 11
+
+**User Story:** As a system administrator, I want automatic saidata repository management, so that I can use SAI without manual setup and always have up-to-date software definitions.
+
+#### Acceptance Criteria
+
+1. WHEN SAI is executed for the first time THEN the system SHALL display a relevant message about downloading saidata repository
+2. WHEN running as a normal user THEN the system SHALL download saidata to $HOME/.sai/saidata directory
+3. WHEN running as root THEN the system SHALL download saidata to /etc/sai/saidata directory (or Windows equivalent)
+4. WHEN downloading saidata THEN the system SHALL use Git clone as the primary method with zip download as fallback
+5. WHEN the `sai saidata` command is executed THEN the system SHALL provide saidata management operations including update, status, and synchronization
+
+### Requirement 12
+
+**User Story:** As a developer, I want detailed debug information when troubleshooting SAI issues, so that I can diagnose problems effectively.
+
+#### Acceptance Criteria
+
+1. WHEN the `--debug` flag is provided THEN the system SHALL display detailed debug information including provider detection, template resolution, and command execution details
+2. WHEN debug mode is enabled THEN the system SHALL show internal state information, configuration loading, and decision-making processes
+3. WHEN debug mode is enabled THEN the system SHALL log all template variable resolutions and provider selection logic
+4. WHEN debug mode is enabled THEN the system SHALL display timing information for operations and performance metrics
+
+### Requirement 13
+
+**User Story:** As a system administrator, I want accurate provider detection and system statistics, so that I can understand which providers are actually available on my system.
+
+#### Acceptance Criteria
+
+1. WHEN `sai stats` is executed THEN the system SHALL only show providers that are actually available based on executable detection
+2. WHEN a provider defines an `executable` field THEN the system SHALL use that executable to determine provider availability
+3. WHEN provider detection fails THEN the system SHALL not list that provider as available in stats output
+4. WHEN multiple providers are available THEN the system SHALL show accurate availability status for each provider
+
+### Requirement 14
+
+**User Story:** As a system administrator, I want to check software versions using SAI's version command, so that I can see installed software versions across different providers.
+
+#### Acceptance Criteria
+
+1. WHEN `sai version <software>` is executed THEN the system SHALL show the version of the software if installed for all available providers
+2. WHEN a provider has a version action defined THEN the system SHALL use that action's command to retrieve version information
+3. WHEN `sai --version` is executed THEN the system SHALL show SAI's own version information
+4. WHEN software is not installed THEN the system SHALL indicate that the software is not installed for that provider
+5. WHEN version information cannot be retrieved THEN the system SHALL show an appropriate error message
+
+### Requirement 15
+
+**User Story:** As a system administrator, I want compact and informative output when multiple providers are available, so that I can quickly understand my options and make informed decisions.
+
+#### Acceptance Criteria
+
+1. WHEN multiple providers are available for an action THEN the system SHALL display provider name and the full command that will be executed
+2. WHEN showing provider options THEN the system SHALL display "Command: (The full command executed/to execute to get the output)" instead of package/version/description
+3. WHEN an action only displays information and doesn't modify the system THEN the system SHALL execute the command for each available provider without asking for selection
+4. WHEN an action modifies the system THEN the system SHALL still prompt for provider selection
+5. WHEN displaying provider options THEN the system SHALL show availability status for each provider
+
+### Requirement 16
+
+**User Story:** As a system administrator, I want all SAI actions to work correctly, so that I can actually manage software using the tool.
+
+#### Acceptance Criteria
+
+1. WHEN any SAI command is executed THEN the system SHALL successfully complete the requested action without errors
+2. WHEN template resolution occurs THEN all saidata template functions SHALL resolve correctly to actual values
+3. WHEN provider actions are executed THEN the commands SHALL be properly constructed and executed
+4. WHEN saidata is loaded THEN the system SHALL correctly parse and use the software definitions
+5. WHEN providers are loaded THEN the system SHALL correctly parse and execute provider actions
+6. WHEN any action fails THEN the system SHALL provide clear error messages indicating what went wrong and how to fix it
+
+### Requirement 17
+
+**User Story:** As a system administrator, I want consistent naming for packages and services in saidata and providers, so that template functions work predictably across all configurations.
+
+#### Acceptance Criteria
+
+1. WHEN defining packages in saidata THEN the system SHALL use `package_name` parameter instead of `name` for package identification
+2. WHEN using template functions THEN `sai_package()` SHALL reference the `package_name` field consistently
+3. WHEN using template functions THEN `sai_service()` SHALL continue to reference the `service_name` field as before
+4. WHEN updating providers THEN all existing provider templates SHALL be updated to use `package_name` instead of `name`
+5. WHEN updating schemas THEN the saidata schema SHALL be updated to require `package_name` field for packages

.kiro/specs/sai-cli-application/requirements.md

@@ -1,11 +1,110 @@
 # Implementation Plan
 
-- [x] 1. Set up Go project structure and core dependencies
-  - Initialize Go module with proper project structure (cmd/, internal/, pkg/)
-  - Add Cobra CLI framework, YAML parsing (gopkg.in/yaml.v3), and logging dependencies
-  - Create main.go entry point and basic CLI structure
-  - Set up build configuration (Makefile) for cross-platform compilation
-  - _Requirements: 7.1, 7.2, 8.1_
+## Phase 1: Fix Core Functionality (Critical)
+
+- [x] 1. Diagnose and fix template resolution system
+  - Analyze current template engine implementation and identify why sai_package(), sai_service() functions fail
+  - Fix template function registration and context passing to ensure saidata is available
+  - Update template functions to properly access package_name field instead of name field
+  - Add comprehensive error handling for template resolution failures with clear error messages
+  - Create unit tests that verify template functions work with existing saidata samples
+  - _Requirements: 16.2, 16.3, 17.2, 17.3_
+
+- [x] 2. Fix provider loading and validation system
+  - Debug current provider YAML loading to identify parsing failures
+  - Fix YAML unmarshaling for all existing provider files (apt.yaml, brew.yaml, docker.yaml, etc.)
+  - Implement proper schema validation against providerdata-0.1-schema.json
+  - Add error handling for malformed provider files with specific error messages
+  - Verify all existing providers load correctly and actions are accessible
+  - _Requirements: 16.4, 16.5_
+
+- [x] 3. Fix saidata loading and parsing system
+  - Debug current saidata loading from docs/saidata_samples/ directory
+  - Fix hierarchical loading (software/{prefix}/{software}/default.yaml pattern)
+  - Implement proper OS-specific override loading and merging
+  - Add schema validation against saidata-0.2-schema.json with clear error messages
+  - Verify existing saidata samples (apache, elasticsearch, etc.) load correctly
+  - _Requirements: 16.4, 16.5_
+
+- [x] 4. Fix command execution and provider action system
+  - Debug why provider actions fail to execute properly
+  - Fix command template rendering with proper saidata context
+  - Implement proper command execution with error handling and output capture
+  - Add validation to ensure commands are executable before attempting to run them
+  - Create comprehensive logging for command execution failures
+  - _Requirements: 16.1, 16.3, 16.6_
+
+## Phase 2: Implement Missing Core Features
+
+- [x] 5. Implement automatic saidata management
+  - Create saidata bootstrap system that detects first-time usage
+  - Implement automatic download to $HOME/.sai/saidata (user) or /etc/sai/saidata (root)
+  - Add Git clone functionality with zip download fallback
+  - Create welcome message display for first-time users
+  - Implement `sai saidata` command for repository management (update, status, sync)
+  - _Requirements: 11.1, 11.2, 11.3, 11.4, 11.5_
+
+- [x] 6. Fix provider detection system
+  - Implement proper executable-based provider detection using provider.executable field
+  - Fix provider availability checking to prevent showing unavailable providers (like apt on macOS)
+  - Update `sai stats` command to only show actually available providers
+  - Add provider detection caching for performance
+  - Create comprehensive provider detection logging for debugging
+  - _Requirements: 13.1, 13.2, 13.3, 13.4_
+
+- [x] 7. Implement debug system
+  - Add --debug flag to root command with comprehensive debug logging
+  - Implement debug logging for provider detection, template resolution, command execution
+  - Add performance timing and metrics collection in debug mode
+  - Create debug output for configuration loading and decision-making processes
+  - Add internal state logging for troubleshooting complex issues
+  - _Requirements: 12.1, 12.2, 12.3, 12.4_
+
+## Phase 3: Improve User Experience
+
+- [x] 8. Fix and improve version command functionality
+  - Separate `sai --version` (SAI version) from `sai version <software>` (software version)
+  - Implement proper software version checking using provider version actions
+  - Add support for showing version across all available providers
+  - Display installation status alongside version information
+  - Add proper error handling when version information cannot be retrieved
+  - _Requirements: 14.1, 14.2, 14.3, 14.4, 14.5_
+
+- [x] 9. Improve output formatting and provider selection
+  - Update provider selection UI to show actual commands instead of package details
+  - Implement automatic execution for information-only commands (search, info, status, etc.)
+  - Add compact output format showing "Command: (full command)" for each provider
+  - Maintain provider selection prompts only for system-changing operations
+  - Update output formatting to be more concise and informative
+  - _Requirements: 15.1, 15.2, 15.3, 15.4, 15.5_
+
+## Phase 4: Data Structure Consistency
+
+- [ ] 10. Standardize package naming across all components
+  - Update saidata-0.2-schema.json to require package_name field for packages
+  - Update all existing saidata samples to use package_name instead of name
+  - Update all provider templates to reference package_name consistently
+  - Update template functions to use package_name field for package resolution
+  - Verify all existing providers work with updated package_name structure
+  - _Requirements: 17.1, 17.2, 17.4, 17.5_
+
+## Phase 5: Testing and Validation
+
+- [ ] 11. Create comprehensive test suite for fixed functionality
+  - Write integration tests that verify all basic SAI commands work (install, status, version, etc.)
+  - Create tests using existing provider files and saidata samples
+  - Add tests for template resolution with real saidata
+  - Implement tests for provider detection across different platforms
+  - Create end-to-end tests that verify complete workflows work correctly
+  - _Requirements: 16.1, 16.2, 16.3, 16.4, 16.5, 16.6_
+
+- [ ] 12. Add error handling and recovery systems
+  - Implement comprehensive error handling with clear, actionable error messages
+  - Add error context and suggestions for common failure scenarios
+  - Create recovery mechanisms for transient failures
+  - Add validation systems that prevent execution when resources don't exist
+  - Implement graceful degradation when providers or saidata are unavailable
+  - _Requirements: 16.6_
 
 - [x] 2. Implement core data structures and YAML parsing
   - [x] 2.1 Create provider data structures matching existing YAML files

.kiro/specs/sai-cli-application/tasks.md

@@ -3,6 +3,9 @@ version: "0.2"
 # CentOS 8-specific overrides for Apache HTTP Server
 # This file demonstrates OS-specific configuration that gets deep-merged with default.yaml
 
+metadata:
+  name: "apache"
+
 packages:
   - name: "httpd"  # CentOS uses 'httpd' instead of 'apache2'
     version: "2.4.37-43.module_el8.5.0+1022+b541f3b1"
@@ -95,39 +98,28 @@ providers:
       "ca-certificates",
       "centos-release"  # CentOS-specific release package
     ]
-    post_install_commands: [
-      "systemctl enable httpd",
-      "systemctl start httpd",
-      "firewall-cmd --permanent --add-service=http",  # CentOS firewall
-      "firewall-cmd --permanent --add-service=https",
-      "firewall-cmd --reload"
-    ]
+
     services:
       - name: "apache"
         service_name: "httpd"
         type: "systemd"
         enabled: true
-        centos_selinux: true  # CentOS-specific SELinux consideration
+
     repositories:
       - name: "appstream"
         url: "http://mirror.centos.org/centos/8-stream/AppStream/x86_64/os/"
         key: "RPM-GPG-KEY-centosofficial"
         type: "os-default"
         components: ["appstream"]
-        centos_stream: true
 
 # CentOS 8-specific compatibility
 compatibility:
   matrix:
     - provider: "dnf"
       platform: ["linux"]
-      os: ["centos"]
       architecture: ["x86_64", "aarch64"]
       os_version: ["8"]
       supported: true
       notes: "Native CentOS 8 package with SELinux integration"
       tested: true
-      recommended: true
-      centos_stream: true
-      selinux_support: true
-      package_version: "2.4.37-43.module_el8.5.0+1022+b541f3b1"
+      recommended: true

docs/saidata_samples/ap/apache/centos/8.yaml

@@ -3,6 +3,9 @@ version: "0.2"
 # macOS 13-specific overrides for Apache HTTP Server
 # This file demonstrates OS-specific configuration that gets deep-merged with default.yaml
 
+metadata:
+  name: "apache"
+
 packages:
   - name: "httpd"  # macOS uses 'httpd' instead of 'apache2'
     version: "2.4.58"
@@ -79,12 +82,12 @@ providers:
         service_name: "httpd"
         type: "launchd"
         enabled: false  # Don't auto-start on macOS
-        plist_path: "/opt/homebrew/etc/httpd/org.apache.httpd.plist"
+
     files:
       - name: "config"
         path: "/opt/homebrew/etc/httpd/httpd.conf"
         type: "config"
-        template: "macos-httpd.conf.j2"  # macOS-specific template
+
     directories:
       - name: "config"
         path: "/opt/homebrew/etc/httpd"
@@ -93,18 +96,16 @@ providers:
     commands:
       - name: "httpd"
         path: "/opt/homebrew/bin/httpd"
-        shell_integration: "zsh"  # macOS default shell
+
 
 # macOS 13-specific compatibility matrix
 compatibility:
   matrix:
     - provider: "brew"
-      os: "macos"  # Changed from 'platform' to 'os'
+      platform: "macos"
       architecture: ["x86_64", "arm64"]
       os_version: ["13.0"]
       supported: true
       notes: "Recommended installation method for macOS 13"
       tested: true
       recommended: true
-      homebrew_formula: "httpd"
-      minimum_macos: "13.0"