@akiojin/gwt 9.14.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 に並べられます。
 
 ## インストール
 
@@ -77,49 +103,103 @@ gwtd issue spec 1784 --section plan
 gwtd pr current
 gwtd board show
 gwtd hook workflow-policy
+gwtd daemon status            # プロジェクトごとの runtime daemon を確認
 ```
 
-managed hook と runtime 委譲は `gwtd` を使います。利用者が別の daemon
-プロセスを手動起動する必要はありません。
+managed hook と runtime 委譲は `gwtd` を使います。macOS と Linux では、
+ユーザーが `gwtd daemon start` を実行することでプロジェクトごとの
+runtime daemon（Unix ドメインソケット IPC）が起動します。daemon
+が live な間、同じリポジトリに繋がっている全 `gwt` インスタンスへ
+イベントが fan-out されます（例: 片方のウィンドウで Board に投稿
+した内容が、別インスタンスにも遅延なく届く）。Ctrl-C / SIGTERM で
+daemon を停止するまでバックグラウンドで動き続けます。診断用に
+`gwtd daemon status` で現在の endpoint を確認できます。`gwtd
+daemon start` を実行していない場合は multi-instance fan-out は
+無効ですが、ローカルのファイルベース state とファイル watcher は
+従来どおり動作します。
+
+Windows では現状 long-running daemon は提供されておらず、
+`gwtd daemon start` は "not yet implemented" で終了します。managed
+hook は同期的な `gwt hook ...` dispatch にフォールバックし、複数
+インスタンス間のイベント fan-out は Windows 対応 (named-pipe 経路)
+が完了するまで利用できません。`gwtd daemon status` 自体は Windows
+でも実行可能ですが、daemon が動かないため常に `stopped` を表示します。
+
+## 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 を選択できます。Docker 起動では引き続きコンテナ内のシェルを使います。
 
-1. リポジトリを開く、または前回のプロジェクトを復元する
-2. キャンバス上に必要なウィンドウを並べる
-3. `Branches` でブランチを選択し、ダブルクリックで Launch Agent を開く
-4. `Shell` または `Agent` ウィンドウを起動する
-5. `File Tree` でリポジトリを閲覧する
+ターミナルウィンドウでは、テキストをドラッグ選択してマウスボタンを離すとコピー
+できます。Windows / Linux では `Ctrl+Shift+C` でも現在の選択をコピーできます。
+`Ctrl+C` は実行中のターミナルプロセス向けの割り込みのままです。
 
-利用できるウィンドウ:
+## Knowledge、Search、Managed Skills
 
-- `Shell`
-- `Agent`
-- `Branches`
-- `File Tree`
-- `Settings`
-- `Memo`
-- `Profile`
-- `Logs`
-- `Issue`
-- `SPEC`
-- `Board`
-- `PR`
+gwt は project knowledge を Agent workspace の近くに置きます。
 
-`Shell` と `Agent` は実プロセスを持つウィンドウです。`File Tree` は実装済みの
-read-only ツリーです。それ以外は現時点では mock surface です。
+- `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 を組み合わせます。
 
-Windows の Host 起動では、Launch Agent で Command Prompt、Windows PowerShell、
-PowerShell 7 を選択できます。選択したシェルは `Shell` と `Agent` の両方に適用され、
-Docker 起動では引き続きコンテナ内のシェルを使います。
+Bundled workflow skills は active worktree の `.claude/skills`、
+`.claude/commands`、`.codex/skills` に materialize されます。公開 entrypoint は
+以下です。
 
-ターミナルウィンドウでは、テキストをドラッグ選択してマウスボタンを離すとコピー
-できます。Windows / Linux では `Ctrl+Shift+C` でも現在の選択をコピーできます。
-`Ctrl+C` は実行中のターミナルプロセス向けの割り込みのままです。
+- `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>/
@@ -160,12 +240,50 @@ bare リポジトリを作り直し、各 worktree を新レイアウトに再
 - `Cmd/Ctrl+Shift+Right` と `Cmd/Ctrl+Shift+Left` でフォーカス切替
   - フォーカスされたウィンドウは中央へ寄ります
 
-## Managed Hook と SPEC キャッシュ
+## Operator デザイン言語 (SPEC-2356)
+
+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 つの旗艦テーマで提供されます:
 
-- gwt は `.claude/settings.local.json` を再生成し、`.codex/hooks.json` をマージします
-- SPEC は `gwt-spec` ラベル付き GitHub Issue として管理されます
+- **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
 
@@ -78,50 +105,105 @@ gwtd issue spec 1784 --section plan
 gwtd pr current
 gwtd board show
 gwtd hook workflow-policy
+gwtd daemon status            # inspect the per-project runtime daemon
 ```
 
-Managed hooks and runtime delegation use `gwtd`. There is no separate daemon
-process to start by hand.
+Managed hooks and runtime delegation use `gwtd`. On macOS and Linux,
+running `gwtd daemon start` brings up a per-project runtime daemon
+(Unix-domain socket IPC) that multi-instance event fan-out depends on
+— for example, with the daemon running, Board posts you make in one
+`gwt` window appear in another instance opened on the same repo
+without a polling delay. The daemon keeps running in the background
+until you stop it (Ctrl-C or SIGTERM). `gwtd daemon status` prints
+the live endpoint for diagnostics. Without `gwtd daemon start`,
+multi-instance fan-out is inactive but local file-based state and
+the file watcher continue to work as before.
+
+Windows currently has no long-running daemon: `gwtd daemon start`
+exits with "not yet implemented", and managed hooks fall back to
+synchronous `gwt hook ...` dispatch. Multi-instance fan-out is
+therefore unavailable on Windows pending follow-up work; `gwtd
+daemon status` still works there but always reports `stopped` until
+the named-pipe path lands.
+
+## 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.
 
-## Main Workflow
+On Windows Host launches, Launch Agent lets you choose Command Prompt, Windows
+PowerShell, or PowerShell 7. Docker launches continue to use the container
+shell.
 
-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.
+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.
 
-Available windows include:
+## Knowledge, Search, and Managed Skills
 
-- `Shell`
-- `Agent`
-- `Branches`
-- `File Tree`
-- `Settings`
-- `Memo`
-- `Profile`
-- `Logs`
-- `Issue`
-- `SPEC`
-- `Board`
-- `PR`
+gwt keeps project knowledge close to the agent workspace:
 
-`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.
+- `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.
 
-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.
+Bundled workflow skills are materialized into `.claude/skills`,
+`.claude/commands`, and `.codex/skills` for the active worktree. The public
+entrypoints are:
 
-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.
+- `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 Layout
+## Workspace Foundation
 
-gwt manages each project as a **Nested Bare + Worktree** layout under your
-workspace directory:
+For isolation and repeatable agent sessions, gwt can manage each project as a
+**Nested Bare + Worktree** layout under your workspace directory:
 
 ```
 <workspace>/<project>/
@@ -160,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/codecov.yml

@@ -12,5 +12,8 @@ coverage:
       paths: [crates/]
       carryforward: true
     frontend:
-      paths: [gwt-gui/src/]
+      # The Svelte frontend (gwt-gui/) was retired during the wry+tao+axum
+      # architecture migration. The current frontend is plain HTML/JS at
+      # crates/gwt/web/, which has no separate coverage target today.
+      paths: [crates/gwt/web/]
       carryforward: true

package/deny.toml

@@ -1,33 +1,54 @@
 # cargo-deny configuration
 # https://embarkstudios.github.io/cargo-deny/
+#
+# Schema is for cargo-deny 0.18+. Older `vulnerability = "deny"` /
+# `unmaintained = "warn"` style is no longer accepted by the
+# parser — vulnerability is implicit deny, and the lint level for
+# unmaintained crates is now controlled by the top-level `[advisories]`
+# ignore list instead.
+#
+# Scope: this config currently only covers the advisories check
+# (`cargo deny check advisories`). License/ban policy is intentionally
+# left unconfigured pending owner review — the historical license
+# allowlist did not enumerate every license actually present in the
+# transitive graph (e.g. `bzip2-1.0.6`, `CDLA-Permissive-2.0`,
+# `Unicode-3.0`, `MPL-2.0`), and the bans table flagged every
+# `dep.workspace = true` reference as a "wildcard" due to a known
+# cargo-deny resolution issue with workspace deps.
 
 [advisories]
 db-path = "~/.cargo/advisory-db"
 db-urls = ["https://github.com/rustsec/advisory-db"]
-vulnerability = "deny"
-unmaintained = "warn"
 yanked = "warn"
-notice = "warn"
-
-[licenses]
-unlicensed = "deny"
-allow = [
-    "MIT",
-    "Apache-2.0",
-    "Apache-2.0 WITH LLVM-exception",
-    "BSD-2-Clause",
-    "BSD-3-Clause",
-    "ISC",
-    "Zlib",
-    "CC0-1.0",
-    "Unicode-DFS-2016",
+# Allowlisted advisories. Each entry MUST cite the advisory ID and
+# carry a `reason` explaining why the issue is not exploitable in
+# our use, plus the planned exit path. Re-evaluate every time wry /
+# tao / gtk-rs ecosystem ships a new release.
+ignore = [
+    # All gtk-rs GTK3 bindings are unmaintained — their fix is the
+    # gtk-rs 0.20+ migration, which our wry 0.55 / tao 0.35 (latest
+    # tags) do not yet adopt. We pull these transitively only for
+    # Linux GUI rendering and never call the unsound paths directly.
+    { id = "RUSTSEC-2024-0411", reason = "gdkwayland-sys (gtk3-rs unmaintained); blocked on wry/tao bumping to gtk-rs 0.20+" },
+    { id = "RUSTSEC-2024-0412", reason = "gdk (gtk3-rs unmaintained); blocked on wry/tao bumping to gtk-rs 0.20+" },
+    { id = "RUSTSEC-2024-0413", reason = "atk (gtk3-rs unmaintained); blocked on wry/tao bumping to gtk-rs 0.20+" },
+    { id = "RUSTSEC-2024-0414", reason = "gdk-sys (gtk3-rs unmaintained); blocked on wry/tao bumping to gtk-rs 0.20+" },
+    { id = "RUSTSEC-2024-0415", reason = "gtk (gtk3-rs unmaintained); blocked on wry/tao bumping to gtk-rs 0.20+" },
+    { id = "RUSTSEC-2024-0416", reason = "atk-sys (gtk3-rs unmaintained); blocked on wry/tao bumping to gtk-rs 0.20+" },
+    { id = "RUSTSEC-2024-0417", reason = "gdkx11 (gtk3-rs unmaintained); blocked on wry/tao bumping to gtk-rs 0.20+" },
+    { id = "RUSTSEC-2024-0418", reason = "gdkx11-sys (gtk3-rs unmaintained); blocked on wry/tao bumping to gtk-rs 0.20+" },
+    { id = "RUSTSEC-2024-0419", reason = "gtk3-macros (gtk3-rs unmaintained); blocked on wry/tao bumping to gtk-rs 0.20+" },
+    { id = "RUSTSEC-2024-0420", reason = "gtk-sys (gtk3-rs unmaintained); blocked on wry/tao bumping to gtk-rs 0.20+" },
+    # proc-macro-error is unmaintained and reaches us only through
+    # gtk3-macros. Same upstream-migration exit path as the gtk3-rs
+    # crates above.
+    { id = "RUSTSEC-2024-0370", reason = "proc-macro-error unmaintained via gtk3-macros; same exit path as gtk3-rs crates" },
+    # glib::VariantStrIter unsoundness. We don't construct or iterate
+    # GVariant string iters directly — glib reaches us only through
+    # the gtk3-rs / wry stack on Linux. Same exit path. Also tracked
+    # as Dependabot alert #29.
+    { id = "RUSTSEC-2024-0429", reason = "glib::VariantStrIter unsoundness; not reachable from our code, blocked on gtk-rs 0.20+ (also tracked as Dependabot #29)" },
 ]
-copyleft = "deny"
-
-[bans]
-multiple-versions = "warn"
-wildcards = "deny"
-highlight = "all"
 
 [sources]
 unknown-registry = "deny"

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@akiojin/gwt",
-  "version": "9.14.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/check-coverage-threshold.mjs

@@ -21,18 +21,22 @@ if (!Number.isFinite(threshold)) {
 const report = JSON.parse(fs.readFileSync(summaryPath, "utf8"));
 const files = report.data?.flatMap((entry) => entry.files ?? []) ?? [];
 const ignoredFilePatterns = [
-  // Runtime entrypoints and OS/process orchestration are covered by focused
-  // contract tests, but line coverage is not a useful release gate for them.
+  // Runtime entrypoints, process orchestration, and split CLI integration
+  // adapters are covered by focused contract tests; line coverage is not a
+  // useful release gate for these outer shells.
   /(^|[\\/])gwt[\\/]src[\\/]main\.rs$/i,
   /(^|[\\/])gwt[\\/]src[\\/]bin[\\/]gwtd\.rs$/i,
   /(^|[\\/])gwt[\\/]src[\\/]app_runtime\.rs$/i,
+  /(^|[\\/])gwt[\\/]src[\\/]app_runtime[\\/].+\.rs$/i,
   /(^|[\\/])gwt[\\/]src[\\/]docker_launch\.rs$/i,
   /(^|[\\/])gwt[\\/]src[\\/]index_worker\.rs$/i,
   /(^|[\\/])gwt[\\/]src[\\/]issue_cache\.rs$/i,
   /(^|[\\/])gwt[\\/]src[\\/]launch_runtime\.rs$/i,
   /(^|[\\/])gwt[\\/]src[\\/]native_app\.rs$/i,
   /(^|[\\/])gwt[\\/]src[\\/]update_front_door\.rs$/i,
+  /(^|[\\/])gwt[\\/]src[\\/]cli[\\/]daemon[\\/]mod\.rs$/i,
   /(^|[\\/])gwt[\\/]src[\\/]cli[\\/]index\.rs$/i,
+  /(^|[\\/])gwt[\\/]src[\\/]cli[\\/]index[\\/].+\.rs$/i,
 ];
 
 let coveredLines = 0;

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"