@astrofoundry/pi-astro 0.33.1 → 0.34.0

package/README.md

@@ -80,7 +80,7 @@ pi                # launch; confirm [Extensions] lists astro-subagents, grimoire
 
 **Bundled subagents** (call them as `astro.<name>`):
 - General-purpose: `code-reviewer`, `google-tech-lead`, `spec-writer`, `tester-api`, `tester-ui`, `ui-architect`, `ui-design-system`, `ui-frontend-developer`
-- Specialists (one homelab area each, need the host setup in [specialists/README.md](specialists/README.md)): `arcane` (Arcane container platform, GitOps first), `identity` (Zitadel, Pomerium routes through the homelab repository, certificates), `network` (UniFi reads and firewall policies, FreeRADIUS, Tailscale), `dns` (Technitium resolvers, Cloudflare zones), `edge` (Frontdoor VPS over IAP, nginx SNI allowlist through the homelab repository), `security` (Wazuh, CrowdSec, log archive, read-only), `backup` (vzdump, Restic layers, GCS offsite, restore tests), `proxmox` (guest lifecycle, snapshots, resources; no create or destroy), `inference` (llama.cpp on Nexus, Hermes gateways and upgrades, Europa health), `media` (trendarr: trending titles, Radarr and Sonarr adds, SABnzbd pause)
+- Specialists (one homelab area each, need the host setup in [specialists/README.md](specialists/README.md)): `arcane` (Arcane container platform, GitOps first; sanitized host checks, Mealie and Paperless dumps, and the documented manager upgrade with an Upgrade button on the daily report), `identity` (Zitadel, Pomerium routes through the homelab repository, certificates), `network` (UniFi reads and firewall policies, FreeRADIUS, Tailscale), `dns` (Technitium resolvers, Cloudflare zones), `edge` (Frontdoor VPS over IAP, nginx SNI allowlist through the homelab repository, public route checks), `security` (Wazuh, CrowdSec, log archive, read-only), `backup` (vzdump, Restic layers, GCS offsite, restore tests), `proxmox` (guest lifecycle, snapshots, resources; no create or destroy), `inference` (llama.cpp on Nexus, Hermes gateways and upgrades, Europa health), `media` (trendarr: trending titles, Radarr and Sonarr adds, SABnzbd pause)
 - Release notes: `release-reviewer` (no tools; judges whether an update could break how Cortex uses a tool, for the Cortex Tools Report)
 - Flourish pipeline: `flourish-input-vision` (image to spec), `flourish-input-narrative` (text to spec), `flourish-input-codebase` (HTML to spec), `flourish-architect` (spec to plan), `flourish-template-developer` (plan to SDK template, needs `@flourish/sdk`), `flourish-example-builder` (template to realistic example), `flourish-preview-runner` (multi-breakpoint preview + screenshots, needs `@flourish/sdk`), `flourish-reviewer` (audit)
 

package/agents/arcane.md

@@ -1,6 +1,6 @@
 ---
 name: arcane
-description: Operates the Arcane container platform and its Compose apps through the arcane tool. Project definitions change through GitOps, then the CLI syncs and verifies. Use for container and project status, logs, restarts, deploys, and Compose changes on the Arcane VM.
+description: Operates the Arcane container platform and its Compose apps through the arcane tool. Project definitions change through GitOps, then the CLI syncs and verifies. Use for container and project status, logs, restarts, deploys, Compose changes, host checks, database dumps, and Arcane manager upgrades on the Arcane VM.
 tools: read, arcane, subagent
 skills: arcane
 systemPromptMode: replace
@@ -18,8 +18,9 @@ Rules:
 - Project definitions of GitOps-managed projects (Compose files, `.env` layout, project folders) change only through `git show`, `git write`, `git commit`, `git push`, then the project's server-side sync (`arcane-cli gitops`). Never edit a managed project through `projects update` or `projects workspace`, even though the CLI allows it.
 - Operational actions (restart, logs, stats, redeploy, image pull, prune) go straight through the CLI.
 - Confirm destructive operations (`down`, `delete`, `prune`) are explicitly requested in the task before running them.
-- Updating Arcane itself is a hand-over: do the repository change and the sync, then end with the exact hand-over block from the skill (numbered host steps, digests, rollback). Never run `system upgrade` or `projects upgrade arcane`.
+- Updating Arcane itself is `manager-upgrade <version>` (owner approval), which runs the whole documented procedure and rolls back on failed checks; the owner's Upgrade button on the Arcane Daily Report runs the same. Never run `system upgrade`, `projects upgrade arcane`, or a manual sync of `arcane`, and never hand host commands to the caller.
+- Host evidence (memory, logs, OOM, capacity, storage, audit) comes from `host <command>`, never from guesses; `host db-restore` only fills an empty database and needs approval.
 - For update questions run `update-report` and answer with its table verbatim in a code block; never answer from `projects updates`, which is stored and paginated.
 - Before a major version update, read its notes with `release-notes`, summarise breaking changes and manual steps, then ask for one go. Never ask the caller to read release notes for you.
 - Report facts from the JSON output. Sensitive fields are already removed; never guess at what was removed.
-- Delegate through `subagent` only to another specialist (`astro.identity`, `astro.network`, `astro.dns`, `astro.edge`, `astro.security`, `astro.backup`, `astro.proxmox`, `astro.inference`) and only for that specialist's own area.
+- Delegate through `subagent` only to another specialist (`astro.identity`, `astro.network`, `astro.dns`, `astro.edge` (public route checks), `astro.security`, `astro.backup` (Restic restores), `astro.proxmox`, `astro.inference`, `astro.media`) and only for that specialist's own area.

package/extensions/astro-discord/daily-report.test.ts

@@ -4,7 +4,7 @@ import { join } from "node:path";
 import { afterEach, beforeEach, describe, expect, it } from "vitest";
 import { describeConfig } from "./admin.ts";
 import { validateConfig } from "./config.ts";
-import { displayVersion, failureMessage, formatDailyReport, REPORT_PREFIX } from "./daily-report.ts";
+import { displayVersion, failureMessage, formatDailyReport, MANAGER_BUTTON, managerButton, managerOffer, managerSummary, REPORT_PREFIX } from "./daily-report.ts";
 import { isDue, readReportState, writeReportState, zonedNow } from "./reports.ts";
 
 const settings = { report: "arcane" as const, channelId: "1549873938140499999", time: "06:00", timeZone: "Europe/Madrid" };
@@ -129,3 +129,31 @@ describe("report schedules config", () => {
         expect(errors.join(" ")).toMatch(/dailyReport was replaced by reports/);
     });
 });
+
+describe("Arcane manager upgrade offer", () => {
+    const report = (rows: unknown[]) => ({ checkedAt: "2026-10-19T04:00:00Z", images: 40, privateImages: [], rows });
+
+    it("offers the newer manager release from the arcane row only", () => {
+        expect(managerOffer(report([{ stack: "arcane", service: "arcane", running: "v2.16.1", latest: "v2.17.0", status: "update", action: "edit digest" }]))).toBe("2.17.0");
+        expect(managerOffer(report([{ stack: "arcane", service: "arcane", running: "v2.16.1", latest: "v2.16.1", status: "up-to-date" }]))).toBeNull();
+        expect(managerOffer(report([{ stack: "media", service: "sonarr", running: "4.0.1", latest: "4.0.2", status: "update" }]))).toBeNull();
+        expect(managerOffer(report([{ stack: "arcane", service: "arcane", running: "v2.16.1", latest: "sha256:abc", status: "update" }]))).toBeNull();
+        expect(managerOffer("nope")).toBeNull();
+    });
+
+    it("draws one button that only the offer can press", () => {
+        const offer = managerButton("2.17.0", "offer")[0].components?.[0];
+        expect(offer).toMatchObject({ type: 2, style: 1, label: "Upgrade Arcane to v2.17.0", custom_id: "arcane:manager:2.17.0" });
+        expect(offer?.disabled).toBeUndefined();
+        expect(managerButton("2.17.0", "running")[0].components?.[0].disabled).toBe(true);
+        expect(MANAGER_BUTTON.exec("arcane:manager:2.17.0")?.[1]).toBe("2.17.0");
+        expect(MANAGER_BUTTON.exec("arcane:manager:latest")).toBeNull();
+    });
+
+    it("summarises each outcome of manager-upgrade", () => {
+        expect(managerSummary({ status: "upgraded", from: "2.16.1", to: "2.17.0", digest: `sha256:${"a".repeat(64)}`, commit: "abcdef1234567", stamp: "20261019T060500Z" })).toMatch(/^✅ Arcane v2\.16\.1 → v2\.17\.0 is running/);
+        expect(managerSummary({ status: "rolled back", from: "2.16.1", to: "2.17.0", reason: "version (\"2.16.1\")", stamp: "20261019T060500Z" })).toMatch(/^⚠️ Arcane v2\.17\.0 failed its checks/);
+        expect(managerSummary({ status: "stopped", from: "2.16.1", to: "2.17.0", reason: "sync timeout" })).toMatch(/^❌ The Arcane upgrade to v2\.17\.0 stopped before the restart: sync timeout/);
+        expect(managerSummary({})).toMatch(/unexpected answer/);
+    });
+});

package/extensions/astro-discord/daily-report.ts

@@ -1,3 +1,5 @@
+import type { MessageComponent } from "./rest.ts";
+
 /** Every scheduled report starts with this, so it stands apart from conversations in the same channel. */
 export const REPORT_PREFIX = "Arcane Daily Report:";
 const MESSAGE_LIMIT = 1900;
@@ -63,3 +65,43 @@ export function formatDailyReport(report: unknown, timeZone: string): { content:
 export function failureMessage(): string {
     return `${REPORT_PREFIX} the version check failed today, so there is no update list. The bridge log on Cortex has the reason.`;
 }
+
+/** custom_id of the report's Upgrade Arcane button: `arcane:manager:<x.y.z>`. */
+export const MANAGER_BUTTON = /^arcane:manager:(\d{1,4}\.\d{1,4}\.\d{1,4})$/;
+
+/** The newer Arcane manager release a report offers (`2.17.0`), from the row of stack and service `arcane`, or null. */
+export function managerOffer(report: unknown): string | null {
+    if (!isReport(report)) return null;
+    const row = report.rows.find((r) => r.stack === "arcane" && r.service === "arcane" && (r.status === "update" || r.status === "release"));
+    const m = row ? /^v?(\d{1,4}\.\d{1,4}\.\d{1,4})$/.exec(displayVersion(row.latest)) : null;
+    return m ? m[1] : null;
+}
+
+export type ManagerButtonState = "offer" | "running" | "upgraded" | "failed";
+
+/** The one button under the report; only the offer is clickable. */
+export function managerButton(version: string, state: ManagerButtonState): MessageComponent[] {
+    const label = { offer: `Upgrade Arcane to v${version}`, running: `Upgrading Arcane to v${version}…`, upgraded: `Arcane v${version} is running`, failed: `Upgrade to v${version} did not complete` }[state];
+    const style = { offer: 1, running: 2, upgraded: 3, failed: 4 }[state];
+    return [{ type: 1, components: [{ type: 2, style, label, custom_id: `arcane:manager:${version}`, ...(state === "offer" ? {} : { disabled: true }) }] }];
+}
+
+function short(value: unknown): string {
+    return typeof value === "string" ? value.replace(/^sha256:/, "").slice(0, 12) : "?";
+}
+
+/** The reply after an upgrade, from the wrapper's `manager-upgrade` answer. */
+export function managerSummary(out: Record<string, unknown>): string {
+    const from = typeof out.from === "string" ? `v${out.from}` : "the previous version";
+    const to = typeof out.to === "string" ? `v${out.to}` : "the new version";
+    const reason = typeof out.reason === "string" ? out.reason.slice(0, 400) : "no reason given";
+    const backup = (out.backup as { archive?: unknown; stamp?: unknown } | undefined)?.stamp;
+    if (out.status === "upgraded") {
+        return `✅ Arcane ${from} → ${to} is running (digest ${short(out.digest)}, pin commit ${short(out.commit)}). Every check passed; other containers kept running. Cold backup: /var/backups/arcane-upgrades/${typeof backup === "string" ? backup : String(out.stamp)}.`;
+    }
+    if (out.status === "rolled back") {
+        return `⚠️ Arcane ${to} failed its checks (${reason}). ${from} runs again and the pin was reverted in git. If ${to} migrated the database, the pre-upgrade data is in /var/backups/arcane-upgrades/${String(out.stamp)} and restoring it is a manual step (arcane/AGENTS.md, Upgrade rollback).`;
+    }
+    if (out.status === "stopped") return `❌ The Arcane upgrade to ${to} stopped before the restart: ${reason}. The pin was reverted; ${from} keeps running.`;
+    return `❌ The Arcane upgrade returned an unexpected answer; check the manager with the arcane specialist before retrying.`;
+}

package/extensions/astro-discord/index.ts

@@ -14,7 +14,7 @@ import { CHANNEL_RULES, helpText, needsPrefixText, parseCommand } from "./comman
 import { ACTIVATION_ENV, type ChannelSettings, type DiscordConfig, type ReportName, type ReportSchedule, allowedSpecialists, canUse, channelSpecialists, isOwner, loadConfig, loadToken, reportSchedule, saveConfig } from "./config.ts";
 import { type ConversationState, type ResolvedConversation, forgetStale, loadState, newConversationId, recordAnswer, resolveConversation, saveState, sessionsRoot, startConversation } from "./conversations.ts";
 import { describeImages, downloadImages, type ImageAttachment, imageAttachments } from "./attachments.ts";
-import { failureMessage, formatDailyReport } from "./daily-report.ts";
+import { failureMessage, formatDailyReport, MANAGER_BUTTON, managerButton, managerOffer, managerSummary } from "./daily-report.ts";
 import { GatewayClient } from "./gateway.ts";
 import { type CommandOption, IS_COMPONENTS_V2, KeyedQueue, MEDIA, MEDIA_COMMANDS, type MediaKind, type Outcome, addOutcome, applyOutcome, commandArgs, hasActiveButton, listMessage, mediaAccess, mediaPointer, parseAddButton, parseAddReport, parseMediaList, parseQueueState, queueLine } from "./media.ts";
 import { cancelledApprovalText, interruptedTaskText, readOpenWork, type OpenWork, type StopReason, writeOpenWork } from "./open-work.ts";
@@ -28,6 +28,7 @@ import {
     collectTools,
     type Exec,
     failureText,
+    INSTALLER,
     layoutMessages,
     type LineState,
     messageComponents,
@@ -111,7 +112,7 @@ interface Interaction {
     token: string;
     type: number;
     channel_id?: string;
-    message?: { id: string; components?: MessageComponent[] };
+    message?: { id: string; content?: string; components?: MessageComponent[] };
     data?: { custom_id?: string; component_type?: number; name?: string; options?: CommandOption[] };
     member?: { user?: { id: string } };
     user?: { id: string };
@@ -134,6 +135,8 @@ const PACKAGE_JSON = fileURLToPath(new URL("../../package.json", import.meta.url
 /** Upper bound for one tool update from an Update button; `brew upgrade` of everything can take a while. */
 const UPDATE_TIMEOUT_MS = 30 * 60_000;
 const REVIEWER = "astro.release-reviewer";
+/** Key of a running Arcane manager upgrade among the tool runs, which count as open work. */
+const MANAGER_RUN = "arcane-manager";
 
 interface ActiveTask {
     specialist: string;
@@ -428,9 +431,11 @@ class Bridge {
         }
         log(`arcane report ${date}: running arcane update-report`);
         let message: { content: string; attachment?: string };
+        let offer: string | null = null;
         try {
-            const stdout = await this.runEntry("arcane", "daily-report", ["update-report"], 15 * 60_000);
-            message = formatDailyReport(JSON.parse(stdout), schedule.timeZone);
+            const report: unknown = JSON.parse(await this.runEntry("arcane", "daily-report", ["update-report"], 15 * 60_000));
+            message = formatDailyReport(report, schedule.timeZone);
+            offer = managerOffer(report);
         } catch (err) {
             log(`arcane report ${date}: check failed: ${err instanceof Error ? err.message.slice(0, 500) : String(err)}`);
             message = { content: failureMessage() };
@@ -440,8 +445,9 @@ class Bridge {
         const posted = await this.rest.createMessage(schedule.channelId, {
             content: message.content,
             ...(message.attachment ? { file: { name: `arcane-daily-report-${date}.txt`, content: message.attachment } } : {}),
+            ...(offer ? { components: managerButton(offer, "offer") } : {}),
         });
-        writeReportState("arcane", { date, status: message.content === failureMessage() ? "failed" : "sent", messageId: posted.id });
+        writeReportState("arcane", { date, status: message.content === failureMessage() ? "failed" : "sent", messageId: posted.id, ...(offer ? { managerOffer: offer } : {}) });
         log(`arcane report ${date}: posted ${posted.id}`);
     }
 
@@ -653,6 +659,69 @@ class Bridge {
         if (services.length > 0) writeRestarts(addRestarts(readRestarts(), [...new Set(services)], label, new Date()));
     }
 
+    /** The Arcane Daily Report's Upgrade button: owners only, the offer of the newest report only, one upgrade at a time. */
+    private async onManagerButton(interaction: Interaction, customId: string): Promise<void> {
+        const match = MANAGER_BUTTON.exec(customId);
+        const userId = interaction.member?.user?.id ?? interaction.user?.id ?? "";
+        this.refreshConfig();
+        if (!match) {
+            await this.rest.ephemeralReply(interaction.id, interaction.token, "This button is no longer active.");
+            return;
+        }
+        if (!isOwner(this.config, userId)) {
+            await this.rest.ephemeralReply(interaction.id, interaction.token, "Only owners upgrade Arcane.");
+            return;
+        }
+        if (this.stopping) {
+            await this.rest.ephemeralReply(interaction.id, interaction.token, "The bridge is restarting; try again in a minute.");
+            return;
+        }
+        const state = readReportState("arcane");
+        if (!state || state.messageId !== interaction.message?.id || state.managerOffer !== match[1]) {
+            await this.rest.ephemeralReply(interaction.id, interaction.token, "This offer is outdated; use the newest Arcane Daily Report.");
+            return;
+        }
+        if (this.toolRuns.has(MANAGER_RUN)) {
+            await this.rest.ephemeralReply(interaction.id, interaction.token, "The Arcane upgrade is already running.");
+            return;
+        }
+        await this.rest.deferUpdate(interaction.id, interaction.token);
+        const message = { channelId: interaction.channel_id ?? "", id: interaction.message?.id ?? "", content: interaction.message?.content ?? "" };
+        await this.toolClicks.run(MANAGER_RUN, () => this.runManagerUpgrade(message, match[1], userId)).catch((err) => log(`arcane upgrade failed: ${err instanceof Error ? err.message : String(err)}`));
+    }
+
+    /**
+     * The upgrade runs through the wrapper (arcane/AGENTS.md "Manager upgrades")
+     * and can take longer than an interaction token lives, so the report and the
+     * reply go through the bot's own message routes. Counted as open work, so no
+     * bridge restart lands in the middle.
+     */
+    private async runManagerUpgrade(message: { channelId: string; id: string; content: string }, version: string, userId: string): Promise<void> {
+        await this.rest.editMessage(message.channelId, message.id, message.content, managerButton(version, "running")).catch(() => undefined);
+        this.toolRuns.set(MANAGER_RUN, { channelId: message.channelId, label: `the Arcane manager to v${version}` });
+        this.saveOpenWork();
+        log(`arcane: manager upgrade to ${version} for ${userId}`);
+        let ok = false;
+        let summary: string;
+        try {
+            const out = JSON.parse(await this.runEntry("arcane", `discord-${userId}`, ["manager-upgrade", version], 80 * 60_000)) as Record<string, unknown>;
+            ok = out.status === "upgraded";
+            summary = managerSummary(out);
+            if (ok) {
+                const cli = await this.execTool("/usr/bin/sudo", ["-n", INSTALLER, "arcane-cli", version], { timeoutMs: 10 * 60_000 });
+                summary += cli.code === 0 ? ` arcane-cli ${version} is installed for the specialists.` : ` arcane-cli ${version} was not installed (${cli.stderr.trim().split("\n").pop()?.slice(0, 200) ?? `exit ${cli.code}`}); the Cortex Tools Report offers it.`;
+            }
+        } catch (err) {
+            summary = `❌ The Arcane upgrade to v${version} did not finish: ${(err instanceof Error ? err.message : String(err)).split("\n")[0].slice(0, 300)}. Check the manager with the arcane specialist before retrying.`;
+        } finally {
+            this.toolRuns.delete(MANAGER_RUN);
+            this.saveOpenWork();
+        }
+        await this.rest.editMessage(message.channelId, message.id, message.content, managerButton(version, ok ? "upgraded" : "failed")).catch(() => undefined);
+        await this.rest.createMessage(message.channelId, { content: summary, replyTo: message.id }).catch(() => undefined);
+        log(`arcane: manager upgrade to ${version} ${ok ? "done" : "did not complete"}`);
+    }
+
     private async brewNodeVersion(): Promise<string> {
         return (await this.execTool("/opt/homebrew/bin/node", ["--version"], { timeoutMs: 30_000 })).stdout.trim();
     }
@@ -1040,6 +1109,10 @@ class Bridge {
             await this.onToolsButton(interaction, customId);
             return;
         }
+        if (customId.startsWith("arcane:manager:")) {
+            await this.onManagerButton(interaction, customId);
+            return;
+        }
         const match = /^apr:([0-9a-f-]{36}):(approve|deny)$/.exec(customId);
         if (!match) return;
         const userId = interaction.member?.user?.id ?? interaction.user?.id ?? "";

package/extensions/astro-discord/reports.ts

@@ -7,6 +7,8 @@ export interface ReportState {
     date: string;
     status: "sending" | "sent" | "failed";
     messageId?: string;
+    /** Arcane report only: the manager release its Upgrade button offers, `2.17.0`. */
+    managerOffer?: string;
 }
 
 /** Local date and minutes past midnight in a time zone. */

package/extensions/astro-discord/restarts.ts

@@ -101,9 +101,13 @@ export const ACTIVITY_COMMAND: Record<Exclude<Service, "bridge">, Command> = {
     astrogate: { file: "/opt/homebrew/bin/astrogate", args: ["status"] },
 };
 
-/** The restart for each service; the bridge's own runs detached because it ends this process. */
+/**
+ * The restart for each service; the bridge's own runs detached because it ends this process.
+ * herdr's Homebrew formula dropped its service block in 0.9.x, so its server runs from our own
+ * LaunchAgent `com.astrofoundry.herdr`; `brew services restart herdr` would unload it for good.
+ */
 export function restartCommand(service: Service, uid: number): Command {
-    if (service === "herdr") return { file: "/opt/homebrew/bin/brew", args: ["services", "restart", "herdr"] };
+    if (service === "herdr") return { file: "/bin/launchctl", args: ["kickstart", "-k", `gui/${uid}/com.astrofoundry.herdr`] };
     if (service === "astrogate") return { file: "/bin/launchctl", args: ["kickstart", "-k", `gui/${uid}/com.monadeo.astrogate`] };
     return { file: "/bin/launchctl", args: ["kickstart", "-k", `gui/${uid}/com.astrofoundry.astro-discord`] };
 }

package/extensions/astro-discord/tools-report.test.ts

@@ -337,7 +337,7 @@ describe("service activity", () => {
     });
 
     it("restarts each service through its manager", () => {
-        expect(restartCommand("herdr", 501)).toEqual({ file: "/opt/homebrew/bin/brew", args: ["services", "restart", "herdr"] });
+        expect(restartCommand("herdr", 501)).toEqual({ file: "/bin/launchctl", args: ["kickstart", "-k", "gui/501/com.astrofoundry.herdr"] });
         expect(restartCommand("astrogate", 501).args).toEqual(["kickstart", "-k", "gui/501/com.monadeo.astrogate"]);
         expect(restartCommand("bridge", 501).args).toEqual(["kickstart", "-k", "gui/501/com.astrofoundry.astro-discord"]);
     });

package/extensions/astro-discord/tools-report.ts

@@ -11,7 +11,7 @@ export const TOOLS_PREFIX = "Cortex Tools Report:";
 const BREW = "/opt/homebrew/bin/brew";
 const NPM = "/opt/homebrew/bin/npm";
 const PI = "/opt/homebrew/bin/pi";
-const INSTALLER = "/usr/local/sbin/specialist-install";
+export const INSTALLER = "/usr/local/sbin/specialist-install";
 const PI_PACKAGE = "@earendil-works/pi-coding-agent";
 const PI_ASTRO = "@astrofoundry/pi-astro";
 const TRENDARR = "@astrofoundry/trendarr";

package/extensions/specialist-gate/approvals.test.ts

@@ -21,6 +21,11 @@ describe("approvals", () => {
         expect(isRisky("arcane", ["--json", "projects", "delete", "media"])).toBe(true);
         expect(isRisky("arcane", ["volumes", "remove", "mealie_mealie-pgdata"])).toBe(true);
         expect(isRisky("arcane", ["system", "upgrade"])).toBe(true);
+        expect(isRisky("arcane", ["manager-upgrade", "2.17.0"])).toBe(true);
+        expect(isRisky("arcane", ["host", "db-restore", "mealie", "20261019T120000Z"])).toBe(true);
+        expect(isRisky("arcane", ["host", "radarr-movie", "tt0120737"])).toBe(true);
+        expect(isRisky("arcane", ["host", "db-dump", "mealie"])).toBe(false);
+        expect(isRisky("arcane", ["host", "container-logs", "sonarr", "2026-09-06T12:00:00Z", "2026-09-06T12:15:00Z"])).toBe(false);
         expect(isRisky("edge", ["vps", "reboot", "--confirm", "--help"])).toBe(false);
         expect(isRisky("proxmox", ["guests"])).toBe(false);
         expect(isRisky("proxmox", ["set", "107", "memory=768"])).toBe(true);

package/extensions/specialist-gate/index.ts

@@ -27,6 +27,9 @@ export const RISKY: Readonly<Record<string, readonly RegExp[]>> = {
         /^(images|volumes|networks)\s+(prune|remove|rm|delete)\b/,
         /^system\s+(prune|upgrade)\b/,
         /^gitops\s+delete\b/,
+        // Arcane VM: upgrading or rolling back the manager, filling a database, and reading Radarr's key from its host config.
+        /^manager-(upgrade|rollback)\b/,
+        /^host\s+(db-restore|radarr-movie|radarr-interface)\b/,
     ],
     identity: [/^zitadel\s+(DELETE|POST|PUT|PATCH)\b/, /^dmz\s+(deploy-config|pomerium-restart|render|lego-renew)\b/],
     network: [/^unifi\s+policy-(create|update|delete)\b/],

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@astrofoundry/pi-astro",
-  "version": "0.33.1",
+  "version": "0.34.0",
   "description": "Personal pi customizations (extensions, subagents, skills, prompts, themes) for the pi coding agent.",
   "keywords": [
     "pi-package"

package/skills/arcane/SKILL.md

@@ -56,27 +56,25 @@ Minor and patch updates need no notes unless the caller asks. When `release-note
 
 ## Updating Arcane itself
 
-The `arcane` project is GitOps-managed and pinned by digest (`ghcr.io/getarcaneapp/manager@sha256:...`). The manager cannot recreate its own container, so the update is a hand-over: you do the repository and sync work, then give the caller exact steps for VM 100 and verify afterwards. Never use `["system", "upgrade"]` or `["projects", "upgrade", "arcane"]` for the manager; both bypass the pinned digest in the repository.
-
-Procedure, in this order:
-
-1. Facts: `["version"]` (running version and digest), then `["update-report"]`: the `arcane` row shows the running and latest release and, for an update, `latestDigest`. If the row is not an update, report that and stop.
-2. Repository: `git pull`, `git show arcane/compose.yaml`, `git write arcane/compose.yaml <file with the new digest, nothing else changed>`, `git diff`, `git commit "Update Arcane manager to <version>"`, `git push`.
-3. Sync: `["gitops", "sync", "arcane", "--yes"]`, then `["gitops", "status", "arcane"]` until the last synced commit is yours. This updates `/opt/docker/arcane/compose.yaml` on VM 100; the container keeps running the old image.
-4. Hand over. End your answer with exactly this block, values filled in:
-
-   ```
-   Arcane manager update <old version> -> <new version>
-   Repository: commit <short hash> pushed and synced (digest <new digest, first 12 chars>).
-   Your steps on VM 100 (ssh arcane), expect ~1 minute of Arcane UI/API downtime; other containers keep running:
-     1. cd /opt/docker/arcane && docker compose pull arcane && docker compose up -d arcane
-     2. docker inspect arcane --format "{{.Config.Image}} {{.State.Status}}"   (expect the new digest, running)
-   Then ask me to verify; I will check version, projects, and GitOps status.
-   Rollback if the manager does not come back: git revert <short hash> in the repository (ask me), then on VM 100: docker compose up -d arcane with the previous digest <old digest, first 12 chars>.
-   Last Restic backup of arcane-data: nightly at 03:00; check the date before you start if the change worries you.
-   ```
-
-5. When the caller reports back: `["version"]` must show the new digest, `["projects", "list"]` must show `arcane` running, `["gitops", "status", "arcane"]` must be clean. Report the three facts.
+The `arcane` project is GitOps-managed and pinned by digest (`ghcr.io/getarcaneapp/manager@sha256:...`), and the manager cannot recreate its own container. `["manager-upgrade", "<version>"]` runs the whole procedure of `arcane/AGENTS.md` "Manager upgrades" in one call: it checks that the official image's revision is the release tag's commit, records the deployed Compose file and every container on VM 100, commits and pushes the digest pin, waits for the file-only sync to report success with the committed file, pulls the image, takes a cold backup of `arcane-data` (only the manager stops), starts the new image with `--no-deps --pull never`, and checks digest, version, local UI, federated login, and that no other container restarted. A failed check reverts the pin and puts the previous image and Compose file back; the data stays as it is, and restoring the pre-upgrade data is a manual step. The answer is JSON with `status`: `upgraded`, `rolled back`, or `stopped` (nothing restarted, pin reverted).
+
+The usual trigger is the owner's **Upgrade Arcane** button under the Arcane Daily Report, which runs the same command and installs the matching `arcane-cli` afterwards. Through the tool, `manager-upgrade` needs an owner's approval; run it only when the caller asks for the manager upgrade, after `update-report` shows the `arcane` row as an update and you have summarised its release notes. Never use `["system", "upgrade"]`, `["projects", "upgrade", "arcane"]`, a manual `gitops sync arcane`, or a hand-over of host commands.
+
+`["manager-rollback", "<stamp>"]` (owner approval) puts back the Compose file and image recorded at that stamp when an automatic rollback did not finish; revert the pin in the repository yourself afterwards with the `git` group.
+
+## Arcane VM operations
+
+`["host", "<command>", ...]` runs fixed operations on VM 100 through the key of user `spc-arcane`. The checks print only allowlisted fields; raw logs and journal text never leave the guest. `["host", "--help"]` is the wrapper's help.
+
+- `container-memory <name>`, `container-stats [name...]` (60 s sample), `container-logs <name> <since> <until> [docker|bazarr-file]` (sanitized event extracts, UTC like `2026-09-06T12:15:00Z`, at most one day), `container-oom <name> <since> <until>`, `kernel-oom <since> <until>`.
+- `host-audit` (installed host files and units, compared with `host/` in the repository), `host-capacity`, `host-storage [area]`, `docker-usage`.
+- `service-check grimoire|mealie` (guest-local endpoints), `crawl4ai-info`, `recyclarr-naming`, `arcane-version`, `queue-callback`, `bazarr-providers`, `mealie-api`, `queue-job <uuid>`, `object-stat grimoire <path>`.
+- `radarr-movie <tt…> [command-id]` and `radarr-interface` read Radarr's key from its host config; each needs an owner's approval.
+- `db-list mealie|paperless`, `db-dump mealie|paperless` (gzip pg_dump into `/var/backups/spc-arcane/<stack>/<UTC>`, checked, with row counts), `db-restore <stack> <stamp>` (owner approval): fills an **empty** database from one of those dumps, the app container stopped meanwhile. It refuses a database that holds tables; emptying one is an operator decision. Dumps are never deleted by the tool; `db-list` names those beyond the last three in `over_keep`.
+
+Public routes (Supabase, Grimoire, Mealie URLs) are `astro.edge`'s `route-probe`, run from Cortex.
+
+`["project-status"]` (or with a project name) lists projects with their GitOps sync: commit, state, hook state, without error text. `["deployment", "check"|"wait", "<project>", "--commit", "<sha>", "--container", "NAME=sha256:ID", ...]` compares the sync and each container's project, image ID, state, and health; `wait` polls every 10 s up to `--timeout` (default 600 s). Read `status` in the answer.
 
 ## Output
 

package/skills/edge/SKILL.md

@@ -11,6 +11,10 @@ The Frontdoor VPS (`frontdoor-1337`, GCP `us-east1-c`, Debian 13, public IP `35.
 
 Fetches `https://auth.37pla.net/.well-known/openid-configuration` through the VPS address. `ok: true` means the whole public path works: VPS nginx, WireGuard, DMZ nginx, Pomerium, Zitadel.
 
+## `route-probe [name...]`
+
+HTTP status of the public routes of services on the Arcane VM, from Cortex through public DNS, the way users reach them: no credentials, no redirect followed. Without names it checks all of them: `supabase-auth-settings` (expects 401: it wants an API key), `supabase-jwks`, `supabase-openid`, `supabase-oauth-discovery`, `supabase-studio` (expects a redirect to the Pomerium sign-in), `grimoire-public`, `grimoire-public-health`, `mealie-public` (200). Each row has `httpCode`, `expected`, `ok`, `seconds`. A status says the route answered; it does not prove the application works or that a browser login succeeds. A failing route with a passing `probe` points at that service's route or container; ask `astro.identity` (Pomerium route) or `astro.arcane` (container) for their side.
+
 ## `vps <command>`
 
 | Command | Effect |

package/specialists/AGENTS.md

@@ -56,6 +56,8 @@ Wrappers ship as TypeScript and run under Node 24 type stripping: erasable synta
 - `entry/specialist-install.sh` runs as root, so it runs only `/usr/bin`, `/bin`, `/usr/sbin`, `/sbin` and the Node it installed, never Homebrew or anything else the main user can write; it checks that `/usr/local/libexec/specialist-node` and its parents belong to root and are writable by nobody else. Arguments are checked before the root test (tests exercise that part). Downloads go to a root-only temporary directory and are verified before use: Node against `SHASUMS256.txt` and the LTS flag in `index.json`, npm tarballs against the registry's `sha512` integrity, arcane-cli against the release's checksums file. Inside `/Users/specialist` it works only as `specialist` (`sudo -u specialist -H`), from a staging directory root hands over, so a link the specialist plants cannot redirect a root write. Each component switches by rename after a check (every installed wrapper's `--help`, `--version` of the new binary) and restores the previous copy when the check fails. Older versions are refused; `rollback` swaps current and previous. Homebrew's `bw` and `jq` (provision) and `gcloud` (edge) still run as `specialist`; that is a separate issue.
 - `main()` waits for stdout and stderr to flush before `process.exit`: on a pipe, exiting right after a write drops everything past the 64 KiB buffer, which cut large answers such as `projects list --all` until 2026-09-25 (`lib/flush.test.ts`).
 - `arcane update-report [--all]` is `lib/image-updates.ts` over `lib/registry.ts`: a fresh `images updates check --all`, then `projects list --all` for the stack and service of each image reference, then the registries' tag lists and manifest digests (anonymous bearer tokens from each registry's challenge; digests by HEAD, which Docker Hub does not count as a pull; lscr.io is read from ghcr.io). A floating or major-series tag is resolved to the release tag whose digest matches the running and the latest build, searching the newest tags of the three commonest release shapes; a fixed tag is compared with the newest tag of the same shape; a digest pin with the newest release. Checks older than one minute before the run count as stale and show as unknown. Private images (anonymous access refused with 401 or 403) are excluded from rows, counts, and table, listed in `privateImages`, and counted in the summary line. The table is fixed-width text for a code block, because Discord renders no Markdown tables.
+- `arcane host <command>` runs over the forced-command key of user `spc-arcane` on VM 100. `HOST_COMMANDS` in `lib/arcane-host.ts` must list exactly the operations of `entry/remote/spc-arcane-op.py` (a test compares them); the tracked copies live in the arcane repository's `host/` (`spc-arcane-host-entry`, `spc-arcane-op`, `spc-arcane-sudoers`, `spc-arcane-install.sh`) with the probes in `scripts/arcane_ops/`. The entry only splits words (letters, digits, space, `._:/+-`) and hands them to `sudo -n /usr/local/sbin/spc-arcane-op`, the one command its sudoers line allows; the op checks the name and every argument and runs the reviewed arcane-ops probes, which print only allowlisted fields. Manager steps (`manager-*`) are internal to `manager-upgrade`/`manager-rollback` and refused through `host`. Nothing on the host deletes data: a manager rollback restores the image and Compose file, not the data volume (R3 stays manual), `db-restore` only fills an empty database, and dumps are never pruned by the tool. `host-audit` compares the host's hashes with `host/<name>` of the `arcane-gitops` checkout after a pull.
+- `arcane manager-upgrade <version>` (`lib/arcane-manager.ts`) follows arcane/AGENTS.md "Manager upgrades": the official image's revision label must equal the release tag's commit (GitHub API), `manager-prepare` records `compose.before.yaml` and every container before the pin commit, the pin goes through the `arcane-gitops` checkout (`git` is exported from `lib/repo.ts` for this), the wait polls `gitops list` and the deployed Compose hash every 30 s for up to 30 minutes, then pull, cold backup, `up -d --no-deps --pull never`, and checks. Any failure before the restart reverts the pin (`stopped`); a failed check after it reverts the pin and runs `manager-rollback` (`rolled back`). The answer always exits 0 with `status`, so the bridge and the agent both see it.
 - `media` runs trendarr unchanged: `trendarrCli` in `media.json` is its `dist/cli.js`, started with `process.execPath` because sudo's PATH has no node. Each call gets `HOME` set to a fresh `0700` directory under `~/.specialists/work/media/` that holds only `.trendarr/config.json` (`0600`, trendarr's own schema, built from the note fields and `media.json`) and is removed in `finally`; trendarr reads no environment variables and has no config flag, and Node's `os.homedir()` follows `$HOME` on POSIX. Every call passes `--json`; `init` is refused. An add prints trendarr's per-ID `results` and exits 0 even when trendarr exits 1 for a failed ID, because the gate shows only stderr on failure; other failures carry trendarr's stderr without its `warning:` lines, which go into the JSON as `warnings`. The bridge's slash commands and Add buttons call the same wrapper through the entry point (`extensions/astro-discord/media.ts`).
 - `arcane release-notes <stack>[/<service>]` is `lib/releases.ts`: a single-image check and `resolveRef` give the running and latest versions, `HttpRegistry.labels` reads `org.opencontainers.image.source` from the latest image (index to linux/amd64 manifest to config blob), and the anonymous GitHub releases API (60 requests an hour, up to 3 pages of 100) gives the releases in between, oldest first. `condenseNotes` keeps each release under 12,000 characters by section priority; `capTotal` drops the oldest releases past 40,000 characters in total.
 

package/specialists/README.md

@@ -4,11 +4,11 @@ A specialist is a Pi subagent that is the only way to operate one area of the ho
 
 | Agent | Area | What it can do |
 |---|---|---|
-| `astro.arcane` | Arcane container platform (VM 100) and its GitOps repository | Every `arcane-cli` operation except its own `config`, `auth`, `self-update`; `update-report` (fresh check of every stack with running and latest release versions); `release-notes <stack>/<service>` (GitHub notes between the two versions); Compose changes of GitOps-managed projects through `git show|write|commit|push`, then `arcane-cli gitops` sync |
+| `astro.arcane` | Arcane container platform (VM 100) and its GitOps repository | Every `arcane-cli` operation except its own `config`, `auth`, `self-update`; `update-report` (fresh check of every stack with running and latest release versions); `release-notes <stack>/<service>` (GitHub notes between the two versions); `project-status`, `deployment check|wait`; `manager-upgrade <version>` and `manager-rollback <stamp>` (the documented manager upgrade, owner approval); `host <command>`: sanitized host checks (memory, stats, logs, OOM, kernel OOM, audit, capacity, storage, Docker usage, service and queue checks) and `db-list|db-dump|db-restore` for Mealie and Paperless through user `spc-arcane` on VM 100; Compose changes of GitOps-managed projects through `git show|write|commit|push`, then `arcane-cli gitops` sync |
 | `astro.identity` | Zitadel; Pomerium, nginx, lego on VM 104; `02-pulsar-proxmox/dmz/` in the homelab repository | Any Zitadel API call (v2, management, admin, auth) with responses redacted; `dmz status|journal|config-template|render|pomerium-restart|nginx-reload|lego-renew|deploy-config`; `git` on the homelab checkout, writes limited to `02-pulsar-proxmox/dmz/` |
 | `astro.network` | UniFi, FreeRADIUS (LXC 108), Tailscale (LXC 105) | Read UniFi sites, devices, clients, networks, zones, firewall policies, WANs; create, update, delete firewall policies; RADIUS and Tailscale checks on Pulsar |
 | `astro.dns` | Technitium primary (Synapse) and secondary (LXC 107); Cloudflare zones `37pla.net`, `monadeo.com` | Read zones and records on both resolvers, resolve, stats; create and delete zones, add, update, delete records on the primary; Cloudflare zones and record add, update, delete |
-| `astro.edge` | Frontdoor VPS (`frontdoor-1337`) over an IAP tunnel; `00-frontdoor-vps/` in the homelab repository | `probe` the public path; `vps status|nginx-conf|nginx-test|journal|wg|bouncer|updates|package|changelog|auto-upgrades|deploy-nginx|reboot --confirm`; `git` on the homelab checkout, writes limited to `00-frontdoor-vps/` |
+| `astro.edge` | Frontdoor VPS (`frontdoor-1337`) over an IAP tunnel; `00-frontdoor-vps/` in the homelab repository | `probe` the public path; `route-probe` (status of the Supabase, Grimoire, and Mealie public routes from Cortex); `vps status|nginx-conf|nginx-test|journal|wg|bouncer|updates|package|changelog|auto-upgrades|deploy-nginx|reboot --confirm`; `git` on the homelab checkout, writes limited to `00-frontdoor-vps/` |
 | `astro.security` | Wazuh, CrowdSec, rsyslog archive on VM 106 | Read-only: `status`, `attention`, `agents`, `alerts`, `decisions`, `bouncers`, `metrics`, `wazuh-alerts`, `wazuh-vulns`, `wazuh-log`, `remote-hosts`, `remote-log`, `journal` |
 | `astro.backup` | vzdump, the shared Restic repository (Pulsar host config, Arcane app backups), GCS offsite from LXC 102 | Status, journals, and manual runs of every layer; `restic-snapshots|stats|ls`, `restic-restore` into `/var/tmp/spc-restore` on Pulsar, `restore-clean` |
 | `astro.proxmox` | Proxmox VE on Pulsar | API token: `guests`, `guest`, `get <path>`, `tasks`; `start`, `shutdown|reboot|stop --confirm`; snapshots create, delete, rollback; `set` of CPU, memory, options, network. Pulsar key: `host-status`, `host-journal`, `updates`, `guest-exec <vmid> <status|journal|df|updates>` |
@@ -33,7 +33,7 @@ Limits: `network` writes only firewall policies on UniFi. `security` is read-onl
 Host: Cortex (macOS on Apple silicon; Homebrew `bw`, `jq`, `gcloud-cli` with `python@3.14`, git; the specialists' Node and trendarr come from `specialist-install`). Steps 1 to 3 are one-time on the services; 4 to 8 are per host.
 
 1. **Vaultwarden.** Account `specialists@monadeo.com` with **Can view** on collection `specialists` in organization `homelab`. Secure Notes with Hidden fields (`_B64` fields hold `base64 -i <keyfile> | tr -d '\n'`):
-   - `arcane`: `ZITADEL_KEY_JSON`, `GITOPS_DEPLOY_KEY_B64`, `ZITADEL_USER_ID` (plain).
+   - `arcane`: `ZITADEL_KEY_JSON`, `GITOPS_DEPLOY_KEY_B64`, `ZITADEL_USER_ID` (plain), `SSH_KEY_ARCANE_HOST_B64` (user `spc-arcane` on VM 100, for `host`, `manager-*`), and optionally `MEALIE_API_KEY` (only `host mealie-api` reads it).
    - `identity`: `ZITADEL_PAT`, `SSH_KEY_DMZ_B64`, `HOMELAB_DEPLOY_KEY_B64`.
    - `network`: `UNIFI_API_KEY`, `SSH_KEY_PULSAR_B64`.
    - `dns`: `TECHNITIUM_TOKEN`, `TECHNITIUM2_TOKEN` (Technitium API tokens of the primary and the secondary), `CLOUDFLARE_TOKEN`, `CLOUDFLARE_ACCOUNT_ID`.
@@ -109,13 +109,14 @@ Host: Cortex (macOS on Apple silicon; Homebrew `bw`, `jq`, `gcloud-cli` with `py
    - Frontdoor VPS: `spc-edge-frontdoor-install.sh` creates user `spc-edge` (group `systemd-journal`), installs `spc-edge-frontdoor-entry.sh` and the sudoers file `spc-edge-frontdoor-sudoers`, and writes `authorized_keys`. Copy the three files and the public key to `/tmp` with `gcloud compute scp --tunnel-through-iap`, then run it as root.
    - Pulsar, root, three more keys: `spc-backup-pulsar-entry.sh`, `spc-proxmox-pulsar-entry.sh`, `spc-inference-pulsar-entry.sh` (tracked in `02-pulsar-proxmox/pulsar/system/`).
    - VM 100, user `arcane`: `spc-backup-arcane-entry.sh` (tracked as `host/spc-backup-arcane-entry` in the `astronaute77/arcane` repository, next to the host backup scripts).
+   - VM 100, user `spc-arcane` (no docker group): `spc-arcane-host-entry.sh` hands each command to the root-owned `spc-arcane-op.py` (installed as `/usr/local/sbin/spc-arcane-op`), the only command `spc-arcane-sudoers` allows; it runs the reviewed arcane-ops probes from `/usr/local/lib/spc-arcane` and the fixed manager and database steps. `spc-arcane-install.sh` creates the user and installs all of it from `/tmp/spc-arcane`; the files are tracked under `host/` in the arcane repository, the probes under `scripts/arcane_ops/`. Add `"hostAddress": "10.0.40.30", "hostUser": "spc-arcane"` to `arcane.json`; other arcane commands do not read them.
    - Nexus, user `nexus`: `spc-inference-nexus-entry.sh` as `/usr/local/sbin/spc-inference-nexus-entry` (tracked in `04-nexus-macstudio/system/`).
    - LXC 101, user `hermes`: `spc-inference-hermes-entry.sh` (tracked in `02-pulsar-proxmox/hermes/system/`).
 8. **Pi**, as the main user: `~/.pi/agent/specialists.json` (below) and the specialist blocks in `~/.pi/agent/security-guard.json` (`specialist-cli`, `arcane-cli`, `-u specialist` in `operations`; `/Users/specialist/**` in `reads` and `writes`; keep the default rules next to them).
    ```json
    { "entry": "/usr/local/bin/specialist-cli", "user": "specialist",
      "specialists": [
-       { "agent": "astro.arcane", "tool": "arcane", "service": "arcane", "timeoutMs": 300000 },
+       { "agent": "astro.arcane", "tool": "arcane", "service": "arcane", "timeoutMs": 5400000 },
        { "agent": "astro.identity", "tool": "identity", "service": "identity", "timeoutMs": 120000 },
        { "agent": "astro.network", "tool": "network", "service": "network", "timeoutMs": 120000 },
        { "agent": "astro.dns", "tool": "dns", "service": "dns", "timeoutMs": 60000 },
@@ -135,8 +136,9 @@ The `astro-discord` extension gives Discord users access to the specialists from
 
 - Channels are configured one by one (`channels.<id>`): `trigger` is `always` (every message that names a specialist counts) or `mention` (only messages that start with `@Cortex` or reply to the bot); `specialists` is `*` or a list. A channel with one specialist needs no prefix: every message there is a task for it. In a channel with several, `dns list the zones` names the specialist; an addressed message without a name gets a reply asking for one. Threads inherit their parent channel's entry; unlisted channels are ignored. The bot replies at once with "<specialist> is working on your task" and shows the typing indicator until the answer replaces that reply. Reactions on your message: ⏳ running, 🔒 waiting for an owner's approval, ✅ done, ❌ failed. `help` shows the specialists you may use in that channel and the commands (`status` lists running tasks; owners in the admin channel also see the `config` commands). Each channel and specialist has one conversation: a reply to the bot's answer, or another task for that specialist within 30 minutes, continues it with everything the specialist saw before; otherwise a new one starts, and a task beginning with `new` forces that. Replied-to and forwarded messages (text, embeds, attachment names) travel with the task, so "check this" on a forwarded alert works. Image attachments on the message or on what it quotes (up to 4, 8 MiB each) are downloaded and passed to the specialist, which sees them; other file types are named only. Sessions live under `~/.config/astro-discord/sessions/<specialist>/` and are deleted after 7 days. Long answers arrive as a `.md` attachment. When the bridge restarts, open approval requests are marked cancelled and running tasks interrupted in Discord; ask again. Scheduled reports are a list in the config, one entry per report: `"reports": [{ "report": "arcane", "channelId": "<id>", "time": "06:00", "timeZone": "Europe/Madrid" }, { "report": "tools", "channelId": "<admin channel id>", "time": "06:00", "timeZone": "Europe/Madrid" }]` (the earlier single `dailyReport` key is refused; move it into the list). The Arcane report posts an "Arcane Daily Report:" message every morning: each service with an update as current to target version, from a fresh `update-report`; replying to it asks the arcane specialist with the report as context. The tools report posts "Cortex Tools Report:": every tool on Cortex with a newer version (Homebrew packages installed on request and casks, Pi, pi-astro, and through `specialist-install` the wrappers, arcane-cli at the Arcane server's version, trendarr, and the specialist Node at the latest LTS), a release-notes verdict from `astro.release-reviewer` for the tools the specialists build on, an Update button per line, and one Upgrade everything for Homebrew. Only owners can press them; nothing is installed otherwise. After an update that needs it, the bridge, herdr, or Astrogate restarts as soon as nothing runs on it; after a day of waiting, a Restart now button appears. The bridge calls `sudo -n /usr/local/sbin/specialist-install` through the sudoers rule from step 4.
 - Media: where the `media` specialist is present (`config channel <#channel> always media`), `/trending [type] [min_rating] [count]`, `/search <title> [type]`, and `/downloads <status|pause|resume|unpause>` run the wrapper without a model. Lists arrive as two messages, Movies and Series, each title with a button beside it: **Add** adds it at once and turns into Added, In library, or Not found (Retry after a failure); a greyed-out In library or No IMDb ID button needs nothing. Notes such as "downloads are paused" go only to the user who clicked. Owners and `access.media` users may use them; anyone else gets a refusal only they see, and in a channel without `media` the bot names the channels that have it. Plain messages in the channel still go to the agent, for requests by name ("add the new Dune"). At startup the bridge sets the three commands as the application's global commands (servers only).
+- Arcane manager: when the morning Arcane Daily Report shows a newer manager release, the message carries an **Upgrade Arcane to vX** button. Only an owner's click on the newest report runs `arcane manager-upgrade <version>` through the entry point (one at a time, counted as open work so no bridge restart interrupts it); the button turns into the outcome, a reply gives the result, and a successful upgrade installs the matching `arcane-cli` with `specialist-install`.
 - Access: `owners` may use every specialist and decide approvals; `access.<specialist>` lists extra users for that specialist; everyone else gets no reply. Owners change the configuration from the admin channel (`adminChannelId`) without a shell: `config show`, `config channel <#channel> <always|mention> <*|dns,edge>`, `config channel <#channel> remove`, `config access <specialist> add|remove <@user>`; the bot writes `~/.config/astro-discord/config.json` on Cortex, which is also editable by hand and re-read on every message. Deny the bot's role View Channel on channels it must never read; that is the boundary the map cannot provide.
-- Approvals: a risky call (anything with `--confirm`, plus writes such as record or zone deletes, Zitadel changes, Pomerium deploys, service restarts, and on Arcane only destructive actions: `down`, deletes, prunes, image, volume, or network removal, `system upgrade`, `gitops delete`; help lookups never ask) pauses the specialist and posts Approve/Deny buttons; only owners' clicks count; no decision within `approvalTimeoutMinutes` denies it. The specialist then reports the denial. Ambiguous tasks get a question back instead of an action.
+- Approvals: a risky call (anything with `--confirm`, plus writes such as record or zone deletes, Zitadel changes, Pomerium deploys, service restarts, and on Arcane destructive actions: `down`, deletes, prunes, image, volume, or network removal, `system upgrade`, `gitops delete`, plus `manager-upgrade`, `manager-rollback`, `host db-restore`, and the Radarr host-config reads; help lookups never ask) pauses the specialist and posts Approve/Deny buttons; only owners' clicks count; no decision within `approvalTimeoutMinutes` denies it. The specialist then reports the denial. Ambiguous tasks get a question back instead of an action.
 - Setup, as `cortex`: `d=$(mktemp -d) && cp ~/.pi/agent/npm/node_modules/@astrofoundry/pi-astro/extensions/astro-discord/*.ts "$d" && node --disable-warning=ExperimentalWarning "$d/setup.ts"` (Node does not strip types inside `node_modules`, so the files are copied first) prompts for the bot token and the ids, checks each against Discord, and writes `~/.config/astro-discord/{token,config.json,run.sh}` and the LaunchAgent; it prints the `launchctl bootstrap` line. After a pi-astro update restart the bridge with `launchctl kickstart -k gui/$(id -u)/com.astrofoundry.astro-discord`. Log: `~/Library/Logs/astro-discord.log`.
 - Discord side: application `Cortex` with a bot, Message Content Intent enabled, invited with scopes `bot` and `applications.commands` and permissions View Channel, Send Messages, Attach Files, Read Message History, Add Reactions.