Install
What installing, diagnosing, updating and removing Hypervibe are designed to do, and why there is nothing to install yet.
On this page
This page explains what the installer is designed to do, so you can see in advance what it will and will not change on a machine. The commands named here are planned names.
One program arrives first, and one owner changes the rest #
A download channel, such as a package manager, only places the planned hyper program on the machine. From then on hyper setup installs the rest. Reactor owns installation: exactly one part of Reactor, the activation owner, changes the installed programs for each installation. A package manager may keep updating the hyper program it placed, but no channel updates anything else.
Releases are designed to be checked before anything changes #
A release names every program it contains by a digest of its content. Before anything changes, setup checks the release against a trust policy the installation keeps separately, so a release can never vouch for itself. Releases are designed to carry a publisher signature, and setup refuses a revoked release, or one below the installation's security floor, even when its old signature is valid.
Release signing is still an open decision. Until it is made, an internal build is unsigned, setup trusts it only through a digest supplied separately, and it is not a public release.
Setup shows its plan before it changes anything #
Setup takes at most four screens, each with one main action.
| Screen | What it shows |
|---|---|
| How will you use this machine? | The profiles: Just me, connect to a team, or a build or agent machine for a team |
| Here's what will happen | What it installs, in product names; where; what it downloads; anything else on the machine it would change |
| Installing | Three steps, downloading, checking and starting; a step is marked done only when it is confirmed |
| Ready | What to do next, and where the receipt is |
Sign-in is never part of installing. Running setup again with the same choices changes nothing, and an interrupted setup resumes the same operation instead of starting another.
Setup writes into one folder and leaves the rest alone #
On a personal machine, everything Hypervibe keeps lives in ~/.hyper: installed versions, the journal and receipts, each part's state, caches and bounded logs. A team server keeps the same layout under a dedicated hyper system user, with no configuration file in /etc. An enrolled repository gets a single .hyper folder holding its workspace binding and the files Hypervibe manages there.
Setup is designed not to:
- create configuration files for you to edit, because settings are records with revisions;
- write agent tools' settings into your home folder; a tool that Hypervibe launches gets its settings in a separate home set up for that launch;
- reset or discard uncommitted work;
- overwrite a program another product installed;
- read stored keys or secret values, or write a credential to disk in clear.
In the first release, setup imports nothing from older tools. A later release is designed to import the folders that earlier Throttle, Lanes and build tools left, once, and only when it replaces the tool that reads them. The plan screen names them first, the old folders stay as a backup, and nothing is deleted without a receipt.
Doctor diagnoses without changing anything #
hyper doctor compares what should be installed with what is installed, what is running and what actually works. It applies nothing and proposes each repair as a plan. A check it cannot complete reads unknown, never healthy. hyper setup status shows what is installed, the release channel, the next update check and the last change.
Updates wait for live work and roll back only when it is safe #
hyper update applies an update now. Background updates through the same owner are planned for a later release. Running work holds an update until it ends. If the new version fails its health check, the previous version returns only when every part's stored data is still readable by it. Otherwise the update is held and repaired forward. A release that was rolled back is never chosen again automatically.
Uninstall removes the programs and keeps your data #
hyper uninstall removes the installed versions, the parts it supervises and every file its journal records writing, and keeps each part's stored data. Adding --purge also removes the data, after each part's backup, and its receipt lists every path it removed. A part that another installed profile still uses is kept.
Every outcome has its own exit code #
Setup is designed to end with one of these exit codes, so a script can tell the outcomes apart. A person sees the same outcome as a plain sentence.
| Outcome | Exit code |
|---|---|
| Ready | 0 |
| Usage error | 2 |
| Refused with nothing changed | 3 |
Not confirmed yet: the last step was interrupted, and hyper setup status checks before changing anything | 4 |
| Needs a decision, such as a missing enrollment code | 5 |
| Not ready yet: it is waiting or repairing, and finishes on its own | 6 |
| Refused after a change; the receipt lists what changed | 7 |
Where to go next #
- Choose a profile compares the ways a machine can be set up.
- First verified change follows the first run after setup.
- Troubleshoot collects refusals and their fixes.