Sentri should be developed using a review-first workflow even when only one developer is active.
- Never push directly to
main. - Start non-trivial work from a linked GitHub issue.
- Create a feature branch for every change.
- Keep commits small and logical.
- Push the branch to GitHub.
- Open a pull request that references the issue.
- Review the full diff before merging.
- Merge only after the review notes are addressed.
codex/<feature-name>feature/<feature-name>fix/<issue-name>
Each commit should do one meaningful thing:
- add one document
- extract one module
- introduce one service
- add one test case set
- integrate one feature path
Avoid mixing UI redesign, backend behavior, and infra changes in a single commit unless they are inseparable.
- Use the issue templates for bug reports and feature requests.
- A PR should close or clearly reference one tracked issue unless the change is emergency-only.
- The PR description should call out the exact frontend, backend, or ML worker surface touched.
- If a change is intentionally partial, note the follow-up issue in the PR body.
Before merging a PR, check:
- a linked issue exists for non-trivial work
- architecture impact is documented
- API contracts are explicit
- tests pass
- mobile build still compiles
- no dead demo-only code path was introduced silently
- performance-sensitive reads and renders are considered
- Frontend should prefer feature modules over giant screen files.
- Backend should keep controllers thin and services explicit.
- AI logic should be explainable, deterministic where possible, and upgradeable to model-backed flows later.
- UI/UX changes should preserve a coherent system, not one-off screens.