@akiojin/gwt 9.15.0 → 9.16.0

package/.husky/pre-push

@@ -11,10 +11,46 @@ unset GIT_DIR GIT_INDEX_FILE GIT_WORK_TREE GIT_PREFIX \
     GIT_OBJECT_DIRECTORY GIT_ALTERNATE_OBJECT_DIRECTORIES \
     GIT_NAMESPACE GIT_COMMON_DIR
 
+ensure_coverage_tooling() {
+  if ! command -v cargo >/dev/null 2>&1; then
+    echo "cargo is required for pre-push checks but was not found on PATH." >&2
+    exit 1
+  fi
+
+  if cargo llvm-cov --version >/dev/null 2>&1; then
+    return
+  fi
+
+  echo "cargo-llvm-cov is not installed. Installing it before coverage check..."
+  if ! cargo install cargo-llvm-cov --locked; then
+    echo "Failed to install cargo-llvm-cov." >&2
+    echo "Run manually: cargo install cargo-llvm-cov --locked" >&2
+    exit 1
+  fi
+
+  if command -v rustup >/dev/null 2>&1; then
+    echo "Ensuring llvm-tools-preview is available..."
+    if ! rustup component add llvm-tools-preview; then
+      echo "Warning: failed to install llvm-tools-preview." >&2
+      echo "Continuing; cargo llvm-cov will validate llvm tool availability." >&2
+      echo "Manual recovery: rustup component add llvm-tools-preview" >&2
+    fi
+  else
+    echo "rustup not found; assuming llvm tools are provided by the active toolchain."
+  fi
+
+  if ! cargo llvm-cov --version >/dev/null 2>&1; then
+    echo "cargo-llvm-cov was installed, but cargo llvm-cov is still unavailable." >&2
+    echo "Ensure Cargo's bin directory is on PATH, then retry push." >&2
+    exit 1
+  fi
+}
+
 echo "Running CI-equivalent lint checks..."
 
 cargo clippy --all-targets --all-features -- -D warnings
 cargo fmt --all -- --check
+ensure_coverage_tooling
 cargo llvm-cov -p gwt-core -p gwt --all-features --json --summary-only --output-path target/coverage-summary.json -- --test-threads=1
 node scripts/check-coverage-threshold.mjs target/coverage-summary.json 90
 bunx --bun markdownlint-cli . --config .markdownlint.json --ignore target --ignore CHANGELOG.md --ignore tasks/todo.md

package/README.ja.md

@@ -1,7 +1,33 @@
 # gwt
 
-gwt は Git worktree の管理と、`Claude Code` / `Codex` / `Gemini` /
-`OpenCode` などのコーディングエージェント起動を行うデスクトップ GUI です。
+gwt は agent-driven development のためのデスクトップ control plane です。
+コーディングエージェント、プロジェクト文脈、共有 coordination、GitHub
+Issue ベースの SPEC、セマンティック検索、managed workflow automation を、
+ネイティブ GUI とブラウザから開ける 1 つの workspace に集約します。
+
+Git worktree は gwt の背後にある隔離基盤です。gwt は安全な task ごとの
+Agent workspace を materialize するために worktree を使いますが、利用者の
+主導線は branch 管理ではなく、作業、Issue、SPEC、検索、Board 文脈から始まります。
+
+## gwt の特徴
+
+- **Agent workspace** — `Claude Code` / `Codex` / `Gemini` / `OpenCode` /
+  `Copilot` / custom agent を共有 canvas から起動・再開・状態確認できます。
+- **Shared Board** — user と agent の communication を repo-scoped timeline に集約し、
+  `status` / `claim` / `next` / `blocked` / `handoff` / `decision` /
+  `question` を扱えます。
+- **Agent 間 coordination** — managed hooks が reasoning milestone の投稿を促し、
+  直近の Board 文脈を注入するため、並列 Agent が判断・引き継ぎ・ブロッカー・
+  自分宛 request を把握できます。
+- **Semantic Knowledge Bridge** — Issue、SPEC、project source、docs を
+  substring だけでなく ChromaDB / multilingual-e5 の semantic index で検索できます。
+- **GitHub Issue-backed SPEC** — `gwt-spec` Issue を正本にしつつ、
+  ローカル cache-backed CLI で section 単位に読み書きできます。
+- **Managed workflow skills** — discussion、Issue routing、planning、
+  TDD implementation、PR、architecture review、project search、agent 管理用の
+  bundled `gwt-*` skills を使えます。
+- **Operator canvas** — Agent、Board、Issue、SPEC、Logs、Memo、Profile、
+  File Tree、Branches、PR surface を mission-control 風 workspace に並べられます。
 
 ## インストール
 
@@ -99,44 +125,81 @@ hook は同期的な `gwt hook ...` dispatch にフォールバックし、複
 が完了するまで利用できません。`gwtd daemon status` 自体は Windows
 でも実行可能ですが、daemon が動かないため常に `stopped` を表示します。
 
-## 基本フロー
-
-1. リポジトリを開く、または前回のプロジェクトを復元する
-2. キャンバス上に必要なウィンドウを並べる
-3. `Branches` でブランチを選択し、ダブルクリックで Launch Agent を開く
-4. `Shell` または `Agent` ウィンドウを起動する
-5. `File Tree` でリポジトリを閲覧する
-
-利用できるウィンドウ:
-
-- `Shell`
-- `Agent`
-- `Branches`
-- `File Tree`
-- `Settings`
-- `Memo`
-- `Profile`
-- `Logs`
-- `Issue`
-- `SPEC`
-- `Board`
-- `PR`
-
-`Shell` と `Agent` は実プロセスを持つウィンドウです。`File Tree` は実装済みの
-read-only ツリーです。それ以外は現時点では mock surface です。
+## Agent Workflow
+
+1. プロジェクトを開く、または前回のプロジェクトを復元する
+2. `Board`、`Issue`、`SPEC`、Knowledge search surface で現在の作業、
+   関連 owner、過去の判断を把握する
+3. まだ branch ではなく作業単位として曖昧な場合は、Project Bar または
+   Command Palette の `Start Work` を選ぶ
+4. `Start Work` から `Agent` を起動する。既知の owner がある場合は
+   Issue / SPEC detail から直接 Launch Agent する
+5. 起動確定時にのみ、gwt が背後の `work/YYYYMMDD-HHMM[-n]`
+   branch / worktree を materialize する
+6. Agent 実行中は shared Board に status、claim、next、blocked、
+   handoff、decision を残して coordination する
+7. Git の確認・filter・cleanup・低レベルな branch/worktree detail が必要な場合だけ
+   `Branches` を開く
+
+主なウィンドウ:
+
+- `Agent` — Start Work / Launch Agent から作成される実 coding-agent process window
+- `Board` — reasoning と coordination のための user / agent shared timeline
+- `Issue` / `SPEC` — semantic search、detail pane、Launch Agent handoff を備えた
+  cache-backed Knowledge Bridge
+- `Logs` — project diagnostics と live log surface
+- `Memo` / `Profile` — repo-scoped note と environment/profile 管理
+- `File Tree` — 実リポジトリの read-only tree
+- `Branches` — branch 確認、filter、cleanup、Git detail
+- `Settings` — application と agent の設定
+- `PR` — pull-request workflow surface。詳細な一覧機能は cache-backed PR source の整備に依存します
+
+`Agent` は coding agent セッション用の実プロセスウィンドウです。`Board` は
+Agent が status、decision、handoff、request を外部化する coordination surface です。
+`Issue` と `SPEC` は frontend から GitHub API response を直接描画せず、
+ローカル cache と semantic index を使います。
 
 Windows の Host 起動では、Launch Agent で Command Prompt、Windows PowerShell、
-PowerShell 7 を選択できます。選択したシェルは `Shell` と `Agent` の両方に適用され、
-Docker 起動では引き続きコンテナ内のシェルを使います。
+PowerShell 7 を選択できます。Docker 起動では引き続きコンテナ内のシェルを使います。
 
 ターミナルウィンドウでは、テキストをドラッグ選択してマウスボタンを離すとコピー
 できます。Windows / Linux では `Ctrl+Shift+C` でも現在の選択をコピーできます。
 `Ctrl+C` は実行中のターミナルプロセス向けの割り込みのままです。
 
-## ワークスペース構成
+## Knowledge、Search、Managed Skills
+
+gwt は project knowledge を Agent workspace の近くに置きます。
+
+- `gwtd issue spec <n>` は GitHub Issue-backed SPEC をローカル cache から読みます。
+- `gwtd issue view <n>` と `gwtd issue comments <n>` は gwt CLI surface から
+  cache-backed Issue access を提供します。
+- `gwt-search` は共有 ChromaDB runtime を通じて SPEC、Issue、source files、
+  docs を検索します。index が無い場合は必要に応じて build され、desktop app は
+  管理対象 Python search runtime を修復できます。
+- Issue / SPEC の Knowledge Bridge window は cache-backed list/detail と、
+  semantic ranking、exact match priority、match percentage を組み合わせます。
+
+Bundled workflow skills は active worktree の `.claude/skills`、
+`.claude/commands`、`.codex/skills` に materialize されます。公開 entrypoint は
+以下です。
+
+- `gwt-discussion` — investigation-first な議論と設計明確化
+- `gwt-register-issue` / `gwt-fix-issue` — Issue intake と Issue 起点の修正
+- `gwt-plan-spec` — 承認済み SPEC の implementation planning
+- `gwt-build-spec` — 承認済み task からの TDD-oriented implementation
+- `gwt-manage-pr` — PR create/check/fix lifecycle
+- `gwt-arch-review` — architecture review と改善 routing
+- `gwt-search` — unified semantic search
+- `gwt-agent` — running agent pane の確認と操作
+
+Managed hooks は user hook を保持しながら、Agent state、workflow guardrails、
+Board reminders、discussion/plan/build Stop checks、coordination-event summaries
+を追加します。
+
+## ワークスペース基盤
 
-gwt は各プロジェクトをワークスペースディレクトリ配下の **Nested Bare + Worktree**
-構成として管理します。
+Agent session の隔離と再現性のため、gwt は各プロジェクトをワークスペース
+ディレクトリ配下の **Nested Bare + Worktree** 構成として管理できます。
 
 ```
 <workspace>/<project>/
@@ -177,12 +240,50 @@ bare リポジトリを作り直し、各 worktree を新レイアウトに再
 - `Cmd/Ctrl+Shift+Right` と `Cmd/Ctrl+Shift+Left` でフォーカス切替
   - フォーカスされたウィンドウは中央へ寄ります
 
-## Managed Hook と SPEC キャッシュ
+## Operator デザイン言語 (SPEC-2356)
 
-- gwt は `.claude/settings.local.json` を再生成し、`.codex/hooks.json` をマージします
-- SPEC は `gwt-spec` ラベル付き GitHub Issue として管理されます
+Operator Design System 採用後、gwt は editorial-industrial 系タイポグラフィ
+(本文 `Mona Sans` / ディスプレイ `Hubot Sans Condensed` / 等幅 `JetBrains Mono`)
+を中核とした単一の mission-control サーフェスとして再設計されました。
+Project Bar / Sidebar Layers / Status Strip / Command Palette / Hotkey
+Overlay / Drawer モーダル / フローティングウィンドウ の全クロームが
+共通トークンを参照し、 2 つの旗艦テーマで提供されます:
+
+- **Dark Operator** (Mission Control / carbon + neon) — 既定、 長時間作業向け
+- **Light Operator** (Drafting Table / bone + ink) — 明るい環境向け
+
+OS の `prefers-color-scheme` に追従しつつ、 Project Bar の **Theme** トグルで
+`auto → dark → light → auto` を循環できます。 選択はブラウザストレージに
+永続化され、 再起動後も維持されます。 xterm 端末パネルは overall theme に
+追従します。 `prefers-reduced-motion: reduce` を有効にすると Living Telemetry
+の pulse rim・Status Strip の ticking・Mission Briefing intro が静止表現に
+縮退します。 `forced-colors: active` (Windows High Contrast / macOS Increase
+Contrast) では system colors にフォールバックします。
+
+### ホットキー
+
+| 組合せ | 動作 |
+| --- | --- |
+| `⌘K` / `⌘P` | Command Palette を開く (全サーフェス アクションの fuzzy 検索) |
+| `⌘B` | Board サーフェスを focus |
+| `⌘G` | Git (Branches) サーフェスを focus |
+| `⌘L` | Logs サーフェスを focus |
+| `⌘?` | Hotkey Overlay (cheat sheet) を toggle |
+| `Esc` | 開いている Palette / Overlay / Drawer を閉じる |
+
+## SPEC と runtime クイックリファレンス
+
+- SPEC の正本: `gwt-spec` ラベル付き GitHub Issue
 - ローカルキャッシュ:
   `~/.gwt/cache/issues/<repo-hash>/`
+- Managed agent integration files:
+  `.claude/settings.local.json` と `.codex/hooks.json`
+- SPEC 一覧を読む:
+
+```bash
+gwtd issue spec list
+```
+
 - SPEC 全体を読む:
 
 ```bash

package/README.md

@@ -2,8 +2,35 @@
 
 [日本語](README.ja.md)
 
-gwt is a desktop GUI for managing Git worktrees and launching coding agents
-such as `Claude Code`, `Codex`, `Gemini`, and `OpenCode`.
+gwt is a desktop control plane for agent-driven development. It brings coding
+agents, project context, shared coordination, GitHub Issue-backed specs,
+semantic search, and managed workflow automation into one native GUI and
+browser-accessible workspace.
+
+Git worktrees are the isolation substrate behind gwt. They let gwt materialize
+safe per-task workspaces for agents, but the product flow starts from work,
+Issues, SPECs, search, and Board context rather than from branch management.
+
+## Why gwt
+
+- **Agent workspace** — launch, resume, and monitor `Claude Code`, `Codex`,
+  `Gemini`, `OpenCode`, `Copilot`, and custom agents from a shared canvas.
+- **Shared Board** — keep user and agent communication in one repo-scoped
+  timeline with `status`, `claim`, `next`, `blocked`, `handoff`, `decision`,
+  and `question` posts.
+- **Agent-to-agent coordination** — managed hooks remind agents to post
+  reasoning milestones and inject recent Board context so parallel agents can
+  see decisions, handoffs, blockers, and targeted requests.
+- **Semantic Knowledge Bridge** — search Issues, SPECs, project source files,
+  and docs through a ChromaDB / multilingual-e5 index instead of relying only
+  on substring matches.
+- **GitHub Issue-backed SPECs** — treat `gwt-spec` Issues as the source of
+  truth while reading and editing sections through the local cache-backed CLI.
+- **Managed workflow skills** — use bundled `gwt-*` skills for discussion,
+  issue routing, planning, TDD implementation, PR work, architecture review,
+  project search, and agent-pane management.
+- **Operator canvas** — arrange Agent, Board, Issue, SPEC, Logs, Memo, Profile,
+  File Tree, Branches, and PR surfaces in one mission-control style workspace.
 
 ## Install
 
@@ -99,45 +126,84 @@ therefore unavailable on Windows pending follow-up work; `gwtd
 daemon status` still works there but always reports `stopped` until
 the named-pipe path lands.
 
-## Main Workflow
-
-1. Open a repository directory or restore the previous project.
-2. Use the canvas to arrange floating windows.
-3. Open `Branches`, select a branch, and double-click to open Launch Agent.
-4. Start `Shell` or `Agent` windows on the selected branch/worktree.
-5. Inspect the repository with the read-only `File Tree` window.
-
-Available windows include:
-
-- `Shell`
-- `Agent`
-- `Branches`
-- `File Tree`
-- `Settings`
-- `Memo`
-- `Profile`
-- `Logs`
-- `Issue`
-- `SPEC`
-- `Board`
-- `PR`
-
-`Shell` and `Agent` are live process windows. `File Tree` is a live read-only
-tree view. The remaining windows are currently mock surfaces where production
-behavior has not been wired yet.
+## Agent Workflow
+
+1. Open a project directory or restore the previous project.
+2. Use `Board`, `Issue`, `SPEC`, and Knowledge search surfaces to understand
+   the current work, related owners, and prior decisions.
+3. Choose `Start Work` from the Project Bar or Command Palette when the task is
+   still work-shaped rather than branch-shaped.
+4. Launch an `Agent` from Start Work, or launch directly from an Issue/SPEC
+   detail when the owner is already known.
+5. Let gwt materialize the backing `work/YYYYMMDD-HHMM[-n]` branch/worktree
+   only when launch is confirmed.
+6. Use the shared Board for status, claims, next steps, blockers, handoffs,
+   and decisions while agents run.
+7. Open `Branches` only when you need Git inspection, filtering, cleanup, or
+   lower-level branch/worktree details.
+
+Common windows include:
+
+- `Agent` — live coding-agent process windows created through Start Work or
+  Launch Agent
+- `Board` — shared user/agent timeline for reasoning and coordination
+- `Issue` and `SPEC` — cache-backed Knowledge Bridge windows with semantic
+  search, detail panes, and Launch Agent handoff
+- `Logs` — project diagnostics and live log surface
+- `Memo` and `Profile` — repo-scoped notes and environment/profile management
+- `File Tree` — live read-only repository tree
+- `Branches` — branch inspection, filtering, cleanup, and Git details
+- `Settings` — application and agent configuration
+- `PR` — pull-request workflow surface; detailed list support depends on the
+  cache-backed PR source as it lands
+
+`Agent` is the live process window for coding-agent sessions. `Board` is the
+coordination surface agents use to expose status, decisions, handoffs, and
+requests. `Issue` and `SPEC` use the local cache and semantic index rather than
+rendering direct GitHub API responses in the frontend.
 
 On Windows Host launches, Launch Agent lets you choose Command Prompt, Windows
-PowerShell, or PowerShell 7. The selected shell applies to both `Shell` and
-`Agent` windows; Docker launches continue to use the container shell.
+PowerShell, or PowerShell 7. Docker launches continue to use the container
+shell.
 
 In terminal windows, drag to select text and release the mouse button to copy.
 On Windows and Linux, `Ctrl+Shift+C` also copies the current terminal
 selection. `Ctrl+C` stays mapped to the running terminal process.
 
-## Workspace Layout
+## Knowledge, Search, and Managed Skills
 
-gwt manages each project as a **Nested Bare + Worktree** layout under your
-workspace directory:
+gwt keeps project knowledge close to the agent workspace:
+
+- `gwtd issue spec <n>` reads GitHub Issue-backed SPECs from the local cache.
+- `gwtd issue view <n>` and `gwtd issue comments <n>` provide cache-backed Issue
+  access through the gwt CLI surface.
+- `gwt-search` searches SPECs, Issues, source files, and docs through the shared
+  ChromaDB runtime. Missing indexes are built on demand, and the desktop app can
+  repair the managed Python search runtime when needed.
+- The Issue/SPEC Knowledge Bridge windows combine cache-backed list/detail views
+  with semantic ranking, exact-match priority, and match percentages.
+
+Bundled workflow skills are materialized into `.claude/skills`,
+`.claude/commands`, and `.codex/skills` for the active worktree. The public
+entrypoints are:
+
+- `gwt-discussion` — investigation-first discussion and design clarification
+- `gwt-register-issue` / `gwt-fix-issue` — issue intake and issue-driven fixes
+- `gwt-plan-spec` — implementation planning for an approved SPEC
+- `gwt-build-spec` — TDD-oriented implementation from an approved task
+- `gwt-manage-pr` — PR create/check/fix lifecycle
+- `gwt-arch-review` — architecture review and improvement routing
+- `gwt-search` — unified semantic search
+- `gwt-agent` — running agent-pane inspection and control
+
+Managed hooks preserve user hooks while adding gwt runtime behavior for agent
+state, workflow guardrails, Board reminders, discussion/plan/build Stop checks,
+and coordination-event summaries.
+
+## Workspace Foundation
+
+For isolation and repeatable agent sessions, gwt can manage each project as a
+**Nested Bare + Worktree** layout under your workspace directory:
 
 ```
 <workspace>/<project>/
@@ -176,13 +242,52 @@ confirmation modal with three actions:
 - Use `Cmd/Ctrl+Shift+Right` and `Cmd/Ctrl+Shift+Left` to cycle focus; the
   focused window is recentered
 
-## Managed Hooks and SPEC Cache
-
-- gwt regenerates `.claude/settings.local.json` and merges `.codex/hooks.json`
-  for managed hooks
-- SPECs are stored as GitHub Issues labeled `gwt-spec`
+## Operator Design Language (SPEC-2356)
+
+Starting with the Operator Design System update, gwt is themed as a single
+mission-control surface with editorial-industrial typography (`Mona Sans` for
+body, `Hubot Sans` condensed for display, `JetBrains Mono` for terminal /
+counters). Every chrome surface — Project Bar, Sidebar Layers, Status Strip,
+Command Palette, Hotkey Overlay, Drawer modals, floating windows — shares a
+single token system that ships in two flagship themes:
+
+- **Dark Operator** (Mission Control / carbon + neon) — the default, optimized
+  for long sessions
+- **Light Operator** (Drafting Table / bone + ink) — for bright environments
+
+The active theme follows your OS `prefers-color-scheme`, but the **Theme**
+toggle in the Project Bar lets you cycle `auto → dark → light → auto`. The
+choice is persisted in browser storage and survives restarts. xterm terminal
+panes follow the overall theme automatically. `prefers-reduced-motion: reduce`
+disables the Living Telemetry pulse rim, status strip ticking, and Mission
+Briefing intro reveal so the UI stays usable in motion-sensitive environments.
+`forced-colors: active` (Windows High Contrast / macOS Increase Contrast)
+falls back to system colors so accessibility is preserved.
+
+### Hotkeys
+
+| Combo | Action |
+| --- | --- |
+| `⌘K` / `⌘P` | Open the Command Palette (fuzzy search over all surface actions) |
+| `⌘B` | Focus the Board surface |
+| `⌘G` | Focus the Git (Branches) surface |
+| `⌘L` | Focus the Logs surface |
+| `⌘?` | Toggle the Hotkey Overlay (cheat sheet) |
+| `Esc` | Close any open palette / overlay / drawer |
+
+## SPEC and Runtime Quick Reference
+
+- SPEC source of truth: GitHub Issues labeled `gwt-spec`
 - Local cache path:
   `~/.gwt/cache/issues/<repo-hash>/`
+- Managed agent integration files:
+  `.claude/settings.local.json` and `.codex/hooks.json`
+- List available SPECs:
+
+```bash
+gwtd issue spec list
+```
+
 - Read a SPEC:
 
 ```bash

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@akiojin/gwt",
-  "version": "9.15.0",
+  "version": "9.16.0",
   "description": "Desktop GUI for Git worktree management and coding agent launch",
   "type": "module",
   "bin": {
@@ -12,8 +12,10 @@
     "dev": "cargo run -p gwt --bin gwt",
     "build": "cargo build --release -p gwt --bin gwt --bin gwtd",
     "test": "cargo test -p gwt-core -p gwt --all-features",
-    "test:frontend-bundle": "node --check crates/gwt/web/app.js && node --check crates/gwt/web/branch-cleanup-modal.js && node --check crates/gwt/web/migration-modal.js",
+    "test:frontend-bundle": "node --check crates/gwt/web/app.js && node --check crates/gwt/web/branch-cleanup-modal.js && node --check crates/gwt/web/migration-modal.js && node --check crates/gwt/web/theme-manager.js && node --check crates/gwt/web/hotkey.js && node --check crates/gwt/web/operator-shell.js",
     "test:frontend-smoke": "node --test crates/gwt/web/__tests__/branch-cleanup.smoke.test.mjs crates/gwt/web/__tests__/migration-modal.smoke.test.mjs",
+    "test:frontend-unit": "node --test crates/gwt/web/__tests__/contrast.test.mjs crates/gwt/web/__tests__/theme-manager.test.mjs crates/gwt/web/__tests__/hotkey.test.mjs crates/gwt/web/__tests__/operator-chrome-structure.test.mjs crates/gwt/web/__tests__/board-surface.test.mjs",
+    "test:visual": "playwright test --config crates/gwt/playwright/playwright.config.ts",
     "test:release-assets": "node scripts/test_release_assets.cjs",
     "test:release-flow": "bash scripts/check-release-flow.sh",
     "test:all": "bash scripts/test-all.sh",
@@ -47,6 +49,7 @@
   "devDependencies": {
     "@commitlint/cli": "^20.5.0",
     "@commitlint/config-conventional": "^20.5.0",
+    "@playwright/test": "^1.49.1",
     "linkedom": "^0.18.12"
   }
 }

package/scripts/test_release_assets.cjs

@@ -89,10 +89,24 @@ run("package scripts keep the GUI front door and release contract explicit", ()
   assert.equal(pkg.bin.gwt, "bin/gwt.cjs");
   assert.equal(pkg.bin.gwtd, "bin/gwtd.cjs");
   assert.equal(pkg.scripts["test:release-assets"], "node scripts/test_release_assets.cjs");
-  assert.equal(
-    pkg.scripts["test:frontend-bundle"],
-    "node --check crates/gwt/web/app.js && node --check crates/gwt/web/branch-cleanup-modal.js && node --check crates/gwt/web/migration-modal.js"
-  );
+  // SPEC-2356 — the frontend bundle now also covers Operator Design System
+  // ESM modules (theme-manager / hotkey / operator-shell). The contract is
+  // expressed as required substrings so future modules can extend the chain
+  // without rewriting the test, while still keeping the legacy SPEC-2008
+  // surfaces (app, branch-cleanup-modal, migration-modal) wired up.
+  for (const required of [
+    "node --check crates/gwt/web/app.js",
+    "node --check crates/gwt/web/branch-cleanup-modal.js",
+    "node --check crates/gwt/web/migration-modal.js",
+    "node --check crates/gwt/web/theme-manager.js",
+    "node --check crates/gwt/web/hotkey.js",
+    "node --check crates/gwt/web/operator-shell.js",
+  ]) {
+    assert.ok(
+      pkg.scripts["test:frontend-bundle"].includes(required),
+      `test:frontend-bundle must include "${required}", got: ${pkg.scripts["test:frontend-bundle"]}`
+    );
+  }
   assert.equal(pkg.scripts["test:release-flow"], "bash scripts/check-release-flow.sh");
   assert.equal(pkg.scripts.dev, "cargo run -p gwt --bin gwt");
   assert.equal(pkg.scripts.build, "cargo build --release -p gwt --bin gwt --bin gwtd");

package/scripts/verify-husky-hooks.sh

@@ -35,6 +35,19 @@ require_not_contains() {
   fi
 }
 
+require_order() {
+  local file="$1"
+  local first="$2"
+  local second="$3"
+  local first_line
+  local second_line
+  first_line=$(grep -Fn "$first" "$file" | head -n 1 | cut -d: -f1 || true)
+  second_line=$(grep -Fn "$second" "$file" | head -n 1 | cut -d: -f1 || true)
+  if [ -z "$first_line" ] || [ -z "$second_line" ] || [ "$first_line" -ge "$second_line" ]; then
+    fail "Expected '$first' to appear before '$second' in $file"
+  fi
+}
+
 require_file "$PACKAGE_JSON"
 require_contains "$PACKAGE_JSON" '"prepare": "test -n \"$CI\" || bunx husky install"'
 require_contains "$PACKAGE_JSON" "\"lint:skills\": \"bash scripts/validate-skill-frontmatter.sh\""
@@ -43,6 +56,11 @@ require_contains "$PACKAGE_JSON" "\"lint:husky\": \"bash scripts/verify-husky-ho
 require_file "$PRE_PUSH"
 require_contains "$PRE_PUSH" "cargo clippy --all-targets --all-features -- -D warnings"
 require_contains "$PRE_PUSH" "cargo fmt --all -- --check"
+require_contains "$PRE_PUSH" "ensure_coverage_tooling"
+require_contains "$PRE_PUSH" "rustup component add llvm-tools-preview"
+require_contains "$PRE_PUSH" "cargo install cargo-llvm-cov --locked"
+require_contains "$PRE_PUSH" "cargo llvm-cov --version"
+require_order "$PRE_PUSH" "if cargo llvm-cov --version >/dev/null 2>&1; then" "if command -v rustup >/dev/null 2>&1; then"
 require_contains "$PRE_PUSH" "cargo llvm-cov -p gwt-core -p gwt --all-features --json --summary-only --output-path target/coverage-summary.json"
 require_contains "$PRE_PUSH" "node scripts/check-coverage-threshold.mjs target/coverage-summary.json 90"
 require_contains "$PRE_PUSH" "bunx --bun markdownlint-cli . --config .markdownlint.json --ignore target --ignore CHANGELOG.md --ignore tasks/todo.md"