Skill: ailough/openclaw-theme-patcher (version 1.0.0)

--- name: openclaw-theme-patcher description: Add, refine, calibrate, or migrate OpenClaw Control UI themes by patching the installed bundled frontend assets in dist/control-ui/assets. Use when a user wants a new WebUI theme, wants colors matched to a reference theme such as VSCode, wants chat/component styling tuned inside a custom theme, or wants an existing custom theme preserved across an OpenClaw upgrade. --- # OpenClaw Theme Patcher Add a new OpenClaw Control UI theme directly into the installed frontend bundle. This skill also covers **theme migration across OpenClaw upgrades**. When a user already has a custom theme on an older installed bundle and wants to keep it after updating OpenClaw, preserve the old theme first, then migrate it into the new bundle using structural comparison rather than heuristic string injection. ## Scope Use this skill for installed bundle patching, not upstream source development. Default rule: add a new theme from the user's requested palette. Do not overwrite built-in themes unless the user explicitly asks. For migrations, use a stricter rule set: - preserve the user's old custom theme first - treat the old and new bundles as potentially different structures - never assume previous patch points still exist after an upgrade - prefer restoring the UI to a known-good stock state over leaving a half-migrated broken theme live ## Files to patch Patch the active OpenClaw install only: - `dist/control-ui/assets/index-*.js` - `dist/control-ui/assets/index-*.css` Resolve the active install first. Do not assume the workspace copy is the live one. ## Workflow For token design and live bundle patch locations, read as needed: - `references/token-mapping.md` - `references/patch-points.md` - `references/theme-migration-checklist.md` when doing a version-to-version preserve/rebuild of an existing custom theme Bundled helper script: - `scripts/backup_theme_bundle.py` — backs up the active live JS/CSS bundles for a given theme id, extracts `:root[data-theme=<id>]` / `:root[data-theme=<id>-light]`, and saves JS snippets for the allowed set, alias map, resolver, and theme card when found If the task is an upgrade or migration, follow the migration workflow below before any new patching. For day-of execution, prefer using `references/theme-migration-checklist.md` as the short operational checklist and this file as the fuller policy/guidance layer. ### 0. Migration workflow for existing custom themes Use this when the user already has a custom theme on an older OpenClaw version and wants to keep it across an update. #### Phase A. Snapshot the old theme before upgrade Before updating OpenClaw: - resolve the active install and active bundle files - extract and save the old theme's CSS selectors from the live CSS bundle - save a copy of the old JS and CSS bundles for offline comparison - record the old theme id, visible label, description, and any resolver behavior you can confirm Preferred method: ```bash python3 scripts/backup_theme_bundle.py <theme-id> --output-dir /path/to/backups ``` Use manual extraction only if the helper script cannot capture enough of the live theme. Leave the backup in the workspace, for example: ```text backups/openclaw-<theme-id>-theme/ report.json <theme-id>.dark.css <theme-id>.light.css bundle-js.txt bundle-css.txt ``` Minimum capture: - old JS bundle path - old CSS bundle path - `:root[data-theme=<theme-id>]` - `:root[data-theme=<theme-id>-light]` if present - old JS snippets containing: - allowed theme id set - theme alias/default map - theme card list - resolver branch for the theme family #### Phase B. Upgrade first, then rediscover structure After the OpenClaw update: - re-resolve the active install and the new hashed bundle filenames - do **not** assume the old JS patch points are still valid - inspect the new bundle's current theme structures fresh #### Phase C. Compare old vs new structures Compare the saved old bundle snippets to the new live bundle and answer these questions before editing: - Does the new bundle still use an explicit allowed-theme set? - Does it still use an alias/default map? - Does it still use a visible theme card list? - Does it still have a resolver that maps theme family + mode to selector id? - Are any of those names, array shapes, or branches materially different? Only patch after those answers are clear. #### Phase D. Patch by exact structure, not guesswork Migration rule: - copy the old theme's CSS token values - re-register the theme in the new bundle **using the new bundle's actual structures** - keep edits surgical and reversible Hard prohibition: - never use broad or heuristic replacements like replacing the first `return e` or first matching `new Set(...)` unless you have first confirmed that exact snippet is the theme resolver or set you intend to patch - never claim success just because the theme card appears; card presence alone is not proof of a correct migration #### Phase E. Verify and, if broken, stop the bleeding first If the migrated theme appears but looks wrong, or if unrelated UI behavior breaks: 1. identify whether the break is in CSS selectors, card registration, alias/default map, or resolver logic 2. if the UI is visibly degraded, first remove the broken migrated entry and revert residual bad injections so the UI returns to stock behavior 3. only then attempt a second migration pass Preferred recovery order: - restore normal UI first - then rebuild the migrated theme from verified structures ### 1. Confirm the active install Run: ```bash which openclaw readlink -f "$(which openclaw)" openclaw status ``` Then locate candidate bundles: ```bash find ~/.npm-global/lib/node_modules /usr/lib/node_modules /usr/local/lib/node_modules \ -path '*/openclaw/dist/control-ui/assets/index-*.js' -o \ -path '*/openclaw/dist/control-ui/assets/index-*.css' ``` If multiple installs exist, patch only the one that matches the active CLI path. ### 2. Define the theme Collect the theme from one of: - a named reference theme - a local config file such as VSCode settings or theme JSON - explicit palette colors - a screenshot plus user guidance Decide before patching: - theme id: lowercase, short, stable - theme label shown in Appearance - dark palette - light palette if the theme should work with the existing light/dark toggle If the theme should support the toggle, implement both dark and light selectors. For both new themes and migrations, define not only the palette but also the intended component feel: - primary chrome and panel feel - assistant bubble feel - user bubble feel - code/pre/blockquote feel - border strength expectations Do not assume token changes alone will always reproduce the intended message-bubble look in newer bundles. ### 3. Add CSS selectors Add: ```css :root[data-theme=<theme-id>]{...} :root[data-theme=<theme-id>-light]{...} ``` Use an existing theme block as the structure template. Keep token names unchanged and only change values. Use `references/token-mapping.md` to translate the user's palette into OpenClaw tokens. At minimum define: - `--bg`, `--bg-elevated`, `--panel`, `--card` - `--text`, `--text-strong`, `--muted` - `--border`, `--border-strong`, `--border-hover` - `--accent`, `--accent-hover`, `--ring`, `--focus` Also define the usual supporting tokens already used by existing themes, including input, secondary, accent-2, state colors, and shadow/subtle variants. If the desired result depends on specific chat bubble behavior, it is acceptable to add small **theme-scoped component overrides** after the root selectors, for example only under: ```css :root[data-theme=<theme-id>] .chat-line.user .chat-bubble{...} :root[data-theme=<theme-id>] .chat-line.assistant .chat-bubble{...} ``` In newer OpenClaw bundles, verify which chat layout branch is actually live before calibrating. There may be more than one branch in the bundled CSS, commonly including `.chat-group...` and `.chat-line...` families. If both exist, inspect both and override the one that actually renders in the current UI; if needed, cover both branches under the same theme-scoped override. Rules for component overrides: - scope them to the theme selector only - prefer chat/message/component overrides only when token-only theming is insufficient - do not change built-in themes while adding overrides for the custom theme - keep overrides as narrow as possible - when multiple chat layout branches exist, confirm the active branch instead of assuming the first matching selector is live ### 4. Register the theme in bundled JS Patch the bundled JS so the theme appears in Appearance settings and mode switching resolves correctly. Use `references/patch-points.md` to locate the smallest reliable JS change points. Update all relevant structures that actually exist in the current bundle: - allowed theme id set - Appearance theme card list - resolver mapping theme family + light/dark mode to CSS selector ids - alias/default map if present Required behavior: - dark mode resolves to `<theme-id>` - light mode resolves to `<theme-id>-light` If the bundle already contains an unused hidden theme id that matches the intended use, it is acceptable to expose and complete it instead of inventing another id. For migrations, mirror the old theme's confirmed behavior, but express it through the new bundle's real structures. Do not port old JS fragments blindly into a new version. ### 5. Refresh and verify After patching: - tell the user to hard refresh: `Ctrl+F5` - restart gateway if needed: `openclaw gateway restart` Success means: 1. the new theme label appears in Appearance settings 2. selecting it visibly changes the UI 3. the top-right light/dark toggle switches between the new theme's variants if both were added 4. built-in themes remain unchanged unless the user requested otherwise 5. chat bubbles, code blocks, blockquotes, and key chrome surfaces match the intended look closely enough for the user For chat-focused themes, explicitly verify both of these: - user bubble color and border treatment - assistant bubble color and border treatment ## Debugging If the theme does not appear: - theme id missing from JS allowed set - theme card list not patched - stale cached JS - wrong install path edited If the theme appears but looks unchanged: - CSS selectors missing - resolver maps to the wrong selector id - only dark or only light selector was added - wrong CSS bundle edited If the light/dark toggle does not work: - resolver was not updated for both variants - `<theme-id>-light` is missing or misspelled If the theme appears but looks wrong or breaks unrelated UI text/layout after a migration: - assume the JS patch hit the wrong structure before assuming the CSS palette is wrong - inspect the exact current resolver/card/alias snippets again - remove any bad migration residue and restore stock behavior before retrying - do not keep a visibly broken migrated theme live just because the theme card exists If the theme is structurally correct but some surfaces still feel off: - treat it as a component-level calibration pass, not a failed migration - inspect the exact CSS rules for chat bubbles, code blocks, and other visible components in the current version - prefer theme-scoped overrides over destabilizing global token changes - if a component override appears correct in CSS but has no visual effect, check whether a later duplicate branch (for example `.chat-group...` vs `.chat-line...`) is the one actually rendering ## Working style - Use exact-text edits for bundled assets - Change the smallest possible amount of JS needed - Keep built-in themes intact unless the user asked otherwise - Do not claim success until the user confirms the live UI changed - For migrations, create reversible workspace backups before editing live bundles - Prefer exact known snippets over heuristic replacements in minified JS - If a first migration attempt fails, document the failure mode and switch to compare-and-rebuild, not more guessing - For new themes too, verify real rendered components after token work; if necessary, do one small theme-scoped calibration pass instead of pretending token-only theming always covers chat surfaces ## Deliverables Leave behind: - patched JS bundle path - patched CSS bundle path - theme id and label - dark/light CSS selectors added - any theme-scoped component overrides added For migrations also leave behind: - backup directory path - old bundle paths used for comparison - whether stock UI was restored at any point during recovery - the exact structures patched in the new version (allowed set / card list / alias map / resolver) - whether the helper backup script was used, and if not, what had to be collected manually

path: references/patch-points.md
content: # Bundle Patch Points

Use this file to patch the installed OpenClaw Control UI bundle with the smallest possible change set.

For upgrade migrations, use this file to compare the old saved bundle structures to the new live bundle before editing. Do not assume old patch locations survive a version bump.

## Active files

Patch the active install only:
- `dist/control-ui/assets/index-*.js`
- `dist/control-ui/assets/index-*.css`

Resolve the live install first with:

```bash
which openclaw
readlink -f "$(which openclaw)"
openclaw status
```

## JS patch points

In the minified JS bundle, locate these structures.

Migration rule: confirm each structure in the current live bundle before patching it. A previous version may have used a different variable name, list shape, or resolver branch layout.

### 1. Allowed theme id set

Typical shape:

```js
var Za=new Set([`claw`,`knot`,`dash`, ...])
```

Add the new theme id here.

### 2. Theme alias/default map

Typical shape:

```js
$a={...,tokyoNight:{theme:`tokyo-night`,mode:`dark`}}
```

Add an alias entry if the bundle uses one.

### 3. Theme card list in Appearance

Typical shape:

```js
var Wb=[
  {id:`claw`,label:`Claw`,...},
  ...
]
```

Add a new card:
- `id`: theme id
- `label`: user-facing label
- `description`: short description
- `icon`: reuse an existing icon token

### 4. Resolver function

Typical shape:

```js
function ro(e,t){...}
```

Required behavior:
- dark mode -> `<theme-id>`
- light mode -> `<theme-id>-light`

Critical warning:
- do not patch the resolver by broad heuristics such as replacing the first `return e`
- only edit the resolver after confirming the exact theme-switch branch in the current bundle
- if you cannot identify the resolver confidently, stop and inspect more context instead of guessing

## CSS patch points

Append or insert two theme selectors:

```css
:root[data-theme=<theme-id>]{...}
:root[data-theme=<theme-id>-light]{...}
```

Use an existing theme block as the structure template.

## Minimal verification

After patching, verify all of these:

1. Theme appears in `Settings -> Appearance -> Theme`
2. Selecting it changes the UI immediately or after hard refresh
3. Top-right light/dark toggle switches variants when both selectors exist
4. Existing themes still look unchanged

For migrations also verify:
5. The migrated theme visually matches the saved old CSS intent
6. No unrelated UI text/layout regressions appear after the JS patch

## Failure mapping

### Theme missing from list
- JS card list not patched
- theme id missing from allowed set
- stale cached JS
- wrong install path edited

### Theme visible but no visual change
- CSS selectors missing
- resolver targets wrong selector id
- wrong CSS file edited

### Light/dark toggle does nothing for new theme
- resolver missing new branch
- `<theme-id>-light` selector missing or misspelled

## Editing style

- prefer exact-text edits
- keep each edit surgical
- do not refactor minified bundle code
- patch the smallest number of strings needed
- when migrating, save the pre-edit live bundle or ensure you already have a stock recovery path
- if a migration patch breaks unrelated UI, remove the broken theme registration first, restore stock behavior, then retry from structural comparison


path: references/theme-migration-checklist.md
content: # Theme Migration Checklist

Use this as the short execution checklist when preserving or rebuilding a custom OpenClaw Control UI theme across versions.

## A. Before upgrade

- Resolve the active install:
  - `which openclaw`
  - `readlink -f "$(which openclaw)"`
  - `openclaw status`
- Record the active bundle paths:
  - `dist/control-ui/assets/index-*.js`
  - `dist/control-ui/assets/index-*.css`
- Extract and save:
  - `:root[data-theme=<theme-id>]`
  - `:root[data-theme=<theme-id>-light]` if present
- Save copies of the old live JS/CSS bundles into a workspace backup folder
- Capture old JS snippets for:
  - allowed theme id set
  - alias/default map
  - theme card list
  - resolver branch

## B. After upgrade

- Re-resolve the new active install and new hashed bundle paths
- Do not reuse old offsets, variable names, or patch positions blindly
- Reconfirm the new bundle's real structures for:
  - allowed set
  - alias/default map
  - card list
  - resolver

## C. Rebuild safely

- Port the old theme's CSS token values into the new CSS bundle
- Register the theme in the new JS bundle using the new version's real structures
- Keep edits surgical and reversible
- Never use heuristic replacements like changing the first `return e`

## D. Verify visually

- Theme appears in `Settings -> Appearance`
- Theme selection visibly changes the UI
- Light/dark toggle switches to the correct paired selector
- Built-in themes still behave normally
- The migrated theme still matches the intended old look closely enough

## E. If visuals are wrong

Treat this as one of two different failure classes.

### Structural failure

Signs:
- theme card appears but wrong theme resolves
- light/dark toggle fails
- unrelated UI text/layout regresses

Action:
- inspect JS structures again
- remove broken migrated entry if needed
- restore stock UI first
- retry from structural comparison

### Calibration failure

Signs:
- structure works, but specific surfaces feel off
- common examples: chat bubbles, code blocks, blockquotes, panel/chrome feel

Action:
- inspect exact current CSS rules for the affected component
- prefer small theme-scoped overrides under `:root[data-theme=<theme-id>] ...`
- keep overrides narrow and avoid changing built-in themes

## F. Chat-specific calibration

For chat bubble work, verify which layout branch is actually live in the current bundle.
Common branches may include:
- `.chat-group...`
- `.chat-line...`

Do not assume the first matching branch is the rendered one.
If necessary, override both branches under the custom theme selector.

## G. Leave behind

- backup directory path
- old bundle paths
- patched new bundle paths
- exact JS structures patched
- CSS selectors added
- any theme-scoped component overrides added


path: references/token-mapping.md
content: # Theme Input → Token Mapping

Use this file when translating a reference theme, screenshot, or palette into OpenClaw Control UI CSS tokens.

## Goal

Map a user's desired theme into a complete and internally consistent token set without changing token names.

## Required output selectors

For a theme id `<theme-id>`:

```css
:root[data-theme=<theme-id>]{...}
:root[data-theme=<theme-id>-light]{...}
```

If the user only wants a dark theme, still prefer drafting a light variant unless they explicitly say dark-only.

## Core mapping

### Background stack

These define the overall depth of the UI.

- `--bg`: main app background
- `--bg-accent`: secondary background zone
- `--bg-elevated`: elevated surface behind panels/dialogs
- `--bg-hover`: hover state on dark/light surfaces
- `--bg-muted`: muted surface fill
- `--panel`: outer panel background
- `--panel-strong`: stronger panel surface
- `--panel-hover`: hovered panel state
- `--card`: card background
- `--popover`: popover / dropdown background
- `--chrome`: top-level chrome with slight transparency
- `--chrome-strong`: stronger chrome layer

Rule:
- keep these in a tight tonal family
- separate them by small but visible steps
- never make `--card`, `--panel`, and `--bg` identical unless the user wants ultra-flat UI

Suggested depth ordering:
- dark: `bg` < `bg-accent/card` < `bg-elevated/panel-strong`
- light: reverse the same logic with lighter surfaces

### Text stack

- `--text`: default text
- `--text-strong`: headings / emphasized text
- `--chat-text`: usually same as `--text`
- `--muted`: secondary text
- `--muted-strong`: stronger secondary text
- `--muted-foreground`: usually same family as `--muted`
- `--card-foreground`: text on cards/popovers
- `--popover-foreground`: text on popovers

Rule:
- `--text-strong` must always be clearly more legible than `--muted`
- do not let muted text get too close to border color

### Border stack

- `--border`: default border
- `--border-strong`: important separators / selected outlines
- `--border-hover`: hovered outline
- `--input`: input border / fill
- `--grid-line`: subtle divider line

Rule:
- in dark themes, borders usually need more contrast than designers first expect
- in light themes, borders should remain visible without turning the UI harsh

### Primary interaction stack

Use the main accent color from the reference theme.

- `--ring`: focus ring source
- `--accent`: primary accent
- `--accent-hover`: hover state of accent
- `--accent-muted`: same hue, lower emphasis
- `--accent-subtle`: low-alpha accent fill
- `--accent-glow`: glow/focus aura
- `--primary`: usually same as accent
- `--primary-foreground`: text on primary buttons
- `--focus`: translucent focus fill

Rule:
- prefer one clear primary accent family
- `--accent-hover` should be a nearby lighter/brighter variant in dark mode, and often slightly darker or richer in light mode

### Secondary accent stack

Use a secondary hue only if the reference theme clearly has one.

- `--accent-2`
- `--accent-2-muted`
- `--accent-2-subtle`

Good sources:
- purple/violet from Tokyo Night
- teal/green from Nord
- mauve/blue from Catppuccin

### State colors

- `--ok`
- `--warn`
- `--danger`
- `--destructive`
- `--info`

Rule:
- keep them readable against the theme background
- do not reuse the primary accent for all states

## Practical extraction order

When deriving from a reference theme, decide in this order:

1. main background
2. elevated/card background
3. default text
4. muted text
5. border family
6. primary accent
7. secondary accent
8. state colors
9. shadows and subtle alpha tokens

## Theme families: common mappings

### Tokyo Night style

Typical anchors:
- background: deep blue-black
- surface: indigo/slate
- text: cool desaturated lavender/blue-gray
- primary accent: blue
- secondary accent: violet
- success: green
- warning: amber
- danger: pink/red

### Nord style

Typical anchors:
- background: cool blue-gray
- surface: slightly lighter steel blue
- text: frosted light gray-blue
- primary accent: icy blue
- secondary accent: teal or muted cyan

### Catppuccin style

Typical anchors:
- background: warm muted dark/light neutrals
- surface: creamy or soft slate layers
- text: soft but clear pastel-tinted neutrals
- primary accent: mauve/blue depending on flavor
- secondary accent: pink/teal/sapphire depending on flavor

## Stability rules

- keep `--ring`, `--accent`, and `--primary` in the same family unless there is a strong reason not to
- keep `--chat-text` aligned with `--text`
- keep `--secondary-foreground` readable on `--secondary`
- keep `--card-foreground` and `--popover-foreground` aligned with the main text stack
- do not invent extra token names

## Fast token checklist

Before finalizing a new theme, check:
- background layers visibly separate
- text is readable on card and panel surfaces
- borders are visible but not louder than text
- accent stands out from info/success/warn/danger
- focus ring is visible on both dark and light variants
- top-right light/dark toggle actually changes the theme variant if both selectors were added


path: scripts/backup_theme_bundle.py
content: #!/usr/bin/env python3
from __future__ import annotations

import argparse
import json
import re
import shutil
import subprocess
from pathlib import Path
from typing import Optional

SEARCH_ROOTS = [
    Path.home() / ".npm-global" / "lib" / "node_modules",
    Path("/usr/lib/node_modules"),
    Path("/usr/local/lib/node_modules"),
]


def run(cmd: list[str]) -> str:
    return subprocess.check_output(cmd, text=True).strip()


def resolve_active_install() -> Path:
    openclaw_bin = run(["bash", "-lc", "which openclaw"])
    resolved = run(["bash", "-lc", f'readlink -f "{openclaw_bin}"'])
    return Path(resolved).resolve().parent


def find_asset(kind: str) -> Path:
    active = resolve_active_install()
    base = active.parent / "dist" / "control-ui" / "assets"
    if kind == "js":
        matches = sorted(base.glob("index-*.js"))
    else:
        matches = sorted(base.glob("index-*.css"))
    if not matches:
        raise FileNotFoundError(f"No {kind} bundle found under {base}")
    return matches[0]


def extract_css_block(css_text: str, selector: str) -> Optional[str]:
    pattern = re.escape(selector) + r"\{[^}]*\}"
    m = re.search(pattern, css_text)
    return m.group(0) if m else None


def extract_js_snippets(js_text: str, theme_id: str) -> dict[str, Optional[str]]:
    snippets: dict[str, Optional[str]] = {
        "allowed_set": None,
        "alias_map": None,
        "resolver": None,
        "theme_card": None,
    }

    allowed = re.search(r"new Set\(\[[^\]]*`" + re.escape(theme_id) + r"`[^\]]*\]\)", js_text)
    if allowed:
        snippets["allowed_set"] = allowed.group(0)

    alias = re.search(r"\{[^{}]*" + re.escape(theme_id) + r":\{theme:`" + re.escape(theme_id) + r"`,mode:`dark`\}[^{}]*\}", js_text)
    if alias:
        snippets["alias_map"] = alias.group(0)

    resolver = re.search(re.escape(f"e===`{theme_id}`?n===`light`?`{theme_id}-light`:`{theme_id}`"), js_text)
    if resolver:
        start = max(0, resolver.start() - 600)
        end = min(len(js_text), resolver.end() + 1200)
        snippets["resolver"] = js_text[start:end]

    card = re.search(r"\{id:`" + re.escape(theme_id) + r"`,label:`[^`]+`,description:`[^`]+`,icon:[^}]+\}", js_text)
    if card:
        snippets["theme_card"] = card.group(0)

    return snippets


def main() -> None:
    ap = argparse.ArgumentParser(description="Backup an installed OpenClaw custom theme from the live bundle.")
    ap.add_argument("theme_id", help="Theme id, e.g. contrast")
    ap.add_argument("--output-dir", default=str(Path.cwd() / "backups"), help="Base backup directory")
    args = ap.parse_args()

    theme_id = args.theme_id.strip()
    out_base = Path(args.output_dir).expanduser().resolve()
    backup_dir = out_base / f"openclaw-{theme_id}-theme"
    backup_dir.mkdir(parents=True, exist_ok=True)

    js_path = find_asset("js")
    css_path = find_asset("css")
    js_text = js_path.read_text(encoding="utf-8", errors="ignore")
    css_text = css_path.read_text(encoding="utf-8", errors="ignore")

    dark_selector = f":root[data-theme={theme_id}]"
    light_selector = f":root[data-theme={theme_id}-light]"
    dark_block = extract_css_block(css_text, dark_selector)
    light_block = extract_css_block(css_text, light_selector)
    js_snippets = extract_js_snippets(js_text, theme_id)

    (backup_dir / "bundle-js.txt").write_text(js_text, encoding="utf-8")
    (backup_dir / "bundle-css.txt").write_text(css_text, encoding="utf-8")
    if dark_block:
        (backup_dir / f"{theme_id}.dark.css").write_text(dark_block, encoding="utf-8")
    if light_block:
        (backup_dir / f"{theme_id}.light.css").write_text(light_block, encoding="utf-8")
    (backup_dir / "js-snippets.json").write_text(json.dumps(js_snippets, ensure_ascii=False, indent=2), encoding="utf-8")

    report = {
        "theme_id": theme_id,
        "bundle_js": str(js_path),
        "bundle_css": str(css_path),
        "css_dark_found": bool(dark_block),
        "css_light_found": bool(light_block),
        "js_snippets_found": {k: bool(v) for k, v in js_snippets.items()},
        "backup_dir": str(backup_dir),
    }
    (backup_dir / "report.json").write_text(json.dumps(report, ensure_ascii=False, indent=2), encoding="utf-8")
    print(json.dumps(report, ensure_ascii=False, indent=2))


if __name__ == "__main__":
    main()


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: suspicious (HIGH)