Prompt: respond to an unreachable or misbehaving ird server

Have an agent work an incident on an ird VPS the way an operator would: tell a pending provider job from a hung box, climb the power ladder gently (graceful shutdown before a hard reset), snapshot before anything destructive, fall back to the account panel when SSH is gone, check the hostname still points at the server, rotate a leaked SSH key, and hand ird a ticket with real diagnostics when the fault is on their side.

Needs: ird access (MCP server or the ird CLI, logged in — ird vps show/activity/snapshot/ssh-keys are CLI-only); a shell with ssh and dig; for the DNS check, the hostname's zone on ird DNS Costs: power operations bill credits_prices → vps.power per request; a safety snapshot bills recurring.image-hourly per GB-hour while kept; the server keeps billing recurring.vps-hourly while shut down; tickets are free (support.writes) Group: servers

Paste everything below the line into a fresh conversation. Fill in the FILL IN block first.

Task

Diagnose SERVER, restore service with the least destructive step that works, and record what you did. Every power operation, snapshot and key change waits for my yes.

FILL IN

SERVER:     app-1                  # name or id from vps_list
SYMPTOM:    ssh times out since 09:10 UTC, site returns 502   # what I see
HOST:       app.example.ro         # hostname anchored at the server (blank = none)
ZONE:       example.ro             # its zone on ird DNS
SSH_USER:   deploy
KEY_ROTATE: no                     # yes = a private key may be compromised; replace it
NEW_KEY:    ./id_ed25519_new.pub   # public key file for the rotation

Non-negotiable rules

1. Read before acting. No power operation before ird vps show and ird vps activity are read and shown to me.
2. Ladder, not hammer. shutdown then power-on before reset; reset and power-off are hard (per the schema) and can corrupt in-flight writes. Each rung waits for the previous to finish.
3. Snapshot before anything destructive. No reset, power-off or rebuild without a snapshot in available state. vps_destroy is never part of this prompt.
4. Poll gently. ird vps activity or vps_list at most once a minute; wait for a pending job, never repeat it.
5. Private keys stay on my machine. Only public keys go to ird vps ssh-keys add.

Steps

A. Is it ird or the box? ird vps show SERVER --json (MCP: vps_list) → state, last_error, ipv4. ird vps activity --json → the latest job for this instance_id: type, state, error, finished_at. No finished_at = the provider is still working: wait, poll gently; G only if it stays unfinished far too long or ends in error. A last_error goes verbatim into the ticket. running with a finished last job means the box itself hung.

B. Reachability. ping -c 3 <ipv4>; nc -vz <ipv4> 22; ssh SSH_USER@<ipv4> (10 s timeout); curl -sSI http://<ipv4>. SSH working means the application: df -h, free -m, journalctl -p err -b, docker ps; fix there before touching power.

C. Hostname. If HOST: dig +short HOST must equal ipv4; dns_get_zone(ZONE) (CLI: ird dns records ZONE) shows the record ird wrote at create. Fix a wrong target with dns_set_record(domain=ZONE, name="HOST.", type="A", data={address: <ipv4>}) (replaces the whole A set).

D. Power ladder. vps_power has five operations: restart, reset (hard), shutdown, power-off (hard), power-on. Order:

1. vps_power(instance_id, operation="shutdown") (CLI: ird vps power shutdown SERVER); wait until vps_list state is no longer running.
2. vps_power(instance_id, operation="power-on") (ird vps power on SERVER); repeat B.
3. Still dead: snapshot first — ird vps snapshot SERVER incident-<date> (a stopped disk snapshots consistently), poll ird vps snapshot images until available — then operation="reset" (ird vps power reset SERVER). power-off is the fallback when shutdown never completes; then power-on.

restart (not marked hard) is the reboot for a box that answers SSH.

E. No SSH at all. ird docs opens the account panel; if it offers a server console (undocumented in CLI and MCP), use it: boot log, ufw status, systemctl status ssh, df -h. Without one, the snapshot from D plus a new server from it (vps-snapshot-restore prompt) is the way back to the data.

F. Rotate a key (if KEY_ROTATE). ird vps ssh-keys add <name> NEW_KEY → new key id; on the server replace the old line in ~/.ssh/authorized_keys for root and SSH_USER, confirm a fresh session with the new key, then ird vps ssh-keys delete <old key id>. The schema takes keys only at vps_create (ssh_key_ids); assume (undocumented) deleting one leaves running servers untouched — the authorized_keys edit is what counts.

G. Ticket (if it is ird's side). support_list_tickets first; then support_create_ticket(title="servers: <symptom> (<server id>)", message=…, service="general") (CLI: ird support new -s … --service general --file report.txt) with the show and activity output, UTC times, what the ladder did, ird version; secrets redacted. Read replies with support_get_ticket when I ask — no polling.

H. Verify. vps_list → running, last_error null; SSH and the app answer on ipv4 and HOST; ird vps activity shows your jobs as succeeded.

Deliverable

A timeline: show/activity at the start, each step and its result, root cause as far as known, snapshot id and monthly cost if taken, key ids added and removed, ticket id if filed, open follow-ups.