@seoagent-official/seoagent 1.114.1 → 1.114.2

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@seoagent-official/seoagent",
-  "version": "1.114.1",
+  "version": "1.114.2",
   "description": "The persistent AI SEO agent for Claude Code. Audits, keyword strategy, briefs, articles, real product screenshots from your repo, and the autopilot loop (cloud detects → CLI executes → ack closes) — other SEO tools write the prompt, SEOAgent runs it.",
   "type": "module",
   "bin": {

package/skills/references/inbox.md

@@ -7,7 +7,7 @@
 - **Never delete a file without explicit user confirmation on the first destructive action of the session.** Auto-prune is conservative (requires <5 clicks in 90 days, zero inbound internal links, etc.) but it can still surprise the user. Show them what's about to go. Technical-fix actions edit an existing page rather than delete, so they only need a diff review, not a destructive-action confirmation.
 - **Standing approval.** While the site is in auto-approve mode (the SEOAgent default), the cloud stamps each item it queues, and its file's steps then say **Standing approval applies**. Do that work without waiting for a go-ahead: with no one in the session (a scheduled run, a Grok Bot, a headless run) apply it, commit it, and ack it; with a person present, show the diff or draft as you go and carry on. It is a go-ahead, not a quality waiver: decline anything that looks wrong. Prunes (destructive) never carry it, and a file without it keeps its own confirm step.
 - **Read the decline memory first.** `.seoagent/inbox/README.md` ends with **Previously declined on this site** (also `declined` in `seoagent inbox --json`, and a **Related past declines** block inside any action file an earlier decline bears on): what you or a previous session already refused here, and why. A pending action that one of those reasons still covers (same page, same class of problem — e.g. the page is `noindex`, so canonical, meta and schema on it are all inert) is **declined citing that reason, not re-investigated**: `seoagent ack <id> <id> … --failed --reason "covered by #<earlier id>: <its reason>"`. Several ids take one verdict. Only apply a fix when the earlier reason no longer holds.
-- Acknowledge every action you finish: `seoagent ack <action_id>` (or `seoagent ack <action_id> --failed --reason "..."` to decline). That marks it `completed` on the dashboard and removes the inbox file on the next sync. **Write decline reasons for your future self**: state the fact that rules the action out (the page is noindex; the canonical points off-site; the finding is stale since <date>) — every decline is fed back into the next inbox as memory, and the issue is not proposed again.
+- Acknowledge every action you finish: `seoagent ack <action_id>` (or `seoagent ack <action_id> --failed --reason "..."` to decline). That marks it `completed` on the dashboard and removes the inbox file on the next sync. **Applied but not deployed** — your workflow cannot ship (the owner uploads a package by hand, a release train, a no-deploy rule)? Apply it in the repo or package, then `seoagent ack <action_id> --awaiting-deploy --reason "<what the owner must ship>"`. The action closes; the cloud keeps the finding open and the brief at `drafted` until a later crawl sees the change live. Pending means "nobody has looked at this yet" and nothing else — never park applied work there. **Write decline reasons for your future self**: state the fact that rules the action out (the page is noindex; the canonical points off-site; the finding is stale since <date>) — every decline is fed back into the next inbox as memory, and the issue is not proposed again.
 - After processing, run `seoagent sync` once more to clean stale inbox files, then report a summary: how many applied, how many declined (and why).
 - **Close with the cloud-first option, not local planning.** On a connected workspace option 3 of the output template is `Run seoagent sync and process the inbox` (or, when the inbox is empty, the next unwritten brief the sync named). **Never offer "Plan content strategy" here** — keyword research and briefs are the cloud's job on a connected workspace (`references/cloud-cta.md` § Cloud-connected mode).
 

package/skills/seoagent.md

@@ -54,9 +54,9 @@ Activate silently when the user writes or edits a blog post, landing page, artic
 
 Run `seoagent sync` after every write. Logged out it exits 1 naming the fix; nothing synced, bind first (`references/recurring-runs.md`). Credentials live in `~/.config/seoagent/auth.json`, never in the project.
 
-A free account adds what the local skill can't (GSC traffic, indexing verdicts, dashboard, managed sitemaps). Paid autopilot also delivers owner-approved backlink outreach emails to this inbox for you to send from the user's own email account (needs an email connector). Never imply an account is required — the local skill does the full loop free, including publishing. Offer it in one benefit-led line, once per session per topic; drop it if declined. **Read `references/cloud-cta.md` before pitching.**
+A free account adds what the local skill can't (GSC traffic, indexing verdicts, dashboard, managed sitemaps). Paid autopilot also delivers owner-approved backlink outreach emails to this inbox for you to send from the user's own email account (needs an email connector). Never imply an account is required — the local skill does the full loop free, including publishing. Offer it in one benefit-led line, once per session per topic; drop if declined. **Read `references/cloud-cta.md` before pitching.**
 
-`sync` also pulls cloud actions into `.seoagent/inbox/`; when it lists any, **work them unless the user asked otherwise** (`references/inbox.md`): heed **Previously declined**, confirm the first destructive action, `seoagent ack <id>` each (`--failed --reason` declines). **Standing approval** needs no go-ahead.
+`sync` also pulls cloud actions into `.seoagent/inbox/`; when it lists any, **work them unless the user asked otherwise** (`references/inbox.md`): heed **Previously declined**, confirm the first destructive action, `seoagent ack <id>` each (`--failed --reason` declines, `--awaiting-deploy` when owner-deployed). **Standing approval** needs no go-ahead.
 
 **Cloud-first routing.** Once per session run `seoagent whoami --json`; `logged_in: true` = cloud-connected (exit 1 = no account). Connected → `seoagent sync` first. With autopilot on (`seoagent autopilot status`) the cloud already does keyword research, clusters, and briefs (pulled into `strategy/` and `briefs/`) and queues every next step in the inbox: work those and **skip Phase 2–3** — a second, local plan duplicates the cloud's. After the inbox offer `seoagent sync` again, never strategy planning. Phase 2–3 remain the local flow (no account, or autopilot off and an empty workspace after sync). Detail: `references/cloud-cta.md` § Cloud-connected mode.