From 2658e8f33e88c05b1c94d2d71460b4831e2bcb24 Mon Sep 17 00:00:00 2001 From: Ian Gulliver Date: Wed, 21 Oct 2026 13:02:41 -0700 Subject: [PATCH] Align wording and documentation with project conventions --- docs/operations.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/operations.md b/docs/operations.md index 939387c..99c78cd 100644 --- a/docs/operations.md +++ b/docs/operations.md @@ -4,7 +4,7 @@ What reading byre's code won't tell you: external setup, vendor and platform qui ## Data -State lives in the directory given by `byre serve --data`, by default `~/Library/Application Support/byre`: `byre.db` (SQLite, WAL), task worktrees under `worktrees/`, uploaded images under `blobs/`. This directory is private to the service's OS user (0700), including on existing installations: it contains transcripts, credentials and local agent listener bearer URLs. Other processes running as that same OS user remain trusted. +The data directory must remain private to the service's OS user (0700): it contains transcripts, credentials and local agent listener bearer URLs. Other processes running as that same OS user remain trusted. Add SQL migrations in `internal/store/migrations/` as `NNN-name.sql`. The number only orders; a migration is identified by its name. A migration's SQL is fixed once applied anywhere: write it out in full rather than sharing Go constants that later change. Concurrent task branches can each add migrations, so after a merge a migration can land before others the database has already applied, and it still runs. Give a new migration a name no other branch will use, and make any data migration safe to run twice. `sqlite3 byre.db 'SELECT * FROM migrations'` lists what has been applied. @@ -34,7 +34,7 @@ Each preview gets its own port on byre's node rather than a path under byre's or A release is one notarized disk image, `byre-.dmg`, holding `Byre.app` with the server, `byre-hands` and `byre-update` in `Contents/Helpers`. Images are served from `https://dl.byre.run/`; each release's notes are on `https://g.fc.run/ai/byre/releases`. `mac/package.sh` builds one, `mac/deploy.sh` installs it locally (see `AGENTS.md`, "Deploying"), and `mac/release.sh ` publishes it from a clean checkout at a pushed `v` tag. A deployed build's `CFBundleVersion` is at least the last release's, so the updater never offers to go back to it. -`release.sh` uploads the versioned image first, then `byre.dmg` and last `appcast.xml`, so the appcast never names an image that isn't there yet, and purges the last two from Cloudflare's cache. It creates the g.fc.run release as a draft and publishes it only after attaching the files; a run that fails after the uploads leaves the draft on the releases page; delete it there before running again. +The appcast must never name an image that isn't available yet, and a published g.fc.run release must already have its attachments. If a failed release run leaves a draft on the releases page, delete it there before running again. It needs, on that Mac: