A desktop shell, with a Homebrew cask and a winget id

[Jing-yilin]

Problem

Some people will want a Dock icon, and Windows users have no path at all. Among comparable products, the ones that ship on Windows did so with a packaged app and a winget id, not a CLI. tldraw offline, the closest precedent (same canvas engine, same agent CLIs, loopback-only), ships a brew cask, a winget id, and dmg, exe and AppImage downloads.

Proposal

Only if the localhost app, the tap and Linux support leave people asking for it. Then:

• A Tauri or Electron shell that wraps the localhost app exactly. Nothing in src/ changes.
• A cask in the same tap, a winget manifest, and direct downloads attached to the release.
• Lift from OpenDesign: packages/platform/src/command.ts (a .cmd shim goes through cmd.exe /d /s /c "..." with windowsVerbatimArguments, and %VAR% in a prompt is rewritten to "^%" so cmd.exe cannot expand it); wellKnownUserToolchainBins() to augment PATH on GUI launch, with the searched directories shown when an agent CLI is not found; per-user NSIS install with no elevation; --appimage-extract-and-run on Linux.
• Signing and notarisation with a retrying notarytool hook; asar: true with asarUnpack for native modules if any remain.

Skip from OpenDesign: the custom od:// protocol, runtime-generated electron-builder config, R2 as the primary release store, the weekly release train.

Out of scope

A hosted authoring app. It is a different product with a different security model.

Context

Step 6 of the sequence in docs/2026-09-19-standalone-app-and-install.md. Ranked last: hard (signing, notarisation, Windows process handling), and Windows is its only unique value. Depends on the localhost app issue.

Sequence

#106 bundle → #114 curl installer → #108 localhost app → #109 Homebrew tap → #110 Linux → #111 desktop shell (only on demand). No PyPI: the toolkit installs from the release tag's tarball (#subdirectory=tools), so there is no second registry to maintain.

[Jing-yilin]

Signing and notarisation are not a blocker: ReScience Lab Inc. already holds an organization Developer Program membership and ships a Mac App Store app from it. The dmg needs a Developer ID Application certificate from that team (not the App Store distribution one) and notarytool in CI with the App Store Connect API key the store app already uses, which must have the Developer or Admin role. The shell stays outside the App Store and outside App Sandbox, per the home-directory decision on #108.

[Jing-yilin]

Progress as of v1.5.1: the macOS half is shipped. The release attaches Super-Prototyping-1.5.1-arm64.dmg and -x64.dmg, and brew install --cask ReScienceLab/tap/super-prototyping installs it (#121). The dmgs are unsigned until the signing secrets are set, so the first open needs the xattr line in the README.

Still open here: everything for Windows and Linux. There is no Windows build, no NSIS installer, no winget manifest, no Linux build, and the .cmd spawning shim for agent CLIs on Windows is not written. Leaving this open for those.

[Jing-yilin]

Decision on signing, 2026-09-21:

• macOS: signed and notarised. The Apple Developer Program membership already exists, so it adds no cost. Wired as of v1.5.2.
• Windows: unsigned for now. The first Windows build ships without a certificate, from windows-latest, which is free for this public repo. A browser download then shows SmartScreen's "Windows protected your PC", and "More info", "Run anyway" gets past it. That is two clicks, not a terminal command, so it does not block a first release the way the macOS warning did.
• Revisit when people report the warning as a blocker. The free route is SignPath Foundation (the publisher shown is theirs, and the maintainer has to apply). The paid one is Azure Artifact Signing at $9.99 a month.

Whether a winget install avoids the SmartScreen prompt for an unsigned installer is unsettled in what I could find, so it gets tested on a real Windows machine before the README says anything about it.