petardlisted

petard keeps you able to operate when the frontier model is down or rate limited. The bar: you type your own words ("bounce the workshop instances", "reset a password", "restart"), and you get back the real command to run, from your system's own ground truth. If it depends on the thing that is down, it is not a petard. petard does not carry that engine itself. It **composes arlo**, a real, local operator that runs on its own power and network. In the user's session, when the frontier is down, you invoke arlo: arlo "restart the cluster" and arlo answers with the grounded command, or says it has no confident match, never inventing one. That is the whole of petard: resolve arlo and hand the user's words to it. ## Resolve arlo (pin, do not vendor) arlo is source of truth and iterates on its own. petard pins a released version and composes it; it does not copy arlo's code into hoistable. The pin is in `pin.json` (arlo v0.1.0, `3dl-dev/arlo`). Install it in the receiver's environment the way any skill installs: /plugin marketplace add 3dl-dev/arlo /plugin install arlo@arlo or use the `arlo` CLI directly. Either way, arlo runs in the user's session, on ground truth harvested from their live system. hoistable never runs arlo's engine in our process; that would be building software instead of composing a skill. ## Why compose, not embed The petard invariant (independent of whatever is down) and the "build the skill, not the software" rule point the same way: arlo