@seoagent-official/seoagent 1.98.1 → 1.98.2

package/package.json

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

@@ -102,6 +102,7 @@ Start by reading `.seoagent/inbox/README.md` (or `seoagent inbox`) to see the li
   - **`mode: revision`** — that slug **already renders live on this site** (`replaces_path` names the file). **Do not place it as a new post and do not overwrite the live file.** `diff` the two, fold in only what is genuinely new or better, and keep the live article's URL, frontmatter and dates. If the draft adds nothing, decline — that is a real answer.
 - **Match the destination's frontmatter contract, not just the draft's.** The cloud draft carries `title`, `meta_description`, and `status`; the repo's content directory may require fields it does not — an `ogImage`, an `excerpt`, a `date`, a tag list — and may enforce them in CI. Read the content directory's `README`/`_README` and one neighbouring post before writing the file. **Drafts arrive with no images**, so when a hero image is required, produce one in the site's existing style and commit it alongside the post; a draft placed exactly as delivered will otherwise turn the build red.
 - **Renaming the slug is encouraged** when the generated one reads as a full sentence; a short slug is the better URL. When you rename, pass `--supersedes <the-delivered-slug>` to `content track`. That is what tells the cloud it is the SAME article under a new name — without it the cloud keeps the original as an unfinished draft and delivers it to you all over again.
+- **A rename has a second half: the draft's own identity fields.** The delivered frontmatter carries the generated `slug:` (and often a `canonical`/`url`), so copying it verbatim into a file you renamed leaves the old slug behind in the body of the post. Loaders commonly resolve identity as `frontmatter.slug || filename` while the **route** resolves from the filename, so the page renders at the new URL and declares a canonical pointing at the old one — a silent self-canonical to a 404, on the page you just chose to publish. Nothing fails loudly. **Drop `slug:` when the destination derives it from the filename**, or update it to the new slug when the destination reads it; do the same for any `canonical`/`url` field. `--supersedes` fixes the cloud's record of the rename, not the repo's.
 - **Close it out with `--action <action_id>` on the `content track`** — that acks the action for you, in the step you were already running. `seoagent ack <action_id>` by hand still works (or `--failed --reason "not publishing; ..."` to decline).
 
 ### `cli_send_outreach_email-<id>.md`