What we tested in Launchpad /
The tests behind Launchpad: inputs, actions, observed results and the limits of that evidence.
A dark release-control interface combines the release queue, staged path, changed-file story and decision checklist. Its public simulation makes review dependencies visible without implying a deployment occurred.
Internal local testing, using synthetic inputs and owned assets. The results below establish the observed software behavior in those scenarios. They do not establish customer ROI, uptime or external deployment readiness.
Real build and package checks
Thirteen Launchpad HTTP checks passed within the combined runner suite. A dependency-free Node fixture executed actual tests and build, produced known bytes and exported them with its approval and evidence. Wrong source revision, unsupported build inputs and unsafe artifact paths were rejected. A rerun removed the previous approval and blocked an unreviewed package.
Two artifacts through the browser
The headed browser imported A and B, created release candidates, ran both commands, approved both and downloaded their ZIPs. Each ZIP's HTML matched its original fixture hash. Promotion changed the visible frame from Synthetic release A to Synthetic release B. The interface displayed the corresponding artifact digest and a new deployment history entry.
Rollback is an observed action
At 390 px width, the operator opened the rollback dialog and confirmed its focused button with Enter. The visible frame returned to A, the active digest matched A and history gained a restored-prior-artifact entry. Reload retained both approvals and the restored digest. Desktop and320 px mobile captures were also inspected, with no document overflow.
Recovery coverage and remaining uncertainty
Seven API rollout checks additionally covered stale target versions, repeated promotion and rollback, frozen A bytes during an A rerun, and unauthenticated or other-workspace access. Separate runner recovery testing delivered a cached completion after forced restart without repeating Docker execution. These bounded checks do not establish external deployment reliability, long-running availability or exhaustive crash recovery.
Source import readiness
A targeted browser test held file reads pending. The import action and file chooser stayed disabled and displayed a reading status. Releasing the file reads enabled the action and the actual four-file source snapshot was saved. This covers the observed import race without repeating or replacing the release-execution evidence.
What this evidence does not establish
The inspected local runner supports dependency-free Node 22 projects, bounded execution and a single artifact up to250 KB under dist/.
Local promotion serves an isolated HTML artifact. No cloud host, production release, DNS change or external deployment credential was used.
The current preview blocks network and forms; applications requiring a backend or external assets need a separately designed deployment path.
A test suite can pass while missing a defect. The approver must evaluate test relevance, output and recovery instructions.
A similar problem in your business?
Bring a real workflow, representative inputs and the result that needs to be reliable.
Shape a project brief