Univer AI Agent Integration Go-Live Checklist: 2026 Mac Browser Regression

The Agent reports success, but the edited cells still look unchanged—or the page may have saved only part of the operation.

Fastest route: verify editor state, Agent permissions, Mac browser interactions, interruption recovery, and reproducible evidence as separate release gates. Do not approve a launch based on a successful demo; run regression only against the browsers and deployment environments your product actually supports.

This guide is for:
- Univer developers checking how an Agent behaves while editing documents.
- QA engineers building Mac browser regression cases and recording failures.
- Product and engineering leads confirming that permissions, recovery, and release evidence are adequate.

Define acceptance around real editing workflows

Start from tasks users will perform, not from an Agent feature list. Select representative spreadsheet, document, or presentation workflows from the product’s actual use cases. For each workflow, write down what the user initiates, what the Agent is allowed to do, and what the user must review or confirm.

For example, a spreadsheet workflow might begin with a user asking the Agent to update a specified range. The acceptance case should identify the intended range, expected values, whether formatting may change, and how the user can tell the operation is complete. A document workflow should distinguish content insertion from formatting changes or deletion. A presentation workflow should record whether the Agent is expected to create, alter, or only suggest slide content.

Keep implementation claims inside the boundary of verified product behavior. Univer’s official repository and spreadsheet quickstart documentation describe the product and documented setup path. They do not prove that a particular Agent integration can safely read or change every editor state. Verify those behaviors in the application under test. Treat a custom command or another extension point as a mechanism to investigate, not as proof that your Agent already has the required permissions or reliable state access; consult the custom command extension guide for the documented boundary.

Before running tests, write a short workflow contract for each case:

• User input: the request and any selected range, document, or slide.
• Agent action: the permitted operation and the objects it may affect.
• Expected result: the visible change, unchanged state, and save behavior.
• User control: how to cancel, review, or reject the operation.
• Evidence: screenshots, relevant logs, and before-and-after editor state.

This keeps “the Agent did something” from being mistaken for “the Agent completed the requested task correctly.”

Check editor state and data consistency

A convincing interface message is not enough. The editor state must let a tester verify both the intended change and the absence of unintended changes. Use a controlled document with a known starting state, and capture the relevant content and formatting before invoking the Agent.

For each workflow, check the following:

• [ ] Record the input state, including the target cells or content and any formatting that matters.
• [ ] State the expected output precisely enough that another tester can compare it without guessing.
• [ ] Confirm the visible editor result after the Agent action.
• [ ] Check the application’s saved or persisted state using the verification method available in your product.
• [ ] Confirm that content outside the authorized target remains unchanged.
• [ ] Capture the result of a successful operation, a user cancellation, and a repeated request.

These cases answer different questions. A successful operation checks whether the intended change appears. Cancellation checks whether stopping an operation leaves a clear, acceptable state. Repeating the request checks whether a second submission duplicates or compounds the change. Do not treat those outcomes as interchangeable.

For spreadsheets, verify cell values and relevant formatting separately. A correct value in the wrong cell is a failure; a correct value with an unintended formula or formatting change may also be a failure. For documents and presentations, check the affected text or objects and any surrounding material that should remain untouched. The official core spreadsheet features documentation can help identify the documented editor features relevant to a test, but the application’s observed behavior remains the acceptance evidence.

The team should also record how it decides that a result is saved. A visual update may precede persistence, while a delayed update may reflect application behavior rather than an Agent failure. Capture the observable state and the supporting application logs or persistence evidence available to the project. Avoid relying on a toast, spinner, or completion message as the sole proof.

Set permission and misoperation boundaries

An Agent should not be treated as authorized to perform every action simply because it can issue an editor command. Define the permitted scope for each workflow, then test both allowed and disallowed actions.

• [ ] Specify which document, sheet, range, or content area the Agent may affect.
• [ ] Attempt an action outside that scope and verify the actual result.
• [ ] Check whether destructive or difficult-to-reverse operations require the confirmation flow your product intends.
• [ ] Cancel during an operation and inspect whether later actions continue.
• [ ] Review logs or other available evidence to identify what was requested, permitted, rejected, or completed.

Keep policy requirements separate from implementation facts. A product requirement might say that deletion needs confirmation. That requirement does not demonstrate that the current integration enforces confirmation. Conversely, a command being available in the editor does not establish that the Agent is entitled to use it. Record the observed behavior for each path, including denied actions, and route failures to the relevant owner.

A failure must not silently expand the Agent’s impact. If one operation is rejected, verify that the remaining sequence stops or follows an explicitly approved fallback. If the interface cannot make the resulting state clear, treat that as a release concern even when the underlying permission check appears to work.

Run Univer AI Agent acceptance in target Mac browsers

Mac browser testing is meaningful only when the environment is recorded. At minimum, note the macOS version, browser and version, deployment target, account or role, and the test document state. Use the combinations your team supports and your users are expected to run; do not turn one passing configuration into a broad compatibility claim.

Exercise interaction paths that can fail even when the editor loads:

• [ ] Move focus through the editor, menus, dialogs, and Agent controls using the supported input methods.
• [ ] Check whether keyboard shortcuts reach the intended control rather than the page or browser.
• [ ] Scroll inside the editor and any nested panels; confirm the expected region moves.
• [ ] Open and close menus, confirmation dialogs, and other overlays, then inspect focus and dismissal behavior.
• [ ] Check layout at the viewport sizes included in the project’s supported environment.
• [ ] Repeat a representative edit and cancellation flow in the actual deployment environment.

The W3C focus-order guidance describes why focus order should preserve meaning and operability. Use that as a review reference, then verify the interface itself. The Web Inspector documentation explains how to examine web content during browser debugging. An inspection tool helps diagnose a result; it does not replace a recorded end-to-end acceptance case.

If the team uses browser automation, confirm which browser and operating-system combinations the selected tooling actually supports. The browser automation browser guide documents the available browser options. Do not label a run “Mac Safari regression” unless the test ran in that target browser on the recorded Mac environment. A run against another browser or a different execution environment may still be useful, but it is evidence for that environment only.

A nuvcloud service overview can help the team understand the available remote Mac testing context when a physical test machine is not readily available. Before treating a remote result as representative, record the environment details and compare them with the project’s required target.

Compare what each test environment can establish

Use this comparison when deciding where to run a case. The correct choice depends on the question being tested, not on which environment is easiest to access.

Test option	Strongest use	Key limitation	Evidence to record
Local Mac with the target browser	Reproducing a user-facing interaction on the team’s supported Mac setup	A single local setup cannot establish behavior on other configurations	OS and browser versions, viewport, deployment, test account, and observed result
Remote Mac environment	Running a controlled browser regression when the team needs access to a Mac test environment	The environment may differ from a user’s device or network; match and record relevant details	Environment identifiers available to the team, browser details, network conditions, and test artifacts
Non-Mac browser or automation environment	Checking application logic, repeatable workflows, and failures that are not specific to Mac browser behavior	It does not prove Mac browser compatibility	Tool and browser configuration, application build, case result, and a clear scope statement

Automated browser contexts can help isolate test sessions: the browser contexts documentation explains how contexts separate browser state. Use isolation to avoid one test inheriting another test’s cookies or session state, but still verify any application-level persistence that is part of the workflow. An isolated session is not a substitute for testing the actual user role, permissions, or deployment.

Test interruptions and repeated submissions

Recovery behavior needs its own acceptance cases. A task that succeeds when the connection is stable may behave differently after a refresh, network interruption, or page-state change. Choose interruption points that reflect realistic risks in your product, and observe what the editor and Agent do afterward.

• [ ] Begin a representative operation and interrupt it using a controlled test condition.
• [ ] Record whether the interface shows a pending, failed, cancelled, or completed state.
• [ ] Inspect the document before submitting the operation again.
• [ ] Retry only after checking whether any part of the first attempt already changed the data.
• [ ] Verify that a repeated submission does not create an unintended duplicate or additional edit.
• [ ] Compare application logs with the visible editor state and record any mismatch.

The Page Visibility API exposes whether a document is visible or hidden through document.visibilityState; use the Page Visibility API reference when a test needs to investigate behavior after a tab becomes hidden. That browser signal does not decide whether an Agent task should pause, continue, or resume. The product must define the intended behavior, and the test must establish whether the implementation follows it.

Retries require particular care. A test framework retry can help diagnose a flaky test, but it can also obscure whether the first attempt changed application data. Review the test retry documentation and make sure the case detects partial changes before it repeats an action. Record the original attempt and the retry separately; do not report only the final green result if the first run exposed a data-integrity issue.

For each interruption case, specify the expected recovery path before running it. The acceptable outcome may be a clean stop, a clear error requiring user action, or a safe resume, depending on the product design. The acceptance record should state which behavior was expected and what actually happened. Avoid declaring recovery successful merely because the page became interactive again.

Keep a traceable release record

A test result should let another engineer reproduce the scenario and understand why it passed or failed. Use one record per case, with enough detail to identify the starting state, environment, action, and evidence.

Include these fields:

• Case ID and workflow being tested.
• Build or deployment identifier.
• macOS and browser versions, recorded at test time.
• User role and relevant permissions.
• Preconditions, including the document state and selected content.
• Agent request and expected editor result.
• Actual result, including whether the change was saved.
• Evidence links, such as screenshots, logs, or defect records.
• Defect reference and retest status, when applicable.

Set pass criteria with the product and engineering owners. There is no universal threshold that makes every Agent integration safe to release. For one workflow, a clear denial of an out-of-scope action may be essential; for another, the key risk may be duplicate edits after a retry. State which risks block launch, who accepts any remaining risk, and which environments have actually passed.

Re-run affected cases when the editor, integration, deployment, or browser changes. Use the recorded environment to decide which regression cases are relevant, then update the evidence rather than carrying forward an old result. The conclusion should be limited to what the record supports: a passing result for a specific build and tested environment, not a general guarantee for every Mac browser or every Agent workflow.

Frequently asked questions

Which workflows belong in the acceptance suite?

Choose workflows users will actually delegate and that represent meaningful product risk. Include the normal successful path, a cancellation, a repeated request, and an attempt beyond the intended permission scope. The suite should also include a case where a user must review or confirm an operation, if that is part of the product’s intended behavior.

What proves that an online spreadsheet edit is correct?

Compare the requested change with the resulting cell values, relevant formulas or formatting, and any surrounding cells that should remain unchanged. Then verify the saved state using evidence available in the application. Keep before-and-after records. A completion message by itself does not prove that the correct range changed or that the change persisted.

How should a Mac browser regression run be scoped?

Name the browser and version, macOS version, deployment target, and relevant viewport or account details in the run record. Test focus, shortcuts, scrolling, overlays, and layout in workflows that use those interactions. Report only the configurations that were exercised; do not infer compatibility with untested browsers or versions.

What should a team do when an Agent task is interrupted?

Inspect the current editor state before retrying. Determine whether the task stopped, completed partly, or applied its changes, using both visible results and available logs. Then compare that outcome with the recovery behavior defined by the product team. Retry only when the case confirms that doing so will not duplicate or compound an existing change.

For short-lived, repeatable Mac browser regression, a rented Mac environment can be more practical than buying and maintaining a dedicated test machine, especially when the team needs a controlled session for a defined test run. It still requires checking that the browser, OS, deployment, and access conditions match the project’s target. A local Mac is a better fit when tests depend on physical peripherals or a continuously available machine; for a temporary remote run, nuvcloud’s Mac environment options provide a path to arrange the test environment.

FAQ

What should you test after connecting an AI Agent to Univer?

Start with the actual tasks users will delegate, then verify each task’s inputs, permitted actions, visible result, save state, and cancellation behavior. Include an unauthorized-action attempt and a repeated submission. Treat the integration as unverified until the team can reproduce the expected outcome from recorded evidence in the supported deployment and browser environment.

How can you confirm that an AI Agent edited an online spreadsheet correctly?

Capture the relevant cell values and formatting before the action, state the expected change precisely, then compare the visible result and saved state afterward. Also test cancellation and a repeat of the same request. A success message alone does not prove that the intended cells changed or that unrelated cells stayed untouched.

What belongs in Mac browser regression testing for an online editor?

Record the actual macOS and browser versions, deployment target, and test account. Exercise focus movement, keyboard shortcuts, scrolling, menus, dialogs, and layout at the viewport sizes your product supports. Re-run the same scenarios after relevant editor or browser updates, and limit conclusions to the combinations you actually tested.

How should you check recovery when a Univer Agent task is interrupted?

Interrupt a representative task by refreshing, changing page visibility, or disconnecting the network in a controlled test. Inspect the application state and logs to determine whether the task stopped, resumed, or submitted again. Check for duplicate edits before retrying, and define the acceptable recovery behavior with the product team rather than assuming every interruption can be resumed safely.