[DealAppSeo]

Opens /lab/start as a public beta and adds one link to it from the home page. The owner authorized this website-only launch on 2026-11-08. No npm release, database change or credential change is part of it.

What changed for visitors

• /lab/start no longer answers 404 on production.
• The preview banner is replaced by a public-beta notice.
• The headline is now "Check your AI's claims against the evidence." The text below it says TrustShell checks the kinds of claims it can read and does not see everything your AI did.
• The home page gains one link, "Try the guided walkthrough". Nothing else on it changes.
• The route stays noindex and out of the sitemap.

/lab/start walks a first-time visitor through Try, Test and Report on three paths: I chat with AI, an AI builds software for me, and I build or run agents. The chat path runs TrustShell's real claim checker in the browser against two saved GitHub Actions runs. It says plainly that TrustShell cannot see AI chats.

What changed outside the new page

• components/test-agent-flow.tsx: shared pieces are exported and report loading moved into a hook. NOT_CHECKED is now neutral rather than amber, and COMMAND_PASSED is dashed. /lab/test-agent remains preview-only.
• lib/trust-report-view.ts: inspectCommand takes an optional launcher. The default is unchanged.
• public/examples/trust-report-example.json: regenerated with 1.9.1. It is real output.
• tests/site-npm-badge.test.ts: the home page may not link to /start; the rule now excludes /lab/start.
• No change to src/, so no change to the published package.

Evidence on commit 4cc6910

Local, on Windows:

• tests/e2e/first-run-walk.mjs, desktop and 375 px phone, against a build made with VERCEL_ENV=production: 295 passed, 0 failed. That is the original 270 checks with the preview-banner check reworded, plus 25 new ones. /lab/start answers 200 while /lab/test-agent still answers 404, which shows the production setting took effect.
• The same walk runs axe-core on the whole page and the home page, with a positive control proving axe can report a violation.
• tests/e2e/test-agent-walk.mjs: 96 passed, 0 failed.
• next build: exit 0.
• Full jest suite: 6097 passed, 9 skipped, 9 failed in 7 suites. None of the 7 reads a file this PR changes. The failures are CRLF line endings, a Windows absolute path, a live network response and a Windows-only battery. CI on Linux decides those; wrapper-readiness sits outside that CI job.

Not verified

• macOS and Linux shells. The commands the page shows were run on Windows.
• Real MCP clients. The server was driven by a script speaking the protocol.
• A screen reader. Accessibility was checked with axe-core, keyboard walks and focus assertions.
• Anyone unfamiliar using it.
• The hosted /check page's own results. The walk confirms it answers 200 and does not submit to it.

Rollback

If the launch fails, production traffic goes back to the saved deployment of commit 7d55cd2. The branch and evidence are kept.

🤖 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 7:32am UTC

[strix-security]

Strix Security Review

✅ No open security findings.

PR summary: Opens the guided walkthrough at `/lab/start` as a public beta (it previously answered 404 on production) and adds one link to it from the home page, plus a refactor that exports the shared report-viewing pieces out of `components/test-agent-flow.tsx` and adds an optional launcher to `inspectCommand`. The page runs TrustShell's real claim checker in the browser against two saved GitHub Actions runs; nothing under `src/` changes.

Review summary

Reviewed all 14 changed files of the /lab/start public-beta launch: the new route and its client-side walkthrough components, the refactored shared report loader, the new inspectCommand launcher parameter, the regenerated example records, and the home-page link. Four independent investigations (generated-shell-command safety, route/gating exposure, client bundle integrity, report-file rendering) plus lint triage (11 items in or reached by the changed files) found no exploitable weakness, and every candidate went through independent validation and was rejected: the launcher argument is a compile-time literal and visitor text stays gated by isRunUrl/isShellSafe; /lab/start exposes only already-public documentation and public GitHub Actions data, with noindex intact and the page absent from the sitemap; the client bundle carries no environment secret or server-only code (verified against a production build) and verdicts cannot be forged through the textarea; uploaded or fetched report content reaches only React text nodes, with the pre-PR size and parse guards intact. Non-blocking hardening worth considering separately: inspectCommand interpolates an unvalidated launcher (latent footgun for a future caller), parseSavedRun could assert an https://github.com scheme before its URL becomes an href, and parseTrustReport could type-check list elements so a malformed report shows the page's own error instead of a generic crash — plus a docs-only clarification that a shell-exported TRUSTSHELL_HOME is not inherited by an MCP host.

Ruled out (8)

• Can a visitor's run URL or claim sentence escape the double quotes of the generated `--claims` command?
  The command renders only inside the `ready` branch gated by `isRunUrl` (an anchored regex whose character classes admit no quote, space, `$`, backtick or newline) and `isShellSafe`, and the emitted string was executed against a stub launcher with the arguments landing exactly as intended.
• Can the new unvalidated `launcher` parameter of `inspectCommand` be attacker-influenced?
  Every call site passes the compile-time literal `npx -y @​hyperdag/trustshell@​1.9.1` or the function default, and no query parameter, cookie, storage value or report field reaches that prop, so the raw interpolation is a latent footgun rather than a reachable injection.
• Does opening `/lab/start` publicly expose gated content or weaken the sibling preview routes?
  The gate is per-page (`VERCEL_ENV` checks in `/lab/test-agent` and `/lab/talk`, untouched), the new page links only to already-public pages, its example JSON holds no keys or local paths, and `noindex` plus sitemap exclusion were confirmed against the shipped metadata and `INDEXABLE_ROUTES`.
• Does running the real claim checker in the browser pull secrets or server-only code into the public bundle, or let a visitor forge a SUPPORTED verdict?
  A production build with marker environment values shipped zero occurrences of the markers, `GITHUB_TOKEN` or `process.env` in the client chunks (the network code is tree-shaken out), the checker consumes no untrusted merge, and statuses come only from fixed observation fields with mismatched run id…
• Can a crafted `report.json` produce script execution or unsafe navigation on the new Report step?
  No `dangerouslySetInnerHTML` or data-driven `href`/`src` exists on that path, every report field renders as an escaped React text node, and the refactored `useReportLoader` preserved the byte-size and parse guards unchanged.
• Can a malformed report crash the Report step?
  It can throw on unvalidated list elements, but only the person who chose that file is affected in their own tab with no data read, no state written and no backend request, so it is a robustness bug rather than a security issue.
• Can a tampered `/examples/run-*.json` turn the receipt's 'Open this run on GitHub' link into a `javascript:` URL?
  That JSON is a same-origin committed static asset whose producer rebuilds the URL with a literal `https:​//github.com/` prefix from regex-validated owner/repo segments, and replacing it would already mean controlling the deploy that renders the page.
• Does the printed MCP config leave a visitor with an ungated server while they believe Guard is set up?
  The page states the condition exactly ('With no policy there, the call runs'), the allow-without-policy default is pre-existing and documented, and the only actor is the visitor configuring their own machine with authority they already hold.

_{Review 1 on this PR · 4cc6910 · requested Nov 9 07:32 UTC when the PR was opened}

---

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

[strix-security]

Reviewed all 14 changed files of the /lab/start public-beta launch: the new route and its client-side walkthrough components, the refactored shared report loader, the new inspectCommand launcher parameter, the regenerated example records, and the home-page link. Four independent investigations (generated-shell-command safety, route/gating exposure, client bundle integrity, report-file rendering) plus lint triage (11 items in or reached by the changed files) found no exploitable weakness, and every candidate went through independent validation and was rejected: the launcher argument is a compile-time literal and visitor text stays gated by isRunUrl/isShellSafe; /lab/start exposes only already-public documentation and public GitHub Actions data, with noindex intact and the page absent from the sitemap; the client bundle carries no environment secret or server-only code (verified against a production build) and verdicts cannot be forged through the textarea; uploaded or fetched report content reaches only React text nodes, with the pre-PR size and parse guards intact. Non-blocking hardening worth considering separately: inspectCommand interpolates an unvalidated launcher (latent footgun for a future caller), parseSavedRun could assert an https://github.com scheme before its URL becomes an href, and parseTrustReport could type-check list elements so a malformed report shows the page's own error instead of a generic crash — plus a docs-only clarification that a shell-exported TRUSTSHELL_HOME is not inherited by an MCP host.

---

Reviewed by Strix
_{Configure security review settings}