Creora

Creora is a place to build a small web app by describing it, and then to do the things a real app needs: publish it at an address of its own, give it a database and accounts, push it to GitHub, and launch a token for it on Robinhood Chain. You sign in with an Ethereum wallet, open a project, and an agent with file tools writes the app while you watch it run beside the transcript. What it writes is yours: the files are in a version history, in a zip, in your repository if you push them, and at a public address if you publish them.

These pages describe what Creora does, how to run it, and how to look after a copy of it. They are the same pages a developer reads in the repository under docs/, and the site serves them at /docs.

Reading order

Start with the first two if you are running Creora, and with the third if you are using it.

• Getting started: requirements, setup, the first run, and the scripts.
• Configuration: every setting, what it does, and which features it turns on.
• Building: projects, the editor, the preview, versions, checkpoints and downloads.
• The agent: how a run works, its tools, its limits, and the keys it runs on.
• Identity: wallet sign in, sessions, usernames, profiles and account deletion.
• Credits: what a run costs, the plans, and the ledger behind them.
• Publishing: public addresses, snapshots, the explore page and search.
• Community: the forum, moderation and achievements.
• Project databases: a Postgres schema per project, the data tools, the public data API and end user accounts.
• GitHub: importing a repository and pushing a project back.
• The API: every endpoint, its conventions and its errors.
• Architecture: how the server is put together, the job queue, the security headers, and what is per process.
• Testing: the suite, the gates and continuous integration.
• The server: the live machine, how to update it and how to look after it.

The launchpad

The token launchpad has its own set of pages, starting at the launchpad overview: how it works, the contracts, deploying them, the app around them, operating it and testing it.

How these pages are written

Every page describes what the code does today, checked against the code, with the real limits and defaults. Where something is deliberately not built, the page says so in a sentence rather than leaving a gap. A feature that is off until it is configured says what turns it on and what happens without it.