What needed solving.
Make a complex local development and cloud-publishing setup repeatable across participant machines while containing credentials and offering recovery from interrupted setup.
- 01Enrolled participant device
- 02Journaled provisioning steps
- 03Verified app + recovery state
Simplified from the implementation and project notes.
How it fits together.
The renderer is a narrow view over a privileged main process
The sandboxed Electron renderer uses typed IPC for a small set of operations; the main process owns commands, filesystem access and credentials. Packaged binaries use checksum-pinned Node, GitHub CLI, Git and Codex App Server. Child environments are built from an allowlist and private tool paths, avoiding global PATH or shell-profile edits. Unit tests cover toolchain discovery, command execution and supervised process behavior. A central choice is to keep arbitrary command execution and raw output out of the renderer.
Project creation is an atomic journal, not one long setup command
Provisioning records each completed step so launch can resume after interruption: copy starter, initialize Git, seed/install dependencies, verify a local app, create the repo, obtain project-scoped Convex/Vercel config, deploy backend, run checks, publish and verify health. Temporary project directories are moved atomically into place, and deterministic deployment markers let a retry recover a deployment when the response was lost. Tests cover project workflow and broker/provider validation; important failures include interruption between steps, stale broker claims and a response lost after deployment.
Recovery reconciles durable state with actual processes and cloud state
A supervisor starts the dev server on an unused loopback port, probes readiness and closes the full child process tree when stopped. One crash can restart automatically; repeated crashes become visible recovery actions. The broker uses one-time enrollment tickets and device credentials stored with Electron safeStorage; instructor actions are queued and acknowledged by polling. Acceptance docs require native-machine golden paths and explicit tests for occupied ports, offline operation, dependency corruption, failed deploys and recovery. The acceptance record must be read for which of those scenarios were actually run.
Building and checking it.
Participants enroll a device, create a project, authenticate to their own GitHub/Codex accounts, and work in a local project-scoped thread. The launcher supervises the dev process and offers restart, reinstall, redeploy or restore recovery actions.
Release candidates are documented as built on Apple Silicon and Windows 11 x64 with platform signing/notarization requirements.
Workshop-owned Convex/Vercel resources and broker are required for provisioning and publishing. The README points to an acceptance record; portfolio claims should distinguish documented acceptance from broad production reliability or participant outcomes.
Source notes
Based on repository code and project records reviewed on October 30, 2026. Historical checks are described as recorded, not rerun for this article. Screenshots, renders, and mockups are labeled individually.
bootcamp-launcher/README.mdbootcamp-launcher/docs/architecture.mdbootcamp-launcher/docs/provisioning-broker.mdbootcamp-launcher/docs/validation.mdbootcamp-launcher/package.jsonbootcamp-launcher/docs/acceptance-2026-08-26.mdbootcamp-launcher/apps/launcher/src/main/projects.test.tsbootcamp-launcher/apps/launcher/src/main/supervisor.test.ts