Skip to content

v0.5.4 — Recovery Hardening + reconciliation pass

Latest

Choose a tag to compare

@maxschottke-spec maxschottke-spec released this 02 Jul 15:27
· 3 commits to main since this release

Added

  • L4a Stage-State-Machine (Phase 2, experimental N=1) — recovery-diagnose overlays a stage state machine on the raw recovery_stage_estimate: it freezes stage progression during an active update rollout (active_update_window) or its 28-day settlement (post_update_settlement), and hard-resets the effective stage to R1 on a fresh major hit (re_entry_detected). New stage_status field in befund.schema.json, marked maturity: experimental_n1. Distinct from the §12a Settlement Gate (operator-batch write-block). Cumulative-damage / multi-hit formula is the follow-up slice (L4b).
  • L2 Quiet-Death-Detection (Phase 2, experimental N=1) — gsc-deep-dive now pulls a per-query weekly click series (query_weekly_series, top 200, up to weekly_series_days days) and ships a zero-dep detector (quiet-death-detect.example.js) that flags slow non-update-driven declines (≥50 % loss over ≥6 monotonic weeks, ≥5 start clicks), annotated with update_correlation (none/partial vs CORE_UPDATES.md) and a pattern_hint. Marked maturity: experimental_n1.
  • L1 Pre-Hit-Baseline-Selektion (Phase 2, experimental N=1) — recovery-diagnose selects the recovery baseline as the historical peak plateau instead of the last stable phase before the hit, flags multi-update erosion (multi_update_erosion_detected), and reports progress against the true peak (recovery_vs_baseline_pct). New pre_hit_baseline field in befund.schema.json, marked maturity: experimental_n1. The R1-R5 stage formula is unchanged (stays VI-peak-based; baseline-relative staging is Lesson 4).
  • LESSONS 2026-06/07 + v0.5.4 roadmap block — five candidate lessons from real post-deploy recovery ops logged in post-core-update-recovery/LESSONS.md (rendered ≠ stored field, governing-fact-before-editing-a-claim, compliance as a recovery axis, knocking-at-the-door cohort, gate append-only audit). ROADMAP.md gains a v0.5.4 "Recovery Hardening" block scoping L1/L2/L4/L5 as pure-Markdown rules; the compliance-aware-recovery runtime skill (L3) is deferred to v0.6 pending cross-case validation. Proof-status honest: causal effect pending. Docs only.
  • v0.5.4 Recovery Hardening rules writtenSAFE_LIVE_CHANGE_RULES.md Pre-Change Checklist gains rule 10 (rendered-source verification: verify what renders, not the stored field — CMS/meta fields can be plugin/theme-overridden) and rule 11 (governing-fact-before-editing-a-claim). SEO_SETTLEMENT_GATE.md §8 gains the append-only-audit rule (unlock/relock cycles append to history arrays, clean-unlock preferred over forced). recovery-diagnose command gains the knocking-at-the-door cohort finder (GSC impressions × CTR × position filter for on-page-hardening targets; now properly integrated as Schritt 11, before the befund write — see the Step-12 integration fix below). Pure-Markdown methodology, no runtime change.
  • Three CI consistency checks in .github/workflows/validate.yml: (1) version consistency — plugin.json version checked against every skill's metadata.version, the rescue orchestrator's "Latest installable version" claim, the README shipped/install-tag lines, plus a schema_version sweep of commands/ and test-fixtures/ against the befund.schema.json const; (2) path portability — any ../../../ escape above the plugin root in plugins/*/skills/ fails the build; (3) export sync — the new zero-dep scripts/check-export-sync.js normalizes exports/skills/*.md against their canonical SKILL.md counterparts (frontmatter strip, code-block/ASCII-tree strip, link unwrap, claude-seo cross-ref and platform-footer removal) and fails on any drift beyond the accepted baseline in scripts/export-sync-baseline.txt (re-accept intentional divergence with --update).

Changed

  • Trigger disambiguation between overlapping skillsrecovery-diagnose (data-driven, requires Sistrix/DataForSEO MCP, writes befund.json) and post-core-update-recovery (pure-Markdown framework, no tools) now point at each other in their frontmatter descriptions; likewise recovery-monitor (API-driven weekly tracking) vs sistrix-monday-recovery-check (CSV-only weekly review). In the rescue orchestrator, the rescue diagnose alias now routes to recovery-diagnose and the framework got the new alias rescue framework; the routing digraph gained the "Core-Update drop + MCP tooling available? → recovery-full" branch and a rescue help else-terminal; the missing sub-skill summaries (ai-citations-tracker, gsc-deep-dive, subscription-monetization-audit, and a pointer to the six recovery-* command specs in commands/) were added.

Fixed

  • README/marketplace fact-check pass — removed the unsupported "30+ marketplaces" claim from README and marketplace.json (the channel-economics skill documents ~6 example marketplaces and works from user CSVs); recovery-diagnose row now says "GSC, with CSV fallbacks" (GSC access is MCP/API-first, CSV is the degradation tier); exports paragraph names the actual shipped file seo-rescue-overview instead of rescue; per-audit cost normalized to ~$0.05–$0.50 everywhere (README table vs. "Before you run anything" row vs. COSTS.md TL;DR previously mixed € and $); recovery-monitor row notes the score is null on insufficient data; CONTRIBUTING link no longer implies a CONTRIBUTING.md exists; CLAUDE.md exports platform list gained the missing Continue.dev; minor wording ("build-up phase", "Recovery Retainer").
  • Recovery spec/schema/script reconciliation + RECOVERY_SYSTEM fork merge — six fixes: (1) schema_version unified to "1.0.0" across all recovery command docs and fixtures (docs claimed "2.0"; schemas, scripts, and existing data are 1.0.0); (2) the fictional "lokaler Minimal-Crawler" fallback removed from the recovery-crawl docs — the script is a data-processing helper, not a crawler; degradation now goes SF MCP → CSV-import → failed; (3) documented script call snippets corrected to the real writeIssuesJSON(...)/writeMonitorEntry(...) signatures, and recovery-monitor.js gained backward-compatible options passthrough for keywords_total, source_notes, settlement_gate_status, change_effects, audit_health, viTrend4wPct, backlinkSpamScore; (4) recovery-monitor score engine aligned with its spec: no hardcoded neutral backlink_quality = 50 (the ≥2-components rule is now real), components emitted as { value, weight } objects with weights normalized to 1.0, issue_reduction gated on fresh issue data, vi_trend computed from vi_trend_4w_pct when provided (befund-baseline fallback documented as such), phase: null without baseline instead of a guessed R2, failed reserved for no-write aborts (history.schema.json updated to match); (5) the two divergent RECOVERY_SYSTEM.md forks merged — plugins/seo-rescue/references/RECOVERY_SYSTEM.md is now the canonical union (v0.5.2 status note + section-10 score disambiguation from the root copy; §4b/§4c/Step-7a/batch-velocity/shared-CMS-trap/§12a kept), the root file is a pointer stub, and the stale "It does not block edits." claim is replaced by "does not block edits by default, except when a Settlement Gate is active (§12a)"; (6) stale "v0.5.1" ship claims corrected to "shipped in v0.5.2" in SISTRIX_MONDAY_RECOVERY_CHECK.md, ROADMAP.md, ARCHITECTURE.md and the sistrix-monday-recovery-check skill.
  • Recovery-command consistency sweeprecovery-plan's settlement-gate output now uses the nested settlement_gate_status mirror ({ active, next_allowed_review_date, unlock_status }) instead of flat fields, matching recovery-diagnose and recovery-monitor; action-plan.schema.json gained the matching settlement_gate_status property (byte-identical to befund/history). recovery-monitor gained the Change Governance and Ausgabe an den User sections for section parity with the other recovery commands. Docs/schema only — no runtime behavior change.
  • Step-12 integration, N=1 markers, stage vocabulary — the knocking-at-the-door cohort finder is now a real workflow step instead of an orphaned appendix: moved to recovery-diagnose Schritt 11 (before the befund write, steps renumbered), hardening_candidates added to befund.schema.json (optional/nullable, max 10 entries, experimental_n1), GSC declared as an optional capability with a graceful-degradation row (hardening_candidates: null + warning without GSC), consumed by recovery-plan as quick-win evidence (risk ≥ yellow) and surfaced in the recovery-full summary; the rule-of-thumb expected-CTR curve now lives in ONE canonical table (recovery-diagnose Schritt 11) referenced from RECOVERY_SYSTEM §8. The v0.5.4 rules (rendered-source verification, governing-fact, gate append-only audit, knocking-at-the-door, §4a healthy-% thresholds, trust-anchor generalization) all carry explicit experimental_n1 / "one observed case (N=1)" markers matching the L1/L2/L4a convention. RECOVERY_SYSTEM gained a stage/phase vocabulary table disambiguating the three namespaces (Stage 0–5 keyword milestones, diagnostic stage R1–R5, work phase R1–R5, ordered R1<R2<R3<R4<R5) with the §4c cross-reference corrected (it pointed R1→R5 at §4, which defines Stage 0–5); the diagnostic R1–R5 bands are now numeric defaults over vi_trend_4w_pct (R1 < −10, R2 −10…+2, R3 +2…+10, R4 > +10 below 0.9×peak, R5 ≥ 0.9×peak; marked experimental/calibratable, consistent with the L4a re-entry threshold), defined in recovery-diagnose itself; stage_status.stage may now be null when VI data is missing.
  • Rescinded AI-citations claim propagated — the "AI citations move 2–6 weeks before SISTRIX VI" operational-finding phrasing (rescinded 2026-06-03, pre-update plateau) is now consistently stated as an N=1 hypothesis ("log the signal, do not act on it alone") in RECOVERY_SYSTEM §4, SISTRIX_MONDAY_RECOVERY_CHECK.md, DECISION_ENGINE r-ai-citations-leading-indicator (confidence Medium → Low, both copies), and the ai-citations-tracker, sistrix-monday-recovery-check, ai-search-rescue, and rescue skill texts.
  • Recovery-suite consistency fixesrecovery-audit: stale "recovery-diagnose calls recovery-audit at the start" claim removed; its settlement_gate example block aligned to the recovery-gate.schema.json field names (settlement_gate_active, allowed_actions, blocked_actions) and seo-change-audit.schema.json now defines the settlement_gate subproperties. SEO_SETTLEMENT_GATE.md: superseded_history[] corrected to the schema name gate_history[], §8 example extended with a gate_history entry, and a sentence maps the three audit surfaces (§8 gate_history / §13 change-history.ndjson recovery_gate_unlock / §11.A settlement_gate_override). recovery-plan + action-plan.schema.json: plan actions unified on actions[] with per-action hypothesis_id/hypothesis_status_snapshot/fix_scope_match/verified_by_source_tier, and the gate fields (hypothesis_verification_gate, batch_limit, live_changes_allowed, allowed_now, blocked_now, emergency_exceptions, reason) added as optional/nullable schema properties. The three Shopware issue types (shopware_url_resolver_conflict, dreisc_301_404_chain, duplicate_canonical_blog) added to issues.schema.json and the recovery-crawl.js SEVERITY_MAP (high; duplicate-canonical upgrades to critical on Top-10 rankings). recovery-crawl.js no longer defaults crawler_provider to 'unknown' (caller must declare it; missing provider warns and caps data_quality at partial) and the CSV value is csv_import (was manual_csv). recovery-diagnose: VI history corrected to 26 weekly snapshots/6 months with the concrete domain.sichtbarkeitsindex date-parameter pattern, and the diagnosis table got an explicit first-matching-row rule (mixed only with two independently evidenced diagnoses). recovery-full: step headers carry the [1/5]…[5/5] numbering, the shared run_id clause was added to all sub-commands ("use the orchestrator's run_id, don't generate your own prefix"), and the "Warnun" typo is fixed. recovery-monitor documents who produces snapshots/cms-slots/*.json (external tooling; monitor/audit are read-if-present). RECOVERY_SYSTEM batch velocity tightened from "3–5 per day" to "3 per calendar day (4–5 only with explicit batch plan, >5 never)" matching the binding SAFE_LIVE_CHANGE_RULES table, and "stable rankings" is now defined once (no ≥5-position swing between Monday snapshots, no money-keyword regression, N=3 consecutive snapshots) and referenced from the Do-Not-Touch exit and the phase-advancement criteria. Porting recovery-audit.md to the German command template is logged as a TODO in the ROADMAP v0.5.4 block.
  • Plugin path portability — all ../../../../ repo-root references in plugins/seo-rescue/skills/ eliminated: SISTRIX_MONDAY_RECOVERY_CHECK.md copied to plugins/seo-rescue/references/ as the canonical copy (the root file is now a pointer stub, analog to RECOVERY_SYSTEM.md), the six recovery SKILL.md wrappers and the sistrix/rescue skills now use ${CLAUDE_PLUGIN_ROOT}/commands|references|schemas|scripts/... instead of ../../ relative paths, and repo-only files referenced from skill text (SECURITY.md, CHANGELOG.md, COSTS.md, ONBOARDING.md, ARCHITECTURE.md, .gitignore, examples/) are explicitly labeled "in the repository, not shipped in the plugin package". The RECOVERY_SYSTEM.md#§N deep links in ARCHITECTURE.md and DECISION_ENGINE.md now point at the canonical plugin copy instead of the root stub.
  • Version/counter sync — the 17 stale metadata.version: '0.5.2' skill frontmatters, the rescue orchestrator's "Latest installable version: v0.5.2" claim, and the README "v0.5.2 shipped" line bumped to 0.5.3 (matching plugin.json); the wrong hardcoded skill counts in the rescue orchestrator ("sixteen sub-skills", "routes to ten specialized sub-skills") replaced with count-free wording — the marketplace "Eighteen" stays, it is correct (1 orchestrator + 17 sub-skills/commands).
  • Frontmatter key user-invokableuser-invocable — the official Claude Code skill frontmatter field is spelled user-invocable (verified against the code.claude.com skills reference); the misspelled key was silently ignored in all 18 skills. Renamed in every SKILL.md plus the CLAUDE.md and exports/ mentions. No behavior change (the value true is the default), but the field is now actually recognized.
  • Export reverse drift — the epistemic caveat on the 50–80 % recovery-outcome range ("observations from a small case-base, not population statistics — treat them as input hypotheses, not predictions") existed only in exports/skills/post-core-update-recovery.md; ported back into the canonical post-core-update-recovery/SKILL.md.