vibey-architecturelisted

Onion layers for vibey (domain, application, infrastructure, cli, tui), import-linter, where new code belongs, the workspace tenants, and how to file a sub-doctrine. Use before adding a module under src/ or writing a standing rule.
the-vibey-project/vibey · ★ 2 · AI & Automation · score 71

Install: claude install-skill the-vibey-project/vibey

# vibey architecture Dependencies point inward. `import-linter` enforces this in CI via four contracts: onion-layers, domain-independence, application-independence, and interfaces-declare-only. ``` src/vibey/ ├── domain/ # PURE. stdlib only. No I/O, no async, no third-party. ├── application/ # Protocol ports + use cases. Imports domain + stdlib. ├── infrastructure/ # Adapters. ONLY layer that may import asyncpg, httpx, etc. ├── cli/ # Typer. Calls application via bootstrap. ├── tui/ # Textual. Calls application via bootstrap. └── bootstrap.py # Composition root — the ONE module that sees every layer. ``` ## Where does new code go? 1. **Touches FS, network, clock, database, or an SDK?** → `infrastructure/`, behind a `Protocol` in `application/interfaces/<area>.py` (`azure`, `build`, `design`, `engines`, `gates`, `ledger`, `observability`, `projects`, `queue`, `review`, `system`, `visual`). `application/ports.py` is a compatibility re-export shim of seven names — never add to it. Never `import asyncpg` or vendor SDKs elsewhere. 2. **Pure decision, zero I/O?** → `domain/`. Examples: `phase.py`, `rotation.py`, `noloss.py`, `circuit.py`, `effort.py`. 3. **Orchestration (port → domain → port)?** → `application/`. 4. **Argument parsing / terminal formatting?** → `cli/` or `tui/`. 5. **Wiring concrete implementations to Protocols?** → `bootstrap.py` ONLY. When in doubt, push logic inward. `lint-imports` name