| name | vitehub |
| description | Build and debug complete ViteHub apps from live docs and installed contracts. Use for server primitives and Runtime Helpers; Agent Definitions, Drivers, Capabilities, Workspaces, Sources, Channels, Triggers, or orchestration; Vite/Nuxt integration, Provider Output, previews, hosts, and deployment. |
ViteHub
Use one proof loop: orient, route, inspect the contract, build, and prove. Exact package exports, installed types, and current raw docs outrank remembered or project-example syntax.
1. Orient
- Inspect the package manifest, lockfile, Vite or Nuxt config, server entry, and nearby project instructions.
- Identify installed ViteHub packages and versions, package manager, framework, host target, and requested outcome.
- Open
https://vitehub.dev/llms.txt, then select the smallest raw Markdown page covering the primary behavior. Links inside references are selection menus; do not open every linked page.
Orientation is complete when the current setup, target outcome, host boundary, and first docs URL are named.
2. Route before code
Choose one primary lane. Server Primitives serve application behavior through Vite Integrations and Runtime Helpers. Agents serve model-backed, harness-backed, or custom-run behavior through Agent Definitions; they may compose Server Primitives without changing the primary lane.
Read only the references whose conditions match, but read them before writing code:
| Task condition | Required reference |
|---|
| New project, uncertain file layout, or cross-feature composition | Project shapes |
Released or pkg.pr.new installation, upgrade, or package mismatch | Installed and preview contracts |
| KV, Blob, Database, Env, Email, Queue, Rate Limit, Sandbox, Shell, or another Server Primitive | Server Primitives |
| Modify an existing framework integration; add Nitro or Nuxt; use generated types; configure a provider; or diagnose a framework-specific failure | Framework composition |
| Agent Definition, Agent Driver, Agent Invocation, instructions, output, hooks, or Evals | Agent Definitions and Drivers |
| Workspace, Source, access scope, mounted files, or write-back | Workspaces, Sources, and access |
| Channel, Trigger, webhook, messages, admission, concurrency, or delivery | Channels and Triggers |
| Capability, tool, secret, rate limit, telemetry, or other granted authority | Capabilities and authority |
| Schedule, Workflow, orchestration retry, idempotency, or terminal state | Schedules, Workflows, and Invocations |
| Box, trusted host, isolation, required command, or deployment target | Boxes and hosts |
| A proof has failed, generated state disagrees, or a runtime/host failure needs diagnosis | Proof and recovery |
| Looking for a complete public application pattern | Project patterns |
Existing @vitehub/*, @vite-hub/vite, or individual hubX() composition | Migration quarantine |
Routing is complete when every requested behavior has one primary lane and every matching reference has been read. Do not load the whole library.
3. Inspect the installed contract
- Read each installed package's
package.json, exports, relevant types, and generated declarations before writing imports or options.
- For a fresh application, install
vite-hub and use its root integration plus feature subpaths. Use direct owner packages only for a focused library, an unexported advanced subpath, or an installed older contract.
- When docs, examples, and installed artifacts disagree, implement the installed artifacts and record the mismatch. Treat project examples as patterns whose imports must be revalidated.
Contract inspection is complete when every planned package, import, option, generated path, and runtime entry exists in the installed graph; no syntax is inferred only from memory.
4. Build the coherent file set
Before editing, map every requested behavior to:
| Behavior | Package owner | Source file | Runtime path | Authority or persistence | Proof |
|---|
Then implement the smallest coherent set: manifest and lockfile, framework integration, discovered Definition where needed, application or orchestration entrypoint, and proof surface. Keep application authority in application code; grant an Agent access only through visible Capabilities, Workspace rules, Sources, Channels, or Box configuration.
Building is complete when every requested behavior has an implemented row and no placeholder, unused integration, implicit authority, or unowned persistence remains.
5. Prove and repair
- Run the narrow typecheck or package test nearest the change, then the relevant build.
- Prove the actual lane: execute the Runtime Helper, perform an Agent Invocation, exercise the webhook or schedule, or inspect generated Provider Output.
- On failure, return to installed exports/types,
.vitehub generated state, the selected raw docs page, and Proof and recovery. Repair the cause and rerun the same proof.
The task is complete when every behavior row has an observed result, or a precise source-backed unsupported boundary. Report commands and observations, docs URLs, installed ViteHub versions or preview commit, contract mismatches, and host limitations.
