From editing to runtime
In Theseus, “saved,” “built,” and “used by the machine” are three different facts. This distinction prevents the most common question: “I changed it, so why is the machine still behaving the old way?”
Why this matters
The editor can contain the latest design while the runtime target is still using the previous deployed version. An AI file change or a refreshed editor preview does not replace the running Object instance. Understanding the lifecycle helps you choose Build, Run, Debug, or Stop instead of repeatedly saving and refreshing.
When you will encounter it
You need to identify the current layer when:
- you or AI changes a Page, Graph, Object, Script, PLC program, or module setting;
- the Navbar shows Build, Run, Debug, Pause, Continue, or Stop;
- you use a local or remote Runtime target;
- Theseus reports that the runtime is not loaded, an artifact is stale, or the App must be stopped first;
- the editor and runtime page appear to show different versions.
Six key concepts
| Stage | What happens | What does not happen |
|---|---|---|
| Editing | You and AI change the current App; editor views and diagnostics refresh after a save | The running Object instance is not replaced automatically |
| Build | Theseus validates source and generates build outputs for Graphs, custom code, Page methods, PLC, and the runtime package | The App does not start and no device action is executed |
| Deploy | The desktop sends the prepared runtime package to the active Runtime target | Deployment alone does not mean the App is running |
| Materialize | The Runtime target loads the deployed version into memory and prepares its Objects, modules, and runtime state | The normal or debug lifecycle does not start |
| Run | Theseus prepares, deploys, and loads what is needed, then starts the App in normal mode | Graph breakpoint debugging is not enabled |
| Debug | Theseus prepares, deploys, and loads what is needed, then starts the App in debug mode | Real device actions are not bypassed, and correctness is not guaranteed automatically |
Think of the order as:
Edit and save → Build → Deploy → Materialize → Run or Debug
You usually do not need to perform every step manually. Run and Debug in the desktop prepare artifacts and deploy them to the active target as needed. An explicit Build is useful when you want to find problems before starting. Some online settings, diagnostics, or status messages mention Materialize; it means “the runtime is loaded,” not “the App is running.”
The authoring/runtime boundary
- After a save, the editor has the latest design. A deployed runtime page still uses the runtime package on its target.
- An editor preview may refresh immediately, but that does not prove that a remote Runtime target received the new version.
- Graph, custom-code, and PLC changes need valid build artifacts. Run and Debug check those artifacts and do not start when preparation fails.
- Object, module, and other runtime-model changes enter a new runtime instance through the next Materialize, Run, or Debug after the App has safely stopped.
- The current object tree is not replaced while the App is Running, Debugging, Paused, Starting, or Stopping. Stop first, then build or start the new version.
- Debug Paused still occupies the runtime. You may Continue or Stop; it is not the same as Stopped.
Which action should you use?
| Goal | Action |
|---|---|
| Check whether Graph, code, or PLC source can produce valid build outputs | Build |
| Validate screens and equipment workflows normally | Run |
| Use breakpoints, pause, inspect values, and diagnose a Graph step by step | Debug |
| Apply a new runtime model while the App is currently active | Stop, then Run or Debug |
| Load an already deployed version for an online capability without starting the lifecycle | Materialize, normally triggered by the related operation |
Before starting, confirm that the Navbar shows the correct Runtime target. Local and remote targets have separate deployed versions, runtime state, and account sessions.
Common misconceptions
- Build is not Run. A successful build only proves that required outputs can be generated.
- Materialize is not Run. It loads the runtime without starting the normal lifecycle.
- Stopped does not always mean never loaded. An App can be materialized while its lifecycle remains Stopped.
- Save is not Deploy. AI and manual saves update authoring state; the runtime target still requires an explicit runtime workflow.
- Selecting a remote target does not move the editor to that machine. App source stays on the desktop; the remote host is only the active execution target.
- A healthy-looking runtime page does not prove that Debug passed. Test the normal, error, and timeout branches of critical workflows.
Next step
- Complete one Build, Run, and failure diagnosis with The build flow.
- Practice breakpoints, Pause, and Continue in Graph automation.
- Read the Runtime target and deployment guidance in App management before using a remote host.