feature: make installer Go-based for better stability & maintainability

.github/INSTALLER_CI_README.md

@@ -0,0 +1,97 @@
+# Installer CI Documentation
+
+This directory contains GitHub Actions workflows for the dotfiles installer project located in the `installer/` subdirectory.
+
+## Workflow Overview
+
+### 🔧 installer-ci.yml
+**Purpose**: Build and test the installer  
+**Trigger**: Push to main or PRs affecting `installer/` directory  
+
+**Jobs (in order)**:
+1. **Build**: Uses GoReleaser to create cross-platform binaries
+2. **Test**: Runs Go test suite with race detection  
+3. **E2E Tests**: Tests installer on multiple platforms in real environments
+
+**Platforms Tested**:
+- Ubuntu (latest)
+- Debian (bookworm container)
+- macOS (latest)
+
+## Build Process
+
+The CI uses GoReleaser in **snapshot mode** to:
+- Build cross-platform binaries (Linux/macOS, AMD64/ARM64)
+- Generate consistent build artifacts
+- **No releases** - just builds for testing
+
+## E2E Testing
+
+The pipeline includes end-to-end testing that:
+
+1. **Downloads** the built installer binary
+2. **Tests** on multiple OS distributions  
+3. **Verifies** compatibility detection works
+4. **Runs** installer in non-interactive mode
+5. **Validates** graceful behavior in CI environments
+
+### Test Configuration
+
+E2E tests use these flags for CI compatibility:
+- `--non-interactive`: Skips all user prompts
+- `--plain`: Disables progress indicators for cleaner logs  
+- `--install-brew=false`: Skips Homebrew for faster testing
+- `--install-prerequisites=false`: Skips prerequisite installation
+- `--git-clone-protocol=https`: Uses HTTPS instead of SSH
+
+### Test Environment
+
+- **Isolated**: Uses `/tmp/test-home` as HOME directory
+- **Timeout**: 300 seconds (5 minutes) to prevent hangs
+- **Graceful Failures**: Expected in CI since we don't have full system setup
+
+## Local Testing
+
+To test the workflow locally:
+
+```bash
+cd installer/
+task build
+./bin/dotfiles-installer install --non-interactive --plain --install-brew=false
+```
+
+## Workflow Structure
+
+```
+.github/
+└── workflows/
+    └── installer-ci.yml    # Main CI pipeline
+```
+
+## Troubleshooting
+
+### Common Issues
+
+1. **Build Fails**: Check Go version in `installer/go.mod`
+2. **E2E Test Fails**: Review platform-specific requirements
+3. **Test Timeout**: E2E tests timeout after 5 minutes
+
+### Debugging E2E Tests
+
+E2E tests are designed to handle CI environment limitations:
+- Allow expected failures (exit code 1) in restricted environments
+- Create isolated test directories
+- Skip complex system modifications
+
+To debug locally:
+```bash
+export HOME="/tmp/test-home"
+mkdir -p "$HOME"
+./installer/bin/dotfiles-installer install --non-interactive --plain
+```
+
+## Future Enhancements
+
+- **Linting**: Will integrate golangci-lint later
+- **Security Scanning**: Can add Trivy scans if needed
+- **Release Automation**: Will add when ready for releases

.github/instructions/go-code-style.instructions.md

@@ -0,0 +1,38 @@
+---
+applyTo: "**/*.go"
+---
+
+# Go Coding Style
+
+## General Guidelines
+
+- Use the Go standard library whenever possible. Only use third-party libraries when necessary.
+- Limit line length to 120 characters.
+- Write code that is easy to test:
+  - Use interfaces to decouple components and improve testability.
+  - Use dependency injection to pass dependencies into functions and methods.
+  - Wrap even basic operations (such as OS functions and file operations) in interfaces to make them easier to mock and test.
+- After each struct definition, verify interface implementation by adding:
+  `var _ InterfaceName = (*StructName)(nil)`
+- Provide a constructor function for each struct, named `NewStructName`.
+  - Place this function immediately after the struct definition and the interface assertion line (if present).
+- Format code for readability:
+  - Vertically align function arguments when there are multiple arguments.
+  - Insert blank lines between logical sections of code.
+  - Do not separate error unwrapping from related code with a blank line; treat it as part of the same section.
+- End all type and function comments with a period, following Go conventions.
+- Pre-allocate collections (such as slices and maps) to their expected size when possible to reduce memory allocations and improve performance.
+
+## Main Tech Stack
+
+- [lipgloss]: Go library for creating visually appealing command-line applications. Used for the installer's CLI.
+- [cobra]: Go library for building command-line applications. Used for the installer's CLI.
+- [viper]: Go library for reading configuration files. Used for the installer's configuration management.
+- [goreleaser]: Go tool for building and releasing Go applications. Used for building and releasing the installer.
+- [gh-actions] (GitHub Actions): CI/CD tool for automating build and release processes. Used for building and releasing the installer.
+
+[lipgloss]: https://github.com/charmbracelet/lipgloss
+[cobra]: https://github.com/spf13/cobra
+[viper]: https://github.com/spf13/viper
+[goreleaser]: https://github.com/goreleaser/goreleaser
+[gh-actions]: https://github.com/features/actions

.github/instructions/go-test-style.instructions.md

@@ -0,0 +1,51 @@
+---
+applyTo: "**/*.go"
+---
+
+# Go Test Style
+
+## General Guidelines
+
+- Place tests in the test package of the package being tested.
+  - For example, if the package is `lib`, the test package should be named `lib_test`.
+- Use the `testify` library for all testing in Go.
+  - Always use the `require` package from `testify` when checking the `error` type.
+- Each test should verify a single behavior or property. Do not test multiple behaviors in a single test.
+- Name tests based on their behavior, using descriptive and natural language.
+  - Example: `Test_CompatibilityConfigCanBeLoadedFromFile` checks if the `CompatibilityConfig` struct can be loaded from a file.
+  - Test names should describe what the test does and what it verifies, not implementation details.
+  - Use the `Test_` prefix for test functions.
+  - If a condition is crucial to the test, include it in the test name.
+    - Example: `Test_CompatibilityConfigCanBeLoadedFromFile_WhenFileExists` indicates that the test checks loading from an existing file.
+    - Separate different conditions with underscores.
+- Use table-driven tests when appropriate. Table-driven tests define a set of inputs and expected outputs in a table, and iterate over the table to run the tests. This pattern makes it easy to add new test cases and keeps the code clean and maintainable.
+
+## Types of Tests
+
+### Unit Tests
+
+- Unit tests verify a single function or method in isolation.
+- Use mocks to isolate the function or method being tested.
+  - Use the [moq](https://github.com/matryer/moq) package to generate mocks.
+
+### Integration Tests
+
+- Integration tests verify the interaction between multiple functions or methods.
+- Integration tests also cover OS-dependent interactions (anything beyond CPU and memory).
+- For every integration test, allow opting out by using `testing.Short()`.
+  - This is useful for running only unit tests in CI/CD pipelines.
+
+## Testing Tech Stack
+
+- [testify]: A Go library for writing tests and assertions.
+- [moq]: A Go library for generating mocks for testing.
+- [mockery]: A Go library for generating mock objects. It is used to generate mock objects in the project.
+
+## Using Mocks
+
+- Use [mockery] to generate mocks for interfaces. Run the command `mockery` (with no arguments) in the root directory of the Go module (for example, the `go-port` directory).
+- In test code, use the generated mocks to test your code. The generated mocks are compatible with the `moq` library, so you can use `moq` features in your tests.
+
+[testify]: https://github.com/stretchr/testify
+[moq]: https://github.com/matryer/moq
+[mockery]: https://github.com/vektra/mockery

.github/prompts/installer-context.prompt.md

@@ -0,0 +1,51 @@
+# Prompt for working on the installer
+
+## General Instructions
+
+- You're an expert in Operating Systems, UNIX shells, and Go.
+- You're passionate about dotfiles.
+- You specialize in configuration management and automation.
+
+## Context
+
+### What is this repository?
+
+This repository is my personal dotfiles repository. It uses [chezmoi][chezmoi] to manage dotfiles
+and configurations across multiple machines. The goal is to have a consistent and easily maintainable setup.  
+It also contains an "installer" to bootstrap the dotfiles on a new machine, as [chezmoi][chezmoi] alone is
+not enough to set up a new machine.
+
+### What is the installer?
+
+Currently, there are two types of installers:
+
+1. **Shell Installer**: A shell script that installs the necessary dependencies and sets up the environment.
+2. **Go Installer**: A Go program that does the same thing as the shell installer but is written in Go.
+
+This is temporary as the goal is to move the shell installer to Go. The shell installer is
+currently the main installer, but the Go installer is being developed to replace it.
+
+### How does the shell installer works?
+
+The shell installer is a 2-step process:
+
+1. Bootstrap script: This script is run first as it is written in POSIX shell and can be run on any
+   platform. It installs the absolute minimum dependencies required to run the main installer,
+   and checks for compatibility. It is located at [`install.sh`](../../install.sh).
+2. Main installer: This is the main installer that installs the necessary dependencies and sets up
+   the environment. It is located at [`install-impl.sh`](../../install-impl.sh).
+   It is written in bash 4.
+
+### What is the goal of the installer?
+
+The goal of the installer is to set up a new machine with the necessary dependencies and configurations
+to run the dotfiles. This includes installing [chezmoi][chezmoi], setting up the environment, and
+configuring the shell. The installer should be easy to use and should work on multiple platforms (Linux, macOS, etc.).
+The installer should also be able to detect the platform and install the necessary dependencies accordingly.
+
+## What should you do?
+
+Analyze the current state of the installer to understand how much of it has been ported to Go.
+Then, ask me what I want to do next.
+
+[chezmoi]: https://chezmoi.io/