doc: improve agentic workflow — CI wait, branch strategy, dependency rules for all agents
CI / lint (push) Successful in 8s
CI / sanitizers (address) (push) Successful in 15s
CI / build-and-test (push) Successful in 54s

This commit is contained in:
2026-07-20 14:22:16 +02:00
parent 02ceb6828b
commit d3b0cb9357
13 changed files with 166 additions and 10 deletions
+12
View File
@@ -112,3 +112,15 @@ When proposing architecture changes:
- Hardcoded constants that should be configurable - Hardcoded constants that should be configurable
- Missing error propagation (silent failures) - Missing error propagation (silent failures)
- Thread safety violations when adding new shared state - Thread safety violations when adding new shared state
## CI & Task Execution
When using `tea` (the task execution agent) to run CI or tests, always set a sufficient timeout (e.g., 600000ms) to allow the workflow to finish. After CI completes, check the results yourself — inspect logs if the run failed. Never assume success.
## Branch Strategy
Never push directly to `main`. All changes must be developed on a feature branch and merged via a pull request. Always create a new branch (`git checkout -b <branch-name>`) before making changes, push it, and open a PR with `gh pr create --fill`. Wait for CI to pass before merging.
## Dependency Installation
All dependencies must be installed via the project's custom Docker image (repo-root `Dockerfile`, same image CI uses) — never via ad-hoc host package installs (no `apt-get install` / `pip install` on the host machine). See `AGENTS.md` for details.
+12
View File
@@ -85,3 +85,15 @@ For each issue found, report:
4. **Description** — what's wrong and how to fix it 4. **Description** — what's wrong and how to fix it
If the code is clean, say so explicitly. Be concise — don't pad with fluff. If the code is clean, say so explicitly. Be concise — don't pad with fluff.
## CI & Task Execution
When using `tea` (the task execution agent) to run CI or tests, always set a sufficient timeout (e.g., 600000ms) to allow the workflow to finish. After CI completes, check the results yourself — inspect logs if the run failed. Never assume success.
## Branch Strategy
Never push directly to `main`. All changes must be developed on a feature branch and merged via a pull request. Always create a new branch (`git checkout -b <branch-name>`) before making changes, push it, and open a PR with `gh pr create --fill`. Wait for CI to pass before merging.
## Dependency Installation
All dependencies must be installed via the project's custom Docker image (repo-root `Dockerfile`, same image CI uses) — never via ad-hoc host package installs (no `apt-get install` / `pip install` on the host machine). See `AGENTS.md` for details.
+12
View File
@@ -190,3 +190,15 @@ Then build with:
```bash ```bash
cmake -B build -S . -DENABLE_ASAN=ON cmake -B build -S . -DENABLE_ASAN=ON
``` ```
## CI & Task Execution
When using `tea` (the task execution agent) to run CI or tests, always set a sufficient timeout (e.g., 600000ms) to allow the workflow to finish. After CI completes, check the results yourself — inspect logs if the run failed. Never assume success.
## Branch Strategy
Never push directly to `main`. All changes must be developed on a feature branch and merged via a pull request. Always create a new branch (`git checkout -b <branch-name>`) before making changes, push it, and open a PR with `gh pr create --fill`. Wait for CI to pass before merging.
## Dependency Installation
All dependencies must be installed via the project's custom Docker image (repo-root `Dockerfile`, same image CI uses) — never via ad-hoc host package installs (no `apt-get install` / `pip install` on the host machine). See `AGENTS.md` for details.
+12
View File
@@ -131,3 +131,15 @@ When explaining code:
3. **Highlight non-obvious parts** — why this design, not that 3. **Highlight non-obvious parts** — why this design, not that
4. **Reference the source**`file:line` for key functions 4. **Reference the source**`file:line` for key functions
5. **Connect to the protocol** — how this piece talks to other pieces 5. **Connect to the protocol** — how this piece talks to other pieces
## CI & Task Execution
When using `tea` (the task execution agent) to run CI or tests, always set a sufficient timeout (e.g., 600000ms) to allow the workflow to finish. After CI completes, check the results yourself — inspect logs if the run failed. Never assume success.
## Branch Strategy
Never push directly to `main`. All changes must be developed on a feature branch and merged via a pull request. Always create a new branch (`git checkout -b <branch-name>`) before making changes, push it, and open a PR with `gh pr create --fill`. Wait for CI to pass before merging.
## Dependency Installation
All dependencies must be installed via the project's custom Docker image (repo-root `Dockerfile`, same image CI uses) — never via ad-hoc host package installs (no `apt-get install` / `pip install` on the host machine). See `AGENTS.md` for details.
+12
View File
@@ -155,3 +155,15 @@ For each bug found:
3. **Reproduction** — exact command to trigger 3. **Reproduction** — exact command to trigger
4. **Fix** — the minimal code change needed 4. **Fix** — the minimal code change needed
5. **Verification** — how to confirm the fix works 5. **Verification** — how to confirm the fix works
## CI & Task Execution
When using `tea` (the task execution agent) to run CI or tests, always set a sufficient timeout (e.g., 600000ms) to allow the workflow to finish. After CI completes, check the results yourself — inspect logs if the run failed. Never assume success.
## Branch Strategy
Never push directly to `main`. All changes must be developed on a feature branch and merged via a pull request. Always create a new branch (`git checkout -b <branch-name>`) before making changes, push it, and open a PR with `gh pr create --fill`. Wait for CI to pass before merging.
## Dependency Installation
All dependencies must be installed via the project's custom Docker image (repo-root `Dockerfile`, same image CI uses) — never via ad-hoc host package installs (no `apt-get install` / `pip install` on the host machine). See `AGENTS.md` for details.
+12
View File
@@ -89,3 +89,15 @@ For each public function:
3. Verify examples actually compile and work 3. Verify examples actually compile and work
4. Update README when adding/changing features 4. Update README when adding/changing features
5. Keep protocol docs in sync with code changes 5. Keep protocol docs in sync with code changes
## CI & Task Execution
When using `tea` (the task execution agent) to run CI or tests, always set a sufficient timeout (e.g., 600000ms) to allow the workflow to finish. After CI completes, check the results yourself — inspect logs if the run failed. Never assume success.
## Branch Strategy
Never push directly to `main`. All changes must be developed on a feature branch and merged via a pull request. Always create a new branch (`git checkout -b <branch-name>`) before making changes, push it, and open a PR with `gh pr create --fill`. Wait for CI to pass before merging.
## Dependency Installation
All dependencies must be installed via the project's custom Docker image (repo-root `Dockerfile`, same image CI uses) — never via ad-hoc host package installs (no `apt-get install` / `pip install` on the host machine). See `AGENTS.md` for details.
+17 -10
View File
@@ -114,20 +114,15 @@ The project uses Gitea Actions. Key jobs:
### Adding a New CI Job ### Adding a New CI Job
```yaml ```yaml
jobs: jobs:
sanitizer: new-job:
runs-on: ubuntu-latest runs-on: ubuntu-latest
container: gitea.tap-tap.win/taptap/fastsync-ci:v7
steps: steps:
- uses: actions/checkout@v4 - uses: actions/checkout@v4
- name: Install dependencies - name: Build and run
run: sudo apt-get update && sudo apt-get install -y libzstd-dev libssl-dev
- name: Build with ASan
run: | run: |
cmake -B build -S . \ cmake -B build -S . && cmake --build build -j$(nproc)
-DCMAKE_C_FLAGS="-fsanitize=address -fno-omit-frame-pointer" \ ./build/tests
-DCMAKE_EXE_LINKER_FLAGS="-fsanitize=address"
cmake --build build -j$(nproc)
- name: Run tests
run: ./build/tests
``` ```
## Verification Checklist ## Verification Checklist
@@ -148,3 +143,15 @@ When designing integration tests:
4. **Verification** — how to check success 4. **Verification** — how to check success
5. **Cleanup** — how to remove test artifacts 5. **Cleanup** — how to remove test artifacts
6. **CI integration** — how to add to the workflow 6. **CI integration** — how to add to the workflow
## CI & Task Execution
When using `tea` (the task execution agent) to run CI or tests, always set a sufficient timeout (e.g., 600000ms) to allow the workflow to finish. After CI completes, check the results yourself — inspect logs if the run failed. Never assume success.
## Branch Strategy
Never push directly to `main`. All changes must be developed on a feature branch and merged via a pull request. Always create a new branch (`git checkout -b <branch-name>`) before making changes, push it, and open a PR with `gh pr create --fill`. Wait for CI to pass before merging.
## Dependency Installation
All dependencies must be installed via the project's custom Docker image (repo-root `Dockerfile`, same image CI uses) — never via ad-hoc host package installs (no `apt-get install` / `pip install` on the host machine). See `AGENTS.md` for details.
+12
View File
@@ -120,4 +120,16 @@ time ./build/client [args...]
# High precision # High precision
perf stat -e task-clock ./build/client [args...] perf stat -e task-clock ./build/client [args...]
## CI & Task Execution
When using `tea` (the task execution agent) to run CI or tests, always set a sufficient timeout (e.g., 600000ms) to allow the workflow to finish. After CI completes, check the results yourself — inspect logs if the run failed. Never assume success.
## Branch Strategy
Never push directly to `main`. All changes must be developed on a feature branch and merged via a pull request. Always create a new branch (`git checkout -b <branch-name>`) before making changes, push it, and open a PR with `gh pr create --fill`. Wait for CI to pass before merging.
## Dependency Installation
All dependencies must be installed via the project's custom Docker image (repo-root `Dockerfile`, same image CI uses) — never via ad-hoc host package installs (no `apt-get install` / `pip install` on the host machine). See `AGENTS.md` for details.
``` ```
+12
View File
@@ -84,3 +84,15 @@ When designing protocol changes:
4. **Serialization code** — changes to `protocol.c`, `config.c`, `chunk.c` 4. **Serialization code** — changes to `protocol.c`, `config.c`, `chunk.c`
5. **Compatibility notes** — how old clients/servers handle the change 5. **Compatibility notes** — how old clients/servers handle the change
6. **Testing strategy** — how to verify the protocol change works 6. **Testing strategy** — how to verify the protocol change works
## CI & Task Execution
When using `tea` (the task execution agent) to run CI or tests, always set a sufficient timeout (e.g., 600000ms) to allow the workflow to finish. After CI completes, check the results yourself — inspect logs if the run failed. Never assume success.
## Branch Strategy
Never push directly to `main`. All changes must be developed on a feature branch and merged via a pull request. Always create a new branch (`git checkout -b <branch-name>`) before making changes, push it, and open a PR with `gh pr create --fill`. Wait for CI to pass before merging.
## Dependency Installation
All dependencies must be installed via the project's custom Docker image (repo-root `Dockerfile`, same image CI uses) — never via ad-hoc host package installs (no `apt-get install` / `pip install` on the host machine). See `AGENTS.md` for details.
+12
View File
@@ -153,3 +153,15 @@ Before and after each refactor, note:
- **Breaking the API** — public headers are contracts; change them carefully - **Breaking the API** — public headers are contracts; change them carefully
- **Rewriting** — refactor incrementally, don't rewrite from scratch - **Rewriting** — refactor incrementally, don't rewrite from scratch
- **Ignoring tests** — if tests don't exist for the code you're refactoring, write them first - **Ignoring tests** — if tests don't exist for the code you're refactoring, write them first
## CI & Task Execution
When using `tea` (the task execution agent) to run CI or tests, always set a sufficient timeout (e.g., 600000ms) to allow the workflow to finish. After CI completes, check the results yourself — inspect logs if the run failed. Never assume success.
## Branch Strategy
Never push directly to `main`. All changes must be developed on a feature branch and merged via a pull request. Always create a new branch (`git checkout -b <branch-name>`) before making changes, push it, and open a PR with `gh pr create --fill`. Wait for CI to pass before merging.
## Dependency Installation
All dependencies must be installed via the project's custom Docker image (repo-root `Dockerfile`, same image CI uses) — never via ad-hoc host package installs (no `apt-get install` / `pip install` on the host machine). See `AGENTS.md` for details.
+12
View File
@@ -139,3 +139,15 @@ Medium: <count>
Low: <count> Low: <count>
Informational: <count> Informational: <count>
``` ```
## CI & Task Execution
When using `tea` (the task execution agent) to run CI or tests, always set a sufficient timeout (e.g., 600000ms) to allow the workflow to finish. After CI completes, check the results yourself — inspect logs if the run failed. Never assume success.
## Branch Strategy
Never push directly to `main`. All changes must be developed on a feature branch and merged via a pull request. Always create a new branch (`git checkout -b <branch-name>`) before making changes, push it, and open a PR with `gh pr create --fill`. Wait for CI to pass before merging.
## Dependency Installation
All dependencies must be installed via the project's custom Docker image (repo-root `Dockerfile`, same image CI uses) — never via ad-hoc host package installs (no `apt-get install` / `pip install` on the host machine). See `AGENTS.md` for details.
+12
View File
@@ -215,3 +215,15 @@ When asked to write tests, produce:
3. The runner.c modification needed 3. The runner.c modification needed
4. Verify with a build and test run 4. Verify with a build and test run
5. Suggest fuzzing targets if relevant 5. Suggest fuzzing targets if relevant
## CI & Task Execution
When using `tea` (the task execution agent) to run CI or tests, always set a sufficient timeout (e.g., 600000ms) to allow the workflow to finish. After CI completes, check the results yourself — inspect logs if the run failed. Never assume success.
## Branch Strategy
Never push directly to `main`. All changes must be developed on a feature branch and merged via a pull request. Always create a new branch (`git checkout -b <branch-name>`) before making changes, push it, and open a PR with `gh pr create --fill`. Wait for CI to pass before merging.
## Dependency Installation
All dependencies must be installed via the project's custom Docker image (repo-root `Dockerfile`, same image CI uses) — never via ad-hoc host package installs (no `apt-get install` / `pip install` on the host machine). See `AGENTS.md` for details.
+17
View File
@@ -55,3 +55,20 @@ cmake -B build -S . && cmake --build build -j$(nproc)
./build/tests # unit tests ./build/tests # unit tests
python3 -m pytest tests/ # integration tests python3 -m pytest tests/ # integration tests
``` ```
## CI Workflow — Waiting for Results
When running the CI workflow via `tea` (the task execution agent), always set a sufficient timeout (e.g., 600000ms) to allow CI to finish. After CI completes, check the results yourself — do not assume success. Use `gh run watch` or similar to monitor CI status, then inspect logs on failure.
## Branch Strategy
Never push directly to `main`. All changes must be developed on a feature branch and merged via a pull request. Always create a new branch before making changes:
```bash
git checkout -b <feature-branch-name>
```
After committing changes, push the branch and create a PR:
```bash
git push -u origin <feature-branch-name>
gh pr create --fill
```
Wait for CI to pass on the PR before merging.