openhands-extensions 0.35.0__tar.gz → 0.36.0__tar.gz

{openhands_extensions-0.35.0 → openhands_extensions-0.36.0}/.agents/skills/custom-codereview-guide.md

@@ -117,11 +117,27 @@ window.
 
 ### Dependencies and supply chain
 
-Apply the general seven-day release-recency guard to the exact dependency version,
-regardless of the package's age or popularity. Validate installation with the
-package manager and runtime used by the extension. Temporary git pins and
-unreleased package APIs are blockers for merge unless the PR is an explicit,
-coordinated stack that will replace them before release.
+Validate installation with the package manager and runtime used by the extension.
+Temporary git pins and unreleased package APIs are blockers for merge unless the
+PR is an explicit, coordinated stack that will replace them before release.
+
+For dependency additions or updates, inspect every changed third-party npm or
+PyPI version, including transitive lockfile changes. Require at least seven days
+since publication of that exact version. Use registry publication/upload metadata
+or the relevant artifact's `uv.lock` `upload-time`; a weekly bot schedule, an old
+package name, or a passing install is not age evidence.
+
+For an under-seven-day artifact, leave a COMMENT naming the package, version,
+publication time, and source, and defer approval until it ages out or a maintainer
+explicitly approves a narrowly documented exception. If publication time is
+unavailable, ask for that evidence. Existing named first-party exemptions apply
+only to those packages, not their third-party dependencies or blanket approval
+of the lockfile. Apply this check before any dependency-bump fast path.
+
+Flag removal or weakening of seven-day uv/Dependabot guards or new broad
+exemptions. Dependabot security updates bypass cooldown, so review them under
+the explicit maintainer-exception rule in `AGENTS.md`; agents cannot approve
+their own bypass.
 
 ### Design context for deep changes
 

{openhands_extensions-0.35.0 → openhands_extensions-0.36.0}/.github/dependabot.yml

@@ -10,6 +10,8 @@ updates:
 
   - package-ecosystem: npm
     directory: /
+    cooldown:
+      default-days: 7
     schedule:
       interval: weekly
     commit-message:
@@ -18,6 +20,8 @@ updates:
 
   - package-ecosystem: pip
     directory: /
+    cooldown:
+      default-days: 7
     schedule:
       interval: weekly
     commit-message:

openhands_extensions-0.36.0/.github/workflows/kanban-app.yml

@@ -0,0 +1,34 @@
+name: Kanban App
+
+on:
+  pull_request:
+    paths:
+      - "apps/kanban-manager/**"
+      - "skills/canvas-extension-api/scripts/validate-extension.mjs"
+      - ".github/workflows/kanban-app.yml"
+  push:
+    branches: [main]
+    paths:
+      - "apps/kanban-manager/**"
+      - ".github/workflows/kanban-app.yml"
+
+permissions:
+  contents: read
+
+jobs:
+  check:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v7
+      - uses: actions/setup-node@v7
+        with:
+          node-version: "24"
+          cache: npm
+          cache-dependency-path: apps/kanban-manager/package-lock.json
+      - run: npm ci --ignore-scripts
+        working-directory: apps/kanban-manager
+      - run: npm run check
+        working-directory: apps/kanban-manager
+      - run: node skills/canvas-extension-api/scripts/validate-extension.mjs apps/kanban-manager
+      - name: Confirm the checked-in bundle is current
+        run: git diff --exit-code -- apps/kanban-manager/extension.js

openhands_extensions-0.36.0/.release-please-manifest.json

@@ -0,0 +1,3 @@
+{
+  ".": "0.36.0"
+}

{openhands_extensions-0.35.0 → openhands_extensions-0.36.0}/AGENTS.md

@@ -137,7 +137,7 @@ When editing or adding skills in this repo, follow these rules (and add new skil
 - Agent-driven plugins (for example `plugins/pr-review` and `plugins/release-notes`) use `uv run --with openhands-sdk --with openhands-tools ...` and require an `LLM_API_KEY` in addition to `GITHUB_TOKEN`.
 - For OpenHands Cloud API guidance, automations, and CLI integration, use `plugins/openhands`. It is the canonical unified OpenHands plugin covering the V1 Cloud API, Automations API, and CLI. The individual skills (`skills/openhands-api`, `skills/openhands-automation`) are also available standalone.
 - When reviewing or editing `skills/openhands-sdk`, validate copy-paste imports against the released packages with `uv run --with openhands-tools --with openhands-workspace --with openhands-agent-server python ...`. In the current released workspace package, the exported remote workspace classes are `APIRemoteWorkspace` / `OpenHandsCloudWorkspace`; `RemoteAPIWorkspace` is not available.
-- For agent-driven plugin scripts, prefer `from openhands.sdk.plugin import PluginSource` and pass `plugins=[PluginSource(source=...)]` into `Conversation`. The current released SDK (`openhands-sdk` 1.49.x) exports both `PluginSource` and `Plugin` from `openhands.sdk.plugin`, so `Plugin.load(...)` imports also work (used by `tests/test_skill_plugin_loading.py`).
+- For agent-driven plugin scripts, prefer `from openhands.sdk.plugin import PluginSource` and pass `plugins=[PluginSource(source=...)]` into `Conversation`. `tests/test_skill_plugin_loading.py` also exercises `Plugin.load(...)` from `openhands.sdk.plugin`.
 - `plugins/qa-changes/action.yml` now has a preflight guard for fork PRs in `pull_request` context: if the PR comes from a fork and `LLM_API_KEY` is unavailable (normal for forks), the action exits successfully with a clear skip notice instead of failing.
 - `skills/bitbucket` should not tell agents to rewrite remotes proactively. In OpenHands, `BITBUCKET_TOKEN` is commonly kept in unencoded `user:token` form for API calls like `curl --user "$BITBUCKET_TOKEN" ...`; only split and URL-encode it when constructing a non-interactive HTTPS Git remote URL.
 
@@ -199,13 +199,48 @@ Important notes:
 - The `code-review` and `codereview-roasted` skills have been merged into a single `code-review` skill. The `/codereview-roasted` trigger is kept as an alias for backward compatibility. The `review-style` action input is deprecated and ignored.
 - `plugins/pr-review` supports an optional `require-evidence` action input that tells the reviewer to require end-to-end proof in the PR description that the code works; test output alone is not sufficient evidence.
 - The corresponding `REQUIRE_EVIDENCE` env flag is consumed by `plugins/pr-review/scripts/agent_script.py` and injected into the review prompt via `plugins/pr-review/scripts/prompt.py`.
+- `plugins/pr-review` supports an optional `require-pinned-actions` input (default `'false'`) that tells the reviewer to require commit-SHA pins on third-party actions in workflow and `action.yml` changes. The reviewed repository's owner is exempt; the `REQUIRE_PINNED_ACTIONS` env flag follows the same path as `REQUIRE_EVIDENCE`.
 - `plugins/pr-review` exposes an `enable-uv-cache` input (default `'false'`) that toggles `setup-uv`'s GitHub Actions cache. Default stays off because a prompt-injected reviewer could poison a shared cache that higher-privilege workflows later consume; opt in only on single-tenant self-hosted runners. The README's "Caching and Security" section documents the threat model and recommends a host-level uv cache volume as the preferred alternative for self-hosted setups.
 - GitHub review suggestions that only delete lines can look empty in `PullRequestReviewComment.body`; the rendered content is available via `bodyText`/`bodyHTML`, so review-context formatting should fall back there before treating a suggestion as empty.
 - Prompt coverage for this behavior lives in `tests/test_pr_review_prompt.py`.
 - `plugins/pr-review`'s `collect-feedback` input should append a short thumbs up/down footer to the main GitHub review body via `agent_script.py` / `prompt.py`, rather than posting a separate PR comment. `evaluate_review.py` should read feedback from review-body reactions while still tolerating legacy issue-comment markers.
+- In `plugins/pr-review/scripts/prompt.py`, PR-derived text (title, head branch, description, review context, files manifest, and patches) goes through the private `_fence_untrusted()` helper, with one nonce per `format_prompt()` call. Keep new PR-derived prompt fields inside these regions; containment tests live in `tests/test_pr_review_prompt_injection.py`.
 
 
 ## When uncertain
 
 - Prefer the official OpenHands docs on skills: https://docs.openhands.dev/overview/skills
 - Prefer the SDK skill guide: https://docs.openhands.dev/sdk/guides/skill
+
+## Dependency release-age policy
+
+- Wait at least seven days after publication before adding or updating a
+  third-party npm or PyPI version, including transitive lockfile changes.
+  A weekly update schedule alone does not enforce this minimum age.
+- Keep Dependabot `cooldown.default-days: 7` for npm and Python version
+  updates, and preserve `tool.uv.exclude-newer = "7 days"` where configured.
+  Existing named first-party exceptions do not exempt their third-party
+  dependencies. Do not add broad exemptions or disable the cutoff to make a
+  resolver succeed.
+- Verify the exact version's publication/upload time from npm or PyPI metadata
+  (or artifact `upload-time` in `uv.lock`), not the package's creation date.
+  If age cannot be established, report the missing evidence rather than guess.
+- Security updates can bypass Dependabot cooldown. An urgent exception needs
+  explicit maintainer approval recorded in the PR with the package, version,
+  advisory/reason, and publication time. Agents must not grant themselves an
+  exception. Keep overrides narrow and remove temporary exceptions afterward.
+- Use the committed lock for reproducible installs; review newly resolved
+  artifacts before committing a lock update.
+
+For manual npm dependency resolution, use npm >= 11.10 with
+`npm install --min-release-age=7` (days), or verify registry timestamps before
+committing the result. Older npm versions do not enforce this option. `npm ci`
+replays the lock and is not proof that newly locked versions meet the age rule.
+
+Use uv >= 0.9.25 for this policy. Older versions cannot parse the boolean
+first-party exemptions and can discard the entire `[tool.uv]` table, including
+`required-version`. Check `uv --version` before running `uv sync`, `uv lock`,
+or `uv run`; this repository does not commit a lockfile to reject old parsers.
+The named exemptions cover the released SDK, tools, workspace, and agent-server
+packages used by the documented import checks; their third-party dependencies
+still have the seven-day cutoff.

{openhands_extensions-0.35.0 → openhands_extensions-0.36.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: openhands-extensions
-Version: 0.35.0
+Version: 0.36.0
 Summary: OpenHands extensions, plugins, and skills (Python bindings for the integration catalog)
 License-File: LICENSE
 Requires-Python: >=3.12

{openhands_extensions-0.35.0 → openhands_extensions-0.36.0}/README.md

@@ -100,7 +100,7 @@ The JS and Python versions are kept in lock-step by `release-please` and guarded
 ## Extensions Catalog
 
 <!-- BEGIN AUTO-GENERATED CATALOG -->
-This repository contains **2 marketplace(s)** with **78 extensions** (67 skills, 11 plugins).
+This repository contains **2 marketplace(s)** with **79 extensions** (68 skills, 11 plugins).
 
 ### large-codebase
 
@@ -119,7 +119,7 @@ OpenHands skills for interacting, improving, and refactoring large codebases
 
 Official skills and plugins for OpenHands — the open-source AI software engineer.
 
-**74 extensions** (65 skills, 9 plugins)
+**75 extensions** (66 skills, 9 plugins)
 
 | Name | Type | Description | Commands |
 |------|------|-------------|----------|
@@ -182,6 +182,7 @@ Official skills and plugins for OpenHands — the open-source AI software engine
 | research-brief | skill | Create a recurring automation that researches a topic using Tavily web search and publishes a structured brief to Not... | `/research-brief:setup` |
 | runtime-api-configs | plugin | Manage warm sandbox pools on OpenHands Enterprise from a Python CLI: list, template, save, and delete warm runtime co... | — |
 | security | skill | Security best practices for secure coding, authentication, authorization, and data protection. Use when developing fe... | — |
+| show-me | skill | Help the user understand the current topic visually with concise diagrams, code-shape sketches, and focused HTML arti... | — |
 | simplified-technical-english | skill | Write explanations and chat in the style of ASD-STE100 Simplified Technical English: short active sentences, one idea... | — |
 | skill-creator | skill | Guide for creating effective skills. This skill should be used when users want to create a new skill (or update an ex... | — |
 | slack-channel-monitor | skill | Create a cron automation that polls up to 10 Slack channels every minute and starts an OpenHands conversation when a ... | `/slack-monitor:poll` |

openhands_extensions-0.36.0/apps/catalog.json

@@ -0,0 +1,18 @@
+[
+  {
+    "id": "kanban-manager",
+    "name": "Kanban Manager",
+    "description": "A beta board for agent work: queue requests, track progress, and review completed tickets.",
+    "source": "./apps/kanban-manager",
+    "manifest": "./apps/kanban-manager/canvas-extension.json",
+    "beta": true
+  },
+  {
+    "id": "vscode",
+    "name": "VS Code",
+    "description": "A managed full-height OpenVSCode editor for the selected Agent Canvas workspace.",
+    "source": "./apps/vscode",
+    "manifest": "./apps/vscode/canvas-extension.json",
+    "beta": true
+  }
+]

openhands_extensions-0.36.0/apps/kanban-manager/.gitignore

@@ -0,0 +1,2 @@
+node_modules/
+*.tgz

openhands_extensions-0.36.0/apps/kanban-manager/.npmignore

@@ -0,0 +1,4 @@
+node_modules/
+test/
+package-lock.json
+*.log

openhands_extensions-0.36.0/apps/kanban-manager/LICENSE

@@ -0,0 +1,21 @@
+The MIT License (MIT)
+
+Copyright © 2025 OpenHands contributors
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the “Software”), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

openhands_extensions-0.36.0/apps/kanban-manager/README.md

@@ -0,0 +1,184 @@
+# Kanban Manager
+
+**Beta.** Install explicitly and enable only after reviewing the source.
+
+Kanban Manager is a board for agent work. You queue requests as cards, a
+manager agent picks them up and dispatches workers, and the board shows what
+each agent is doing right now and what has landed.
+
+It is a Canvas Extension with no server of its own. Everything it needs — the
+board, its settings, ticket attachments — is JSON on the Agent Server's own
+filesystem, written through the file API.
+
+(Previously published here as `vibe-board`.)
+
+
+## Install in Agent Canvas
+
+In **Customize -> Apps -> Add app**, use:
+
+- Source: `https://github.com/OpenHands/extensions`
+- Path within repository: `apps/kanban-manager`
+- Revision: choose the reviewed release tag or commit containing this app.
+
+Installation leaves the app disabled. Review the source and revision, then
+choose **Enable trusted app**. Open **Kanban Manager** from the navigation.
+The app uses the active Agent Server's file API. Cloud backends do not currently
+support Canvas Apps.
+
+### Existing installations
+
+The app name remains `kanban-manager` (version `0.2.0`), and its board data
+remains at `~/.openhands/vibe-manager/` on the same Agent Server. Browser keys
+such as `vibe.workspace` and `vibe.theme` also stay unchanged. Moving this
+package does not move, rewrite, or delete that data or any manager automation.
+
+When switching an existing installation, stop active UI edits, disable the old
+app, and remove its installed package through Canvas. Do not delete its board
+data. Install the new coordinates above on the **same backend**, then enable
+and check that the existing workspaces and tickets appear. Do not run two
+copies under different app names against the same data. A workspace that moved
+to a different Agent Server needs a separate, deliberate data migration.
+
+### Compatibility and optional manager
+
+The board works as a manual Kanban without starting an automation. Enabling the
+app does not start a manager or create a conversation. **Start manager** is an
+explicit, separate action and can dispatch agents that use paid models.
+
+The imported manager, chat, and attachment features rely on the existing
+Canvas backend registry and a deployment that exposes the Automation service
+at `/api/automation/v1` using the selected backend's credentials. This is not
+a portable host-API guarantee: a remote backend without that route can use the
+manual board, but manager actions may be unavailable. The migration does not
+add routes, change credentials, or grant access to another backend.
+
+## Credits and migration source
+
+Originally authored by Robert Brennan, with contributions from OpenHands.
+This migration preserves their app and automation code.
+
+Moved from [OpenHands/canvas-apps](https://github.com/OpenHands/canvas-apps/tree/b83068fdce5ec7f85c07b8aefa15d413982059d0/kanban-manager)
+at `b83068fdce5ec7f85c07b8aefa15d413982059d0`, retaining the MIT [LICENSE](LICENSE).
+The app vendors its original board styles and automation from
+[rbren/vibe-manager](https://github.com/rbren/vibe-manager).
+
+The separate [canvas-apps PR #21](https://github.com/OpenHands/canvas-apps/pull/21)
+proposes a React/FastAPI/SQLite rewrite. It was still open when this migration
+was prepared and is **not** included. Its code and any live database must not
+be treated as migrated; a future port requires its own review and data plan.
+
+## Lanes
+
+Cards move left to right: **Pending** → **In progress** → **Needs input** →
+**Finished**, plus a **Verified** lane you can toggle for the archive. Drag a
+card to reprioritise within a lane. Click one to open a drawer with the full
+append-only history; adding a note to a finished ticket reopens it.
+
+In-progress cards show the worker's most recent action as it happens, so you
+can see an agent working without opening its conversation.
+
+## The manager
+
+The control in the top right owns the manager automation for the selected
+workspace, so a board can be made autonomous without leaving Canvas:
+
+- **Start manager** (orange) — there is no manager yet, or it was stopped.
+  Clicking it packs the automation's python sources (compiled into the bundle,
+  `src/automation/`) plus a per-workspace `config.json` into a `tar.gz`,
+  uploads it to `POST /api/automation/v1/uploads`, and creates a cron
+  automation that runs `python3 main.py` once a minute. The automation id is
+  recorded on the workspace.
+- **manager ✓ / working / ✗** — a manager is running. The badge reports the
+  last run and the manager conversation; clicking it triggers a run now.
+- **Stop manager** — `PATCH {"enabled": false}`. The automation and its run
+  history are kept, so starting again is a re-enable with a fresh tarball.
+
+Two implementation notes, since neither is obvious:
+
+- The tar archive is built in the browser and gzipped with
+  `CompressionStream`. Sizes in the ustar header must be **byte** counts, not
+  string lengths, or a file with any multi-byte character truncates and every
+  following header lands mid-stream.
+- The upload is a plain `fetch` rather than `host.agentServer.request`,
+  because the host client JSON-stringifies any body that is not `FormData`,
+  which would corrupt the gzip bytes. Every other call goes through the host.
+
+Without a manager the board is still a perfectly good manual kanban: you can
+create, edit, reorder and verify tickets, and open the conversation behind any
+card.
+
+## How it stores state
+
+There is no database and no backend process. The store is a directory tree
+under the Agent Server's home:
+
+```
+~/.openhands/vibe-manager/
+  index.json                                  workspaces + settings
+  workspaces/<id>/tickets/<tid>/ticket.json   one file per ticket
+  attachments/<id>/<filename>                 uploaded files
+```
+
+The directory keeps its old name so boards created by earlier installs — and
+by the manager automation, which writes the same files from the shell — are
+still found.
+
+Reads are `GET /api/file/download`, writes are `POST /api/file/upload`, both
+through the host's `agentServer.request` so they are same-origin and
+authenticated by Canvas. The home directory is resolved at runtime from
+`GET /api/file/home` rather than assumed, so this works whatever user the
+Agent Server runs as.
+
+Two consequences worth knowing:
+
+- **One file per ticket is what keeps writers apart.** There is no conditional
+  upload to build a compare-and-swap on, so the extension, the manager
+  automation and the manager's CLI would lose each other's edits if they all
+  rewrote one board document. Touching separate files, they cannot. The two
+  documents still shared — `index.json`, and a ticket two writers both target —
+  carry a `rev`/`writer` pair that detects a lost write and re-applies it.
+- **Reads bypass the HTTP cache.** The file API sends `ETag`/`Last-Modified`
+  but no `Cache-Control`, so a browser may reuse a stale response for its
+  heuristic freshness window. On the directory listing that assembles the
+  board, that means a ticket created moments earlier never appears at all.
+  Both the listing and `readJson` defeat it per request; attachment blobs are
+  immutable and stay cacheable.
+
+## Build
+
+The checked-in `extension.js` is the built bundle; the sources are in `src/`.
+
+```bash
+npm ci
+npm run check     # build + test
+```
+
+`build.mjs` bundles the ES modules with esbuild and inlines two things that
+must travel with a single-file extension:
+
+- `src/board.css`, scoping every selector under `.vibe-ext` and rewriting
+  `rem` lengths onto a local `--vibe-rem`, so the board can size itself
+  without restyling Canvas;
+- `src/automation/*.py`, the manager automation, because "Start manager"
+  uploads it from the browser and the machine running Canvas has no checkout
+  of it to read.
+
+Both are vendored from [rbren/vibe-manager](https://github.com/rbren/vibe-manager),
+which is where they are maintained. The bundle's destination comes from the
+manifest's `entrypoint`, so the declared and built paths cannot drift.
+
+## Tests
+
+`test/extension.test.js` mounts the built bundle against a linkedom DOM and a
+fake host, and covers rendering, lane sorting, the submit path, the manager
+start/stop control and disposal. It runs on the bundle rather than the
+sources, so a broken build fails the suite.
+
+`test/manager.test.mjs` checks the browser-built tarball with real GNU tar. It
+also has two tests that talk to a running automation backend; they skip unless
+a session key is available (`OH_SESSION_API_KEYS_0`, plus `VIBE_TEST_INGRESS`
+if it is not on `http://127.0.0.1:8000`).
+
+The upstream repository additionally has tests that drive the real Agent Server
+file API; those need a running server and are not included here.

openhands_extensions-0.36.0/apps/kanban-manager/build.mjs

@@ -0,0 +1,122 @@
+/* Build the Kanban Manager canvas extension into one self-contained browser
+   ESM file: the bundle carries the board, the stylesheet and the manager
+   automation's python sources, because an extension is a single file.
+
+   The stylesheet is vendored in src/board.css. Two transforms adapt it to
+   living inside Canvas:
+
+   1. Every selector is scoped under .vibe-ext, and the page-level selectors
+      (:root, html, body, *) are rewritten onto that root, so the extension
+      cannot restyle Canvas.
+   2. rem lengths become calc(N * var(--vibe-rem)). The SPA sets
+      html { font-size: 120% } to scale itself, which an extension must not do
+      to the host page; --vibe-rem reproduces that scale locally instead.
+*/
+
+import { mkdirSync, readFileSync, writeFileSync } from "node:fs";
+import { dirname, join } from "node:path";
+import { fileURLToPath } from "node:url";
+import esbuild from "esbuild";
+import postcss from "postcss";
+import prefixer from "postcss-prefix-selector";
+
+const here = dirname(fileURLToPath(import.meta.url));
+const ROOT_CLASS = ".vibe-ext";
+
+// Build only from this package: unrelated files in the parent repository must
+// not replace the vendored stylesheet or the manager automation.
+const SOURCE_CSS = join(here, "src", "board.css");
+const AUTOMATION_DIR = join(here, "src", "automation");
+const AUTOMATION_MODULES = ["main.py", "vibestore.py", "vibectl.py"];
+
+/* The manifest decides where the bundle goes, so the declared entrypoint and
+   the built file cannot drift apart (this package publishes it under dist/,
+   the canvas-extensions repo at the package root). */
+const MANIFEST = JSON.parse(readFileSync(join(here, "canvas-extension.json"), "utf8"));
+const OUTFILE = join(here, MANIFEST.entrypoint);
+
+// Selectors that target the page itself. Inside the extension they all mean
+// "our root element" instead.
+const PAGE_LEVEL = new Set([
+  ":root",
+  "html",
+  "body",
+  "html, body",
+  "html,body",
+]);
+
+function scopeSelector(selector) {
+  const trimmed = selector.trim();
+  if (PAGE_LEVEL.has(trimmed)) return ROOT_CLASS;
+
+  // html[data-theme="light"] -> .vibe-ext[data-theme="light"]  (the SPA's light
+  // mode is a token override; we keep it on our own root so the toggle never
+  // touches Canvas's <html>).
+  if (trimmed.startsWith("html[")) {
+    return ROOT_CLASS + trimmed.slice("html".length);
+  }
+  // html[data-theme="light"] .foo -> .vibe-ext[data-theme="light"] .foo
+  if (trimmed.startsWith("html[data-theme")) {
+    return ROOT_CLASS + trimmed.slice("html".length);
+  }
+  if (trimmed === "*") return `${ROOT_CLASS}, ${ROOT_CLASS} *`;
+  return null; // fall through to the default prefixer behaviour
+}
+
+function remToScaled(css) {
+  // 0.9375rem -> calc(0.9375 * var(--vibe-rem)). Skip 0rem and anything already
+  // inside a var() fallback chain we generated.
+  return css.replace(/(-?\d*\.?\d+)rem\b/g, (match, value) => {
+    const n = Number(value);
+    if (!Number.isFinite(n) || n === 0) return match;
+    return `calc(${value} * var(--vibe-rem))`;
+  });
+}
+
+async function buildCss() {
+  const raw = readFileSync(SOURCE_CSS, "utf8");
+  const result = await postcss([
+    prefixer({
+      prefix: ROOT_CLASS,
+      transform(prefix, selector, prefixedSelector) {
+        return scopeSelector(selector) ?? prefixedSelector;
+      },
+    }),
+  ]).process(raw, { from: SOURCE_CSS });
+
+  // --vibe-rem reproduces the SPA's html { font-size: 120% } locally. Change
+  // this one value to rescale the whole board inside Canvas.
+  const scale = `${ROOT_CLASS} { --vibe-rem: 1.2rem; }\n`;
+  // setup.css is extension-only and already written scoped, so it bypasses the
+  // prefixer but still gets the rem rescale.
+  const setup = readFileSync(join(here, "src", "setup.css"), "utf8");
+  return scale + remToScaled(result.css) + remToScaled(setup);
+}
+
+function readAutomation() {
+  return Object.fromEntries(
+    AUTOMATION_MODULES.map((name) => [name, readFileSync(join(AUTOMATION_DIR, name), "utf8")]),
+  );
+}
+
+const css = await buildCss();
+const automation = readAutomation();
+mkdirSync(dirname(OUTFILE), { recursive: true });
+
+await esbuild.build({
+  entryPoints: [join(here, "src", "extension.js")],
+  outfile: OUTFILE,
+  bundle: true,
+  format: "esm",
+  platform: "browser",
+  target: "es2022",
+  legalComments: "none",
+  define: {
+    __VIBE_CSS__: JSON.stringify(css),
+    __VIBE_AUTOMATION__: JSON.stringify(automation),
+  },
+});
+
+const out = readFileSync(OUTFILE, "utf8").replace(/[ \t]+$/gm, "");
+writeFileSync(OUTFILE, `/* Generated by build.mjs - do not edit. */\n${out}`);
+console.log(`built ${MANIFEST.entrypoint} (${(out.length / 1024).toFixed(1)} KB)`);

openhands_extensions-0.36.0/apps/kanban-manager/canvas-extension.json

@@ -0,0 +1,19 @@
+{
+  "schema_version": 1,
+  "name": "kanban-manager",
+  "display_name": "Kanban Manager",
+  "version": "0.2.0",
+  "description": "Agent dispatch board: queue work, watch agents pick it up, review what lands.",
+  "entrypoint": "extension.js",
+  "contributes": {
+    "pages": [
+      {
+        "id": "board",
+        "title": "Kanban Manager",
+        "path": "/board",
+        "nav_label": "Kanban Manager",
+        "description": "Kanban board of agent work across your workspaces."
+      }
+    ]
+  }
+}