Add Build Remote Agent phone pairing (gbr/1)

[LinespottingPrivate]

What

Docs-only adapter so HAPI users can pair Build Remote Agent as a phone spectator on the desktop coding-agent host.

HAPI remains first-party remote UI. GBR is a spectator phone for the desktop coding-agent host. Companion, not a HAPI replacement.

Phone is spectator + veto, not orchestrator. Attach only http://127.0.0.1:8788 or stdio gbr-mcp. No mailbox keys. Protocol gbr/1.

Files: docs/guide/gbr.md, README.md, docs/.vitepress/config.ts

How

curl -fsSL https://grokbuildremote.com/install.sh | bash
gbr-agent version          # v0.6.0+
gbr-agent pair && gbr-agent run
curl -sS http://127.0.0.1:8788/health

Windows: irm https://grokbuildremote.com/install.ps1 | iex

Independent product by Linespotting AB. Not affiliated with xAI or SpaceX.
Agent: https://github.com/LinespottingOrg/GrokBuildRemote-Agents (MIT)

[github-actions]

Findings

• [Major] Official docs execute mutable third-party install paths without integrity verification (docs/guide/gbr.md:11, docs/guide/gbr.md:19, docs/guide/gbr.md:46).
• [Minor] The “Attach” section provides no HAPI or underlying-agent configuration step; no GBR integration was found elsewhere in the repo (docs/guide/gbr.md:29).

Summary
Review mode: initial

Two issues found: one supply-chain risk and one incomplete integration path.

Testing
Not run (automation). Documentation-only CI checks are pending; PR-provided installer, clone, npm, and docs-runtime commands were intentionally not executed.

HAPI Bot

[github-actions]

[MAJOR] Pin or remove the executable third-party install path

These instructions make HAPI’s official docs ask users to execute mutable code from a third-party domain with no version pin, checksum, or signature. The version check happens only after that code has run; the unpinned git clone plus npm install at lines 46–48 has the same supply-chain problem. Because the installed process is then given spectator/veto access to coding sessions, compromise directly affects session confidentiality and control.

Suggested fix:

Install `gbr-agent` from a version-pinned release and verify its published checksum/signature before running it. HAPI does not recommend piping mutable third-party URLs directly into a shell.

Apply the same pin-and-verify requirement to the MCP checkout, using a release tag or immutable commit and a lockfile-based install.

[github-actions]

[MINOR] Document the actual attachment point

This section stops at exposing a localhost API and an MCP executable; it never states which HAPI component or underlying agent consumes either one, nor gives a config/CLI step. A repo-wide search finds no GBR client or configuration outside these new docs. Users can install and pair the separate product, but cannot complete the advertised “Attach” step from HAPI.

Suggested fix:

## Relationship to HAPI

HAPI does not connect to the GBR Bot API or `gbr-mcp`. GBR runs independently on the same coding-agent host; configure it directly in the underlying coding agent using the vendor’s instructions.

If HAPI integration is intended, replace that note with the exact HAPI command/configuration and the supported-agent scope.

[github-actions]

Findings

• [Major] The root README now opens with installation instructions for an unrelated third-party product, before HAPI is even described. This regresses the repository's user-overview/quick-start entry point and can cause users looking for HAPI installation to install GBR instead README.md:3.
  Suggested fix:

  # HAPI
  
  Run official Claude Code / Codex / Cursor Agent / Grok Build / OpenCode / Kimi / Copilot / Antigravity / Pi / DeepSeek Harness sessions and control them remotely through a Web / PWA / Telegram Mini App.
  
  ## Docs
  - [Build Remote Agent companion](docs/guide/gbr.md) — optional third-party spectator

• [Major] The checksum command does not verify the binary against the pinned digest printed in the document. It downloads both the executable and SHA256SUMS from the same release, so replacing both artifacts still passes; the hard-coded digest above is never used. This leaves the earlier supply-chain issue unresolved for a tool documented as able to inject into every discovered terminal docs/guide/gbr.md:51.
  Suggested fix:

  curl -fsSL -o gbr-agent-darwin-arm64 "$BASE/gbr-agent-darwin-arm64"
  printf '%s  %s\n' 'de7e065ef2cf6877b3b2cd04679a67b627f876337f529247e236204543e4062c' 'gbr-agent-darwin-arm64' |
      shasum -a 256 -c -

• [Minor] “User plugins live in this repo” is false for HAPI: no GBR manifests, mcp.servers configuration, or gbr-pair extension exists outside these new docs. Users still cannot tell whether HAPI consumes the API/MCP endpoint or where the required attachment configuration lives docs/guide/gbr.md:63.
  Suggested fix:

  HAPI does not consume the GBR Bot API or `gbr-mcp`. Configure GBR directly in the underlying coding agent using the vendor plugin registry linked above.

Summary

Review mode: follow-up after new commits

Three issues found. The new commits remove the original mutable installer/clone commands, but the checksum trust model and attachment guidance remain incomplete, and third-party installation content now displaces HAPI's own README introduction.

Testing

Not run (automation). The integration check passed; the main test check was still pending at review time. Suggested validation: build the VitePress docs and smoke-test each documented install command on a clean supported host.

HAPI Bot

[github-actions]

[MAJOR] Keep the HAPI README entry point about HAPI

This new top-level “Install” section installs GBR, not HAPI, and appears before the first sentence explaining what HAPI is. The repository guide defines this README as the user overview/quick start, so users arriving for HAPI installation are now directed to an unrelated third-party binary first. The additional GBR-specific section after Credits has the same scope problem.

Suggested fix:

# HAPI

Run official Claude Code / Codex / Cursor Agent / Grok Build / OpenCode / Kimi / Copilot / Antigravity / Pi / DeepSeek Harness sessions and control them remotely through a Web / PWA / Telegram Mini App.

## Docs
- [Build Remote Agent companion](docs/guide/gbr.md) — optional third-party spectator

Keep the operational GBR installation and terminal-roster details in the dedicated guide only.

[github-actions]

[MAJOR] Verify against the pinned digest, not a co-hosted manifest

The example downloads both the executable and SHA256SUMS from the same replaceable release. If the release assets are replaced, the binary and manifest can change together and this command still succeeds; none of the hard-coded hashes at lines 37–42 participates in verification. Because the documented agent can inject into every discovered terminal, this leaves the previous supply-chain finding unresolved. The duplicate README example has the same issue.

Suggested fix:

curl -fsSL -o gbr-agent-darwin-arm64 "$BASE/gbr-agent-darwin-arm64"
printf '%s  %s\n' 'de7e065ef2cf6877b3b2cd04679a67b627f876337f529247e236204543e4062c' 'gbr-agent-darwin-arm64' |
    shasum -a 256 -c -

Use the corresponding checked-in digest for each platform, or verify a separately signed manifest.

[github-actions]

[MINOR] Point to the actual attachment configuration

In this HAPI guide, “this repo” means the HAPI repository, but a repo-wide search finds no GBR manifests, mcp.servers configuration, or gbr-pair extension outside these docs. The section still lists an API and MCP executable without stating whether HAPI consumes them, so the attachment path from the earlier review remains incomplete.

Suggested fix:

HAPI does not consume the GBR Bot API or `gbr-mcp`. Configure GBR directly in the underlying coding agent using the vendor plugin registry linked above.

If HAPI integration is intended, replace that note with the exact HAPI command/configuration and supported-agent scope.