2025-12-11 21:50:42 +00:00
|
|
|
# ADR-002: Distribution Strategy
|
|
|
|
|
|
|
|
|
|
## Status
|
2026-01-08 09:55:37 +00:00
|
|
|
|
2025-12-11 21:50:42 +00:00
|
|
|
Accepted
|
|
|
|
|
|
|
|
|
|
## Context
|
2026-01-08 09:55:37 +00:00
|
|
|
|
2025-12-11 21:50:42 +00:00
|
|
|
Provisioning needed a clean distribution strategy that separates user-facing tools from development artifacts. Key challenges included:
|
|
|
|
|
|
|
|
|
|
1. **Development Artifacts Mixed with Production**: Build tools, test files, and development utilities scattered throughout user directories
|
|
|
|
|
2. **Complex Installation Process**: Users had to navigate through development-specific directories and files
|
|
|
|
|
3. **Unclear User Experience**: No clear distinction between what users need versus what developers need
|
|
|
|
|
4. **Configuration Complexity**: Multiple configuration files with unclear precedence and purpose
|
|
|
|
|
5. **Workspace Pollution**: User workspaces contained development-only files and directories
|
|
|
|
|
6. **Path Resolution Issues**: Complex path resolution logic mixing development and production concerns
|
|
|
|
|
|
|
|
|
|
The system required a distribution strategy that provides:
|
2026-01-08 09:55:37 +00:00
|
|
|
|
2025-12-11 21:50:42 +00:00
|
|
|
- Clean user experience without development artifacts
|
|
|
|
|
- Clear separation between user and development tools
|
|
|
|
|
- Simplified configuration management
|
|
|
|
|
- Consistent installation and deployment patterns
|
|
|
|
|
- Maintainable development workflow
|
|
|
|
|
|
|
|
|
|
## Decision
|
2026-01-08 09:55:37 +00:00
|
|
|
|
2025-12-11 21:50:42 +00:00
|
|
|
Implement a **layered distribution strategy** with clear separation between development and user environments:
|
|
|
|
|
|
2026-01-08 09:55:37 +00:00
|
|
|
### Distribution Layers
|
|
|
|
|
|
2025-12-11 21:50:42 +00:00
|
|
|
1. **Core Distribution Layer**: Essential user-facing components
|
|
|
|
|
- Main CLI tools and libraries
|
|
|
|
|
- Configuration templates and defaults
|
|
|
|
|
- Provider implementations
|
|
|
|
|
- Task service definitions
|
|
|
|
|
|
|
|
|
|
2. **Development Layer**: Development-specific tools and artifacts
|
|
|
|
|
- Build scripts and development utilities
|
|
|
|
|
- Test suites and validation tools
|
|
|
|
|
- Development configuration templates
|
|
|
|
|
- Code generation tools
|
|
|
|
|
|
|
|
|
|
3. **Workspace Layer**: User-specific customization and data
|
|
|
|
|
- User configurations and overrides
|
|
|
|
|
- Local state and cache files
|
|
|
|
|
- Custom extensions and plugins
|
|
|
|
|
- User-specific templates and workflows
|
|
|
|
|
|
2026-01-08 09:55:37 +00:00
|
|
|
### Distribution Structure
|
|
|
|
|
|
2026-01-14 01:56:30 +00:00
|
|
|
```
|
2025-12-11 21:50:42 +00:00
|
|
|
# User Distribution
|
|
|
|
|
/usr/local/bin/
|
|
|
|
|
├── provisioning # Main CLI entry point
|
|
|
|
|
└── provisioning-* # Supporting utilities
|
|
|
|
|
|
|
|
|
|
/usr/local/share/provisioning/
|
|
|
|
|
├── core/ # Core libraries and modules
|
|
|
|
|
├── providers/ # Provider implementations
|
|
|
|
|
├── taskservs/ # Task service definitions
|
|
|
|
|
├── templates/ # Configuration templates
|
|
|
|
|
└── config.defaults.toml # System-wide defaults
|
|
|
|
|
|
|
|
|
|
# User Workspace
|
|
|
|
|
~/workspace/provisioning/
|
|
|
|
|
├── config.user.toml # User preferences
|
|
|
|
|
├── infra/ # User infrastructure definitions
|
|
|
|
|
├── extensions/ # User extensions
|
|
|
|
|
└── cache/ # Local cache and state
|
|
|
|
|
|
|
|
|
|
# Development Environment
|
|
|
|
|
<project-root>/
|
|
|
|
|
├── src/ # Source code
|
|
|
|
|
├── scripts/ # Development tools
|
|
|
|
|
├── tests/ # Test suites
|
|
|
|
|
└── tools/ # Build and development utilities
|
2026-01-12 04:42:18 +00:00
|
|
|
```
|
2026-01-08 09:55:37 +00:00
|
|
|
|
|
|
|
|
### Key Distribution Principles
|
2025-12-11 21:50:42 +00:00
|
|
|
|
|
|
|
|
1. **Clean Separation**: Development artifacts never appear in user installations
|
|
|
|
|
2. **Hierarchical Configuration**: Clear precedence from system defaults to user overrides
|
|
|
|
|
3. **Self-Contained User Tools**: Users can work without accessing development directories
|
|
|
|
|
4. **Workspace Isolation**: User data and customizations isolated from system installation
|
|
|
|
|
5. **Consistent Paths**: Predictable path resolution across different installation types
|
|
|
|
|
6. **Version Management**: Clear versioning and upgrade paths for distributed components
|
|
|
|
|
|
|
|
|
|
## Consequences
|
|
|
|
|
|
|
|
|
|
### Positive
|
2026-01-08 09:55:37 +00:00
|
|
|
|
2025-12-11 21:50:42 +00:00
|
|
|
- **Clean User Experience**: Users interact only with production-ready tools and interfaces
|
|
|
|
|
- **Simplified Installation**: Clear installation process without development complexity
|
|
|
|
|
- **Workspace Isolation**: User customizations don't interfere with system installation
|
|
|
|
|
- **Development Efficiency**: Developers can work with full toolset without affecting users
|
|
|
|
|
- **Configuration Clarity**: Clear hierarchy and precedence for configuration settings
|
|
|
|
|
- **Maintainable Updates**: System updates don't affect user customizations
|
|
|
|
|
- **Path Simplicity**: Predictable path resolution without development-specific logic
|
|
|
|
|
- **Security Isolation**: User workspace separated from system components
|
|
|
|
|
|
|
|
|
|
### Negative
|
2026-01-08 09:55:37 +00:00
|
|
|
|
2025-12-11 21:50:42 +00:00
|
|
|
- **Distribution Complexity**: Multiple distribution targets require coordinated build processes
|
|
|
|
|
- **Path Management**: More complex path resolution logic to support multiple layers
|
|
|
|
|
- **Migration Overhead**: Existing users need to migrate to new workspace structure
|
|
|
|
|
- **Documentation Burden**: Need clear documentation for different user types
|
|
|
|
|
- **Testing Complexity**: Must validate distribution across different installation scenarios
|
|
|
|
|
|
|
|
|
|
### Neutral
|
2026-01-08 09:55:37 +00:00
|
|
|
|
2025-12-11 21:50:42 +00:00
|
|
|
- **Development Patterns**: Different patterns for development versus production deployment
|
|
|
|
|
- **Configuration Strategy**: Layer-specific configuration management approaches
|
|
|
|
|
- **Tool Integration**: Different integration patterns for development versus user tools
|
|
|
|
|
|
|
|
|
|
## Alternatives Considered
|
|
|
|
|
|
|
|
|
|
### Alternative 1: Monolithic Distribution
|
2026-01-08 09:55:37 +00:00
|
|
|
|
2025-12-11 21:50:42 +00:00
|
|
|
Ship everything (development and production) in single package.
|
|
|
|
|
**Rejected**: Creates confusing user experience and bloated installations. Mixes development concerns with user needs.
|
|
|
|
|
|
|
|
|
|
### Alternative 2: Container-Only Distribution
|
2026-01-08 09:55:37 +00:00
|
|
|
|
2025-12-11 21:50:42 +00:00
|
|
|
Package entire system as container images only.
|
|
|
|
|
**Rejected**: Limits deployment flexibility and complicates local development workflows. Not suitable for all use cases.
|
|
|
|
|
|
|
|
|
|
### Alternative 3: Source-Only Distribution
|
2026-01-08 09:55:37 +00:00
|
|
|
|
2025-12-11 21:50:42 +00:00
|
|
|
Require users to build from source with development environment.
|
|
|
|
|
**Rejected**: Creates high barrier to entry and mixes user concerns with development complexity.
|
|
|
|
|
|
|
|
|
|
### Alternative 4: Plugin-Based Distribution
|
2026-01-08 09:55:37 +00:00
|
|
|
|
2025-12-11 21:50:42 +00:00
|
|
|
Minimal core with everything else as downloadable plugins.
|
|
|
|
|
**Rejected**: Would fragment essential functionality and complicate initial setup. Network dependency for basic functionality.
|
|
|
|
|
|
|
|
|
|
### Alternative 5: Environment-Based Distribution
|
2026-01-08 09:55:37 +00:00
|
|
|
|
2025-12-11 21:50:42 +00:00
|
|
|
Use environment variables to control what gets installed.
|
|
|
|
|
**Rejected**: Creates complex configuration matrix and potential for inconsistent installations.
|
|
|
|
|
|
|
|
|
|
## Implementation Details
|
|
|
|
|
|
2026-01-08 09:55:37 +00:00
|
|
|
### Distribution Build Process
|
|
|
|
|
|
2025-12-11 21:50:42 +00:00
|
|
|
1. **Core Layer Build**: Extract essential user components from source
|
|
|
|
|
2. **Template Processing**: Generate configuration templates with proper defaults
|
|
|
|
|
3. **Path Resolution**: Generate path resolution logic for different installation types
|
|
|
|
|
4. **Documentation Generation**: Create user-specific documentation excluding development details
|
|
|
|
|
5. **Package Creation**: Build distribution packages for different platforms
|
|
|
|
|
6. **Validation Testing**: Test installations in clean environments
|
|
|
|
|
|
2026-01-08 09:55:37 +00:00
|
|
|
### Configuration Hierarchy
|
|
|
|
|
|
2026-01-14 01:56:30 +00:00
|
|
|
```
|
2025-12-11 21:50:42 +00:00
|
|
|
System Defaults (lowest precedence)
|
|
|
|
|
└── User Configuration
|
|
|
|
|
└── Project Configuration
|
|
|
|
|
└── Infrastructure Configuration
|
|
|
|
|
└── Environment Configuration
|
|
|
|
|
└── Runtime Configuration (highest precedence)
|
2026-01-12 04:42:18 +00:00
|
|
|
```
|
2026-01-08 09:55:37 +00:00
|
|
|
|
|
|
|
|
### Workspace Management
|
2025-12-11 21:50:42 +00:00
|
|
|
|
|
|
|
|
- **Automatic Creation**: User workspace created on first run
|
|
|
|
|
- **Template Initialization**: Workspace populated with configuration templates
|
|
|
|
|
- **Version Tracking**: Workspace tracks compatible system versions
|
|
|
|
|
- **Migration Support**: Automatic migration between workspace versions
|
|
|
|
|
- **Backup Integration**: Workspace backup and restore capabilities
|
|
|
|
|
|
|
|
|
|
## References
|
2026-01-08 09:55:37 +00:00
|
|
|
|
2025-12-11 21:50:42 +00:00
|
|
|
- Project Structure Decision (ADR-001)
|
|
|
|
|
- Workspace Isolation Decision (ADR-003)
|
|
|
|
|
- Configuration System Migration (CLAUDE.md)
|
|
|
|
|
- User Experience Guidelines (Design Principles)
|
2026-01-08 09:55:37 +00:00
|
|
|
- Installation and Deployment Procedures
|