fix(software): prevent partial command package releases

[NathanFlurry]

• Clear stale command staging when canonical outputs are unavailable.
• Reject incomplete or non-executable command artifacts during build and publish.
• Prepare @agentos-software/grep 0.3.5-rc.1.

[NathanFlurry]

Stack for rivet-dev/agentos

• #1877 fix(software): prevent partial command package releases 👈
• main

Get stack: forklift get 1877
Push local edits: forklift submit
Merge when ready: forklift merge 1877

_{change qromqotv}

[railway-app]

🚅 Deployed to the agentos-pr-1877 environment in agentos

Service	Status	Web	Updated (UTC)
agentos	😴 Sleeping (View Logs)	Web	Aug 1, 2026 at 2:54 am

---

🚅 Environment agentos-pr-1877 in rivet-frontend has no services deployed.

[nhoelterhoff]

Is there a timeline for publishing this, and is there anything I can test against in the meantime?

Context on why I am asking: we run an in-guest pi agent over a mounted git repo, and we are working around what look like the pre-parity command shims rather than the real tools. Concretely, on @agentos-software/ripgrep 0.3.3 (whose bundled manifest reports ripgrep 0.3.0-rc.2) the rg in the guest:

• rejects --no-mmap, which real ripgrep 14 accepts;
• exits 2 with Not a directory (os error 54) for rg PAT . and rg PAT ./, while rg PAT "$(pwd)" works;
• treats a rootless rg PAT as "search nothing" (exit 1, no output, on a tree with matches);
• prunes directories on a positive filter: with matches at AGENTS.md and accounts/dekra/state.md, -g '*.md' and -t md each return only the top-level file, exit 0, no error. Negative globs (-g '!*.txt') behave correctly.

That last one is the dangerous one for us — it is a silently incomplete search, and we compile customer knowledge from it, so a missed match becomes wrong content. Real ripgrep does none of these, which is what makes me think we are on the old shim; docs-internal/registry-parity-worklist.md lists both grep and ripgrep as DONE (replaced with real GNU grep / real upstream ripgrep), so I assume this is exactly the packaging gap this PR fixes.

We have also hit the grep half of it: the published @agentos-software/grep 0.3.4 manifest declares only egrep->bin/egrep and fgrep->bin/fgrep, no grep binary, so a bare grep in the guest is command not found (the registry page does list grep as available).

On testing before a release: I looked for something pullable and could not find one — npm has nothing newer (ripgrep latest 0.3.3, grep latest 0.3.4, and the rc dist-tags point back at 0.3.0-rc.2), the GitHub releases carry sidecar binaries and pyodide wheels but no .aospkg, and the CI runs only upload benchmark results. Building locally looks like it needs the whole patched WASI toolchain (toolchain/Makefile wants c/vendor/wasi-sdk, the patched std sysroot, and prebuilt commands under target/wasm32-wasip1/release/commands), which is more than I want to take on to test someone else's fix.

Since software: accepts a plain { packagePath }, any prebuilt .aospkg would be enough — a 0.3.5-rc.1 on npm, an rc dist-tag, or even an artifact attached to a run. If one of those is easy for you, I am happy to run it through a real workload and report back: I can reproduce all four rg behaviours above deterministically and have an e2e that publishes to a throwaway branch.