@seoagent-official/seoagent 1.115.0 → 1.116.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@seoagent-official/seoagent",
-  "version": "1.115.0",
+  "version": "1.116.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/audit-checks.md

@@ -24,7 +24,7 @@ Three rules govern every finding:
 
 **Do not assert repo-internal specifics (file paths, line numbers) as fact in a live-state finding.** They are fixing *hints*, not verified live facts — mark them `Likely` and phrase as "likely in `app/layout.tsx`", never "on line 42".
 
-**Mechanical backstop — verify-recs runs automatically on every sync, and you still run it at the end of every audit session.** The rules above are also enforced deterministically, twice: (a) every `seoagent sync` — including the PostToolUse hook that fires after each file write — runs a verify-recs pass first, correcting `.seoagent/**/*.md` claims as they're written (watch for `verify-recs: corrected …` lines in the hook output); and (b) after writing the audit outputs (and any fixes/work log), run `seoagent verify-recs` yourself, passing any files you wrote outside `.seoagent/` as arguments. It scans the authored markdown against `evidence.md` and rewrites, in place with a `CORRECTION (verify-recs)` annotation, any absence claim or add-recommendation about a title, meta description, canonical, Open Graph/Twitter tag, or JSON-LD `@type` the live page already serves. Treat its corrections as authoritative: carry every one into the final response, and never restate the original (corrected) claim. On SOURCE-RENDER evidence it applies no corrections and reports that live-state claims can't be verified.
+**Mechanical backstop — verify-recs runs automatically on every sync, and you still run it at the end of every audit session.** The rules above are also enforced deterministically, twice: (a) every `seoagent sync` — including the PostToolUse hook that fires after each file write — runs a verify-recs pass first, correcting `.seoagent/**/*.md` claims as they're written (watch for `verify-recs: corrected …` lines in the hook output); and (b) after writing the audit outputs (and any fixes/work log), run `seoagent verify-recs` yourself. With no arguments it checks every authored `.seoagent/` file; naming files (`seoagent verify-recs WORK-LOG.md`) checks only those files, so run it once more, with the paths, for any file you wrote outside `.seoagent/`. It scans the authored markdown against `evidence.md` and rewrites, in place with a `CORRECTION (verify-recs)` annotation, any absence claim or add-recommendation about a title, meta description, canonical, Open Graph/Twitter tag, or JSON-LD `@type` the live page already serves. Treat its corrections as authoritative: carry every one into the final response, and never restate the original (corrected) claim. On SOURCE-RENDER evidence it applies no corrections and reports that live-state claims can't be verified.
 
 ## Crawlability & Indexation
 
@@ -346,7 +346,7 @@ If `seoagent crawl` couldn't run (offline, no domain), fall back to per-page Web
 The evidence-citation contract is enforced by the CLI, not just by the prompt — twice over:
 
 1. Every `seoagent sync` (including the PostToolUse hook that fires after each file write) runs a verify-recs pass first, so false claims in `.seoagent/**/*.md` are corrected as the files are written — when the hook output reports a `verify-recs: corrected …` line, treat it as authoritative and carry the correction into your response.
-2. At the end of the session — after writing your outputs, BEFORE composing the final summary — run `seoagent verify-recs` yourself (pass any work-log/summary files you wrote outside `.seoagent/` as arguments), because files outside `.seoagent/` are only checked when you pass them. This is still the MANDATORY final step of any audit/optimization session.
+2. At the end of the session — after writing your outputs, BEFORE composing the final summary — run `seoagent verify-recs` yourself, then `seoagent verify-recs <file>…` for any work-log/summary files you wrote outside `.seoagent/`. Files outside `.seoagent/` are only checked when you name them, and named files are checked instead of `.seoagent/`, not in addition. This is still the MANDATORY final step of any audit/optimization session.
 
 **If `evidence.md` is a SOURCE RENDER (undesignated local dev-server crawl), verify-recs cannot verify live-state claims — it will say so; re-crawl with `--url <live origin>` before finalizing any live-state summary.** It re-checks every authored `.seoagent/**/*.md` against `evidence.md` and REWRITES, in place with a `CORRECTION (verify-recs)` annotation, any "added X / there was no X / X was missing" claim about a head-level entity (title, meta description, canonical, Open Graph, twitter:card, or a JSON-LD `@type` such as `Organization`/`SoftwareApplication`/`WebSite`) that the evidence shows the live page ALREADY serves. **Reflect every correction it reports in your final message** — never let a corrected claim survive into the summary (use `--json` to branch on the result programmatically). The deterministic way to do that: build the final message from `seoagent summary` (see `references/session-protocol.md`), which quotes the corrected on-disk state — including every CORRECTION line — instead of trusting your memory of what you found. It never touches `evidence.md`, generated projections (`pages.md`/`keywords.md`), the inbox, or anything under `.claude/`, and it always exits 0 — a correction is the check working, not an error. **It never rewrites dated history either:** a line authored BEFORE the crawl day (a `[YYYY-MM-DD]`-stamped or dated-heading `changelog.md` entry, or an `audit/latest.md` whose `audited_at:` predates `evidence.md`'s `captured_at`) is a record the re-crawl confirms, not a false claim. verify-recs lists those as **stale** — when it does, note the finding as fixed in the current re-audit (`latest.md` fixed/new/regressed diff); do not edit the old line and do not restate it as an open finding.
 

package/skills/references/session-protocol.md

@@ -9,7 +9,7 @@ Every session has a budget — headless/one-shot runs have a hard turn cap, inte
 1. **Consolidate writes — keep NEW files under ~20 per session.** One audit doc, one migration plan, one fixes batch — not a file (or a file update) per finding. If you're about to create a new file, first ask whether an existing one should be extended instead (extend `audit/latest.md` rather than a second audit file; add a section to `roadmap.md` rather than a new planning doc). Do NOT write per-item bookkeeping updates (a changelog line here, a roadmap tick there, a status touch after each action) as you go; accumulate them and batch them into a single write at the end of the session — one changelog append, one roadmap update, one `seoagent sync`. Every file write also fires the sync hook, so fewer writes = more budget for real work.
 2. **Batch multi-file code edits.** When a fix touches several source files (meta tags across layouts, a redirects config + a sitemap), make the edits back-to-back as one batch, then verify once — don't interleave each edit with checks, syncs, or commentary turns.
 3. **Scope a single-session ask to what one session can ship.** For a single-session "grow organic traffic" ask, deliver the audit findings + the migration plan + the top shippable fixes. Do NOT draft full article inventories or write every article in the plan — that is multi-session work; list the briefs (slug + target keyword + role) in the roadmap instead and let later sessions write them.
-4. **Reserve the final turns for the wrap-up.** When the work above is done, end the session with exactly two steps: `seoagent verify-recs` (pass any work-log files written outside `.seoagent/` — the sync hook already covers `.seoagent/` itself) and then **`seoagent summary`**, whose output is what you present as the final message. **No new workstreams after the summary** — do not open a new work stream (another audit pass, another content draft) you cannot finish inside the budget. An unfinished extra stream plus a missing summary is worth less than a complete summary.
+4. **Reserve the final turns for the wrap-up.** When the work above is done, end the session with exactly two steps: `seoagent verify-recs` (name any work-log files written outside `.seoagent/` — naming files checks only those files, and the sync hook and `seoagent summary` already cover `.seoagent/` itself) and then **`seoagent summary`**, whose output is what you present as the final message. **No new workstreams after the summary** — do not open a new work stream (another audit pass, another content draft) you cannot finish inside the budget. An unfinished extra stream plus a missing summary is worth less than a complete summary.
 5. **Prefer editing an existing file over creating a new one** when appending related content. Fewer files means fewer writes, fewer sync round-trips, and a workspace the next session can actually read.
 
 **Session economy applies to bookkeeping, never to findings completeness.** The rules above trim churn — file-write sprawl, re-polish loops, per-item status ticks — they never license dropping findings. Reporting **every confirmed finding** from `.seoagent/audit/findings.md` (every title in the final message at minimum; full detail by reference to the file) is **non-negotiable**: a terse report that omits confirmed findings is a failed session, not an economical one. `seoagent summary` makes this mechanical — its "Technical findings (from live crawl)" section lists every finding title, and that list is never truncated.