Brightencode Launcher v0.1.24

Fall back to sha256sum when shasum isn't on PATH

Windows' Git Bash runner apparently dropped shasum (Perl-based) from its
default PATH — v0.1.24's Windows release build failed at the
beforeBuildCommand step with "shasum: command not found", even though
v0.1.23 built fine 5 days earlier. sha256sum (GNU coreutils) reads the same
checksum-file format and is available on Linux/Windows; shasum stays as
the fallback for macOS, which doesn't ship sha256sum by default.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Brightencode Launcher v0.1.23

Replace placeholder app icon with Brightencode mark

Brightencode Launcher v0.1.22

wired up library

Brightencode Launcher v0.1.21

Restructure My Apps around Installed + account library, add remove-fr…

Brightencode Launcher v0.1.20

Add Installed/My Apps/Browse tabs with catalog search

The launcher was single-purpose (just the installed-apps gallery) —
this adds a tab bar plus a search input above the gallery so the
whole catalog is browsable from inside the app, not just the website:

- browse_catalog (orchestrator::search_catalog, worker's GET /search)
  lists the public catalog, cross-referenced against the local library
  so each tile shows Install vs Launch. Utility repos are filtered out,
  matching securexe-web's own Library page default.
- install_from_catalog reuses flow::install_and_launch exactly like a
  signed securexe://run link or the in-app Update action — no
  signature needed since the user is installing something already
  sitting in their own launcher, not following an arbitrary link.
- repo::is_safe_repo_path validates a Browse-tile repo string arriving
  over IPC (from the worker's own search results) before it's turned
  into a filesystem slug.
- My Apps tab is a stub for now (cross-device library sync isn't wired
  up yet) — shows an explicit "coming soon" empty state rather than an
  empty gallery that looks broken.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Brightencode Launcher v0.1.19

Prefer the worker's icon over the bundle's when both are available

The worker's /icon endpoint is meant to be the single source of truth
for an app's icon — the same iconUrl-or-generated-badge securexe-web's
RepoIcon renders — but install_and_launch had the priority backwards:
it only fetched the worker icon when the downloaded bundle had nothing
extractable. In practice nearly every one of these repos ships some
default framework icon (never customized), so that fallback almost
never triggered, and the gallery ended up showing generic bundled
icons instead of each app's distinct worker badge — visibly out of
sync with the website.

backfill_icons re-syncs every installed app's icon now, not just ones
with nothing cached, so apps that already have a stale bundle-icon
cached from before this fix get corrected too.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Securexe Launcher v0.1.17

Tweak empty-state copy for clarity

Minor wording change, also serving as a real v0.1.17 test release to
verify the in-app updater actually works end-to-end against production.

Securexe Launcher v0.1.16

Add a real one-click updater for the launcher itself (macOS)

The update notification's button previously just opened the GitHub
release page, leaving the actual install (download DMG, mount, drag to
Applications, eject, relaunch) entirely manual. This runs that whole
sequence via a visible Terminal script instead: download, quit the
running instance, install, strip the quarantine flag, relaunch.

Deliberately not a "real" auto-updater — the app is ad-hoc signed (no
paid Apple Developer ID yet), and per Apple's own DTS guidance, ad-hoc
signatures have no stable identity across builds, so TCC permission
grants (Local Network, etc.) will still reset on update regardless of
how the new build gets installed. Stripping quarantine here does fix
the Gatekeeper "unidentified developer" prompt specifically (the
standard workaround for that), but the permission-reset behavior is a
real limitation that only a real Developer ID + notarization removes —
documented in the code rather than glossed over.

Windows/Linux fall back to opening the release page, same as before —
no scripted installer for those yet.

Verified: the generated script is checked for syntax validity (`sh -n`,
real parse-check, not just string matching) and correct step ordering
in a test — never executed for real, since it operates on
/Applications and would kill/replace whatever's actually installed.

Securexe Launcher v0.1.15

Add "remove from library" distinct from uninstall

New remove_from_library command: drops a slug from library.json and
reports a "removed" event to the worker, but never touches the actual
downloaded files (unlike uninstall, which does both). Gallery now shows
two small buttons per tile — the existing × (uninstall, destructive) and
a new − (remove from library, keeps the download) — sharing the same
click-twice-confirm interaction via a new makeConfirmButton helper.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Securexe Launcher v0.1.14

Tell the worker when a device unlinks, not just locally

unlink previously only cleared ~/.securexe/account.json — the worker never
learned the device disconnected, so it kept showing up as linked on the
website forever. Now unlink calls the worker first (while the device token
is still in hand) and clears local state regardless of whether that call
succeeds.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>