Compare commits

..

No commits in common. "main" and "v1.0.0" have entirely different histories.
main ... v1.0.0

6 changed files with 4 additions and 21 deletions

View File

@ -10,7 +10,7 @@
"name": "222a-seo-audit", "name": "222a-seo-audit",
"source": "./plugins/222a-seo-audit", "source": "./plugins/222a-seo-audit",
"description": "SEO-аудит, анализ проблем, client reports через 222A.ru", "description": "SEO-аудит, анализ проблем, client reports через 222A.ru",
"version": "1.1.0" "version": "1.0.0"
} }
] ]
} }

View File

@ -1,7 +1,7 @@
{ {
"name": "222a-seo-audit", "name": "222a-seo-audit",
"description": "SEO audits, technical issue analysis, and client reports via 222A.ru MCP", "description": "SEO audits, technical issue analysis, and client reports via 222A.ru MCP",
"version": "1.1.0", "version": "1.0.0",
"author": { "author": {
"name": "222A.ru", "name": "222A.ru",
"url": "https://222a.ru" "url": "https://222a.ru"

View File

@ -5,7 +5,7 @@
"url": "https://222a.ru/api/mcp", "url": "https://222a.ru/api/mcp",
"headers": { "headers": {
"Authorization": "Bearer ${MCP_222A_TOKEN}", "Authorization": "Bearer ${MCP_222A_TOKEN}",
"X-Plugin-Version": "1.1.0" "X-Plugin-Version": "1.0.0"
} }
} }
} }

View File

@ -5,12 +5,6 @@
## [Unreleased] ## [Unreleased]
## [1.1.0] - 2026-05-28
### Added
- Поддержка optional параметра `mode=compact|full` в `get_audit_context` (контракт 1.51.0+ на 222a.ru). compact опускает `issues[]`, добавляет `issues_summary` агрегаты и `drill_down_hints`, режет `progress_since_previous.top_*` до 5. Использовать на больших проектах для orientation/triage.
## [1.0.0] - 2026-05-23 ## [1.0.0] - 2026-05-23
Первый публичный релиз плагина 222a-seo-audit. Первый публичный релиз плагина 222a-seo-audit.

View File

@ -31,7 +31,7 @@ Use the 222A MCP server for SEO audit context instead of scraping local database
- To explain progress between two completed audits, call `compare_audits` and save useful conclusions as `progress_comparison` when write access exists. Treat the issue `changed` bucket as severity changes; same-severity persistent issues are in `unchanged`. - To explain progress between two completed audits, call `compare_audits` and save useful conclusions as `progress_comparison` when write access exists. Treat the issue `changed` bucket as severity changes; same-severity persistent issues are in `unchanged`.
- When monitoring an audit, poll politely, avoid tight loops, and always keep `audit_run_id` visible so the user can resume later. - When monitoring an audit, poll politely, avoid tight loops, and always keep `audit_run_id` visible so the user can resume later.
- List resources to discover available audits: `resources/list`. - List resources to discover available audits: `resources/list`.
- Read `audit://{audit_run_id}/context` or call `get_audit_context` before analysis. On large projects (issues_total > ~3000) prefer `get_audit_context(audit_run_id, mode="compact")` for orientation — it omits the heavy `issues[]` array, adds `issues_summary` aggregations + `drill_down_hints`, and trims `progress_since_previous.top_*` to 5. Drill down via `get_top_priorities`, `get_executive_summary`, `get_issue_clusters`, or `get_issue_pages` per the hints. - Read `audit://{audit_run_id}/context` or call `get_audit_context` before analysis.
- Read `audit://{audit_run_id}/workspace-summary` or call `get_audit_workspace_summary` when deciding whether to create/update a manager synthesis or client report. Use `workspace.progress_since_previous` for a quick progress note when available. - Read `audit://{audit_run_id}/workspace-summary` or call `get_audit_workspace_summary` when deciding whether to create/update a manager synthesis or client report. Use `workspace.progress_since_previous` for a quick progress note when available.
- Read `audit://{audit_run_id}/analyses` before writing, to avoid duplicating prior conclusions. - Read `audit://{audit_run_id}/analyses` before writing, to avoid duplicating prior conclusions.
- Save durable, manager-facing output with `save_audit_artifact` unless the user explicitly says not to save it. - Save durable, manager-facing output with `save_audit_artifact` unless the user explicitly says not to save it.

View File

@ -241,17 +241,6 @@ Input:
Output includes the same safe context as `audit://123/context` in `structuredContent`. When a previous completed audit exists for the same project, `progress_since_previous` summarizes the adjacent diff: previous/current audit ids and finish times, resolved and organically appeared issue counts, issues attributed to newly connected data sources, issues attributed to data sources that became unavailable, improved/worsened severity counts, flaky perf counts (`appeared_flaky_count`, `resolved_flaky_count`, `changed_flaky_count`, `top_flaky_issues`), site-level issue counts (`site_appeared_issues_count`, `site_resolved_issues_count`, `site_changed_issues_count`, `top_site_appeared_issues`, `top_site_resolved_issues`, `top_site_changed_issues`, plus parallel `site_appeared_due_to_new_data_source_count` / `site_resolved_due_to_data_source_unavailable_count` and `top_site_*` variants), page deltas, `top_resolved_pages`, `top_appeared_pages`, HTTP status recovery/regression counts, score/page-crawl deltas, and top safe issue samples. `appeared_issues_count` is organic; explain `appeared_due_to_new_data_source_count` and `top_appeared_due_to_new_data_source` separately as new evidence, not automatic site degradation. `resolved_issues_count` is organic; explain `resolved_due_to_data_source_unavailable_count` and `top_resolved_due_to_data_source_unavailable` separately as false-positive resolutions caused by a previously connected source going offline, not real fixes. Flaky perf issues are kept out of `appeared`/`resolved`/`changed` buckets and routed to `appeared_flaky`/`resolved_flaky`/`changed_flaky` instead — these are measurement noise around lab thresholds, not real progress or regression. Site-level issues (ya.*, seo.duplicate_*, tech.crawled_not_in_sitemap, seo.url_*, content.near_duplicate, seo.hreflang_*, seo.indexed_not_crawled) are tracked separately in the `site_issues` bucket — they affect many URLs at once, not single pages. Use this for a quick manager answer about what was fixed since the last audit; call `compare_audits` for full drill-down (`compare_audits` payload includes both `issues` and `site_issues` buckets). Output includes the same safe context as `audit://123/context` in `structuredContent`. When a previous completed audit exists for the same project, `progress_since_previous` summarizes the adjacent diff: previous/current audit ids and finish times, resolved and organically appeared issue counts, issues attributed to newly connected data sources, issues attributed to data sources that became unavailable, improved/worsened severity counts, flaky perf counts (`appeared_flaky_count`, `resolved_flaky_count`, `changed_flaky_count`, `top_flaky_issues`), site-level issue counts (`site_appeared_issues_count`, `site_resolved_issues_count`, `site_changed_issues_count`, `top_site_appeared_issues`, `top_site_resolved_issues`, `top_site_changed_issues`, plus parallel `site_appeared_due_to_new_data_source_count` / `site_resolved_due_to_data_source_unavailable_count` and `top_site_*` variants), page deltas, `top_resolved_pages`, `top_appeared_pages`, HTTP status recovery/regression counts, score/page-crawl deltas, and top safe issue samples. `appeared_issues_count` is organic; explain `appeared_due_to_new_data_source_count` and `top_appeared_due_to_new_data_source` separately as new evidence, not automatic site degradation. `resolved_issues_count` is organic; explain `resolved_due_to_data_source_unavailable_count` and `top_resolved_due_to_data_source_unavailable` separately as false-positive resolutions caused by a previously connected source going offline, not real fixes. Flaky perf issues are kept out of `appeared`/`resolved`/`changed` buckets and routed to `appeared_flaky`/`resolved_flaky`/`changed_flaky` instead — these are measurement noise around lab thresholds, not real progress or regression. Site-level issues (ya.*, seo.duplicate_*, tech.crawled_not_in_sitemap, seo.url_*, content.near_duplicate, seo.hreflang_*, seo.indexed_not_crawled) are tracked separately in the `site_issues` bucket — they affect many URLs at once, not single pages. Use this for a quick manager answer about what was fixed since the last audit; call `compare_audits` for full drill-down (`compare_audits` payload includes both `issues` and `site_issues` buckets).
**Optional параметр `mode` (контракт 1.51.0+):**
- `mode: "full"` (default) — полный payload, включая массив `issues[]` со всеми обогащениями per-issue (priority, fix_effort, quick_win, remediation_summary, data_freshness, acknowledged).
- `mode: "compact"` — orientation/triage режим без длинного `issues[]`:
- Опускается ключ `issues`.
- Добавляется `issues_summary` с агрегатами `{total, by_severity, by_category, by_priority_bucket}` (присутствует в обоих режимах).
- Массивы `progress_since_previous.top_*` обрезаются до 5 элементов (counts остаются полные). В full режиме теперь возвращается до 10 элементов.
- Добавляется `drill_down_hints` со списком тулов для углубления: `get_top_priorities`, `get_executive_summary`, `get_issue_clusters`, `get_issue_pages`, `compare_audits`.
Использовать compact на больших проектах (issues_total > ~3000), где full уходит за лимит токенов AI-клиента.
### `get_issue_pages` ### `get_issue_pages`
Requires `mcp.read`. Requires `mcp.read`.