sirily
431a60f9c8
Closes #1 - hide exact quota values from GET /api/account - keep only the approximate quota bucket in the public account payload - add a regression test for the public account response contract - document that completed tasks should end with a PR Co-authored-by: sirily <sirily@git.shararam.party> Reviewed-on: #16
1.6 KiB
1.6 KiB
Contributing
Branching Rule
- Direct pushes to
masterare forbidden. - Every task must be implemented in a separate branch.
- Finished work must be delivered through a merge request into
master.
Standard Flow
- Update local
master. - Create a task branch from
master. - Pick or confirm the target issue in Gitea before implementation.
- Implement the change in that branch.
- Run the relevant verification for the change.
- Commit the work in that branch.
- Push the branch to Gitea.
- Open a merge request into
master. - Link the merge request to the issue in the MR body using
Closes #<issue-number>orRefs #<issue-number>. - If the Gitea UI does not show the link clearly, add an explicit comment in the issue with the MR number and URL.
- Merge only after review or explicit approval.
Branch Naming
Use short, purpose-driven names, for example:
feature/auth-password-resetfix/session-revokedocs/deployment-noteschore/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.