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

fix: hide exact quota values from account response #16

Merged
sirily merged 4 commits from fix/account-quota-contract into master 2026-03-10 15:52:16 +03:00
Conversation 0 Commits 4 Files Changed 7 +13 -7
2 changed files with 13 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Showing only changes of commit dfcbaf8b43 - Show all commits

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`. - 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. - 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. - 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. - 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 ## Standard Flow
1. Update local `master`. 1. Update local `master`.
2. Create a task branch from `master`. 2. Create a task branch from `master`.
3. Implement the change in that branch. 3. Pick or confirm the target issue in Gitea before implementation.
4. Run the relevant verification for the change. 4. Implement the change in that branch.
5. Commit the work in that branch. 5. Run the relevant verification for the change.
6. Push the branch to Gitea. 6. Commit the work in that branch.
7. Open a merge request into `master`. 7. Push the branch to Gitea.
8. Merge only after review or explicit approval. 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 ## Branch Naming
Use short, purpose-driven names, for example: Use short, purpose-driven names, for example:
@@ -31,3 +34,4 @@ Use short, purpose-driven names, for example:
## Agent Workflow ## Agent Workflow
- Codex or any other coding agent must create and use a dedicated branch per task. - 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`. - 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.