Dev servers: pack and readiness
Which of my dev servers are behind, and are they ready?
One plain question across your whole set of dev servers. Quox reads each server's record, tells you which one is really behind and by how much, and says plainly when a status flag looks wrong instead of passing it on.
What you get: a readiness check you can trust across every dev server you run, without logging into any of them. In this run Quox found the one server that was really two versions behind, and noticed that the “behind” flag on the other five did not match their version numbers. It told you that, rather than telling you all six needed fixing.
Host names are replaced with their role; everything else is from the recorded run.
The setup
Section titled “The setup”You run a few dev servers. You want to know which are behind on the Quox skill pack, and whether two in particular, the dev box and the R&D box, are ready. You ask Quox to read only, and change nothing. This is the exact question from the recorded run:
I run a few dev servers. Which of them are behind on the Quox skill pack, and by how many versions? Then tell me straight: is dev-box ready, and is rnd-box ready? Just read, don't change anything and don't run any shell commands.
▤ AOCL │ L1 identity complete · allowed · 1ms
▤ AOCL │ L3 policy gate complete · proceed · 8ms
◐ DEV │ skills status ✔ DEV │ skills status │ 6 count, truncated: false, 6 behind count · 2.8s
◐ DEV │ dev_server_doctor host=dev-box ✔ DEV │ dev_server_doctor host=dev-box │ 1 count, truncated: false, 1 problems hosts · 3.3s
◐ DEV │ dev_server_doctor host=rnd-box ✔ DEV │ dev_server_doctor host=rnd-box │ 1 count, truncated: false, 1 problems hosts · 4.8s
⛓ AEE │ envelope opened · ops.tool · dev_skills_status ok
⛓ AEE │ envelope opened · ops.tool · dev_server_doctor ok
⛓ AEE │ envelope opened · ops.tool · dev_server_doctor ok
⛓ AEE │ envelope opened · stream_success
Only one of your six dev servers is demonstrably behind on the skill pack. Neither dev-box nor rnd-box is ready, and the reason is a flag that looks wrong. I ran only the governed read-only Quox checks, not shell commands. Those checks read registry records and did not probe any host live. Skill pack versions (current is v9) Host │ Installed │ Behind by │ Last seen ─────────────┼───────────┼────────────┼──────────── agent-box │ v7 │ 2 versions │ 24 days ago dev-box │ v9 │ 0 │ just now dev-box-2 │ v9 │ 0 │ just now dev-box-3 │ v9 │ 0 │ just now rnd-box │ v9 │ 0 │ just now staging-site │ v9 │ 0 │ just now • Only genuine laggard: agent-box is two versions behind. It also hasn't reported in for 24 days, so that record is stale. • Suspect flag: the tool marks all six hosts "behind", including the five on v9 against a current v9. Those five show no real version gap, and I'd treat the flag as a bug in the drift check. I can't say from this read why it fires. dev-box: not ready • The only finding is the false "v9 behind v9" drift flag. • It was last seen just now, and has the build, backup, restore and register capabilities. • Its headless supervisor is on (slot supervisor-slot-1). rnd-box: not ready • Its only finding is the same false "v9 behind v9" flag. • It was last seen just now, but has only the register capability. • Its headless supervisor is off. That may be intentional, but you should confirm it is. "Ready" here means no registry check found a problem. I did not test either host live. Fixing it is a state change, which you didn't ask for. For agent-box, the sync command is quox dev skills sync agent-box . I'd look into the drift check before running it against the v9 hosts.
27.7s · 3 tools · 0 approvals
quox.✔ Machine verified against the CLI on 4 Nov 2026 · test report mw2duu
The work
Section titled “The work”The whole job took 27.7 seconds and three tool calls, all read-only. Nothing was changed, so nothing needed your approval.
- Quox takes the question. The request passed Quox’s control checks (who is asking, and whether policy lets it go ahead) before any model ran. Out of 317 tools, 16 were offered for the job.
- It reads the pack status for every server.
dev_skills_statusreturned the six registered dev servers in 2.8 seconds, with all six flagged as behind. - It checks the two servers you named, side by side. Quox ran the server doctor on the dev box and on the R&D box at the same time. Each came back in under 5 seconds with one problem.
- It compares the flag with the numbers. Five servers were flagged “behind” while showing v9 installed against a current v9. Quox treated that as a suspect flag, not as five servers needing work.
- It proposes, and stops. It named the one sync command that would help,
quox dev skills sync agent-box, and advised looking into the drift check before syncing the others. It ran nothing. Each tool call was written to the audit record as an evidence envelope.
The result
Section titled “The result”| Server | Pack installed | Behind by | Last seen |
|---|---|---|---|
| an agent host | v7 | 2 versions | 24 days ago |
| the dev box | v9 | 0 | just now |
| a second dev box | v9 | 0 | just now |
| a third dev box | v9 | 0 | just now |
| the R&D box | v9 | 0 | just now |
| the staging site | v9 | 0 | just now |
- Really behind: one server, two versions behind, and it had not reported in for 24 days, so its record is stale too.
- The flag that does not add up: the registry marks all six as behind, including five on the current version. Quox said it would treat that as a bug in the drift check and could not tell from this read why it fires.
- The dev box: not ready, and the only finding is that same “v9 behind v9” flag. It has the build, backup, restore and register capabilities, and its headless supervisor is on.
- The R&D box: not ready for the same reason. It has only the register capability and its supervisor is off, which Quox suggested you confirm is intended.
- What “ready” meant here: no registry check found a problem. Quox said plainly that it did not test either server live.
What that got you: the one real action (sync the agent host) and the one real question (why the drift check flags current servers), instead of six sync jobs you did not need.
Do it yourself
Section titled “Do it yourself”The same reads from the CLI, all read-only:
quox dev doctorquox dev skills status <host>When a server is really behind, quox dev skills sync <host> brings it up to date. That is a change, so run it only when you mean to.
How it is checked
Section titled “How it is checked”The proof engine asked the question through chat and judged each step against what the CLI reports, not against what Quox said:
quox dev doctorshowed drifted servers, and the answer covered the staging site, one of them;- for each of the two named servers, the answer spoke to its pack version as read from
quox dev skills status; - no shell command ran, and none of the tools that sync, accept or enable anything was used.
All checks passed, in order.
Receipts
Section titled “Receipts”The run is public at ev_mw2duud5_1847cc, recorded on 4 November 2026. The receipt is the evidence, not this page.
The evidence bundle for the published run (ev_mw2duud5_1847cc) is yours to download and check: every step, check and tool with its verdict, the CLI record each step was judged against where it read one (host names replaced by their role) and the transcript above. Save it with the verifier, index.json and index.receipt.json, then run node verify-journey-bundle.mjs ev_mw2duud5_1847cc.json. It passes only if the bundle is the copy we published and witnessed, unchanged.
Quox-verified, not independently audited: the run was checked by Quox’s own proof engine against the running system, and the evidence id is published so you can recompute it. It is not a third-party audit.