paulkinlan/web-resilience/web-resilience-fix

Web Resilience Fix

Map resilience audit findings to concrete remediation patterns, apply the fixes (against the site's source when available), and re-run the audit to measure the delta. Companion to web-resilience-audit.

When to use

• The user has a resilience audit report (from web-resilience-audit or the eval

harness) and wants the issues fixed.

• The user wants a remediation plan for a known failure class (offline, fonts,

low memory, backgrounding).

• You are the "fix" step of the eval loop (audit → fix → re-audit → delta).

The pattern library

Map each finding class to remediation patterns. The modern-web-guidance corpus covers performance + font-visual-stability; resilience-specific patterns below are the gaps the guides must fill (see docs/GUIDES-GAP.md). Where a guide exists, follow it; where it doesn't, use the canonical pattern here + flag the gap so a guide can be authored.

Guide library (guides/ — 22)

Every failure class has a guide: symptom → root cause → canonical pattern → before/after → re-verify command. Consult the guide for the class you're fixing (offline-fallback, font-resilience, js-resilience, backgrounding-lifecycle, crash-recovery, permission-denial-handling, abort-controller-timeouts, heavy-ads-interventions, dns-network-failure, third-party-dependency-resilience, service-worker-operations, realtime-reconnect, asset-starvation, low-memory, cold-start-cache-strategy, css-resilience, storage-quota, single-core, session-recovery, optimistic-ui-reconciliation, spa-deep-link-routing, hydration-consistency).

Process

1. Read the audit report (audit.json). Group findings by failure class.
2. For each class: pick the patterns above, check modern-web-guidance for a

matching recipe, and apply fixes to the source when the user provides it (or produce a precise remediation plan with file/line targets).

1. Fix + retest: re-run the audit with the same launcher the audit skill uses

(WR="${WEB_RESILIENCE_HOME:-$HOME/.gemini/config/plugins/web-resilience-plugin}/bin/wr", then $WR audit <url> --all --prime --screenshot --out /tmp/reaudit-<site>) and compare:

• network failures under offline/dns-fail (should drop to ~0 with a SW)
• fonts all loaded or graceful fallbacks under block-fonts
• console errors under block-js/block-css (should be ~0)
• nav under offline (should succeed via SW shell)
• crash/background recovery signals

1. Report the delta as a table (scenario → before → after → verdict).

Leak detection

For memory-related findings, use the CDP memory domains: Memory.getDOMCounters (node/JS listener counts before vs after repeated interactions), Memory.prepareForLeakDetection, and heap snapshots via the HeapProfiler domain. A growing DOM-node or listener count across repeated flows = a leak to fix (event listener cleanup, detached nodes, closures retaining DOM).

Rules

• Never weaken a test to make a fix pass — the audit assertions are the contract.
• If a pattern is missing from modern-web-guidance, apply the canonical pattern

AND flag the guide gap (docs/GUIDES-GAP.md) so it can be authored.

• One failure class can need multiple guides (e.g. offline → SW shell + offline

UI + state sync). Don't stop at the first pattern.