Actions

Chat can perform the same shipped non-admin project actions available in the product, including bulk operations. It uses one server-authored action plan for each requested mutation.

One confirmation per operation

Before a mutation, Chat resolves the exact targets, validates access and preconditions, and shows one confirmation containing:

• The exact effect and affected count.
• The frozen target set for a bulk action.
• Important blockers or warnings.
• Whether the action is reversible, conditional, or irreversible.
• Any effects that cannot be undone, such as external publishing, indexing, traffic exposure, or discarded content.

Research, planning, preflight checks, and metered read-only data calls do not create confirmation cards. Normal navigation, copy, and export also do not require confirmation. Writes, publishing, Draft generation, and other state-changing actions still require confirmation.

Support tickets use the same confirmation boundary. Asking for a human or choosing Contact support only prepares a server-authored preview. The email is sent only after you review and confirm the verified requester address, AI summary, selected user-authored messages, and any redaction or truncation notices. A confirmed ticket is one-shot and cannot be sent twice.

Reversibility

• Reversible means SERPclimber can build a supported undo action and retained the required previous state.
• Conditional means an undo depends on the entity’s current state or timing, or external effects may remain.
• Irreversible means SERPclimber cannot safely restore the previous state.

An action is never labeled reversible only because a user could manually make a similar change later.

Bulk actions and retries

For requests such as “exclude every page containing /archive/ in the slug,” the server resolves the filter into frozen page IDs before confirmation. Each target executes independently. The result separates succeeded, failed, and skipped items.

“Retry failed” creates a new confirmation containing failed IDs only. Successful targets are not run again.

Drafting and publishing

“Draft an Experiment” uses the current Page Detail Page when available. Otherwise Chat uses an unambiguous discussed Page or a clearly dominant Opportunity. If the Page must first be added to Experiments, that change and Draft generation are combined into one confirmation.

After approval, the conversation shows one live Experiment workflow. It advances from generating to Draft, running, awaiting decision, and completed as the underlying Experiment changes. Publishing, regeneration, cancellation, Draft edits, and decisions each prepare a new confirmation with their complete effects.

Draft generation and regeneration confirmations expose the exact frozen steering plus the status of any saved Chat research attached to it. Failed website previews are not used as evidence. If no usable saved evidence is attached, the confirmation says so; the generation pipeline can still perform its own steering-directed public web research.

For an inline Draft edit, Chat reads stable edit targets from the current persisted Draft variant. It can change one section or the whole Draft without asking you to paste the content. The confirmation embeds a frozen Current Draft → Proposed Draft diff; Confirm applies exactly that proposal and never edits the captured baseline.

If the Draft changes after the confirmation is prepared, the action stops without writing and Chat must prepare a fresh diff. Whole-Draft edits that exceed the safe context or action size limits must be narrowed to a section or handled with Regenerate.

Credentials are always entered in the secure Integrations screen, never in Chat.