See what a change would break, before you make it
A Tessryx app is built from separate pieces, and each one declares what it uses: this page reads that record, this workflow calls that integration. Tessryx stores those links as a graph your AI can query from either end.
Your AI reads the graph before it changes things. Ask it to remove a field or delete an old workflow and it can tell you which pages would notice, or preview the delete and report what would fail. The app below is a real one; hover a piece to see what depends on it.
- custom domain
- endpoint
- workflow
- datafile
- schema
$ analyze_resource --kind workflow --resource birthday/theme --hypothetical delete
deployable: false · errors: 7
- errorworkflow:birthday/home-render would break: steps[0](theme).sub_workflow.workflow references "birthday/theme@published", which would no longer exist
- errorworkflow:birthday/invite-render would break: steps[0](theme).sub_workflow.workflow references "birthday/theme@published", which would no longer exist
- errorworkflow:birthday/admin-render would break: steps[0](theme).sub_workflow.workflow references "birthday/theme@published", which would no longer exist
- errordynamic_endpoint:birthday/home would break: depends on birthday/home-render, which would break
- errordynamic_endpoint:birthday/i/:token would break: depends on birthday/invite-render, which would break
- errordynamic_endpoint:birthday/admin would break: depends on birthday/admin-render, which would break
- errorcustom_domain:birthday.nickpage.tech would break: depends on birthday/home, which would break
How it works
- 01
Ask in either direction
You can ask for everything a page depends on, or for everything that depends on a schema. Each answer says whether a link follows the live version or the draft.
- 02
Preview before acting
A hypothetical delete, unpublish or publish returns the problems it would cause, and an app gets a yes or no on whether it can deploy.
Questions
Can I see this graph in the dashboard?
Not yet. Today it is a tool your connected AI uses, which is where the question usually comes up.
Does it block a delete that would break something?
It doesn't. Deletes always go through. The analysis is there so you or your AI can decide first, and a piece left pointing at something deleted fails with a clear error.
Under the hood
The technical details
- get_resource_graph
- Walks depends_on (default depth 3) or depended_on_by (transitive), showing each edge's @published or @latest text and what it resolves to now.
- analyze_resource
- Findings with severities, a deployable flag, and hypothetical delete, unpublish and publish previews. Read-only.
- declared, not inferred
- Edges come from the references each definition declares; values computed while a workflow runs are reported as unknowable rather than guessed.
- deletes
- Never blocked and never cascade. Anything left pointing at a deleted piece fails cleanly.
Related features
Apps: one project, managed as a unit
An app gathers a project's pieces, from its data to its pages and schedules, into one place you open and manage together. New pieces in the project's folder join automatically.
Version history and rollback
Each saved change to a page, a workflow, an integration, a schedule or an app becomes a numbered version. Going back means publishing an earlier one.
Drafts and publishing
Your changes are drafts until you publish them. You can try a draft with real data first and then publish the version you checked.
Publishing refuses broken references
If a page or workflow points at something that doesn't exist or was never published, publishing it is refused, with the reason. Drafts can still be saved in any order.