|
| 1 | +# Contributing |
| 2 | + |
| 3 | +Thanks. Keep it tight. |
| 4 | + |
| 5 | +## Before You Send Anything |
| 6 | + |
| 7 | +- open or find the issue first |
| 8 | +- keep one branch per issue |
| 9 | +- read the workflow docs in `workflows/` |
| 10 | + |
| 11 | +Use these, not your imagination: |
| 12 | + |
| 13 | +- `workflows/GITHUB-ISSUE.md` |
| 14 | +- `workflows/GITHUB-PR.md` |
| 15 | +- `workflows/GIT-COMMIT.md` |
| 16 | +- `workflows/RELEASE.md` |
| 17 | + |
| 18 | +## Local Checks |
| 19 | + |
| 20 | +Run the obvious stuff before you ask anyone else to look: |
| 21 | + |
| 22 | +```bash |
| 23 | +./deva.sh --help |
| 24 | +./deva.sh --version |
| 25 | +./claude-yolo --help |
| 26 | +./scripts/version-check.sh |
| 27 | +shellcheck deva.sh agents/*.sh docker-entrypoint.sh install.sh scripts/*.sh |
| 28 | +``` |
| 29 | + |
| 30 | +If you change Docker image behavior, auth flows, or release logic, test those paths directly. Do not ship "should work". |
| 31 | + |
| 32 | +## What We Want |
| 33 | + |
| 34 | +- small, focused changes |
| 35 | +- direct docs |
| 36 | +- boring shell scripts that still work tomorrow |
| 37 | +- explicit auth and mount behavior |
| 38 | +- no surprise regressions |
| 39 | + |
| 40 | +## What We Do Not Want |
| 41 | + |
| 42 | +- prompt-engineering fluff in docs |
| 43 | +- magical wrappers around simple shell code |
| 44 | +- untested auth changes |
| 45 | +- random formatting churn |
| 46 | +- force-push chaos on shared branches |
| 47 | + |
| 48 | +## Docs Rules |
| 49 | + |
| 50 | +Update docs when behavior changes: |
| 51 | + |
| 52 | +- `README.md` for user-facing workflow |
| 53 | +- `CHANGELOG.md` for release notes |
| 54 | +- `DEV-LOGS.md` for significant work |
| 55 | +- `SECURITY.md` when the reporting path or threat model changes |
| 56 | + |
| 57 | +## Pull Requests |
| 58 | + |
| 59 | +A good PR does three things: |
| 60 | + |
| 61 | +1. says what changed |
| 62 | +2. says why it changed |
| 63 | +3. says how you tested it |
| 64 | + |
| 65 | +If it touches auth, container boundaries, or release mechanics, include the exact command you ran. |
| 66 | + |
| 67 | +## Releases |
| 68 | + |
| 69 | +Do not freestyle releases. |
| 70 | + |
| 71 | +Follow `workflows/RELEASE.md`. Update version, changelog, and docs together, then tag the release. If the tree is dirty and you do not understand why, stop. |
0 commit comments