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

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.
4. Use fullscreen for focused work, or Dock as tab when you want the page or source visible beside the conversation.
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, Validate 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.

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; Validate 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.

4. Validate saved content first

Ask AI to Validate the final saved App after making changes:

• Validate is read-only. It does not Build, Deploy, start the Runtime, or authorize any of those actions.
• Validate reads saved content on disk. Unsaved editor drafts are not part of the final whole-App check.
• Whole-App Validate is appropriate for cross-file checks before delivery; document Validate is useful for locating an error in one supported document.
• Build also checks project resolution and packaging, so a passing Validate does not prove that Build or runtime execution will pass.
• 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

1. Read AI's completion summary, Validate 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 Problems and confirm that final saved content has no new blocking error.

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 Build and Runtime actions

AI may inspect or change a runtime target only when the current request explicitly names an action or explicitly asks for runtime debugging. “Complete the change,” “validate it,” and an ordinary source task do not include this authorization.

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	Builds saved files and delivers that version to the selected target	Requires Allow once and target Admin; does not Preview or start
Preview / Run / Debug / Stop	Performs the named Runtime 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.

Build reads saved files only and does not save editor drafts for you. Preview, Run, and Debug use only the version currently delivered to the target and never Build implicitly. To put a source change into the Runtime, explicitly Build first, then separately request Preview, Run, or Debug.

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 Validate and Problems refer to final saved content.
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, Validate 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.

Validate checked an older version

Save all relevant drafts, then ask AI to Validate the whole App. Validate does not read unsaved editor state.

Validate passes, but Build fails

This can happen because Build also checks project dependencies and delivery preparation. Repair the saved project files using the Build diagnostics, then run Validate and Build again. Do not treat Validate as runtime proof.

Build completes, but the App does not start

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

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. Validate, snapshots, and 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.
• Validate 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.