coding-bash-clean-architecturelisted

# Clean Architecture for Bash ## Overview Framework-agnostic, structured Bash architecture optimized for **change**, **testability**, and **clear boundaries**. Inner layers never call outer layer functions directly. Domain stays pure (no I/O, no external commands). **Target:** Bash >=4.3 | `set -euo pipefail` | Pure domain | Tool-agnostic core | No global mutable state in domain ## When to Use - Starting a new bash script/project that needs long-term maintainability - Reviewing existing shell scripts for architecture violations (I/O mixed with logic) - Deciding where a new function belongs (domain vs application vs adapter) - Structuring data flow between CLI input, business logic, and system output - Setting up testing strategy with proper isolation - Refactoring monolithic "god scripts" into clean architecture **When NOT to use:** - One-liner scripts or trivial wrappers (<30 lines) - Scripts that are purely I/O orchestration with no business logic (simple `rsync` wrappers, etc.) - Use SCRIPT mode for single-file scripts (see `script-mode.md`) **Capability check (REVIEW / judgment).** Judging architecture/layer violations (I/O mixed with logic, wrong function placement) is capability-sensitive - a weaker model misjudges it. Run REVIEW mode on a pinned `sonnet` subagent (`opus` for a large or high-stakes codebase); pin the tier per dispatch, never inherit the session model. If you keep it inline and the session is on a lesser tier, offer switch-model-or-continue. See `