@seoagent-official/seoagent 1.109.0 → 1.110.0

package/package.json

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

@@ -5,7 +5,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.
-- **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) and new landing pages (a new URL) never carry it, and a file without it keeps its own confirm step.
+- **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.
 - After processing, run `seoagent sync` once more to clean stale inbox files, then report a summary: how many applied, how many declined (and why).
@@ -94,9 +94,9 @@ Start by reading `.seoagent/inbox/README.md` (or `seoagent inbox`) to see the li
 - `Read` it. The frontmatter has `action_id`, `keyword`, `opportunity` (`easy_win` | `competitor_gap`), `volume`, `difficulty`, and `intent`. The body explains why this keyword is worth a page.
 - Cross-reference the site's keyword inventory for related keywords — they tell you which cluster this page belongs to and which secondary keywords to weave in. It is `.seoagent/strategy/keywords/*.md` once the cloud shards it, and `.seoagent/keywords.md` otherwise; a synced workspace usually has only one of the two. **The action file names the files this workspace actually has — use those.** Do not assume a file named after the cluster in the rationale exists: a keyword whose cluster has no article role assigned yet is written to `strategy/keywords/unclustered.md`, so search the directory for the keyword rather than opening `<cluster>.md`.
 - Pick an article type from `intent` (commercial/transactional → product or comparison page; informational → guide or pillar). Pick a clean URL slug from `keyword`.
-- Write the article following the content-production protocol (Phase 4 — match the article type's quality rules, add internal links from related cluster pages, etc.). Show the user the draft before publishing (interactive sessions can use the visual review loop — `references/draft-review.md`).
+- Write the article following the content-production protocol (Phase 4 — match the article type's quality rules, add internal links from related cluster pages, etc.). Follow the file's go-ahead step: **Standing approval** → publish, commit, ack; otherwise show the user the draft before publishing (interactive sessions can use the visual review loop — `references/draft-review.md`).
 - **If the action body has a "Screenshots to capture" section** (SaaS product), follow `references/screenshots.md` — a landing page for a SaaS product should lead with a real product screenshot in the hero + feature sections, captured from this repo's UI.
-- Publish where this project's content lives (repo `content/` or the connected CMS). Safe (new content) — but still confirm the user wants this specific page before committing.
+- Publish where this project's content lives (repo `content/` or the connected CMS). Safe (new content). Without **Standing approval**, confirm the user wants this specific page before committing.
 - Acknowledge: `seoagent ack <action_id>` (or `--failed --reason "already covered by /existing-page"`).
 
 ### `cli_draft_ready-<id>.md`