sirily/nroxy
1
0
Fork 0
Code Issues 11 Pull Requests 2 Actions Packages Projects Releases Wiki Activity

docs: require explicit issue-to-pr linking in gitea workflow

Browse Source
This commit is contained in:
sirily
2026-03-10 15:47:15 +03:00
parent d49561b396
commit dfcbaf8b43
2 changed files with 13 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
AGENTS.md
View File

@@ -52,5 +52,7 @@ This repository is a TypeScript monorepo for `nproxy`, a crypto-subscription ima
- Treat the remote Gitea repository as the source of truth for task tracking when the user refers to `issues`.
- Before starting implementation, open the relevant Gitea issue and read its full problem statement and acceptance criteria instead of guessing from local notes.
- If the user asks to "continue work" or pick the next task, inspect the open Gitea issues and choose the first one that is logically ready to implement.
- After finishing the task, push the branch and create a Gitea PR linked to the issue, usually with `Closes #<issue-number>` in the PR body.
- After finishing the task, push the branch and create a Gitea PR linked to the issue.
- Every task PR must include an issue reference in the PR body, usually `Closes #<issue-number>` (or `Refs #<issue-number>` when it should not auto-close on merge).
- If the issue-to-PR link is not clearly visible in Gitea, add an explicit comment in the issue with the PR number and URL.
- If Gitea access requires credentials or network escalation, use the configured repository environment and approved escalation flow instead of skipping the issue lookup.

16
CONTRIBUTING.md
View File

@@ -8,12 +8,15 @@
## Standard Flow
1. Update local `master`.
2. Create a task branch from `master`.
3. Implement the change in that branch.
4. Run the relevant verification for the change.
5. Commit the work in that branch.
6. Push the branch to Gitea.
7. Open a merge request into `master`.
8. Merge only after review or explicit approval.
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:
@@ -31,3 +34,4 @@ Use short, purpose-driven names, for example:
## 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.