onsite-apply

Apply approved changes (the gate lives here)

1. Read profile + env file. Poll the channel first if telegram, via core.approval.process_telegram_decisions(root, token, chat_id) - it persists the poll offset and tolerates unknown/stale ids without raising.

2. List approved onpage-fix items. For each: a. require_approved(path) - this raises on anything not approved. Never catch that error to proceed; report it and skip. b. snapshot() the post (title + meta + content if the proposal touches it) -> save to outcomes/<item-id>-rollback.json in the brain repo. c. Apply via the CMS adapter (onsite.cms.adapter_for; wordpress or git-static per cms.type - the git-static branch below replaces steps b-g): update_seo_meta / update_post per the proposal body. (update_rankmath remains as the WordPress adapter's alias for update_seo_meta.) d. Verify: get_rendered_head(target_url) - assert the new title/description appear in the rendered head. On mismatch: rollback() immediately, then PYTHONPATH="$CLAUDE_PLUGIN_ROOT/lib" python3 -m core status <item-path> failed --actor agent, append a signal "apply-verify failed", and alert. Never leave the item approved. e. PYTHONPATH="$CLAUDE_PLUGIN_ROOT/lib" python3 -m core status <item-path> applied --actor agent; write an outcome record outcomes/<item-id>.md: what changed, when, rollback file, measurement due dates (+7d, +28d). Because the verify just succeeded, also write the re-verification window into the record, exactly these keys (see site-repo-contract.md):

   reverify:
     due: <UTC now+1h>     # first scheduled re-check
     until: <UTC now+48h>  # window end; drift watch owns the horizon after
   

   hoo-daily re-checks the live values between due and until so an external revert (a bulk plugin restore, a theme update) surfaces within hours, not at the next audit. f. On a successful verify, refresh the drift baseline for this page (onsite.drift.snapshot_pages on this post id, merged into the stored onsite.drift.baseline_path entry, then save_baseline) so the change we just made intentionally is never flagged as drift by the next hoo-daily run. g. IndexNow: when site-profile.yaml has indexnow: {enabled: true, key: ...} (additive key), call hoo.indexnow.submit(host, key, [target_url]) after the successful verify and record the returned status in the outcome record (indexnow: {status: N, submitted: 1}). A non-200 is recorded, never retried in-run, and never fails the apply. Skipped in dry-run - nothing changed, nothing to submit.

3. Commit + push the brain repo if git. Summarize: applied / skipped / failed.

4. Outcome summary - the approver always hears what happened. Compose ONE message for the whole run and deliver it through the configured approval channel (telegram: one sendMessage over the same transport send_item uses; slack/email: one post/send; in-session: print the summary; pr-merge: no live channel mid-cycle - append the summary to the run report and outcome records instead). Never send per-item messages. Content, one line per item:

   • applied and verified: item id + what changed
   • partially-applied: item id + the exact human step from the status note - the approver must know what is waiting on them
   • failed / rolled back: item id + the reason Silent success is a bug: whoever said yes hears the result, whether it landed, half-landed, or failed. A run that touched nothing sends nothing.