@seoagent-official/seoagent 1.116.0 → 1.117.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@seoagent-official/seoagent",
-  "version": "1.116.0",
+  "version": "1.117.1",
   "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

@@ -4,7 +4,7 @@
 
 **Golden rules (these also live in the skill body):**
 
-- **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.
+- **Never delete a file without explicit user confirmation on the first destructive action of the session.** An `owner_approved: true` prune already has it (the owner approved it in Slack or on the dashboard). 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. **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.
@@ -39,6 +39,7 @@ Start by reading `.seoagent/inbox/README.md` (or `seoagent inbox`) to see the li
 
 - `Read` it. **Check `source:` in the frontmatter first — it changes what already happened.**
   - **`source: repo`** — a *suggestion* for a page that lives in this repo. Nothing has been changed: the page is live and the cloud has not marked it pruned. The frontmatter has `slug` and `page_url`; the body has the 90-day Search Console numbers behind it. The cloud cannot see inbound internal links, so **search the repo for links to the page's path before anything else — any inbound link means decline** (`--failed --reason "kept; linked from <page>"`). Also decline when the page earns its place off-search (docs, changelog, emails). If a stronger page covers the topic, a 301 to it beats a bare deletion. A decline is remembered; the page is not proposed again.
+  - **`owner_approved: true`** (with `source: repo`) — the owner already said yes in Slack or on the dashboard. Do not ask again, and **do not decline because other pages link to it: do the whole job in one change.** (1) Find every internal link to the page — content, components, nav/footer config, hand-kept sitemaps, related-links data. (2) Repoint each to the replacement: `replacement_url` in the frontmatter (SEOAgent named it when it asked the owner), else the closest parent page that exists, else `/`; remove a link only when no sensible target exists. (3) Add a permanent 301 from the old path to it the framework's native way (Next.js `redirects()` in `next.config.*`, or the `middleware`/`vercel.json` the site already uses; Netlify/Cloudflare `_redirects`; Astro `redirects`; Hugo `aliases`; add the standard one if none exists). (4) Delete the page. (5) Name all of it in your summary: the page removed, each file whose links changed and to where, the redirect and its file. Decline only when the page's source or a redirect mechanism cannot be found. The file's **Do the whole job** section has the same steps. Without `owner_approved`, everything above stands.
   - **No `source`** — a legacy cull from a cloud-published article: the cloud already archived it and serves 410. The frontmatter has `action_id`, `article_id`, `slug`, and `cms_type`; remove the leftover file.
 - **Find the local file** that corresponds to the article. Look under `content/`, `src/content/`, `app/blog/`, `posts/`, `pages/blog/`, or wherever this project's articles live. Match by slug first, then by URL path. If you can't find an exact match, ask the user before doing anything destructive.
 - **Confirm with the user once per session** before deleting the first article. Show the title, slug, and the file path you intend to delete. After they confirm, proceed for the rest without re-prompting unless something looks ambiguous.