Build, remote Runtime target, and Player

This final tutorial turns “it runs on the development machine” into “it is accepted on the target machine and runtime terminal.” AI checks the local project and build diagnostics. You own the target account, remote deployment, Start, and Player binding.

What you will accomplish

• Distinguish Build, Runtime target, deployment, and Player
• Ask AI to perform a pre-delivery project review
• Restore and approve a critical timeout parameter yourself
• Connect to a remote RuntimeHost and build for its RID
• Upload the runtime package through Start
• Select a page in Player and bind the terminal to it

Four concepts are enough for now

Concept	Purpose
Build	Prepares Page Methods, Graphs, custom code, and PLC sources as a runtime package the target can load.
Runtime target	The RuntimeHost used for deployment, run, debug, and runtime administration. It is local by default and can be switched to a remote host.
Deployment	Uploads the desktop-built runtime package to the active target. There is no separate Deploy button in the title bar; Start and Debug perform the required build and upload first.
Player	A terminal shell for runtime pages. It contains no editor and does not build projects locally.

Before you start

• Complete Simulated Object, Graph, and Debug.
• Make sure the remote RuntimeHost is reachable through a trusted HTTPS origin. Protected remote management operations such as deployment, Debug, and Stop require HTTPS.
• Have a target administrator account, or use a current Qixin login already bound to a target administrator.
• Install Theseus Player on the terminal. Windows also requires Microsoft Edge WebView2 Runtime.

Step 1: Ask AI for a delivery-readiness review

Keep the app Stopped and note the changes already present in Git or Task details. In AI Command Center, select qxauto and mention the home page, Packaging Workstation Graph, and simulator script if one exists. Send:

Goal: Review the current Packaging Workstation app for delivery readiness and repair only blocking local authoring issues.

Review scope:
- Confirm that the Home page exists and that Page Methods, widget expressions, and object references are valid
- Confirm that the Packaging Workstation Object description and Graph binding are clear
- Inspect Graph Success, Timeout, Init, and Dispose paths
- Run current page and graph diagnostics
- Run the App Build only while the app is in a Stopped or buildable Error state

Allowed:
- Repair only current-app source issues required to pass diagnostics and Build
- Revalidate and rebuild until successful or until an explicit blocker is identified

Forbidden:
- Do not add, connect, or switch Runtime targets
- Do not deploy, Start, Debug, or Stop a remote app
- Do not change target accounts, licenses, certificates, Player settings, PLC addresses, Pulsar, or Safety
- Do not hide errors or add broad fallbacks

Output:
- Changed files
- Diagnostics and Build results
- A delivery checklist for Home, Object, Graph, and timeout parameters
- Items that still require human approval

The expected result is usually no new feature: diagnostics and Build pass, and AI identifies the human approval items. Stop if it proposes process or Safety changes and route them to the responsible engineer.

Expected AI impact

• With no blocker, AI may change no files.
• With source diagnostics, it should change only the confirmed Page, Graph, simulator Object, or related i18n.
• AI may run the App Build, but it must not connect a remote target, upload, Start, Stop, or configure Player.

A successful Build proves that artifacts can be produced. It does not prove process or safety correctness.

Your manual adjustment: Restore the release timeout

The previous tutorial forced an object override of 500 ms. Restore and approve it before delivery:

1. Select the Packaging Workstation object under Resources → Objects.
2. Change its cycleTimeoutMs override to 3000, or clear the override to use the graph default of 3000.
3. Save the object configuration.
4. Run the normal path once with local Debug, confirm success, and select Stop.

This decision intentionally remains human-owned. Its value comes from process and field validation, not from the fact that AI generated it.

Step 2: Add and connect the remote Runtime target

1. Select the current Runtime target name to the left of the title-bar runtime controls.
2. In Manage Runtime Targets, select Add target.
3. Enter a name and Origin. Do not include /api. Use a full production HTTPS origin such as https://runtime.example.com.
4. Select Save.
5. Select Check for the new target and confirm that it is Reachable and reports a RID.
6. Select Connect and follow the UI to initialize or sign in with the current login or a target account.
7. Complete the connection with an account that has management access and confirm that the target is marked Selected.

Switching targets changes only the execution target for the current desktop process. It does not redirect developer sign-in, files, Git, AI, or LSP to the remote host.

Step 3: Build for the target and start

1. Confirm that the title bar shows the remote target name and cloud icon.
2. Confirm that the app is Stopped and every file is saved.
3. Select Build. The desktop reads the remote runtime identifier and prepares platform-specific output for that RID.
4. Wait for Build to succeed. If it fails, inspect Problems, repair, and try again.
5. Select Start.

Start rechecks the required artifacts, creates a deploy package, uploads it to the active RuntimeHost, and runs the deployed app. It is normal for the remote target not to contain the app before its first deployment. Opening the editor alone never uploads it.

Wait for the title-bar status to become Running before testing Player.

Step 4: Bind the runtime page in Player

1. Start Theseus Player.
2. Enter the complete origin under RuntimeHost address, for example https://runtime.example.com or a controlled LAN test address such as http://192.168.1.10:9210. Do not enter /api or a page path.
3. Choose the terminal language and select Continue.
4. Complete Runtime target initialization or account sign-in inside the runtime view.
5. Open Packaging Workstation from the runtime app list. If the page has role restrictions, sign in with the appropriate App user as well.
6. When the Home page opens, Player records the same-origin /apps/{appId}/pages/{pageId} path and binds this terminal to that runtime page.
7. Exit and restart Player. It should return directly to the bound Packaging Workstation home page.

The Runtime target account and App user are separate identities. The first grants access to the app list on the target; the second grants access to role-protected pages inside an app.

Delivery acceptance checklist

• The remote target is Reachable, Selected, and reports the expected RID
• An engineer restored and approved cycleTimeoutMs
• Page and Graph diagnostics have no errors
• Build succeeds for the target RID
• Start moves the remote app to Running
• Player can sign in, find Packaging Workstation, and open Home
• Restarting Player returns directly to the bound page
• The terminal test covers normal cycle, Fault, and ResetFault
• The responsible owners approved field accounts, certificates, licensing, networking, and backup policy

Safety boundary

danger

AI must not select a production Runtime target, enter accounts or secrets, approve certificates, deploy, Start, Stop, or approve Safety. An authorized person must perform and record every operation that changes remote runtime state.

• HTTP can support controlled LAN runtime-page testing, but remote management operations require HTTPS.
• Player is a runtime terminal, not a project backup, and it contains no build tools.
• Deploying the simulated Object to a remote host still produces a simulator. Reopen equipment semantics, interlocks, and commissioning review before connecting hardware.
• A successful Build is not a production-release decision.

Recovery guide

Symptom	Check and recovery
Target Check fails	Check the origin, DNS or IP, port, network, and RuntimeHost. Do not include /api.
The target is Reachable but cannot Connect	Check initialization, account permissions, and HTTPS. Use an administrator for deployment authorization.
Build fails	Keep the app Stopped and inspect Problems. Ask AI for read-only root-cause analysis before approving the smallest repair.
Start reports not deployed or upload failed	Confirm that the intended remote target is Selected, the account has management access, and HTTPS works, then select Start again.
Player cannot see the app	Confirm that the desktop deployed and started the same app on the RuntimeHost configured in Player.
Player says no Home is configured	In editor Resources, right-click packaging-station, select Set as Home Page, then deploy and Start again.
Player cannot load its WebView	Install WebView2 Runtime on Windows. On other platforms, check Player support and network permissions.
The terminal must bind to another page	Use Reconfigure from Player's configuration or error surface, enter the correct RuntimeHost, and select the app page again.

You have now completed the full AI-first loop: express the goal, inspect AI output, make a manual adjustment, verify with Debug, build for a target, start remotely, and deliver through Player.