@astrofoundry/pi-astro 0.18.3 → 0.18.5

package/agents/arcane.md

@@ -7,6 +7,8 @@ systemPromptMode: replace
 inheritProjectContext: false
 inheritSkills: false
 maxSubagentDepth: 1
+model: openai-codex/gpt-6-astra
+thinking: xhigh
 ---
 You are the Arcane specialist. The `arcane` tool is your only way to reach Arcane and its GitOps repository. You have no shell and no file access; if a task needs anything else, say so and stop.
 
@@ -16,6 +18,6 @@ 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 ends with a hand-over: after the repository change and the file sync, stop and give the caller the host commands from the skill. Never run `system upgrade` or `projects upgrade arcane`.
+- 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`.
 - 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`) and only for that specialist's own area.

package/agents/identity.md

@@ -7,6 +7,8 @@ systemPromptMode: replace
 inheritProjectContext: false
 inheritSkills: false
 maxSubagentDepth: 1
+model: openai-codex/gpt-6-astra
+thinking: xhigh
 ---
 You are the identity specialist. The `identity` tool is your only way to reach Zitadel and the DMZ guest. You have no shell and no file access; if a task needs anything else, say so and stop.
 

package/agents/network.md

@@ -7,6 +7,8 @@ systemPromptMode: replace
 inheritProjectContext: false
 inheritSkills: false
 maxSubagentDepth: 1
+model: openai-codex/gpt-6-astra
+thinking: xhigh
 ---
 You are the network specialist. The `network` tool is your only way to reach UniFi, FreeRADIUS, and Tailscale. You have no shell and no file access; if a task needs anything else, say so and stop.
 

package/package.json

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

package/skills/arcane/SKILL.md

@@ -29,13 +29,27 @@ The full `arcane-cli` is available. The tool refuses only `config`, `auth`, `sel
 
 ## Updating Arcane itself
 
-The `arcane` project is GitOps-managed and pinned by digest (`ghcr.io/getarcaneapp/manager@sha256:...`). The documented path (Arcane installation guide, homelab self-management exception) has three steps; you do the first two and hand over the third.
-
-1. Repository: `git pull`, `git show arcane/compose.yaml`, find the new digest with `["projects", "updates"]`, `git write` the file with the new digest, `git diff`, `git commit "Update Arcane manager image"`, `git push`.
-2. Sync files: trigger the `arcane` project's GitOps sync through `["gitops", ...]` so `/opt/docker/arcane/compose.yaml` matches the repository. The manager cannot recreate itself from its own sync.
-3. Stop and report: the caller runs on VM 100, in `/opt/docker/arcane`, `docker compose pull arcane && docker compose up -d arcane`, then asks you to verify with `["version"]` and `["projects", "list"]`.
-
-Never use `["system", "upgrade"]` or `["projects", "upgrade", "arcane"]` for the manager: both bypass the pinned digest in the repository.
+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), `["projects", "updates"]` (new digest, if any). If there is no 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.
 
 ## Output
 

package/specialists/README.md

@@ -8,7 +8,7 @@ A specialist is a Pi subagent that is the only way to operate one area of the ho
 | `astro.identity` | Zitadel; Pomerium, nginx, lego on VM 104 | Any Zitadel API call (v2, management, admin, auth) with responses redacted; `dmz status|journal|config-template|render|pomerium-restart|nginx-reload|lego-renew` |
 | `astro.network` | UniFi, FreeRADIUS (LXC 108), Tailscale (LXC 105) | Read UniFi sites, devices, clients, networks, firewall policies, WANs; RADIUS and Tailscale checks on Pulsar |
 
-Call one with `/run astro.<name> -- <task>` or through the `subagent` tool (both from the bundled `astro-subagents` extension). Specialists may call each other once (`maxSubagentDepth: 1`). Each tool takes `args`, an array of strings; `["--help"]` lists the subcommands.
+Call one with `/run astro.<name> -- <task>` or through the `subagent` tool (both from the bundled `astro-subagents` extension). Specialists may call each other once (`maxSubagentDepth: 1`). They run on `openai-codex/gpt-6-astra` with `xhigh` thinking, set by `model` and `thinking` in each `agents/<name>.md`; an agent without these fields inherits the caller's model and thinking. Each tool takes `args`, an array of strings; `["--help"]` lists the subcommands.
 
 ## How it is secured