ai/byre
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 6 Wiki Activity

Tell agents to deploy only when asked, and document how

Browse Source
This commit is contained in:
Ian Gulliver
2026-10-15 10:28:36 -07:00
parent a569cf94c7
commit c777409dc1
1 changed files with 15 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files
AGENTS.md
+15 -4
View File
@@ -4,12 +4,23 @@ These are requirements, not preferences. Changing one needs the owner's agreemen
## Workflow
- Deploy before handing off. Any change that affects the running server or the web UI is deployed to the service before you stop and report, so the owner can look at it immediately: `go generate ./web` if web sources changed, then `go install ./cmd/byre && launchctl kickstart -k gui/$(id -u)/run.fc.byre`, always as that one command, never `go install` on its own. Then confirm it came up: the tail of `~/Library/Logs/byre.log`, and `GET /api/admin/status` through the `tailscale serve` URL (`tailscale serve status` shows it). Report what you deployed and what you checked.
- `go install` does not restart the service. If byre restarts after your install without your kickstart, another agent deployed its own branch, and the running binary is theirs, not yours.
- You run inside byre, so the kickstart kills your own turn partway through the command. That is expected, not a reason to skip it. Make the deploy the last action of the turn. You resume with a "byre restarted while you were mid-turn" message; do the checks then, and confirm the service started after your kickstart.
- The restart can cut off the record of the last tool call before the kickstart, or the kickstart itself, so you may resume with no memory of having deployed. Before concluding that another agent restarted byre, compare the service's start time (`started_at` in `/api/admin/status`, or the last `listening` line in the log) with your most recent `go install`: a restart right after your own install is most likely your kickstart.
- Never deploy unless the owner asks for it in the current turn. A finished change is reported undeployed; the owner deploys it, or asks you to. Never run `go install ./cmd/byre` or restart the service on your own initiative, not even to check that a change works.
- `docs/operations.md` describes the layout, data, service and APIs; keep it current with every change.
## Deploying
When asked to deploy, do exactly this, from the worktree root:
1. `go generate ./web`, if anything under `web/src/` or `api/openapi.yaml` changed.
2. `go install ./cmd/byre && launchctl kickstart -k gui/$(id -u)/run.fc.byre`, always as that one command, never `go install` on its own, and always the last action of the turn.
3. When you resume, confirm it came up: read the tail of `~/Library/Logs/byre.log`, and `GET /api/admin/status` through the `tailscale serve` URL (`tailscale serve status` shows it). Report what you deployed and what you checked.
What to expect:
- `go install` does not restart the service. If byre restarts after your install without your kickstart, another agent deployed its own branch, and the running binary is theirs, not yours.
- You run inside byre, so the kickstart kills your own turn partway through the command. That is expected, not a reason to skip it. You resume with a "byre restarted while you were mid-turn" message; do the checks then, and confirm the service started after your kickstart.
- The restart can cut off the record of the last tool call before the kickstart, or the kickstart itself, so you may resume with no memory of having deployed. Before concluding that another agent restarted byre, compare the service's start time (`started_at` in `/api/admin/status`, or the last `listening` line in the log) with your most recent `go install`: a restart right after your own install is most likely your kickstart.
## Web UI layout
- Exactly two panes, side by side, each exactly half the width, at every window size. Never three or more columns, never a sidebar, never a resizable or collapsible split.