clean-architecturelisted

# Clean Architecture ## Overview Use this skill to decide three things during architecture work: 1. Where each responsibility belongs. 2. Which dependencies are allowed. 3. How much structure is justified at the current size. Prefer a clean core: domain rules and use-case orchestration stay separable from real-world effects; effects enter through explicit boundaries; important domain values use semantic types when invalid primitives would cause misuse; and abstractions exist only when they protect testing, substitution, or boundary clarity. Do not add abstractions for speculative future shape. Minimal abstractions are preferred unless an interface, type, boundary, or package protects testing, substitution, dependency direction, or reader clarity today. The four-zone vocabulary is a practical carving, not a natural law: it separates domain meaning, concrete effects, inbound surfaces, and composition. If a repo uses different names, preserve those roles and dependency direction rather than forcing these labels. Treat names as flexible when a repo has established vocabulary, but keep these boundary semantics stable: - `entrypoints` are inbound ways the outside world calls the program: CLI, HTTP, jobs, hooks, commands, routes, handlers, presenters, argument parsing, and wire-format parsing when needed. Inbound surfaces and transport-specific request/response code live here. - `startup` is the composition root: build concrete dependencies, select implementations, and wire