Artifacts

An artifact is a bundle of static files with an id, an owner, a visibility state and a version history. It is served from the product's own edge plane at https://superart.page/{id}/, and the dashboard that lists it holds none of its bytes.

Addressed by id, labelled by slug

The id is a v4 UUID assigned on first deploy. It is the address, and it never changes.

The slug is how you name a thing — lowercase kebab, three to sixty-three characters. It is a label, not an address. Two people may pick the same slug; {handle}/{slug} is the unique pair, and it maps to an id through an alias. That mapping is what makes deploying the same name twice land on the same artifact rather than minting a new URL every time.

Kinds

Every artifact declares one of six kinds: page, slideshow, survey, tracker, video or tool. The words describe what a visitor does — reads it, advances through it, answers it, adds entries to it, watches it, operates it — rather than what it was built with, because that is the distinction somebody browsing their own artifacts is actually making.

page is the default, and the one that matters most: a single self-contained HTML document is something any agent can produce, including one with no shell.

Chrome, never a renderer

No user-authored code ever runs on the platform's own origin. The dashboard shows artifacts; it never executes them. That separation is not a detail — it is what makes a real access gate possible, because the session cookie and the artifact bytes live on different origins and only one of them is trusted.

It also means artifacts are not styled by this system. They are deliberately free to look like anything, and the design language on the dashboard governs the dashboard only.

Thumbnails

The gallery shows a screenshot of the published version, taken by the worker after the deploy has already answered. A deploy is never held up by a browser and never fails because of one; a missing thumbnail is a placeholder in the gallery rather than an error anywhere.