openclacky 1.4.1 → 1.5.1

data/lib/clacky/web/theme.js

@@ -1,12 +1,12 @@
 // theme.js — Theme switcher module
 //
-// Behavior:
-//   • Default follows the OS preference (prefers-color-scheme).
-//   • User can manually override via the 🌓 header button — persisted
-//     to localStorage. Once overridden, the explicit choice wins.
-//   • Choosing the theme that happens to match the current OS setting
-//     clears the override, restoring "auto-follow-system" mode.
-//   • Responds to live OS theme changes when no manual override is set.
+// Single storage key "clacky-theme" stores one of: light | dark | dim | warm
+// All four values are first-class themes — no separate "bg-theme" dimension.
+//
+// Usage:
+//   Theme.init()               — call once on page load
+//   Theme.apply("dark"|…)      — set any theme explicitly
+//   Theme.current()            — returns effective data-theme value
 
 const Theme = (() => {
   const STORAGE_KEY = "clacky-theme";
@@ -18,53 +18,27 @@ const Theme = (() => {
       ? "dark" : "light";
   }
 
+  function _effectiveTheme() {
+    return localStorage.getItem(STORAGE_KEY) || _systemTheme();
+  }
+
   function _applyAttr(theme) {
     document.documentElement.setAttribute(ATTR_NAME, theme);
-    _updateToggleIcon(theme);
+    _syncBgCards();
     window.dispatchEvent(new CustomEvent("clacky-theme-change", { detail: { theme } }));
   }
 
-  function _updateToggleIcon(theme) {
-    const headerToggle = document.getElementById("theme-toggle-header");
-    if (headerToggle) {
-      // Icon shows what you'd switch TO, not what you are on.
-      if (theme === "light") {
-        // In light mode → show moon (click to go dark)
-        headerToggle.title = I18n.t("header.theme.toDark");
-        headerToggle.innerHTML = `<svg xmlns="http://www.w3.org/2000/svg" width="16" height="16" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" class="icon-sm">
-          <path d="M12 3a6 6 0 0 0 9 9 9 9 0 1 1-9-9Z"/>
-        </svg>`;
-      } else {
-        // In dark mode → show sun (click to go light)
-        headerToggle.title = I18n.t("header.theme.toLight");
-        headerToggle.innerHTML = `<svg xmlns="http://www.w3.org/2000/svg" width="16" height="16" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" class="icon-sm">
-          <circle cx="12" cy="12" r="4"/>
-          <path d="M12 2v2"/>
-          <path d="M12 20v2"/>
-          <path d="m4.93 4.93 1.41 1.41"/>
-          <path d="m17.66 17.66 1.41 1.41"/>
-          <path d="M2 12h2"/>
-          <path d="M20 12h2"/>
-          <path d="m6.34 17.66-1.41 1.41"/>
-          <path d="m19.07 4.93-1.41 1.41"/>
-        </svg>`;
-      }
-    }
-
-    // Legacy settings toggle (kept for compatibility)
-    const toggle = document.getElementById("theme-toggle");
-    if (toggle) {
-      const icon  = theme === "light" ? "🌙" : "☀️";
-      const label = theme === "light" ? "Dark" : "Light";
-      toggle.innerHTML = `<span class="theme-icon">${icon}</span><span>${label}</span>`;
-    }
+  // Update active state on all .settings-bg-theme-card buttons.
+  function _syncBgCards() {
+    const effective = current();
+    document.querySelectorAll(".settings-bg-theme-card").forEach(btn => {
+      btn.classList.toggle("active", btn.dataset.bgTheme === effective);
+    });
   }
 
   // ── Public API ───────────────────────────────────────────────────────
   function init() {
-    const saved = localStorage.getItem(STORAGE_KEY);
-    const effective = saved || _systemTheme();
-    _applyAttr(effective);
+    _applyAttr(_effectiveTheme());
 
     // Live-follow OS changes when user has no manual override.
     if (window.matchMedia) {
@@ -75,36 +49,31 @@ const Theme = (() => {
         }
       };
       if (mq.addEventListener) mq.addEventListener("change", onChange);
-      else if (mq.addListener) mq.addListener(onChange);  // Safari < 14
+      else if (mq.addListener) mq.addListener(onChange); // Safari < 14
     }
-
-    // Re-apply title text when language changes.
-    document.addEventListener("langchange", () => _updateToggleIcon(current()));
   }
 
-  // Explicit apply (used by toggle). Persists the choice unless it equals
-  // the OS preference — in which case we clear the override so subsequent
-  // OS theme changes once again propagate.
+  // Apply any theme (light | dark | dim | warm).
   function apply(theme) {
-    _applyAttr(theme);
+    // If the chosen theme matches OS default, no need to persist
     if (theme === _systemTheme()) {
       localStorage.removeItem(STORAGE_KEY);
     } else {
       localStorage.setItem(STORAGE_KEY, theme);
     }
+    _applyAttr(theme);
   }
 
-  function toggle() {
-    const current = document.documentElement.getAttribute(ATTR_NAME) || _systemTheme();
-    const next = current === "dark" ? "light" : "dark";
-    apply(next);
+  // Keep applyBg as alias for backward compat (settings.js calls it)
+  function applyBg(theme) {
+    apply(theme);
   }
 
   function current() {
     return document.documentElement.getAttribute(ATTR_NAME) || _systemTheme();
   }
 
-  return { init, toggle, apply, current };
+  return { init, apply, applyBg, current };
 })();
 
 // Initialize theme on page load

data/scripts/build/src/uninstall.sh.cc

@@ -34,7 +34,7 @@ uninstall_gem() {
     command_exists gem || return 1
     if gem list -i openclacky >/dev/null 2>&1; then
         print_step "Uninstalling via RubyGems..."
-        gem uninstall openclacky -x
+        gem uninstall openclacky -a -x
     else
         print_info "Gem 'openclacky' not found (already removed)"
     fi

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: openclacky
 version: !ruby/object:Gem::Version
-  version: 1.4.1
+  version: 1.5.1
 platform: ruby
 authors:
 - windy
@@ -371,9 +371,7 @@ files:
 - lib/clacky/default_extensions/ext-studio/api/handler.rb
 - lib/clacky/default_extensions/ext-studio/ext.yml
 - lib/clacky/default_extensions/ext-studio/panels/studio/view.js
-- lib/clacky/default_extensions/ext-studio/skills/ext-debug/SKILL.md
-- lib/clacky/default_extensions/ext-studio/skills/ext-publish/SKILL.md
-- lib/clacky/default_extensions/ext-studio/skills/ext-scaffold/SKILL.md
+- lib/clacky/default_extensions/ext-studio/skills/ext-develop/SKILL.md
 - lib/clacky/default_extensions/general/agents/general/avatar.png
 - lib/clacky/default_extensions/general/agents/general/system_prompt.md
 - lib/clacky/default_extensions/general/ext.yml
@@ -406,7 +404,6 @@ files:
 - lib/clacky/default_skills/cron-task-creator/SKILL.md
 - lib/clacky/default_skills/cron-task-creator/evals/evals.json
 - lib/clacky/default_skills/deploy/SKILL.md
-- lib/clacky/default_skills/extend-openclacky/SKILL.md
 - lib/clacky/default_skills/mcp-manager/SKILL.md
 - lib/clacky/default_skills/media-gen/SKILL.md
 - lib/clacky/default_skills/media-gen/scripts/video_seq.sh

data/lib/clacky/default_extensions/ext-studio/skills/ext-debug/SKILL.md

@@ -1,71 +0,0 @@
----
-name: ext-debug
-description: Debug an OpenClacky extension that won't load, throws errors, or whose panel/api/skill/agent isn't showing up. Use when the user reports something broken with their extension, when `clacky ext verify` reports issues, or when a change didn't take effect. Reads structured verify errors and fixes manifest and file problems.
----
-
-# Extension Debug
-
-Diagnose and fix a broken extension. Your primary instrument is `clacky ext verify` —
-it's a compiler for extensions: every issue is structured with a `code`, `message`,
-the offending `file`, and a `hint` telling you how to fix it.
-
-## Step 1 — Run verify
-
-```
-clacky ext verify
-```
-
-Read the output line by line. `[OK]` lines confirm resolved units. `[ERR]` blocks a
-load; `[WARN]` is advisory. Each issue looks like:
-
-```
-[ERR] <ext> <unit> (<code>) — <message> [<file>]
-         hint: <how to fix>
-```
-
-## Step 2 — Fix by error code
-
-- **`loader.error`** — a file the manifest points at is missing or the container
-  couldn't be parsed. Check the `file` path exists and `ext.yml` is valid YAML. A skill
-  needs `SKILL.md` under `skills/<id>/`; an agent needs its `prompt` file; a panel needs
-  its `view` file; api needs `api/handler.rb`.
-- **`schema.unknown_contributes`** — a top-level key under `contributes:` isn't one of
-  `panels api skills agents channels patches hooks`. Fix the spelling.
-- **`schema.unknown_field` / `schema.unknown_key`** — a unit has a field that isn't
-  allowed for its type. Remove or rename it. Allowed fields:
-  - panel: `id title title_zh description description_zh view order attach`
-  - api: `id handler`
-  - skill: `id dir protected`
-  - agent: `id title title_zh description description_zh order prompt panels skills`
-  - channel: `id platform adapter`
-- **`schema.bad_attach`** — a panel `attach:` entry isn't a valid token. Use agent ids
-  or `"*"` for all.
-- **`ref.missing_panel`** — an agent references `panels: [id]` that no panel provides.
-  Fix the id, or use `<ext_id>/<panel_id>` to reference a panel in another extension.
-- **`ref.missing_skill`** — an agent references `skills: [id]` that no skill provides.
-  Fix the id or add the skill.
-- **`ref.missing_attach_agent`** — a panel's `attach:` names an agent that doesn't
-  exist. Fix the agent id.
-- **`override`** (warning) — a unit in a higher layer is shadowing a lower one
-  (`local > installed > builtin`). Usually intentional; confirm with the user if not.
-
-Fix one issue, re-run verify, repeat until clean.
-
-## Step 3 — "It verifies but doesn't show up"
-
-If verify is clean but a change isn't visible:
-- **Hot reload is per-request.** After editing `view.js`, `handler.rb`, or a `SKILL.md`,
-  the user must **reload the WebUI page** — there's no restart, but a stale tab won't
-  update on its own. Editing `ext.yml` also applies on the next load.
-- **Panel not appearing?** Check the panel's `attach:` (or the agent that references it
-  via `panels: [id]`). A panel with no `attach` and no referencing agent has nothing to
-  mount onto.
-- **API 404?** Routes are relative to `/api/ext/<ext_id>/`. Confirm the handler subclasses
-  `Clacky::ApiExtension` and the route pattern matches what `view.js` fetches.
-- **Skill not triggering?** The AI selects skills by their `description`. Make the
-  description concrete about WHEN to use it.
-
-## Step 4 — Confirm the fix
-
-End with a clean `clacky ext verify` and have the user reload to confirm the behavior
-actually works — don't declare success on "should work."

data/lib/clacky/default_extensions/ext-studio/skills/ext-publish/SKILL.md

@@ -1,73 +0,0 @@
----
-name: ext-publish
-description: Pack and publish an OpenClacky extension to the marketplace, publish a new version, list published extensions, or unpublish one. Use when the user wants to ship, release, publish, update, or take down an extension. Handles packing, the license requirement, versioning, and the already-published case.
----
-
-# Extension Publish
-
-Take a finished local extension and ship it to the OpenClacky marketplace, then confirm
-it's live.
-
-## Before publishing
-
-- The extension must live in the **local** layer (`~/.clacky/ext/local/<id>/`). Only
-  local containers can be packed. Encrypted (`SKILL.md.enc`) containers are rejected.
-- Publishing requires an **activated user license** — it proves creator identity, and
-  the platform attributes the extension to that account. If activation is missing, tell
-  the user to activate first; don't try to work around it.
-- Run `clacky ext verify` one last time and confirm no errors before shipping.
-
-## Publish (first time)
-
-```
-clacky ext publish <id>
-```
-
-This packs the local container into a zip and uploads it. On success you'll see:
-
-```
-Published <id> v<version> → status=<status>
-```
-
-Options:
-- `--status draft` — publish as a draft (not yet visible on the public marketplace).
-  Omit or use `--status published` to go live.
-- `--changelog "..."` — release notes for this version.
-
-## Publish a new version
-
-If the extension is already published, a plain `publish` fails with:
-
-```
-Error: <id> already published. Re-run with --force to publish a new version.
-```
-
-Re-run with `--force` (and ideally a `--changelog`) to publish a new version. The patch
-version auto-increments on the platform side.
-
-```
-clacky ext publish <id> --force --changelog "Fixed the weather refresh bug"
-```
-
-## List your published extensions
-
-```
-clacky ext published
-```
-
-Shows each extension with its latest version, status, and unit summary.
-
-## Unpublish
-
-```
-clacky ext unpublish <id>
-```
-
-Soft-deletes (takes down) one of your published extensions. Confirm with the user
-before doing this — it removes it from the marketplace.
-
-## Wrap up
-
-After a successful publish, tell the user the version and status in plain terms, and
-mention they can run `clacky ext published` to see it in their list, or bump a new
-version anytime with `--force`.

data/lib/clacky/default_extensions/ext-studio/skills/ext-scaffold/SKILL.md

@@ -1,65 +0,0 @@
----
-name: ext-scaffold
-description: Scaffold a new OpenClacky extension from an idea. Use when the user wants to create, start, or bootstrap a new extension, plugin, panel, agent, or skill container. Maps the idea to the right contributes types and generates a working skeleton in the local layer.
----
-
-# Extension Scaffold
-
-Turn a plain-language idea into a working extension skeleton, then read the generated
-files so you know what you're working with.
-
-## Step 1 — Understand the idea
-
-Figure out what the extension should DO and which contributes types it needs. Ask one
-clarifying question only if it's genuinely ambiguous. Common mappings:
-
-- "Show me X in a side panel / add a button / dashboard" → **panel** (+ **api** if it
-  needs a backend or to call an external service).
-- "A capability the AI can invoke" (summarize, translate, format) → **skill**.
-- "A specialized assistant with its own personality/tools" → **agent** (usually
-  bundling its own panels/skills).
-- "Connect to Slack / an in-house IM" → **channel**.
-
-Keep it minimal. Most useful extensions are one panel + one handler, or one skill.
-Do NOT add `patches` or `hooks` unless the user explicitly asks — they run arbitrary
-Ruby and carry supply-chain risk.
-
-## Step 2 — Generate the skeleton
-
-Pick a lowercase, hyphenated id derived from the idea (e.g. `weather-panel`).
-
-```
-clacky ext new <id>
-```
-
-This creates `~/.clacky/ext/local/<id>/` with a working hello panel + handler:
-- `ext.yml` — the manifest
-- `panels/hello/view.js` — a panel that pings the backend
-- `api/handler.rb` — a `Clacky::ApiExtension` subclass mounted at `/api/ext/<id>/`
-
-Use `--full` only if the user needs the kitchen-sink reference exercising all seven
-contributes types — it's a lot to read, so prefer the plain scaffold otherwise.
-
-## Step 3 — Read what was generated
-
-Always read the generated `ext.yml`, `view.js`, and `handler.rb` before editing. This
-is your starting point; you'll reshape it to match the idea.
-
-## Step 4 — Reshape to the idea
-
-Edit the files into real, working code:
-- Rename the panel id and `view.js` path to match the feature.
-- Update `ext.yml` `contributes:` — add `skills:`/`agents:` blocks if needed. A skill
-  is a `SKILL.md` under `skills/<id>/`; an agent is a `system_prompt.md` that can
-  reference `panels: [id]` and `skills: [id]`.
-- In `view.js`, reuse host CSS classes (`btn-primary`, `btn-secondary`, `form-input`,
-  `form-textarea`, `form-label`) so the panel inherits the theme automatically.
-- In `handler.rb`, define routes relative to the `/api/ext/<id>/` mount.
-
-## Step 5 — Confirm it loads
-
-Run `clacky ext verify` and confirm the new units resolve with no errors. Then tell
-the user to reload the WebUI page — panels and api changes are live on the next request,
-no restart needed.
-
-If verify reports problems, switch to debugging (the ext-debug skill covers this).

data/lib/clacky/default_skills/extend-openclacky/SKILL.md

@@ -1,106 +0,0 @@
----
-name: extend-openclacky
-description: Customize, fix, override or extend openclacky itself — change a built-in tool's behavior, intercept/audit/block tool calls, plug in a new IM channel (Slack, in-house IM…), or add UI to the Web UI (panel, button, settings tab). Trigger on "patch openclacky", "block dangerous commands", "audit tool use", "add Slack channel", "extend the web ui", "改 openclacky 内置", "拦截工具调用", "扩展 web 界面". Do NOT trigger for ordinary feature work in the user's own project that doesn't touch openclacky.
----
-
-# Extending Openclacky
-
-Openclacky ships one unified extension mechanism — an **extension container**
-declared by a single `ext.yml`. It survives `gem update` and never requires
-editing the gem source.
-
-**Never tell the user to `bundle show openclacky` and edit the gem.**
-
-## The one entry point
-
-Every extension lives in a container directory:
-
-```
-~/.clacky/ext/local/<id>/
-  ext.yml         # single manifest — declares everything the container contributes
-  panels/…        # WebUI panels (JS)
-  api/handler.rb  # HTTP API backend
-  skills/…        # AI skills
-  agents/…        # agent profiles + prompts
-  channels/…      # IM adapters
-  patches/…       # runtime method patches
-  hooks/…         # shell hooks
-```
-
-Scaffold with:
-```bash
-clacky ext new <id>            # minimal hello-panel starter
-clacky ext new <id> --full     # kitchen-sink example with every contributes type
-```
-
-The ext.yml `contributes:` map declares which of these 7 types the container
-provides. A container may use one, several, or all.
-
-## Pick what to add to `contributes:`
-
-| User wants to… | contributes: field |
-|---|---|
-| Add a **WebUI panel / button / settings tab / data visualisation** | `panels:` |
-| Add an **HTTP API backend** (routes under `/api/ext/<id>/…`) | `api:` (a single `handler.rb`) |
-| **Change behavior of a built-in method** in openclacky (e.g. `WebSearch#execute` timeout) | `patches:` |
-| **Audit / block / observe** tool calls (block `rm -rf /`, log every shell command) | `hooks:` |
-| Plug openclacky into a **new IM platform** (Slack, in-house IM, custom webhook) | `channels:` |
-| Add a **new AI skill** (SKILL.md) | `skills:` |
-| Bundle a **custom agent profile** with its own panels + skills | `agents:` |
-
-## Authoritative documentation
-
-Read the relevant reference doc with `web_fetch` before writing code —
-don't guess field names, hook events, adapter methods, or the `Clacky.ext`
-WebUI contract.
-
-- Extension containers (ext.yml overview) → https://www.openclacky.com/docs/extend
-- Panels (WebUI) → https://www.openclacky.com/docs/extend-webui
-- API backends → https://www.openclacky.com/docs/extend-api
-- Patches → https://www.openclacky.com/docs/extend-patches
-- Shell Hooks → https://www.openclacky.com/docs/extend-shell-hooks
-- Channel Adapters → https://www.openclacky.com/docs/extend-channel-adapter
-
-## WebUI host services live under `Clacky.*`
-
-The single public API surface for WebUI extensions is `window.Clacky`.
-All host services are exposed as properties on it — reach for them there,
-not through bare globals or `window.Xxx`:
-
-```js
-Clacky.Sessions.on("switched", handler);   // active session store
-Clacky.Router.go("session");                // top-level view routing
-Clacky.I18n.t("some.key");                  // translations
-Clacky.Modal.confirm("Delete?");            // dialogs
-Clacky.Notify.info("Saved");                // toasts
-Clacky.Auth.passed;                          // auth state
-Clacky.Workspace.list(dir);                 // working-directory files
-Clacky.Skills.list();                       // skill catalog
-Clacky.Backup.load();                       // backup/restore state
-Clacky.WS.send({ type: "..." });            // send a WebSocket message to the agent
-```
-
-Rules:
-
-- Prefer `Clacky.Xxx.method(...)` — this is the recommended, forward-stable form.
-- `window.Clacky.Xxx.method(...)` works too and is fine in defensive code.
-- **Never** write `window.Sessions` / `typeof window.Sessions` / `"Sessions" in window`
-  — bare host names are `const` bindings, not `window` properties, so those checks
-  return `undefined` / `false` even though the module is loaded.
-- The bare form (`Sessions.on(...)`) still works for backwards compatibility
-  but is not the pattern to teach or generate.
-
-## Execution playbook
-
-1. **Identify** which `contributes:` fields the user's intent needs (use the table above; ask if genuinely ambiguous).
-2. **Read the doc(s)** for those fields. The doc is the contract.
-3. **Scaffold** with `clacky ext new <id>` (or `--full` if the user wants every type wired up as a reference).
-4. **Edit** `ext.yml` to declare the fields, and fill in the referenced files (panel view.js, api handler.rb, patches/xxx.rb, etc.).
-5. **Verify** with `clacky ext verify`. Surface any error/skip lines to the user verbatim.
-6. **Reload** the WebUI page (for panel/api changes take effect on next request — no restart needed).
-
-## When NOT to use this skill
-
-- The user is building features in their own application that just *use* openclacky — that's normal coding, no extension container needed.
-- The user wants a brand-new tool/skill for *their* project — use `.clacky/skills/` or `.clacky/tools/` in their project, not a gem-level container.
-- The change can be made via `clacky config set ...` — prefer config over patches.