- Delete deprecated CLAUDE.md - Create root-level AGENTS.md for AI assistant guidance - Create SDD constitution in .specify/memory/constitution.md - Align documentation with PARA structure (docs/product/project-brief.md, docs/tech/stack.md, docs/plans/) - Add standardized YAML frontmatter to all documentation files - Update README.md with saTway branding and structure
32 lines
1.1 KiB
Markdown
32 lines
1.1 KiB
Markdown
---
|
|
description: >-
|
|
Decision to use Ansible for managing workstation configuration and lifecycle.
|
|
tags:
|
|
- adr
|
|
- ansible
|
|
- configuration-management
|
|
last_updated: '2026-03-09'
|
|
---
|
|
|
|
# ADR 1: Use Ansible for Workstation Configuration Management
|
|
|
|
## Status
|
|
Accepted
|
|
|
|
## Context
|
|
The mw-pfeddersheim-workstation requires a consistent, reproducible configuration. Manual changes lead to "configuration drift" and make it difficult to replicate the environment on new hardware.
|
|
|
|
## Decision
|
|
We will use **Ansible** as the primary tool for managing system-wide and user-specific configurations.
|
|
|
|
## Rationale
|
|
- **Agents and Push-based**: No agent needs to be installed on the host (other than Python/SSH).
|
|
- **Declarative**: Focuses on state rather than process.
|
|
- **Low Barrier to Entry**: Uses YAML and Jinja2 templates, which are well-understood in the satware AG stack.
|
|
- **Portability**: Roles can be shared across different workstations if needed.
|
|
|
|
## Consequences
|
|
- All persistent changes must be scripted in Ansible before application.
|
|
- `ansible-playbook` becomes the primary entry point for setup.
|
|
- Requires maintaining vault secrets for sensitive configurations.
|