feat: support http/https proxy for IMAP #21
@@ -3,16 +3,19 @@
|
||||
## 1. Coding Principles
|
||||
|
||||
### 1.1 Simplicity First
|
||||
|
||||
- No out-of-scope features.
|
||||
- No abstractions for single-use code.
|
||||
- If 50 lines work instead of 200, write 50.
|
||||
|
||||
### 1.2 Surgical Changes
|
||||
|
||||
- Only change lines directly related to the request.
|
||||
- Never refactor adjacent code unless asked.
|
||||
- Remove orphaned imports/variables/functions your changes created.
|
||||
|
||||
### 1.3 Goal-Driven Execution
|
||||
|
||||
- Define success criteria before coding.
|
||||
- Verify each step before moving to the next.
|
||||
|
||||
@@ -83,10 +86,9 @@ All work starts from a Gitea issue. Two phases, each with a dedicated role:
|
||||
|
||||
## 5. Gitea Tools
|
||||
|
||||
- If git remote contains `git.thuanle.me`, ALWAYS use Gitea MCP tools.
|
||||
- Alway use Gitea MCP tools in this project.
|
||||
- Scope: read PR/issue, list comments, post replies, create/edit PRs, reviews.
|
||||
- Use `tea` CLI only as fallback when MCP is unavailable.
|
||||
- Do not use `gh` for Gitea repositories.
|
||||
- Local CLI tools (`git`, `go`, `rg`) are fine for local validation.
|
||||
|
||||
---
|
||||
|
||||
Reference in New Issue
Block a user