.opencode/agents/architect.md

@@ -112,3 +112,15 @@ When proposing architecture changes:
 - Hardcoded constants that should be configurable
 - Missing error propagation (silent failures)
 - 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.

.opencode/agents/c-reviewer.md

@@ -85,3 +85,15 @@ For each issue found, report:
 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.
+
+## 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.

.opencode/agents/cmake-expert.md

@@ -190,3 +190,15 @@ Then build with:
 ```bash
 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.

.opencode/agents/code-explainer.md

@@ -131,3 +131,15 @@ When explaining code:
 3. **Highlight non-obvious parts** — why this design, not that
 4. **Reference the source** — `file:line` for key functions
 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.

.opencode/agents/debugger.md

@@ -155,3 +155,15 @@ For each bug found:
 3. **Reproduction** — exact command to trigger
 4. **Fix** — the minimal code change needed
 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.

.opencode/agents/doc-generator.md

@@ -89,3 +89,15 @@ For each public function:
 3. Verify examples actually compile and work
 4. Update README when adding/changing features
 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.

.opencode/agents/integrator.md

@@ -114,20 +114,15 @@ The project uses Gitea Actions. Key jobs:
 ### Adding a New CI Job
 ```yaml
 jobs:
-  sanitizer:
+  new-job:
     runs-on: ubuntu-latest
+    container: gitea.tap-tap.win/taptap/fastsync-ci:v7
     steps:
       - uses: actions/checkout@v4
-      - name: Install dependencies
-        run: sudo apt-get update && sudo apt-get install -y libzstd-dev libssl-dev
-      - name: Build with ASan
+      - name: Build and run
         run: |
-          cmake -B build -S . \
-            -DCMAKE_C_FLAGS="-fsanitize=address -fno-omit-frame-pointer" \
-            -DCMAKE_EXE_LINKER_FLAGS="-fsanitize=address"
-          cmake --build build -j$(nproc)
-      - name: Run tests
-        run: ./build/tests
+          cmake -B build -S . && cmake --build build -j$(nproc)
+          ./build/tests
 ```
 
 ## Verification Checklist
@@ -148,3 +143,15 @@ When designing integration tests:
 4. **Verification** — how to check success
 5. **Cleanup** — how to remove test artifacts
 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.

.opencode/agents/perf-analyst.md

@@ -120,4 +120,16 @@ time ./build/client [args...]
 
 # High precision
 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.
 ```

.opencode/agents/protocol-designer.md

@@ -84,3 +84,15 @@ When designing protocol changes:
 4. **Serialization code** — changes to `protocol.c`, `config.c`, `chunk.c`
 5. **Compatibility notes** — how old clients/servers handle the change
 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.

.opencode/agents/refactorer.md

@@ -153,3 +153,15 @@ Before and after each refactor, note:
 - **Breaking the API** — public headers are contracts; change them carefully
 - **Rewriting** — refactor incrementally, don't rewrite from scratch
 - **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.

.opencode/agents/security-auditor.md

@@ -139,3 +139,15 @@ Medium: <count>
 Low: <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.

.opencode/agents/test-writer.md

@@ -215,3 +215,15 @@ When asked to write tests, produce:
 3. The runner.c modification needed
 4. Verify with a build and test run
 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.

AGENTS.md

@@ -55,3 +55,20 @@ cmake -B build -S . && cmake --build build -j$(nproc)
 ./build/tests                # unit 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.