Apps

An app is a project (a storefront, a blog, a marketing site) gathered into one place. It groups the related pieces (the data, the pages, the logic, the integrations) so you edit and manage them as a single unit rather than hunting for them one by one.

#What an app gives you

• One editing surface. Opening an app gathers its members in a sidebar grouped by kind (schemas, content, pages, workflows, schedules) where you jump to any of them, create new ones right inside the app, and edit the app's own definition, all without leaving the project.
• A front door for your domain. A custom domain points at an app, which is how Tessryx knows which pages to serve at your address.
• A clean boundary. Analysis and cleanup happen at the app level: "is this whole project sound and ready to publish?" is a question about the app.

#How membership works

An app is a live lens, not a container. It doesn't own its pieces or freeze their versions. It names a rule, and the current set of pieces matching that rule is the app. Add a matching piece and it joins automatically; remove it and it drops out. Nothing is ever "moved into" an app.

The rule is built from three parts:

• Folder rules: every piece whose slug sits under a path is a member: "everything under storefront/." A rule can be scoped to certain kinds (just the pages, say, not the schemas).
• Includes: specific extras pulled in from outside those folders, such as a shared workflow two projects use, or the app's own front door. The page whose slug is exactly the project name sits at the root, not inside the folder, so it's named explicitly.
• Excludes: specific pieces a folder rule would otherwise sweep in.

An app can also carry light presentation for the studio (an icon and accent color), and list the custom domains it's served at, a claim that this app serves there; the routing itself lives on the domain.

#Publishing an app

Publishing an app promotes the grouping: which pieces belong. It does not publish each piece inside it; those go live on their own, when you publish them. So an app can be set up while its pages are still drafts. See Publishing.

Do you need one? For anything with more than a couple of pieces, yes. It keeps things organized as the project grows. For a one-off, your agent may skip it. When in doubt, group.

#Exporting and importing an app

An app can leave as a file. From the app's page, Export walks its membership and hands you a single zip: the app's definition plus the current draft of every member (schemas, content records, workflows, pages, integrations, schedules) as plain, readable JSON. It's the whole project as definitions, which is also why an agent can read it, translate it, or help you rebuild it somewhere else.

Three things deliberately don't travel:

• Secret values. The bundle names the secrets the app's integrations use, so you know which to add on the other side, but the values themselves are never read or exported.
• Media files. Content may reference media by URL; the bytes stay in the workspace that owns them. Re-upload on the other side, or point the references at their new home.
• Custom domains and internal ids. Cross-references are carried by slug and re-resolved on import, so the bundle isn't tied to the workspace it came from.

Import, from the Apps list, re-creates the app and its members in whichever workspace you're in, in dependency order so references resolve as it goes. Before anything is created you see a review of exactly what will be created and what will be skipped. A piece whose slug already exists in the target is skipped, never overwritten, so importing into a busy workspace can't clobber real work. Nothing is published on import; you (or your agent) publish once it holds together, as with anything else. Secrets the bundle names are listed so you can add them, with their own values, in Secrets Manager.

Handing a client the site you built them, moving a project between workspaces, or shipping a working starter to someone else is the same three steps: export, send the zip, import.

#Deleting an app

Because an app is a lens and not a container, deleting the app removes only the grouping. Every schema, page, workflow, and datafile it gathered stays exactly where it is, and you can regroup them under a new app at any time.

When you actually want the project gone, the app's settings offer a separate Delete all content action. It walks the app's membership, deletes every piece it owns one by one (you watch the progress as it goes) and then removes the app itself. This one is permanent and cannot be undone, so it asks you to type the app's slug to confirm first.