Onboarding
How GUVIX works
Four steps, in order. Each produces something you can check before the next begins, and each section below says what the step cannot do yet in the same place as what it can.
Token→Computer→AI Builder→Live Application
Step 1
A token
You configure it. Your wallet signs it. GUVIX never holds a key.
What happens
- You enter a name, a symbol, a description, an image and links.
- GUVIX builds the exact instruction set and simulates it against mainnet first.
- You see every account and every instruction before anything is signed.
- Your wallet asks you to approve. Submission is a separate, explicit step after that.
- Nothing is recorded as launched until a signature is CONFIRMED at a stated commitment.
What it cannot do yet
- GUVIX cannot sign for you, and will not generate a wallet to do it. No private key or seed phrase is ever created, stored or requested.
- No launch has been submitted from this build. Submitting one costs real SOL and needs your explicit approval each time.
Step 2
A computer
A real GPU from a real provider, with a ceiling you set.
What happens
- Inventory, pricing and availability are read from the provider and stamped with when they were read.
- You set a spending ceiling before anything is provisioned. There is no default.
- One request carries an idempotency key, so a retry cannot create a second paid instance.
- The machine becomes RUNNING only when the provider confirms it.
- When the ceiling is reached the instance is stopped and the reason is recorded.
What it cannot do yet
- No provider credential is configured in this environment, so inventory is empty and reservation is unavailable.
- GPU time is never free. The provider charges by the second or the hour and GUVIX shows that cost before you commit to it.
Step 3
An AI builder
Describe the product. An agent plans it, writes it, checks it and reports every step.
What happens
- A build moves through CREATED, QUEUED, PROVISIONING, RUNNING, TESTING, DEPLOYING, COMPLETED.
- Every state change is written together with the event that caused it, naming the worker process.
- Generated files are validated by GUVIX's own checks: the markup, every local asset reference, and each file's hash.
- The log on the project page is those rows and nothing else.
What it cannot do yet
- No model credential is configured, so a language model is not planning anything. A deterministic, rule-based planner runs instead and every job it touches is labelled with which planner produced it.
- Generated code is never executed on this host. There is no container runtime here, so the executor refuses rather than running it beside the database credentials.
Step 4
A live application
A url, and a health check that passed. Both, or it is not complete.
What happens
- The built files are served and then fetched over HTTP, as a real request to a real server.
- A 200 with an empty body is not a pass either; the response has to carry content.
- The url, the status and the instant it was checked are all recorded and shown.
What it cannot do yet
- COMPLETED is refused by the database unless the row carries a url, a check instant and a status between 200 and 399. It is a CHECK constraint, so a refactor cannot drop it.