Launchpad /
Ready is a state. Prove it.
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.
- Practice
- Digital products
- Built by
- Lumia Digital
- Application
- Independent source & workspace
- Current release
- Local / September 2026
A release decision you can follow.
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.
Cytoscape release relationshipsThe problem worth solving.
A release decision depends on several related facts: which revision was tested, whether the build actually ran, which bytes were produced and who approved those bytes. A green badge detached from its source or artifact cannot answer those questions. Recovery instructions are also incomplete when nobody can identify the previous artifact that should be restored.
Launchpad is a local release room that connects an imported source revision to actual test and build results, owner approval and an exported package. Its local HTML target serves a frozen approved artifact inside an isolated frame. A subsequent release creates another deployment snapshot, making it possible to restore the exact earlier bytes without rebuilding the old release or trusting a mutable download.
The application was evaluated using two small, owned HTML fixtures with different visible release labels and hashes. That makes promotion and rollback directly observable without connecting production infrastructure. It is an independent Lumia build for demonstrating release mechanics, not a client delivery story or a claim of measured incident reduction. The intended benefit is that the operator can explain and reproduce each release decision.
Designed for: Developers and delivery leads who need a small, inspectable release and recovery workflow for dependency-free Node builds producing a single local artifact.
From input to a useful result.
Prepare the source and release
Import an authorized folder, inspect its revision and choose the build script. Enter the output path under dist/ and meaningful recovery instructions. The demonstrated path uses node --test followed by node build.mjs and emits dist/index.html. Each release stays associated with its selected immutable source snapshot.
Run and inspect actual checks
Start tests and build from the release view. The action becomes unavailable while the executor is working, and the interface displays persisted command results afterward. Read the regression output and build evidence; a successful click or a queued job is not a finished build. Correct source issues in a new snapshot when needed.
Approve and package the artifact
After passing checks, the owner reviews the release and approves the current evidence and exact artifact digest. Download the ZIP to retain the built file, release evidence and recovery instructions. If checks run again, review the new evidence and approval state before reusing the release. Approval is tied to the reviewed record.
Promote and restore locally
Compare the proposed and current artifact digests in the promotion dialog. Confirm to serve the approved HTML in the local isolated frame. After a second promotion, the rollback dialog identifies the prior digest and revision. Restore it and check both visible content and history. This action changes only this product's local preview target.
What the software actually did.
These results come from internal workflow testing of the local product. The records are controlled test inputs; customer deployments and commercial impact have not been measured.
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.
Make the boundary clear.
- 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.
Questions before you start.
Does Promote locally deploy my website publicly?
No. It changes this installation's isolated HTML preview target. The tested flow did not connect an external hosting service or publish a public site.
Does rollback rebuild the previous release?
The implemented local rollback restores a frozen deployment artifact. API testing confirmed the earlier snapshot still works after the associated release is rerun and its current approval changes.
What is inside the release ZIP?
The tested package contains the actual dist/index.html bytes, release-evidence.json and ROLLBACK.txt. Its artifact hash matched the independently prepared fixture.
Why approve after the checks pass?
Execution supplies evidence; approval records the owner's decision about a particular revision and artifact. Changes or reruns require a fresh review rather than inheriting an outdated approval.
More from this practice.
All fifteen products
Orbit
A plum review room puts the artwork at the centre, with a project-file rail, version history, numbered pins and threaded feedback. The public interface is an interactive example of a full-stack creative-review app.
Explore the case study
ARMORY
A mineral-green asset workbench pairs a large interactive 3D stage with an object inspector and collection shelf. Three original GLBs can be inspected and downloaded from the public interface.
Explore the case study