yolo/agent-skills
3
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

feat(skills): machine-wide gate for heavy test runs

Browse Source 
Parallel yolo/nightshift/blitz sessions each ran the full suite and OOMed
the box. gate.sh caps concurrency, memory and build parallelism; skills now
run scoped checks in the loop and one gated full run per push.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015YUXS63P1WCdC6bEKWcnAE
This commit is contained in:
naps62
2026-07-27 12:41:03 +00:00
parent c8de8bcb5a
commit 999f759691
6 changed files with 167 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files
skills/linear-common/COMMON.md
+41
View File
@@ -238,6 +238,47 @@ If already in a worktree: stay here. Check out the issue branch if the current b
5. Never amend commits — always create new ones.
6. Keep the tracking issue updated (Linear, Gitea, or GitHub, per `tracker`) if scope changes significantly.
## Local verification budget (shared machine)
Several autonomous sessions (`/yolo`, `/nightshift`, `/work`, `/blitz`) run on one box at once, each with subagents. If every one runs the full suite whenever it feels like it, the machine OOMs and all of them die. If instead everything gets pushed for CI to check, CI is clogged and feedback is slow. So: **scoped checks locally, full suite once per push, heavy commands through the gate.**
### Tiers
| When | Run | How |
|---|---|---|
| Inner loop, after each change | typecheck + lint + tests **for the touched module only** | direct, no gate |
| Once, right before push/PR | the project's `buildCommand` (full suite) | through `gate.sh` |
| Anything else | nothing | let CI do it |
Never run the full suite twice for the same push. Never run it "to be sure" after a green scoped run of the same code.
### The gate
Any command that compiles the whole project or runs the whole suite goes through the machine-wide semaphore:
```bash
<skills-root>/linear-common/scripts/gate.sh -- <buildCommand>
```
It bounds concurrency machine-wide (default `nproc/4` slots), caps the command's memory and CPU via a systemd scope, and pins test/build parallelism env vars (`CARGO_BUILD_JOBS`, `RUST_TEST_THREADS`, `VITEST_MAX_*`, `MAKEFLAGS`, `GOMAXPROCS`, node heap) so the suite doesn't fan out to every core.
- **Exit 75** = no slot or too little free RAM within the wait budget. It did **not** run. That is a normal outcome, not an error: push and let CI cover it, and say so in the commit/PR body. Do not retry in a loop, do not bypass the gate by running the command directly.
- **Exit 137** = killed by the memory cap, NOT a test failure. Do not go hunting for a bug that isn't there. Re-run once with `AGENT_GATE_MEM_MAX=6G` if the suite genuinely needs more.
- `gate.sh --status` shows slots busy and free RAM. Cheap; check it before deciding to run anything heavy.
- If the file isn't executable on this install, prefix with `bash`.
- Knobs (env): `AGENT_GATE_SLOTS`, `AGENT_GATE_WAIT` (default 600s), `AGENT_GATE_MEM_MAX` (3G), `AGENT_GATE_MEM_FLOOR` (2000MB), `AGENT_GATE_JOBS`.
### Subagents
- Subagents **never run the full suite**, ever. They run scoped checks on what they touched. The session that dispatched them runs the full suite once, at the end.
- Cap concurrent subagents at **3** per session, **2** if their tasks build or test. `gate.sh --status` showing no free slots is a signal to dispatch fewer, not to wait.
### Pushing
- One push per finished unit of work. Not per commit, not per milestone.
- Don't push to trigger CI as a substitute for the local scoped checks — that is how CI gets clogged.
- When the gate was skipped (exit 75), the push is doing real verification work: arm the one-shot CI watcher so a red build surfaces.
## Rules
- **Never ask the user** during autonomous work unless you hit a genuine blocker (architectural contradiction, missing credentials, ambiguous requirements that could go very wrong).