[DealAppSeo]

Do not merge until npm view @hyperdag/trustshell version returns 1.9.1. This branch is what gets published, and its docs say 1.9.1 is on npm.

In 1.9.0, one trustshell run that selected no tests and exited 0 made "All tests pass" SUPPORTED. A note beside it said this showed only that the command passed, but the word claims more than an exit code can show. TrustShell records how a command ended and cannot tell whether it tested anything.

What changes

• A claim paired with a command now tops out at COMMAND_PASSED. Claims checked against GitHub's record of a run can still be SUPPORTED.
• Reports move to schema 0.2-draft. verify rebuilds a report under its own schema, so a folder made by 1.9.0 keeps its word and still verifies.
• Exit codes do not change.
• The release test gains five steps on the packed artifact: an empty run and what the report says about it, a failure followed by an easier run, a script swapped after pinning, and the claim that depended on it.
• Version 1.9.1 and its install pins.

Against the published 1.9.0 tarball, five files differ: CHANGELOG.md, README.md (version pins), package.json (version) and dist/cli/trust-report.js with its .d.ts. None added, none removed.

Evidence

• Tests failed before the fix for the right reason. Putting SUPPORTED back turns 5 red.
• A real folder made by the published 1.9.0 is pinned as a fixture and verifies. It caught a bug the unit tests missed: a new style rule changed the HTML of older reports, so they failed verification. The fixture's bytes must stay exact, so it is marked -text.
• The other results are in the checks on this PR.

Limits

COMMAND_PASSED is still shown in the "good" colour and still exits 0. It means the command ended cleanly, nothing more, and the report says so. The separate scripted attack that 1.8.0 received has not been run on this tarball.

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
trustshell-landing	Ready	Preview	Nov 9, 2026 3:27am UTC

[strix-security]

Strix Security Review

✅ No open security findings.

PR summary: Release 1.9.1 of @​hyperdag/trustshell: a claim paired with a command that exited 0 now reads COMMAND_PASSED instead of SUPPORTED, reports move to schema 0.2-draft while `verify` still accepts and rebuilds 1.9.0-era 0.1-draft folders, and the release test gains five steps on the packed artifact.

Review summary

Reviewed the 1.9.1 release diff: the Trust Report status change (a bound claim whose command exited 0 now reads COMMAND_PASSED instead of SUPPORTED), the new 0.2-draft schema with a 0.1-draft compatibility path in verify, the browser viewer's widened schema acceptance, the new release-e2e steps, the byte-pinned 1.9.0 fixture, and the version pins across docs and skills. The security-relevant question is whether the schema field taken from an untrusted report.json can be used to launder COMMAND_PASSED back into SUPPORTED; it cannot, because report.json is listed in MANIFEST.sha256 and the manifest digest is Ed25519-sealed and checked against the caller's pinned --root, and flipping the schema also breaks the byte-for-byte rebuild. The committed dist/ was verified byte-identical to a fresh tsc build of the changed source and to the packed tarball, so the published artifact matches the reviewed code. No vulnerabilities found.

Ruled out (5)

• Can a report folder's own schema field launder a COMMAND_PASSED claim into SUPPORTED in `trustshell trust-report verify`?
  report.json is listed in MANIFEST.sha256 and the manifest digest is Ed25519-sealed and checked against the caller's pinned --root, so flipping the schema fails the manifest check, the seal's args_hash, or the byte-for-byte rebuild; only a holder of the trusted sealing key could re-seal, and that ke…
• Is the 0.1-draft compatibility path indistinguishable from a genuine 1.9.0 report?
  It is the documented compatibility behaviour stated in the PR description, the rendered HTML differs between schemas, and producing a laundered folder requires the trusted sealing key, so no attacker without that key gains anything.
• Can a crafted report.json inject markup or make a forged report look verified in the browser viewer?
  parseTrustReport performs no verification and the page says so, every report field is rendered as an escaped React text child, and the only dangerouslySetInnerHTML uses are in untouched docs pages.
• Does the hand-edited dist/ diverge from the reviewed src, so the published 1.9.1 tarball behaves differently?
  A fresh `tsc --project tsconfig.sdk.json` build is byte-identical to the committed dist across all 151 files, the sdk-dist-fresh gate passes, and the packed tarball carries the same sha256 for both changed files.
• Do the new release-e2e steps or the byte-pinned fixture weaken the release gate or commit a secret?
  The new steps only add assertions (including a stronger check that a swapped script's side effect is absent), all writes stay under the mkdtemp work dir, and the fixture contains only a public key and no credentials.

_{Review 1 on this PR · 25aa6ae · requested Nov 9 03:31 UTC when the PR was opened}

---

Reviewed by Strix
_{Re-run review · Configure security review settings}

[strix-security]

Reviewed the 1.9.1 release diff: the Trust Report status change (a bound claim whose command exited 0 now reads COMMAND_PASSED instead of SUPPORTED), the new 0.2-draft schema with a 0.1-draft compatibility path in verify, the browser viewer's widened schema acceptance, the new release-e2e steps, the byte-pinned 1.9.0 fixture, and the version pins across docs and skills. The security-relevant question is whether the schema field taken from an untrusted report.json can be used to launder COMMAND_PASSED back into SUPPORTED; it cannot, because report.json is listed in MANIFEST.sha256 and the manifest digest is Ed25519-sealed and checked against the caller's pinned --root, and flipping the schema also breaks the byte-for-byte rebuild. The committed dist/ was verified byte-identical to a fresh tsc build of the changed source and to the packed tarball, so the published artifact matches the reviewed code. No vulnerabilities found.

---

Reviewed by Strix
_{Configure security review settings}