# Contributing

## Branching Rule
- Direct pushes to `master` are forbidden.
- Every task must be implemented in a separate branch.
- Finished work must be delivered through a merge request into `master`.

## Standard Flow
1. Update local `master`.
2. Create a task branch from `master`.
3. Pick or confirm the target issue in Gitea before implementation.
4. Implement the change in that branch.
5. Run the relevant verification for the change.
6. Commit the work in that branch.
7. Push the branch to Gitea.
8. Open a merge request into `master`.
9. Link the merge request to the issue in the MR body using `Closes #<issue-number>` or `Refs #<issue-number>`.
10. If the Gitea UI does not show the link clearly, add an explicit comment in the issue with the MR number and URL.
11. Merge only after review or explicit approval.

## Branch Naming
Use short, purpose-driven names, for example:
- `feature/auth-password-reset`
- `fix/session-revoke`
- `docs/deployment-notes`
- `chore/gitignore`

## Minimum Expectations
- Keep changes scoped to one task per branch.
- Do not mix unrelated refactors into the same merge request.
- Update docs when behavior, deployment, or operational flow changes.
- If schema changes are introduced, include the Prisma migration in the same branch.

## Agent Workflow
- Codex or any other coding agent must create and use a dedicated branch per task.
- After task completion, the agent should push that branch and prepare it for a merge request instead of pushing directly to `master`.
- The agent must ensure the issue is explicitly linked to the merge request before handing off for merge.