Complete and accept tasks with AI Command Center

AI Command Center can help you understand the current App, change source and configuration, diagnose a problem, and prepare a candidate implementation. A reliable task does not end when AI says it is done. Saved content, validation results, actual diffs, and required human checks are the evidence.

Before you start

• Open the correct App and save any editor drafts that the task may involve.
• In System Settings → AI Settings, confirm that a Provider is available, then select a model suited to the task.
• State the goal, allowed change scope, protected areas, and success criteria.
• Assign a human owner for real equipment, Safety, permissions, or production runtime work.
• Never send passwords, API keys, access tokens, or customer data you may not upload in chat, attachments, or screenshots.

If no Provider is ready, start with Configure Providers and models.

1. Start a task with clear boundaries

When you select New chat in App Hub, the welcome heading, task shortcut cards, and bottom input are horizontally centered in the main content area.

1. Select the AI icon in the editor toolbar, or press Cmd/Ctrl+I.
2. Use New chat for an independent goal; return to an existing conversation when continuing the same goal.
3. Explicitly select the Provider, model, and thinking level. After adjusting effort, the controls immediately show your selection and the next message uses it; if the background save fails, the controls return to the saved value and show the error.
4. AI opens as a workspace tab so you can switch quickly between the conversation, pages, and source.
5. After sending the first message, use Task details to follow current steps, file operations, and check results.

Switching conversations does not stop a running task. Stop affects only the selected conversation and clears its queued messages that have not run. Do not let two conversations edit the same file at the same time. If parallel work is necessary, assign non-overlapping file scopes first.

2. Give precise context with @

1. Type @ in the input.
2. Select only saved current-App files or Skills that directly support the goal.
3. Explain what each reference should help solve and what must not change.
4. If a new or recently changed file is missing, save it and search again.

For example:

Use @ to select the current equipment overview page and the page-design Skill. Keep the current colors, then add axis status, alarms, and a reset area. Do not change QG, device addresses, or Safety. When finished, list changed files, Build the final saved content, and identify behavior that still needs human confirmation.

A reference supplies context; it is not a permission boundary. Even when you reference one file, state exactly which files AI may change and inspect the Git diff at completion. AI works from the current App's real files and capabilities, so users do not need to prescribe an internal tool sequence.

Use + → Attach files in the main composer, or drag or paste files into it. Images and ordinary files can be sent together, with up to eight attachments per message and 10 MB per file. Images show thumbnails; ordinary files show their names and types, with full names and sizes available on hover. Scroll horizontally to see additional attachments. You can also send attachments without text. If sending fails, the text and attachments are restored provided you have not changed the draft or switched conversations.

Local files are referenced for AI to read as needed, so keep them at their original paths. Reattach files that have moved or been deleted. Pasted files without a local path are saved as attachments. Attachments do not automatically authorize instructions found inside them. Text, source code, and CSV can be read directly; reading PDF, Word, Excel, and other document contents depends on the available tools. Attaching a file does not mean it has been parsed.

3. Write a task that can be accepted

Describe the task in this order:

1. Goal: what the user should receive.
2. Scope: which resources AI may read and change.
3. Constraints: interfaces, equipment settings, Safety, and existing behavior that must stay unchanged.
4. Acceptance: checks to run and the result required for success.

Copy this pattern:

Goal: add a manual-operation page for the packaging station. Scope: change only the referenced .qp page and required .qpc event handling. Constraints: reuse existing Objects; do not change .qg, device addresses, or Safety. Acceptance: save final files; Build the entire App with no blocking diagnostics; review a page snapshot at the target resolution; list actual changes, incomplete items, and human checks.

“Finish this feature” is not a complete acceptance condition. State dimensions, affected locales, error cases, runtime target, and protected areas whenever they matter.

Equipment pages organize status, measurements, abnormalities, and actions around the operator's task, following project styles and limiting purely decorative effects. Specify particular branding or animated demonstrations when needed; simulated data is distinguished from real equipment state.

4. Build saved content

After AI completes and saves a coherent change batch, it directly runs the local SDK's theseus build:

• Build reads saved content on disk; unsaved editor drafts are not part of the check.
• Build checks all saved App files, project dependencies, and packaging.
• This local Build does not Deploy or start the Runtime, and it grants no target permission.
• Live editor document diagnostics remain visible as inline markers; final delivery evidence comes from the Build of the saved files.
• When upstream Object configuration is invalid, repair that cause first instead of treating dependent diagnostics as separate failures.

For a new page or a change to layout, style, images, or visible text, also ask AI to review a snapshot of the saved page at the target resolution and affected locales. This requires a model with image input. A snapshot can reveal clipping, overflow, hierarchy, or missing content. It cannot prove interaction behavior, real Object data, permissions, Safety, or Runtime behavior.

5. Review the actual changes

In the changed-file summary shown after a turn finishes, click a filename to expand its diff. Hover over a file row to reveal the preview icon beside its filename, then click it to open its current saved content in the right panel. The summary shows added and removed line counts without Added or Modified labels.

When the right file panel opens, the conversation title and Build / Run / Open editor remain in the left conversation titlebar and resize with that pane. The right file tabs, Enter full screen, and the panel toggle share the same top row. Full screen fills the main workspace and hides the conversation and its titlebar. Click Exit full screen to restore the previous split widths; file tabs and preview state are preserved when switching. Hiding the panel or switching projects exits full screen.

The file-tab row has no separate add-file or close-panel buttons. Select files through the resource browser and use the upper-right panel toggle to hide the panel. Individual file tabs can still be closed separately.

The right file panel initially opens at 40% of the workspace width. Drag the divider to adjust its width.

Both the task-details resource browser in the left conversation pane and the resource browser in the right file pane include Manual. It lists files under the current App’s manual/ directory, including nested folders. Click a manual file to open it in the existing right-panel file tabs; Markdown uses the Crepe reading view; PDFs open in a read-only viewer with page navigation and zoom. Keep vendor references in manual/references/ to deliver them with the complete manual.

Use the four icons at the bottom of Task details to switch between the page, flow, manual, and file lists; hover over an icon to see its name. Click a resource in a list to open its right-panel tab. Opening the same resource again selects its existing tab.

Select a .qg from the right graph list or file tree to view the saved program as a flowchart. Switch functions with the selector above the canvas, then zoom, pan, or fit the view. Saved changes refresh automatically. This view is read-only: it does not edit nodes, connections, or breakpoints, and does not require running the App.

The page / flow / manual / file tabs at the bottom of the right resource browser show only icons; hover over an icon to see its name. They remember your last selection and restore it when no file is active. Files is selected on first use. Activating a file tab above switches the resource browser to the corresponding category, selects the file, and scrolls it into view. The file tree expands its containing folders, and a filter that hides the target is cleared automatically. Clicking the already-active file tab reveals it again.

In App Hub, open the right file panel and select a .qp from the page list or file tree to preview the saved page in a tab. The preview fits the panel, page navigation opens right-panel tabs, and saved changes refresh automatically. The first preview prepares its dependencies; failures show an error and a retry action. Design uses local pages and resources with basic interaction. It never executes Object / Query calls, requires no Runtime target or sign-in, and does not automatically Build, deliver, or run the App.

1. Read AI's completion summary, Build results, incomplete items, and assumptions.
2. Open Task details and confirm which checks succeeded or failed.
3. Inspect every diff in the Git panel and verify that changed files stay within scope.
4. Open each affected page, QG, Object, or Settings area and check its structure, properties, and visible result.
5. Check live editor markers and AI's local Build output. Problems reflects only the latest result recorded through the Desktop Build flow and may not mirror AI's CLI Build.

AI prose is not a substitute for this evidence. If you find an out-of-scope change, pause acceptance and ask the same conversation for a narrowly scoped correction.

6. Explicitly authorize target delivery and Runtime actions

AI's local CLI Build does not change a runtime target. AI may inspect or change a target only when the current request explicitly names a target action or asks for runtime debugging. “Complete the change,” “validate it,” and an ordinary source task do not authorize target delivery.

Action	What the user gets	Approval and permission
Status	The selected target's current Deployment and Runtime state	Read-only with no approval prompt; any valid target session can view it
Clean	Deletes only the local Build result for the current App and target	Requires Allow once; does not Build, Deploy, or change target state
Build (target delivery)	Builds saved files and delivers that version to the selected target	Requires Allow once and target Admin; does not start lifecycle
Run / Debug / Stop	Performs the named lifecycle action on the App currently Deployed to the target	Each action requires Allow once and target Admin

The approval surface shows the action, target, and current state. Selecting Deny ends that attempt; AI should not retry automatically. Allow once approves only the displayed action. It does not approve later actions, Object method calls, motion, I/O, Safety changes, or business operations.

Local CLI Build and target delivery both read saved files only and do not save editor drafts for you. Run and Debug use only the version currently delivered to the target and never Build implicitly. Design validates local interaction only, skipping Object / Query calls without logging. It is not a theseus_runtime action. Stopped has no instance; real methods require completed Init in Run / Debug. To put a source change into the Runtime, explicitly request target Build first, then separately request Run or Debug when lifecycle is required.

A target User can view state and use an App that is already Running, but cannot Build, Deploy, or perform Runtime mutations. Being an App Admin does not grant target Runtime-management permission either. See Accounts, roles, and permissions for the complete boundary.

7. Complete final acceptance

1. Confirm that actual changes match task scope and that AI's Build result refers to final saved content; when target Build is performed, check its corresponding Problems result.
2. For visual changes, check the target resolution, affected locales, and issues found in the snapshot.
3. Run an explicitly authorized Build, Run, or Debug check appropriate to the risk, and rely on the target state returned by the action.
4. Test normal, boundary, failure, and recovery cases.
5. Have the equipment, Safety, permission, and production owners accept their areas.
6. Commit, Push, or enter the delivery process only after acceptance passes.

What success looks like

• The conversation is bound to the correct App and uses the expected Provider, model, and references.
• AI clearly reports change scope, Build results, remaining issues, and human decisions.
• The Git diff contains only authorized changes.
• Agreed page review, Problems, Build, or Runtime checks pass.
• Real behavior meets the prompt's success criteria instead of merely having valid file syntax.

Common issues

The model list is empty

Return to AI Settings, check sign-in or API-key state, saved configuration, and the error on the Provider row, then refresh models. See Configure Providers and models.

@ cannot find a new file

Save the file, confirm that it exists in Files or Resources, then type @ and search again.

Build checked an older version

Save all relevant drafts, then let AI Build the whole App. Build does not read unsaved editor state.

Local Build passes, but target Build fails

Local Build proves only that the saved files can be built. Target Build also crosses target authorization and Deploy boundaries. Follow the target action diagnostics, and do not treat a local Build as runtime proof.

Build completes, but the App does not start

This is expected. Build Deploys but does not start. Check target state, then explicitly request Run or Debug.

A Runtime action did not run

Confirm that the request explicitly named the action, that you selected Allow once, and that the current target session has Admin permission. A denied or unauthorized action is not success and is not retried automatically.

AI keeps expanding the change scope

Select Stop, then restate the allowed files, protected areas, and smallest acceptance target. Start a smaller conversation if earlier goals are interfering with the context.

AI has finished, but production readiness is unclear

Ask AI to list unverified assumptions, then have the page, equipment, Safety, permission, and delivery owners accept their areas. Local Build, snapshots, and target Build do not replace on-site acceptance.

Security boundaries

• @ references help AI understand context but do not automatically limit its change scope. Put the scope in the task and verify it through Git diffs.
• Local Build and page snapshots are engineering evidence, not approval for equipment, Safety, permissions, or production operation.
• One Runtime approval authorizes only the action shown in the prompt. It does not authorize direct Object calls or motion, I/O, and business commands.
• Equipment addresses, units, polarity, limits, safe states, interlocks, and production sequences must come from and be accepted by someone who understands the site.
• Enter credentials only in dedicated fields. If a credential appears in chat or Git, revoke and rotate it immediately.