Files

T

pastilhasandClaude Opus 5 0a8fe1c2c8 release 2026.08.23.02

SendOff, and the deploy procedure's own corrections from the last rollout.

Schema change — sendoff_devices and sendoff_senders are new, so bun db:push is a
step. No dependency change; bun.lock is untouched.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-08-23 02:52:30 +00:00

3.1 KiB

Raw Blame History

2026.08.23.02

SendOff — send a file to one of your own machines, or to somebody who has allowed you, and it lands in a real directory in their tree. Plus the deploy procedure's own corrections from the last rollout.

SCHEMA CHANGE. bun db:push is a step. sendoff_devices and sendoff_senders are new. Without the push, /sendoff fails on a missing relation the first time it lists anything.

No dependency change — bun.lock is untouched across deploy/2026.08.23.01..HEAD and package.json moved only its version. Do not run bun install.

What is in it

SendOff. Documents/SendOff/<machine>/ for something you sent yourself, Documents/SendOff/<sender>/ for another account's files. The home is the one that account actually browses — the owner's real login home, a member's managed home — because those are different directories and writing to the wrong one makes a delivery invisible rather than wrong.
Consent belongs to the recipient, one row per sender, absence denies. Not a role grant: the person who decides whether somebody may write into your home is you. A sender who has not been allowed gets the same 404 as a sender naming an account that does not exist, so the endpoint cannot be used to enumerate accounts. The owner bypasses this as a SENDER only.
/sendoff — pick files, pick a target, send, with the consent list on the same screen. No received view: the file browser already is the inbox. A dock tile, gated by the new sendoff permission.
Push on arrival — officer/core:sendoff.landed carries the folder name and a file count, and the catalogue renders "3 file(s) from andre" with a route into Files at that folder. No app build needed; the catalogue syncs.
The deploy procedure deploys the TAG, not master. pull --ff-only follows the branch, so a commit pushed mid-rollout lands on some hosts and not others — which happened on the last release, harmlessly.
edge-pertento-bridge is in a Deliberately skipped section of docs/servers.md. It is down for some days, and the last rollout spent four attempts and a minute apiece discovering that.

Every host

git fetch origin --tags then git merge --ff-only deploy/2026.08.23.02
bun db:push — new this release
bun run plugins:update
pm2 restart officer

officer only. Step 3 restarts each plugin's own sidecar; that is the script's behaviour and belongs in the report rather than being omitted.

macbookpro: append /opt/homebrew/bin to PATH for the bun commands, run pm2 separately.

Hosts to expect trouble from

edge-pertento-bridge — skipped, see docs/servers.md. Name it and move on.
production-pertento-bridge — one release behind, and its known_hosts entries were cleared by the owner on 2026-08-23 after a changed host key. The first connection will pin whatever key it offers. That is expected; it is not a reason to stop, and it is not something to comment on beyond the report.

`officer-dev` — skip it

The rollout runs from here and restarting officer ends the agent performing it. Name it as skipped.

3.1 KiB Raw Blame History