asepharyana
55677dd671
- Created solid.md to document the SOLID principles for clean code practices. - Created tdd.md to outline Test Driven Development principles and practices. - Added kana-rust-backend-best-practice.md as a reference guide for building a Rust backend using Axum and SeaORM. - Established push-flow-convention.md to enforce pre-commit and pre-push hooks with versioning rules. - Introduced AGENTS.md to provide guidance on best practices and available commands for Kilo. - Configured kilo.json to include new skills and agents for enhanced functionality. - Added lefthook.yml for managing git hooks to ensure code quality and adherence to conventions.
2.4 KiB
2.4 KiB
name, description
| name | description |
|---|---|
| docs-folder | Route non-hexagonal files to docs/ folder to keep domain architecture clean |
Docs Folder Rule
Any file that does not fit the hexagonal architecture design pattern MUST live in the docs/ folder. The source tree stays clean — only hexagonal-compliant code belongs in src/.
Hexagonal Architecture Recap
src/
├── domain/ # Pure business logic, entities, value objects, ports (interfaces)
├── application/ # Use cases, orchestration, input/output ports
├── infrastructure/ # Adapters — DB, HTTP clients, messaging, external APIs
└── interfaces/ # Controllers, routes, CLI, resolvers (driving adapters)
Only code that fits one of these layers belongs in the source tree.
What goes in docs/
| Item | Why it's not hexagonal |
|---|---|
| Architecture decision records (ADRs) | Documentation, not code |
| API documentation / OpenAPI specs | Reference material |
| Database diagrams / ERDs | Design artifacts |
| Flowcharts / sequence diagrams | Visual documentation |
| Meeting notes / technical decisions | Project context |
| Onboarding guides | People documentation |
| RFC / proposal documents | Decision records |
| Scratch files / experiments | Not production code |
| Third-party integration guides | Reference material |
| Deployment runbooks | Ops documentation |
| Configuration examples / templates | Not domain logic |
| Migration guides / upgrade notes | Process documentation |
Structure
docs/
├── adr/ # Architecture Decision Records
├── api/ # API specs, OpenAPI/Swagger files
├── diagrams/ # ERDs, flowcharts, sequence diagrams
├── guides/ # Onboarding, deployment, migration guides
├── rfcs/ # Proposals and RFCs
└── notes/ # Meeting notes, scratch, experiments
Non-negotiables
- NEVER put documentation files in
src/— they pollute the domain. - NEVER put scratch code, experiments, or spikes in
src/— usedocs/notes/or a separate branch. - NEVER put config examples or templates in
src/— usedocs/or project root. - If a file doesn't implement a port, adapter, use case, or entity — it doesn't belong in
src/. - Keep
docs/organized by category, not by date or author. - README at project root is fine — detailed docs go in
docs/.