# Deploy report — 2026.08.26.02

**5 of 5 target hosts succeeded.** Two hosts skipped by plan (`officer-dev`, `edge-pertento-bridge`).

Tag `deploy/2026.08.26.02` → `121a77ce`. `package.json` at that commit reads `2026.08.26.02` — tag and
version agree. Every host ended at `121a77ce` exactly, merged by `--ff-only` against the tag rather than
the branch.

Second release under this watcher, and the second the loop has executed. The claim was taken by the
watcher before this agent was spawned; this agent recorded `done` after the rollout.

## The release changed no schema, and that makes the `db:push` reading solid

This release touches five files: two deploy documents, `package.json`, and
`src/workspaces/state/useAuthoredLayout.ts` with its test. **No `schema.ts` changed**, so drizzle's desired
state is byte-identical before and after the merge. Anything `push` wants is pre-existing drift, deductively
rather than by assumption.

Per doctrine, exit 0 was not taken as evidence. Every host was run with `--verbose` to read the statements
push actually wanted, and then queried directly.

**The standing diff from `2026.08.26.01` is unchanged and is present on all five:**

```sql
ALTER TABLE "command_hq_sessions" ALTER COLUMN "reference_paths" SET DEFAULT '{}';
```

`alpha` additionally wants the documented drop-and-re-add of `pk_music_now_playing`. Nothing new appeared on
any host — the set of wanted statements is identical to last night's, host for host.

Verified by query, per host, not inferred:

| Host                         | `command_hq_sessions.reference_paths` | `pk_music_now_playing` | `roles` |
| ---------------------------- | ------------------------------------- | ---------------------- | ------- |
| `alpha`                      | `'{}'::text[]` — correct              | present (`contype=p`)  | 4       |
| `fofos`                      | `'{}'::text[]` — correct              | n/a                    | 4       |
| `production-pertento-bridge` | `'{}'::text[]` — correct              | n/a                    | 4       |
| `deadpool-rezio-bridge`      | `'{}'::text[]` — correct              | n/a                    | 4       |
| `macbookpro`                 | `'{}'::text[]` — correct              | n/a                    | 4       |

Each database is already in the state the schema code asks for. The rollout was not stopped for it: the
plan's stop condition is "if it wants to alter something", and this is drizzle re-emitting a statement
whose effect is already in place. **That stop signal is still spent**, exactly as last night's report said —
worth fixing at the schema code, and it is the one thing here the owner should act on.

No direct SQL was run anywhere. None was authorised and none was needed.

## Per host

Steps in plan order on every host: ff-merge to the tag → `bun db:push` → `bun run plugins:update` →
`pm2 restart officer`. No `bun install` anywhere — the plan forbids it and no dependency changed.
`officer-claude-code` was not restarted anywhere, per the plan.

### `alpha` — OK

- `e9f1760f` → `121a77ce`. Tree clean, no untracked files.
- `db:push` exit 0; standing diff plus `pk_music_now_playing`; database verified correct by query.
- `plugins:update` 14/14 in 55s. That step bounces roughly a dozen sidecars itself (`sidecar: started` per
  plugin) — more moved on this host than the `officer` line below suggests.
- `officer` restarted: `online`, `restart_time` 4 → 5.

### `fofos` — OK

- `a7c9dab2` → `121a77ce`, the short fast-forward the plan predicted: it adds only the version bump and the
  plan file, since the fix itself was hand-applied here at 05:22. Not drift.
- One untracked file, `scripts/chk.ts`. Noted, not a reason to skip — a fast-forward cannot touch it, and
  nobody's work was discarded.
- `db:push` exit 0; standing diff only; verified by query. 43 tables in `public`.
- `plugins:update` 3/3 in 21s (`browser`, `gitea`, `proxy-manager`).
- `officer` restarted: `online`, `restart_time` 31 → 32.
- **This is a host the release actually matters on** — it has the `browser` plugin whose layout names
  `officerdev/chat`.

### `production-pertento-bridge` — OK

- `e9f1760f` → `121a77ce`. Tree clean.
- `db:push` exit 0; standing diff only; verified by query.
- `plugins:update` 1/1 in 4s.
- `officer` restarted: `online`, `restart_time` 9 → 10.

### `deadpool-rezio-bridge` — OK

- Logged in as `br`, per `docs/servers.md`.
- `e9f1760f` → `121a77ce`. Tree clean.
- `db:push` exit 0; standing diff only; verified by query.
- `plugins:update` 2/2 in 7s.
- `officer` restarted: `online`, `restart_time` 15 → 16.

### `macbookpro` — OK, and it was awake

- `e9f1760f` → `121a77ce`. Tree clean.
- `PATH` appended with `/opt/homebrew/bin` for the `bun` steps; `pm2` run as a separate command on the
  interactive shell, so nothing was shadowed.
- `db:push` exit 0; standing diff only; verified by query.
- `plugins:update`: `no plugins installed — nothing to update`. Not a failure.
- `officer` restarted: `online`, `restart_time` 17 → 18.

## Skipped, and why

- **`officer-dev`** — the host this agent runs on. Not pulled, nothing restarted. It already holds this
  code at `121a77ce`. Its working tree carries another session's uncommitted changes
  (`src/servers/hono.ts`, `src/workspaces/hooks/src/useClient.ts`, an untracked
  `src/servers/hono-error-shape.test.ts`) — untouched. **The owner restarts `officer` here deliberately,
  as the last step.**
- **`edge-pertento-bridge`** — skipped on the plan's instruction: 300+ commits behind with no `roles`
  table, its catch-up is a by-hand job, do not contact it. It was not contacted.

  Note the disagreement, because an orchestrator reading the wrong document gets this wrong: `docs/servers.md`
  lists this host in the platforms table as a deploy target again, with an empty "Deliberately skipped"
  section. The **plan** overrides it, and the plan is right — a `db:push` on a host with no `roles` table is
  the exact shape of change this doctrine refuses. `docs/servers.md` is stale on this point.

## What was not verified

**The fix itself was not clicked.** The plan's check is "open `/browser`, hard refresh, confirm it renders
rather than showing 'This screen failed to render'". That is a browser action on a logged-in session, and
this agent has no session on any of these hosts. What is verified is that the code carrying the fix is at
`HEAD` on every target and that `officer` came back `online` on each. **The one-click confirmation is
still owed, on a host with the `browser` plugin — `fofos` or `alpha`.**