Search
Every page, by section. Search runs in your browser and sends your query nowhere.
Get started
- Get started What Hypervibe will do for a builder, what you will need, what is not available yet and the path through this section.
- Choose a profile The ways Hypervibe is designed to be set up on a machine, who each one is for, what each needs and which evidence each still lacks.
- Install What installing, diagnosing, updating and removing Hypervibe are designed to do, and why there is nothing to install yet.
- First verified change The planned first run on one machine, from enrolling a repository to accepting a verified change and reading what it cost.
- Read a receipt What a run receipt records, how the verifier's verdict differs from the receiver's decision, and how cost reads when part of it is unknown.
Products
- Products The components that make up Hypervibe, what each one owns and where to read more.
- Hypervibe platform What the Hypervibe platform will keep for the other components, from identity and settings to grants, the capability registry and the workspace inventory.
- Rocket! How Rocket!, the agent engine, will turn a goal into a candidate change you review, under approvals bound to the exact effect.
- Lanes How Lanes will keep every agent seat in view, bring the questions that need you to the front and carry messages between agents and people.
- Throttle How Throttle will admit and route every model request, hold every credential, and count capacity and cost so that unknown cost never reads as zero.
- Reactor How Reactor will admit, run and receipt builds, verification and agent tool calls on registered resources, and why its verdict is never the same as acceptance.
- Fleet How Fleet, Hypervibe's privileged operations workspace, will manage machines, capacity, rollout and repair under revocable grants, without a store or scheduler of its own.
- Companion What the planned phone companion will let you see and answer away from your computer, how it pairs, and how its access ends.
Managed workspaces
- Managed workspaces How Hypervibe will keep a workspace's repositories, configuration and instructions in one managed desired state, so that a fresh checkout and the workspace's records reproduce it.
Work and quality
- Work and quality How Hypervibe defines the outcome you want, tracks each attempt at it, and keeps verification, acceptance and cost as separate facts.
Context and evidence
- Context and evidence How Hypervibe records where evidence came from, keeps an agent's context small, checks access each time it is reached, and attributes cost without guessing.
Deploy and operate
- Deploy and operate How Hypervibe is planned to run for one person or a team, how people and machines join, and who may perform each sensitive operation.
Extend
- Extend How extension packages are planned to add tools, skills, hooks and connectors to Hypervibe without adding authority, and what is still open for package authors.
Reference
- Reference What the reference section will hold, from the hyper command tree to error codes and legacy aliases, and why only qualified entries become executable reference.
- Commands The planned hyper command line, its command families and the trusted !hyper composer prefix, and why no command is executable reference yet.
- Standings What each standing on these pages means, and what does and does not count as evidence for it.
- Glossary The words Hypervibe uses, each with one meaning, and the historical names that still point to something real.
Architecture
- Architecture How Hypervibe's components fit together, who owns each decision, how the parts talk, where state lives and which boundaries keep it safe.
Troubleshoot
- Troubleshoot How Hypervibe is designed to report refusals, unavailable actions and outcomes that are not confirmed yet, and where to look first when something goes wrong.