# GAME AGENT RULES (coordinator, 29 Oct). Every agent that touches the Unity repo reads this, PORT_BRIEF.md and PORT_ARCH.md first.

- **Repo:** /Volumes/Workspace/Projects/StickFight (git worktrees; `git worktree list`). Remote `farisbasha` (github farisbasha/Stickbash). The remote `origin` is never touched.
- **Base:**
  - The kill work is NOT on v4. The port base is `port-base` = v4-play4 (e35e2350) + tf-movie (ee82bbdb), built by the INTEGRATOR.
  - Until it exists, start from e35e2350 and rebase onto port-base when the integrator announces it.
  - v4 is the only merge target. Only the coordinator merges, by exact hash, after the user's OK. Never use v4-play* or friends* as merge targets.
- **Worktrees and disk:**
  - Make your own worktree under /Volumes/Workspace/Projects/StickFight-<you> on your own branch.
  - Disk is tight (~17 GB free on Workspace, ~10 GB internal). Do NOT copy a Unity Library. Symlink Library from an existing worktree for csc_check only (sparse-worktree practice: see TF_VM.md / tools), and never open that Library in an editor.
  - No Builds/ in your worktree. Builds come from the build train (TOOLS) or the integrator.
  - Check `df -h /Volumes/Workspace` before any large write, and stop and tell the coordinator if it's under 6 GB.
- **Unity:**
  - ONE editor on the whole Mac, through `tools/locked.sh unity -- …`. Players go through `tools/locked.sh player` (2 slots); csc_check holds the csc slot.
  - The online-features session (friends*/v4-online branches, protocol 141) shares these locks, so keep editor time short.
  - Never wrap build_test.sh in locked.sh (it locks itself).
  - Never merge into v4 while build_test runs.
  - The bashatest VM (`tools/vm/vmctl.sh lane up|build|lab|stills`, ssh root@bashatest.howincloud.com) has unity 1 / player 2 / csc 2 slots. Use it for labs and builds when the Mac slot is busy.
- **Git:**
  - `git add <paths>` only. Plain commit messages with no attribution lines.
  - No push (the coordinator pushes), no merge into v4, no rebase of shared branches, no reset --hard / clean / stash drop / force anything, no branch deletes.
- **After any build:** game builds rewrite ProjectSettings/ProjectSettings.asset (the identity). Never `commit -a`; commit by path, and `git restore` ProjectSettings.asset after builds unless the change is intended.
- **Pushed branches:** once the coordinator has pushed your branch, never rebase it again. Bring in newer port-base with a merge commit, so the remote stays fast-forward and no force push is ever needed.
- **Files:**
  - Don't edit files another agent owns (see your brief). Shared engine files (KillCineLab / KillSysLab / KillSysFilm / HUD / Match) belong to their named owner.
  - If you need a change there, write it to /Volumes/Workspace/Scratch/tf-port/REQUESTS.md and tell the coordinator.
- **Machine:**
  - Park if the 5-min load is > ~35 or memory free is < ~25 %: finish the step, release the locks, write your STATE, report.
  - Kill only your own PIDs, never pkill/killall. No sudo. Never print keys/.env.
  - Headless Chrome only (`--headless=new`, private profile, deleted after; never `open`).
  - Delete files only with python on absolute paths.
- **State and reports:**
  - Keep `/Volumes/Workspace/Scratch/<you>/STATE.md` current (done / doing / next / blockers), so you can be parked and resumed at any time.
  - Report to the coordinator at each milestone, with commit hashes, exact commands, numbers and capture paths.
  - Don't claim anything you didn't run. Failing numbers are reported as failing.
- **Never open a visible game window on the Mac (user 29 Oct):** the user uses this Mac. Launch players only headless (-batchmode, the capture tooling, tools/locked.sh player), and only from builds that contain 0e9bd087 (test runs are muted). Never run a player with only -version or other flags; to check a build, read its log / Info.plist instead. Prefer the bashatest VM for player runs.

- **Accounts and usage (csr):** read ~/CSR_FOR_AGENTS.md. In short: read-only `csr status` only; on a 5-hour-limit error stop at a safe point, write STATE and report (the coordinator resumes you); never run cswap or the state-changing csr commands.
- **Killing processes (30 Oct, after a cross-agent kill):** select PIDs only by your own FULL path (your worktree / Scratch dir / VM lane), check `ps -o args= -p <pid>` before every kill, and kill only those. Never select by a bare script name (several agents use the same tool names: vm_capture.sh, thexrun, locked.sh). Never pkill/killall.
- **Remote waiters (30 Oct, THE-X's find):** a `pgrep -f "Unity.*-batchmode"` run through `ssh ... 'bash -c ...'` matches its own remote shell and never sees Unity free (an hour lost). Use the bracket trick: `pgrep -f "[U]nity.*-batchmode"`, `[l]ocked.sh`.
- **Unique script names (30 Oct, second cross-agent kill):** prefix every VM/Mac script you write with your kill key or agent name (e.g. `hw_vm_r3.sh`, `kb_vm_r3.sh`), and select PIDs to kill ONLY by your own full path (`/root/killport/<your-dir>/...`), never by a bare script name pattern.
- **Mac load (30 Oct 23:15, load hit 83-104):** with 16+ agents on the Mac, do frame extraction / ffmpeg / crop sheets / csc checks on the bashatest VM where possible; on the Mac run them `nice -n 15`, one heavy process at a time per agent, and check `uptime` first: if the 1-min load is > 35, wait (sleep-poll) before starting anything heavy.
- **SSH to the VM (31 Oct, "Can't assign requested address" on the Mac):** many agents opening one ssh/scp per call exhaust the Mac's local ports. Reuse one connection: `ssh -o ControlMaster=auto -o ControlPath=/tmp/<prefix>_%r@%h -o ControlPersist=120 ...` (same options for scp/rsync -e), and batch remote commands into one call.
- **VM queue (31 Oct ~10:15):** vm_slot gates page Chromes / players (load5 > 10 parks them; never raise it: the production API runs there). Unity lane builds go through the lane's Unity lock directly (still ONE Unity build at a time on the VM). Batch jobs (QA re-runs, big render sweeps) keep at most ONE job queued at a time so kill builds/captures aren't starved; full sweeps after 18:00.
- **csc checks (31 Oct ~11:25, Mac load 45-60):** a Mac csc_check compiles the whole game (~1 core-minute+). Batch your edits and run csc once per commit, not per edit. When the Mac's 1-min load is > 30, run it on your VM lane instead (`lane csc <lane>`), or wait.
- **Killing a job's children (31 Oct, 3 agents slipped into `pkill -P`):** never `pkill` in any form. To stop your own job's children: `pgrep -P <your verified pid>` to LIST them, check each with `ps -o args= -p <child>` shows your own path, then `kill <child>` one by one (then the parent).
- **Mac renders (31 Oct ~12:45, Mac load peaked 117-235):** headless Chrome renders / ffmpeg side-by-sides on the Mac only when BOTH the 1-min load < 25 and the 5-min load < 30, one per agent, niced; otherwise wait or use the VM. (The coordinator's page autosync now runs WITHOUT the library live probe.)
- **SECOND MAC WORKER (31 Oct ~15:00, M2 GPU):** `/Volumes/Workspace/Scratch/mac2/m2.sh build <branch|hash>` (pushed commits only; warm build ~67 s vs VM 195 s) and `m2.sh cap <name> "<scenario>"` (real-GPU capture, ~35 s vs VM 230-466 s; results under /Volumes/Workspace/Scratch/mac2/runs/<name>). Also status / jobs / follow / fetch / clean. ONE heavy job at a time (it queues); refuses under 10 GB free. Use it FIRST for captures, splits and perf (real GPU numbers); keep the VM for Linux lane builds/labs when the M2 is busy. Page motionQA: /Volumes/Workspace/Scratch/mac2/m2_motionqa.sh <key>. README: /Volumes/Workspace/Scratch/mac2/README.md.
- **ALL THREE MACHINES (USER 31 Oct ~15:10: "use this mac, fida mac, vm evrything, as u like"):** use whichever is free: (1) the M2 worker (m2.sh; fastest captures/builds, real GPU), (2) the VM (lanes), (3) THIS Mac too: Unity builds and headless captures via tools/locked.sh unity / player (ONE editor at a time, shared with the online session; headless only, never a visible window), when the 1-min load is < 30 and memory free >= 30 %. Pick the shortest queue; don't wait an hour on one machine while another is idle.
M2 BUILD PIN (31 Oct 15:58): every M2 capture/perf/lab job names its own build (M2_BUILD=<id>); 'current' moves when another agent builds. Check the build id in each result.
VM QUIET WINDOW (31 Oct, for basha-86's server load test): start NO new VM jobs 19:45-20:15 IST. Use the M2 / this Mac. In general from now: the M2 first, the VM last (basha-86's online labs time out when the VM is loaded). Never leave long lab players on the VM: watch your own and kill stale ones by PID.
VM USE AFTER 20:15 (31 Oct): when the M2 queue has > 4 waiting, non-perf labs (flow, gore, arenas, home captures) may go to the VM lane, max 2 of ours at a time on the VM, niced, never left running. Perf stays M2-exclusive.
ZSH TRAP (31 Oct): in zsh, "$var:c..." / "$var:r..." etc. are history modifiers (zonelab:perf:$q:castle arrived as ...1astle). Write ${var}:castle with braces in any zsh script or command line.
MAC LOAD SHARING (user 31 Oct 21:10): coordinate with basha-86 via /Volumes/Workspace/Scratch/coord/MAC_LOAD.md. Before a heavy Mac job: 1-min load < 25 and mem free > 25 %, else the M2 (Fida's Mac) or the VM. Log START/END lines there. The M2 first, the VM second, this Mac last (max one niced Unity build).
M2 SHARED (31 Oct 21:25): basha-86 also uses the M2 via m2.sh (live_* runs, BuildMac of live heads, no exclusive runs). Expect their jobs in the FIFO; name runs with your lane prefix.
PRIORITY (user 31 Oct 22:40): "prioritize works other than the new animations (do the animation without affecting the speed of work of the others, if all are almost over u can do these animation prioitly)".
- PRIORITY lanes (they get Fida's Mac + this Mac first): INTEGRATOR, ENGINE-3/4, ENGINE-FX, ROTATION, OLDFIX, KILL-9 sabre trigger, MAPS-FIX map look, KILLTEXT, GLOAT-UI.
- LOW-PRIORITY lanes (new animations: the porters, MID-ENGINE mids, ZONE-LOOKS): the VM lane ONLY for bakes/builds/gates (pk_gate --lane vm, pk_bake_batch --lanes vm), max 2 of ours on the VM at once. No M2 jobs and no heavy Mac jobs, except a single exclusive perf run when truly needed (ask the coordinator first). They speed up again when the coordinator says the priority work is nearly done.
