Lesson 4: Remote delivery and Player

This lesson delivers the Packaging Workstation from the first three lessons to another machine, then opens its Home Page in Player. The Runtime manual is authoritative for shared configuration and access rules; this lesson keeps only the steps needed for the continuous example.

What you will accomplish

• Confirm the people, equipment, and downtime boundary for remote delivery
• Bind the current App to the correct remote runtime target
• Deliver and start the saved version with a Release Build
• Connect Player to the runtime target, open Home, and accept the terminal

Before you start

• Complete Lesson 3: QG flows, Object calls, and debugging, and save the changes intended for delivery.
• Obtain the remote target name, access address, and a trusted secure connection.
• Have a target administrator own connection and delivery. See Runtime target accounts and permissions.
• Obtain the Player installer appropriate for the field terminal.
• Confirm whether this is a test or production machine, plus the downtime window, license, backup, equipment safety conditions, and recovery owner.

warning

Remote delivery can replace an App already on the target and can lead to physical equipment actions. Do not Build, Start, Debug, or Stop until the target and site state are confirmed.

Step 1: Create the delivery checklist

Start a new AI Command Center task and send:

Perform a read-only remote-delivery review of the current Packaging Workstation App.

List:
- Build blockers and unconfirmed changes in the saved project
- Home Page, roles, equipment, QG, timeout, fault, and recovery checks that require human acceptance
- Runtime target, license, network, downtime-window, and Player facts that the site owner must provide

Do not edit files, connect or switch a runtime target, Build, Deploy, Start, Debug, or Stop.

Turn the response into a checklist. The target address, account, password, certificate risk, equipment direction, and Safety conclusion must come from the responsible people, never from AI guesswork.

Step 2: Connect the remote runtime target

1. Open the Runtime target selector in the editor toolbar.
2. Follow Connect a remote runtime target to add, check, and connect the target.
3. Verify the target name, access address, machine information, and Admin access.
4. Record whether it is a test or production target and who approved this delivery.

Connection selects where later actions operate. It does not upload the project or change local files, Git, or AI conversations.

Step 3: Build Release and run

1. Save all delivery content and record the current version baseline.
2. Confirm that the App is Stopped and the toolbar still shows the verified remote target.
3. Select Build Release from the Build menu.
4. If another App is already on the target, verify the target, both App names, and the downtime plan before approving replacement.
5. Wait for Build to succeed, then confirm that Problems has no delivery-blocking error.
6. Select Start and wait for Running.
7. Open that target's runtime page and verify Home, navigation, roles, normal flow, faults, and recovery.

A Release Build is for delivery acceptance and does not support QG source breakpoints. If acceptance fails, Stop, return to the project, repair it, and Build again. Do not hide a problem by repeatedly selecting Start.

Step 4: Configure and accept Player

1. Install and open Player on the field terminal.
2. Follow Use Theseus Player on a site terminal and enter the access address of the same runtime target.
3. Enter the runtime page with the site-approved runtime-target account. If the App uses business roles, sign in to the operator identity with the appropriate App user.
4. Open Packaging Workstation Home and confirm that Player records the correct Page binding.
5. Close and reopen Player, then confirm that it returns to the same target and Page.

Player displays an App already delivered to the target. It does not edit or Build the project and is not a project backup.

Delivery acceptance checklist

• Target name, address, test/production classification, and approver are confirmed
• The current session has target-administrator access; ordinary runtime accounts are configured separately
• Release Build succeeds and Problems has no blocking error
• Replacement, downtime, and recovery plans are approved
• The runtime page and Player show the same App and Home Page
• App users, Page roles, and operator journeys are verified with real accounts
• Normal, boundary, fault, Stop, and recovery scenarios are complete
• License, network, equipment, and Safety results are recorded

If something goes wrong

Symptom	Continue here
The target is unreachable or connection fails	Connect a remote runtime target
You are signed in but lack permission	Runtime target accounts and permissions
Build, Start, or runtime state fails	Build and runtime acceptance
Player cannot enter the target or Page	Use Theseus Player on a site terminal
Page roles do not behave as expected	App users, roles, and runtime-page sign-in

After this lesson, record the customer-delivery baseline through Version control reference and preserve the field acceptance results.