Help me use Generative Engine Solution (GES) through this connected MCP client.

Start with read-only onboarding. Make no WordPress changes:
1. Call generative-engine-solution/ai-operating-instructions with section "quickstart", then section "full". Read both guides.
2. Read generative-engine-solution/account-status, generative-engine-solution/get-control-surface and generative-engine-solution/get-mutation-catalog. Discover the current WordPress capabilities, connection/OAuth permissions, installed adapters, plan limits and dependencies from these live responses.
3. Summarize the connected site and GES version, active plan, available permissions, supported actions and any blockers. Explain how we will preview, review, approve, apply and verify changes. Wait for my next request.

For later work:
- Follow my request and the live product contract. Documentation is guidance, not permission. A plan or permission preset never grants WordPress capabilities or approves a write. Do not ask for Full Access when narrower permissions suffice.
- Read the exact target first. All remote WordPress writes must use reviewed GES Jobs: Create -> Analyze -> Review -> Approve -> Apply -> Verify -> Audit. Group compatible changes into one Job where supported. Reads do not need Jobs.
- Show the exact proposed changes and obtain approval before Apply. Draft creation and publishing are distinct actions; do not publish unless I authorize publishing. Unsupported or ambiguous targets must fail safely.
- For each approved READY mutation row, call get-review-item using its actual job_id and row_id. Retrieve its exact top-level confirmation_required, even after approval or when requires_review is false. Call start-job-apply with confirmations keyed by the actual row ID as a string and its unchanged confirmation_required value. A Job ID or step_id is not a row ID. Never guess confirmation strings.
- Dependent steps need fresh live resolution and review as required. Do not bypass expired previews, stale hashes, missing permissions or unsupported payloads.
- After Apply, read Job status and the saved native result; report per-step verification, revisions/audit where available, and any partial failures. Cross-resource rollback is guarded compensation, not an atomic transaction.
- If a connection drops or a write is uncertain, inspect Job/row status and use supported reconciliation before any retry. Never blindly replay an Apply or invent missing recovery evidence.
- If a required tool or permission is unavailable, report the exact error and the narrow next step. If no GES connector is available, ask me to connect it; do not pretend to have read the site or executed a tool.

- Universal Job responses include workflow.state and workflow.next_call. Treat this as a continuation hint, not authority. After approval, if my existing authorization covers the exact proposal, execute the returned ready_to_apply call with its actual row-ID confirmation map instead of stopping at approval or requesting another WordPress login. Follow refresh/recovery/reconcile instructions when indicated; never change a hash/expiry or replay uncertain writes. On completion follow the exact Page/Post/CPT read-back call and distinguish draft from published.
