Website Editor

How Website Execution Works

The Website Editor uses a canonical execution platform for all connected website work. Whether triggered by an admin operator or handed off from the SEO agent, every change follows the same persisted job record, transport policy, and lifecycle semantics.

No live mutation happens without a bounded, previewed, and approved job. The platform never makes unbounded or wildcard edits to any site.

Transport Modes

Website jobs run through one of two transport modes:

WordPress Live Mode

• Writes go directly to the connected WordPress REST API
• Targets must be explicitly bounded (specific pages, posts, or elements)
• riskLevel is mandatory — classify the change explicitly
• Backups are required by default
• Previews are generated before execution

GitHub PR Mode

• Commits to a configured working branch (never main or master)
• Direct writes to the repo default branch are rejected by policy
• Pull request creation is optional (createPullRequest: true)
• Promotion to main is a separate PR step
• The connected GitHub connection carries the working branch preference (e.g., test)

Job Lifecycle

Every website execution job moves through these states:

Preview and Result Artifacts

Preview (Pre-Execution)

Before any change is applied, the system generates a preview artifact containing:

• Summary — what the job plans to do
• Warnings[] — any concerns detected
• BlockedReasons[] — why execution may be blocked
• BackupRef — reference to the pre-change backup
• RequiresBackup — whether a backup was created
• Operations[] — typed list of planned operations

Result (Post-Execution)

After execution, the result artifact includes:

• Summary — what was done
• Status — final execution status
• ErrorMessage — if applicable
• BranchName / CommitSha — for GitHub transport
• PullRequestUrl — if a PR was created
• DestinationUrl — live URL of the changed resource
• BackupRef — for rollback if needed
• Operations[] — typed list of completed operations

Approval Flow

1. Operator creates a job — defines objective, targets, and transport
2. System generates preview — job moves to preview_ready
3. Operator reviews preview — inspects planned operations, warnings, and blocked reasons
4. Operator approves — job moves to queued for worker execution
5. Worker executes — job moves to running, then completed or failed
6. If review required — job pauses at review_required for final sign-off

SEO Agent Handoff

The SEO agent can create website execution jobs when it has resolved executable inputs:

• Blog posts are queued as WordPress drafts (operation: "write_entity", postType: "post", status: "draft")
• Money-page edits go through the same bounded execution contract
• The SEO runtime cannot call WordPress or GitHub mutation helpers directly — it must create a job

Supported SEO Operations

Bounded Execution

Every job must declare:

• allowedTargets[] — what the job is permitted to modify (cannot be empty or contain wildcards)
• blockedTargets[] — explicit guardrails for sensitive areas
• changeRequest — typed request with kind, summary, and structured payload
• objective — human-readable bounded scope for the job

Freeform prompt blobs are not accepted as the executable contract. Every change must be structured and typed.

Activity and Audit Trail

Every lifecycle transition emits a shared website activity record:

Activity status values follow the shared four-level contract: info, success, warning, error.

Managing Jobs

Via Admin UI

1. Navigate to the client's website section
2. Review pending jobs in the execution queue
3. Inspect preview artifacts before approving
4. Approve or reject queued jobs
5. Monitor running jobs via heartbeat status

Via API

# List jobs for a client
GET /admin/website-execution/jobs?clientId=CLIENT_ID

# Get job detail with preview
GET /admin/website-execution/jobs/JOB_ID

# Approve and queue a previewed job
POST /admin/website-execution/jobs/JOB_ID/approve

# Cancel a queued or running job
POST /admin/website-execution/jobs/JOB_ID/cancel

Troubleshooting