|
| 1 | +# Contributing Guide |
| 2 | + |
| 3 | +Thank you for your interest in improving AetherEngine. This document outlines the lightweight |
| 4 | +process for contributing during the MVP phase. As the platform matures we will expand and |
| 5 | +formalize governance and engineering policies. |
| 6 | + |
| 7 | +## Principles |
| 8 | + |
| 9 | +1. Security & Reproducibility First – Changes must build deterministically using the pinned |
| 10 | + Rust toolchain and produce no new critical `cargo-deny` violations. |
| 11 | +2. Small, Reviewable Changes – Prefer a sequence of incremental pull requests over a large |
| 12 | + monolith. |
| 13 | +3. Test What You Touch – For any user‑facing logic or new data model, add or extend tests. |
| 14 | +4. Explicit Ownership – Each PR must list at least one reviewer from `@aether/platform-team`. |
| 15 | + |
| 16 | +## Development Quick Start |
| 17 | + |
| 18 | +```bash |
| 19 | +./dev.sh bootstrap # install toolchain & local services |
| 20 | +./dev.sh verify # quick smoke validation |
| 21 | +make test # run workspace tests |
| 22 | +``` |
| 23 | + |
| 24 | +The control plane expects Postgres at the URL printed by `dev.sh bootstrap`. Override with: |
| 25 | + |
| 26 | +```bash |
| 27 | +export DATABASE_URL=postgres://aether:postgres@localhost:5432/aether_dev |
| 28 | +``` |
| 29 | + |
| 30 | +## Branching & Commits |
| 31 | + |
| 32 | +- Default branch: `main` |
| 33 | +- Feature branches: `feat/<short-topic>` (e.g. `feat/deploy-endpoint`) |
| 34 | +- Bugfix branches: `fix/<issue-or-symptom>` |
| 35 | +- Commit messages: Conventional prefix recommended (e.g. `feat: add /deployments POST handler`). |
| 36 | + |
| 37 | +## Pull Request Checklist |
| 38 | + |
| 39 | +Before requesting review ensure: |
| 40 | + |
| 41 | +- [ ] `cargo build --workspace --all-targets` succeeds |
| 42 | +- [ ] `cargo test --workspace` is green |
| 43 | +- [ ] `cargo fmt -- --check` has no diff |
| 44 | +- [ ] `cargo clippy -- -D warnings` is clean (use `allow` attributes sparingly) |
| 45 | +- [ ] `cargo deny check` passes |
| 46 | +- [ ] Added / updated tests & docs for any new behavior |
| 47 | +- [ ] Generated artifacts (e.g. CRD YAML) updated if schema changed (`make crd`) |
| 48 | + |
| 49 | +## SQLx Offline Metadata |
| 50 | + |
| 51 | +We use SQLx offline mode. When you add or modify queries: |
| 52 | + |
| 53 | +```bash |
| 54 | +docker run --rm -p 5433:5432 -e POSTGRES_PASSWORD=postgres postgres:15 & |
| 55 | +# Wait a few seconds for readiness or use pg_isready |
| 56 | +export DATABASE_URL=postgres://postgres:postgres@localhost:5433/postgres |
| 57 | +cargo sqlx migrate run |
| 58 | +cargo sqlx prepare --workspace --check -- --all-features |
| 59 | +``` |
| 60 | + |
| 61 | +Commit the updated `sqlx-data.json` at workspace root if changed. |
| 62 | + |
| 63 | +## CRD Updates |
| 64 | + |
| 65 | +If you change the `AetherApp` Rust definition regenerate the CRD manifest: |
| 66 | + |
| 67 | +```bash |
| 68 | +make crd |
| 69 | +``` |
| 70 | + |
| 71 | +Commit the resulting `k8s/aetherapp-crd.yaml`. |
| 72 | + |
| 73 | +## Coding Conventions |
| 74 | + |
| 75 | +- Use ` anyhow::Result<T>` for fallible public async functions in binaries. |
| 76 | +- Map domain errors with `thiserror` enums where appropriate (avoid stringly typed errors). |
| 77 | +- Keep modules focused; prefer a short file over a megafile. |
| 78 | +- Avoid premature abstraction; duplicate once, abstract the third time. |
| 79 | + |
| 80 | +## Observability |
| 81 | + |
| 82 | +- Use structured logs: `info!(app_id=%id, "deployed")` style. |
| 83 | +- Avoid logging secrets or personally identifiable information. |
| 84 | + |
| 85 | +## License & Ownership |
| 86 | + |
| 87 | +Source code is proprietary (see `LICENSE`). All contributors must have signed the internal |
| 88 | +contributor agreement (handled out-of-band) before merge. |
| 89 | + |
| 90 | +## Reporting Issues |
| 91 | + |
| 92 | +File issues in the repository with a clear description, reproduction steps, and expected vs actual |
| 93 | +behavior. Tag with `bug`, `enhancement`, or `question`. |
| 94 | + |
| 95 | +## Roadmap Alignment |
| 96 | + |
| 97 | +Large changes (schema, public API, multi-component refactors) require a short design proposal |
| 98 | +(1–2 pages, problem statement, options, decision) added under `docs/` and linked in the PR. |
| 99 | + |
| 100 | +--- |
| 101 | +Thank you for helping build AetherEngine! |
0 commit comments