v0.12.0 — Pixel Map trigger (rotation-tolerant colour matching)

Downloads

• PixelPulse-Setup-vX.Y.Z-windows.exe — the full app (GUI + engine bundled). This is what most people want — see Installation.
• PixelPulse-Core-vX.Y.Z-windows.zip — a standalone, compiled CLI-only engine (no GUI, no Python install needed) for driving PixelPulse straight from a rules.json file. See Running from Source for how the CLI works.

---

What's new — Pixel Map trigger (for targets that move and rotate)

Image matching only tolerates a target moving, not rotating — the moment a target spins or turns, it stops matching the original capture. The existing pixel-colour trigger only ever checks one fixed screen point, so it can't follow a moving target either. Testing surfaced exactly this gap: a target that both moves and rotates couldn't be reliably detected by either existing trigger type.

Pixel Map is a new third trigger kind built for that case: it records a handful of key colours from the target and matches wherever several of them cluster together on screen — completely ignoring the target's current rotation, since it never compares the colours' relative angle to each other, only whether they're near one another.

• Auto-Detect Colours — select a region on screen and the app automatically picks out its most prominent colours (k-means colour quantization).
• Pick Colours with Magnifier — a new standalone pixel magnifier tool (also reachable from Settings → Tools) shows the live RGB value under your cursor as you move, and lets you click to add several colours to a list.
• Minimum colours to match / Cluster search radius — tune how many key colours need to cluster together, and how close counts as "clustered", trading sensitivity against false positives. Always scans the whole screen.

Because it only checks colour proximity, not layout, a Pixel Map rule can have more false positives than an image trigger if the same colours happen to cluster elsewhere on screen — the tolerance/colour-count/minimum-matches controls exist specifically to tune that tradeoff.

Verified: 18 new backend tests (detection algorithm, capture.detectColours, WebSocket wiring) plus manual browser testing against a real backend — trigger-kind switching, colour picking via the magnifier, Test Match round-trips (including a genuine "no match" result against real screen content, and a real live capture.pixel call from the magnifier overlay itself), Edit re-opening with colours preserved, and the standalone Settings entry point.

Other

• README (EN + zh-TW) and the in-app Help manual document the new trigger and magnifier tool.
• GitHub Wiki gained a bilingual "Pixel Map" page.

---

Downloads / 下載說明

• PixelPulse-Setup-vX.Y.Z-windows.exe——完整應用程式（GUI + 內建引擎）。大多數人應該下載這個——請見 安裝說明。
• PixelPulse-Core-vX.Y.Z-windows.zip——獨立、已編譯好的純 CLI 引擎（沒有 GUI、不需要另外安裝 Python），可以直接用 rules.json 檔案驅動 PixelPulse。CLI 用法請見 從原始碼執行。

---

新功能 —— 像素圖（Pixel Map）觸發條件（給會移動又旋轉的目標用）

圖片比對只耐得住目標移動位置，耐不住旋轉——目標一轉角度，跟截圖不像了就比對失敗。既有的像素顏色觸發條件只檢查螢幕上單一固定座標，同樣沒辦法跟著移動的目標跑。測試中剛好遇到這個缺口：一個「又會移動、又會旋轉」的目標，兩種既有觸發條件都沒辦法可靠偵測到。

像素圖 是新增的第三種觸發條件，就是為了這種情境設計：記錄目標身上幾個關鍵顏色，偵測時只要這些顏色在畫面上某處群聚在一起就算命中——完全不管目標現在轉到哪個角度，因為從來不比較顏色點之間的相對角度，只看它們是否彼此靠近。

• 自動偵測顏色——在螢幕上框選一個區域，應用程式會用 k-means 色彩量化自動抓出裡面最主要的幾個顏色。
• 使用放大鏡挑選顏色——新增的獨立像素放大鏡工具（也可以從設定 → 工具開啟），滑鼠移動時即時顯示游標下的 RGB 值，點擊即可把好幾個顏色加進清單。
• 至少要命中幾個顏色 / 群聚搜尋半徑——調整需要幾個關鍵顏色群聚在一起、多靠近才算「群聚」，藉此在敏感度跟誤判率之間取捨。一律掃描整個螢幕。

因為只檢查顏色是否彼此靠近、不檢查排列方式，如果畫面上剛好有別的地方也有相同顏色群聚，像素圖規則的誤判機率可能會比圖片比對高——容許誤差、顏色數量、最低命中數這幾個控制項就是為了讓你調整這個取捨。

驗證方式：新增 18 個後端測試（偵測演算法、capture.detectColours、WebSocket 串接），另外針對真實後端做了瀏覽器手動測試——切換觸發條件類型、透過放大鏡挑色、Test Match 來回測試（包含針對真實螢幕內容測出真正的「沒有命中」結果，以及放大鏡疊層本身發出的真實 capture.pixel 請求）、編輯重新開啟後顏色保留正確、設定頁的獨立入口也確認可用。

其他

• README（中英雙語）與 App 內建說明手冊都補上了新觸發條件與放大鏡工具的說明。
• GitHub Wiki 新增雙語的「像素圖」頁面。

v0.11.0 — Batch image upload

Downloads

• PixelPulse-Setup-vX.Y.Z-windows.exe — the full app (GUI + engine bundled). This is what most people want — see Installation.
• PixelPulse-Core-vX.Y.Z-windows.zip — a standalone, compiled CLI-only engine (no GUI, no Python install needed) for driving PixelPulse straight from a rules.json file. See Running from Source for how the CLI works.

---

What's new — batch image upload

A new Batch Upload button on the Rules page turns a folder of reference images into one rule per image in a single step, instead of repeating the single-image "New Rule" flow for each one.

• Select several image files at once — each becomes its own rule (template trigger, whole-screen scan, click action, dry-run).
• Default names are plain sequential numbers ("1", "2", "3", ...) — they pick up after the highest number already in use, so a batch never collides with rules you already have, whether created manually or from an earlier batch.
• Rename any of them afterward with Edit (from v0.8.0) — the numbers are just a quick starting point, not meant to stick.
• If one file fails to import (corrupt image, etc.), it's skipped and the rest of the batch still completes; a summary of what failed shows at the top of the page.

No backend or protocol changes — this reuses the existing image-import and rule-create messages, just orchestrated client-side in a loop.

Verified: manual browser testing against the real backend — uploaded a batch of 3 images (got rules "1"/"2"/"3", each with a distinct imported image and the expected defaults), uploaded a second batch of 2 more (correctly continued as "4"/"5" with no collision), then renamed one via Edit and confirmed it updated in place rather than duplicating.

---

下載說明

• PixelPulse-Setup-vX.Y.Z-windows.exe——完整應用程式（GUI + 內建引擎）。大多數人應該下載這個——請見 安裝說明。
• PixelPulse-Core-vX.Y.Z-windows.zip——獨立、已編譯好的純 CLI 引擎（沒有 GUI、不需要另外安裝 Python），可以直接用 rules.json 檔案驅動 PixelPulse。CLI 用法請見 從原始碼執行。

---

新功能 — 批量上傳圖片

規則頁新增一個 批量上傳 按鈕，可以一次把一整批參考圖片變成一條條規則，不用對每張圖片重複跑一次「新增規則」的單張圖片流程。

• 一次選取好幾張圖片檔案 —— 每張都會各自變成一條規則（樣板觸發、全螢幕掃描、點擊動作、dry-run）。
• 預設名稱是單純的流水號（「1」、「2」、「3」...）——會接在目前已經用掉的最大數字之後繼續編，所以不管是手動建立的還是前一批上傳的既有規則，這次批次都不會撞名。
• 之後隨時可以用 編輯（v0.8.0 新增）幫任何一條改名 —— 數字只是個方便的起點，不是要你一直用下去。
• 如果某個檔案匯入失敗（圖片檔損毀等），會跳過該檔案、繼續處理其餘的，畫面最上方會顯示一則彙總，說明哪些檔案失敗了。

沒有任何後端或協定變動 —— 這次純粹是重複使用既有的圖片匯入與新增規則訊息，在前端用迴圈編排而已。

驗證方式：針對真實後端做了瀏覽器手動測試 —— 上傳一批 3 張圖片（得到規則「1」／「2」／「3」，各自對應不同的匯入圖片，且都套用預期的預設值），再上傳一批 2 張（正確接續編號為「4」／「5」，沒有撞名），接著用編輯幫其中一條改名，確認是原地更新而不是新增重複的規則。

v0.10.0 — In-app auto-updater

What's new — in-app auto-updater

The installed app now checks GitHub Releases for a newer version once per launch. This is the last of the four pieces from the recent GUI overhaul (rule editing, delete-all, redesign, and now this).

• Nothing happens without confirmation. If a newer version is found, a dialog asks before anything downloads or installs — no silent background updates.
• Won't interrupt a running engine. If the engine is active when an update is found, you're told to stop it first rather than having it cut off mid-run.
• Real reinstall, not an overwrite. Once confirmed, it downloads the new installer, closes the app, and reinstalls silently — the same NSIS installer already used for manual installs automatically detects and removes the previous version first, so this is a clean reinstall rather than a patch-in-place. Your rules and captured template images (%APPDATA%\PixelPulse\) live outside the install directory and are untouched either way. The app reopens automatically once it's done.
• Settings page already showed the running version (added in v0.9.0) — this is what the update check compares against.

Verified: version comparison (including the case naive string comparison gets wrong — "0.10.0" sorting before "0.9.0"), the GitHub API call and installer-asset matching, the engine-running check in both states, and the download pipeline were each tested against real endpoints. Launched an actual packaged build and confirmed the full detection path fires correctly end-to-end, reaching the confirmation dialog.

Known limitation, stated plainly: the final step — confirming the dialog and letting it actually download, quit, reinstall, and relaunch — was not exercised live in this session. That step modifies the app's own installed files, and testing it against a real, working install carried more risk than it was worth to verify in-session. If you hit anything unexpected the first time an update prompt appears, please open an issue.

---

新功能 — App 內建自動更新

安裝好的 App 現在每次啟動都會檢查一次 GitHub Releases 有沒有新版本。這是最近這一輪 GUI 大改版四件事裡的最後一塊（規則編輯、刪除全部、重新設計，現在加上這個）。

• 沒有確認就什麼都不會發生。 發現新版本時會先跳出對話框詢問——在你確認之前，不會下載或安裝任何東西，沒有背景靜默更新這回事。
• 不會打斷正在執行的引擎。 如果發現新版本時引擎正在跑，會請你先手動停止，而不是強行中斷正在執行的規則。
• 真正的重新安裝，不是覆蓋式更新。 確認之後，會下載新的安裝檔、關閉程式、靜默重新安裝——手動安裝時本來就在用的同一套 NSIS 安裝檔，會自動偵測並先移除舊版本，所以這是乾淨重裝，不是原地覆蓋。你的規則跟擷取到的樣板圖片（%APPDATA%\PixelPulse\）不在安裝目錄裡，完全不受影響。安裝完成後會自動重新開啟。
• 設定頁本來就會顯示目前版本（v0.9.0 加的）——更新檢查比對的就是這個版本號。

驗證方式：版本比較邏輯（包括字串比較會判斷錯誤的案例——"0.10.0" 用字串排序會排在 "0.9.0" 前面）、GitHub API 呼叫與安裝檔資產比對、引擎執行狀態的兩種情境、下載寫檔流程，都各自針對真實端點測試過。也實際啟動打包後的版本，確認整條偵測流程在真正的 Electron 主行程裡完整跑過一次，正確跳出確認對話框。

如實說明的已知限制：最後一步——按下確認之後真正下載、結束程式、重新安裝、自動重開——這次沒有做真實的端對端測試。這一步會動到 App 自己已經安裝好的檔案，拿一份真實在用的安裝去冒險測試，風險不划算。如果你第一次看到更新提示時遇到任何異常，歡迎開 issue 回報。

v0.9.0 — GUI redesign: sidebar, Settings page, refreshed style

What's new — GUI redesign: sidebar navigation, Settings page, refreshed style

The main window used to be one long scrolling column with everything crammed onto it — engine controls, rule list, and activity log all stacked together. It's now organized into a sidebar with three focused pages:

• Rules — engine start/stop and the rule list (unchanged content, just its own page now).
• Activity — the live event log, full-page instead of squeezed at the bottom.
• Settings (new) — language switcher, the app's own version number, and the Help panel trigger, all pulled out of the cramped status bar into one dedicated place.

Other changes:

• Icon-based language switcher: the "中文"/"EN" text buttons are now icon buttons (using the language icon from the project's design resources), rendered via a CSS mask so the icon always matches the current text colour exactly instead of an approximate filter-based tint.
• App version display: Settings now shows the running app's actual version, via a new app:get-version bridge — this is also the plumbing a future in-app update checker will reuse.
• Refreshed toggle switches: every on/off setting in the app (dry-run, whole-screen scanning, once-per-appearance, rule enabled) is now a pill-style toggle switch instead of a bare browser checkbox — loosely inspired by community reference designs in the project's resources (not copied verbatim; one consistent visual style applied throughout).

No behavior changes to rules, triggers, or actions — this release is purely about how the app is organized and looks.

---

新功能 — GUI 重新設計：側邊欄導覽、設定頁、視覺風格更新

主視窗原本是一個很長的捲動頁面，把引擎控制、規則清單、活動紀錄全部疊在一起。現在改成側邊欄 + 三個各自獨立的頁面：

• 規則 —— 引擎啟動/停止跟規則清單（內容不變，只是變成獨立頁面）。
• 活動紀錄 —— 即時事件紀錄，改成整頁顯示，不再擠在畫面最下面。
• 設定（新增）—— 語言切換、App 自己的版本號，以及說明面板的入口，全部從原本擁擠的狀態列搬到這個獨立的地方。

其他變動：

• 語言切換改成圖示：原本「中文」/「EN」的純文字按鈕，換成用語言圖示（取自專案的設計素材）做的圖示按鈕，用 CSS mask 渲染，讓圖示顏色永遠精確跟隨目前的文字顏色，而不是用大概湊色的濾鏡效果。
• App 版本顯示：設定頁現在會顯示目前執行中 App 的實際版本號，透過新增的 app:get-version 橋接取得——這也是之後App 內建更新檢查功能會直接複用的管線。
• 切換開關視覺更新：App 裡所有開關型設定（dry-run、全螢幕掃描、每次出現觸發一次、規則啟用）都從瀏覽器原生的核取方塊，換成藥丸形切換開關 —— 靈感來自專案設計素材裡的社群參考範例（不是照抄，而是挑出一套一致的視覺語言套用到全App）。

規則、觸發條件、動作的行為完全沒有變動 —— 這次發佈純粹是介面組織方式與外觀的更新。

v0.8.0 — Edit existing rules, delete all at once

What's new — edit existing rules, delete all at once

Rules could previously only be deleted and recreated from scratch — no way to tweak an existing one without losing all its settings. Two additions:

• Edit Rule: click the new Edit button on any rule card to open the same 3-step editor, pre-filled with that rule's current trigger, action, and safety settings. Change anything (including the name) and save — it updates the rule in place instead of creating a duplicate.
• Delete All: a new button in the rule list header clears every rule at once. Unlike deleting a single rule, this asks for confirmation first (showing how many rules will be removed), since it's a lot harder to walk back.

Verified: 8 new automated tests (60 total, all passing) covering in-place updates, renaming, name-collision rejection, and bulk deletion at both the service and WebSocket layers — plus manual browser verification against the real backend: created a rule, edited it (renamed + toggled a setting), confirmed it updated in place rather than duplicating, then exercised the Delete All confirmation dialog (declined it — rule survived; confirmed it — list cleared).

---

新功能 — 編輯現有規則、一次刪除全部

規則之前只能刪除重建，沒辦法在不遺失原本設定的情況下微調一條既有規則。這次新增兩個功能：

• 編輯規則：點擊規則卡片上新增的 編輯 按鈕，會開啟跟新增規則一樣的三步驟編輯器，並預先帶入這條規則目前的觸發條件、動作、安全參數。改完任何欄位（包括名稱）存檔後，會原地更新這條規則，而不是新增一條重複的。
• 刪除全部：規則清單標題列新增一個按鈕，可以一次清空所有規則。跟刪除單一規則不同，這個會先跳出確認對話框（顯示會刪除幾條規則），因為影響範圍大很多、比較難挽回。

驗證方式：新增 8 個自動化測試（總計 60 個，全數通過），涵蓋服務層與 WebSocket 層的原地更新、改名、名稱衝突拒絕、批次刪除 —— 另外針對真實後端做了瀏覽器手動驗證：建立一條規則、編輯它（改名 + 切換一個設定）、確認是原地更新而不是新增重複，接著測試「刪除全部」的確認對話框（取消時規則還在；確認後清單清空）。

v0.7.1 — Fix: default image rules to whole-screen scanning

Fix: image rules now default to whole-screen scanning

Follow-up to v0.7.0's instant-trigger rules. A screen-cropped image trigger defaulted to matching only inside the exact box it was captured from — if the target ever moved (a button shifts, a window resizes, the UI relayouts), the rule would silently stop detecting it entirely. That defeats the point of an image-based trigger, which should find its target wherever it shows up.

Scan the whole screen is now checked by default when capturing an image from the screen (it was already forced-on for uploaded image files). You can still uncheck it for a smaller, faster scan region with fewer false positives if you specifically want the target locked to one spot.

No backend or schema changes — this is a GUI-only default flip. Existing saved rules are unaffected either way.

---

修正：圖片規則現在預設全螢幕掃描

接續 v0.7.0 的即時觸發規則。從螢幕框選出來的圖片觸發，原本預設只在當初框選的那個確切區域裡比對 —— 如果目標日後移動了位置（按鈕位移、視窗改變大小、介面重新排版），規則會直接、無聲無息地再也偵測不到。這違背了圖片觸發的本意：應該要能在目標出現的任何地方找到它。

從螢幕框選圖片時，Scan the whole screen 現在預設打勾（上傳圖片檔案的情況本來就已經強制全螢幕）。如果你確實想把目標鎖定在同一個位置、換取更快的掃描速度與更少的誤判，仍然可以自己取消勾選。

沒有任何後端或資料格式變動 —— 這純粹是 GUI 端的預設值調整，不影響任何已經存好的規則。

v0.7.0 — Instant-trigger rules: whole-screen, upload, edge-trigger

What's new — instant-trigger rules

Feedback: the rule editor didn't do what one user pictured — they wanted "give it an image, and the instant the app sees it after launch, it types/clicks, with no count or ordering settings to fuss over." Rather than replacing the existing rule editor, three independent, combinable options were added to it:

• Trigger region is now optional. Leave it unset and the rule scans the whole screen instead of a fixed region — the target can appear anywhere. A screen-cropped region can still opt into whole-screen scanning via a new Scan the whole screen checkbox.
• Template images can come from a file, not just a screen crop. A new Browse for Image File option (native OS file picker) lets you point at an existing image instead of drag-selecting a live region. An uploaded image always scans the whole screen — there's no captured region to fall back to.
• New retrigger mode: "Only trigger once until it disappears and reappears." An alternative to the existing cooldown timer — the rule fires once the instant its target appears, then stays silent until the target disappears and comes back, instead of repeatedly firing every scan tick (or every cooldown interval) while it stays visible.

All three are opt-in and off by default — every existing rule and the existing screen-crop workflow behave exactly as before.

Verified: 6 new automated tests (52 total, all passing) covering the full-screen scan fallback, the appear/disappear edge-triggering logic, and the new image-import WebSocket message — plus manual browser verification against the real backend in both English and 繁體中文, checking that saved rules persist the new fields correctly and the new rule-list badges ("whole screen" / "once per appearance") render correctly.

---

新功能 — 即時觸發規則

使用者回饋：規則編輯器不是他想像中的樣子 —— 他想要的是「給一張圖片，App 啟動後一看到就直接輸入/點擊，不用煩惱次數或順序設定」。這次沒有另外做一套取代現有編輯器的東西，而是在既有規則編輯器裡新增三個彼此獨立、可以自由組合的選項：

• 觸發範圍現在是可選的。 不設定的話，規則會掃描整個螢幕，而不限於固定區域 —— 目標可以出現在任何地方。框選出來的區域也可以另外勾選新的 Scan the whole screen 核取方塊，改成全螢幕掃描。
• 樣板圖片現在可以來自檔案，不只是螢幕框選。 新增的 Browse for Image File 選項（原生系統選擇檔案視窗）可以直接指向一張既有的圖片，不用即時拖曳框選畫面。上傳的圖片一律掃描整個螢幕 —— 因為沒有對應的框選區域可以退回去用。
• 新的重新觸發模式：「只在目標出現時觸發一次，直到它消失後重新出現才會再觸發」。 這是既有冷卻時間之外的另一種選擇 —— 規則在目標一出現的那一刻就觸發一次，之後保持沉默，直到目標先消失、再重新出現才會再觸發一次，而不是它持續可見時每次掃描（或每個冷卻週期）都重複觸發。

三個都是選用、預設關閉 —— 所有既有規則跟既有的螢幕框選流程，行為完全不受影響。

驗證方式：新增 6 個自動化測試（總計 52 個，全數通過），涵蓋全螢幕掃描的退回邏輯、出現/消失邊緣觸發的判斷邏輯，以及新的圖片匯入 WebSocket 訊息 —— 另外針對真實後端做了瀏覽器手動驗證，中英文都測過，確認存檔的規則正確保留新欄位、規則清單的新徽章（「whole screen」／「整個螢幕」、「once per appearance」／「每次出現觸發一次」）都正確顯示。

v0.6.0 — Phase 6: a real Windows installer

What's new — Phase 6: a real Windows installer

PixelPulse now ships as a single Windows installer (PixelPulse-Setup-v0.6.0-windows.exe), alongside the existing CLI-only zip. This closes the gap the CLI-only packaging left: previously the GUI only worked if you separately started the Python server by hand (python -m core.server) in a terminal before launching Electron.

• The Python engine is bundled inside the installed app (via PyInstaller) and the GUI now starts it automatically in the background when you launch PixelPulse — no terminal, no manual server command, no separate Python install.
• Rules and captured template images are stored per-user under %APPDATA%\PixelPulse\.
• .github/workflows/release.yml builds and uploads this installer automatically on every release, right alongside the CLI-only bundle — both artifacts, one workflow.
• Chose electron-builder's own NSIS installer target over the originally-planned separate Inno Setup step, once it was clear electron-builder already produces a complete, standalone Windows installer on its own — no reason to layer a second installer tool on top of it.

Verified by actually running the packaged build, not just building it: launched the real packaged app, confirmed it auto-spawns the bundled server, confirmed the GUI connects to it over the WebSocket, and confirmed a created rule persists correctly to %APPDATA%\PixelPulse\rules.json. That testing caught and fixed a real bug — Electron's app.getPath("userData") was resolving to %APPDATA%\gui (from package.json's internal package name) instead of %APPDATA%\PixelPulse, now fixed with an explicit app.setName("PixelPulse").

Known limitation: the interactive installer wizard itself (the click-through: welcome → choose folder → install → finish) wasn't verified by automation in this environment — driving that specific UI wasn't reliably scriptable here. The installer builds successfully and the packaged app's actual runtime behavior (the part that actually matters — does it start, does it connect, does it save your data) was fully verified as described above. A manual install/uninstall test checklist is included in the project's internal Phase 6 notes for anyone who wants to double-check the wizard itself. The installer is also unsigned (no code-signing certificate), so Windows SmartScreen will show an "unknown publisher" warning on first run — expected for an unsigned open-source build, not a sign of tampering.

---

新功能 — Phase 6：真正的 Windows 安裝檔

PixelPulse 現在打包成單一 Windows 安裝檔（PixelPulse-Setup-v0.6.0-windows.exe），跟既有的 CLI-only zip 並存。這補上了 CLI-only 打包留下的落差：之前 GUI 必須先手動另外啟動 Python 伺服器（python -m core.server）才能用。

• Python 引擎已經打包進安裝好的 App 裡（透過 PyInstaller），GUI 啟動時會自動在背景啟動它——不需要終端機、不需要手動下伺服器指令，也不需要另外安裝 Python。
• 規則與擷取到的樣板圖片存放在每個使用者各自的 %APPDATA%\PixelPulse\ 底下。
• .github/workflows/release.yml 現在每次發佈都會自動建置並上傳這個安裝檔，跟 CLI-only 的壓縮檔一起放在同一個 Release 裡——一個 workflow，兩個附件。
• 原本規劃是另外用 Inno Setup 整合安裝檔，這次改用 electron-builder 自己內建的 NSIS 安裝檔功能——確認它本身就能產出完整、獨立的 Windows 安裝檔之後，就沒有必要再疊一層額外的安裝工具。

驗證方式是真的執行打包後的版本，而不只是建置成功就算數：實際啟動打包後的 App，確認它會自動啟動內建的伺服器、確認 GUI 有透過 WebSocket 連上、確認建立的規則會正確存到 %APPDATA%\PixelPulse\rules.json。這次測試抓到並修正了一個真實的 bug——Electron 的 app.getPath("userData") 原本解析成 %APPDATA%\gui（來自 package.json 內部的套件名稱），而不是預期的 %APPDATA%\PixelPulse，現在用明確呼叫 app.setName("PixelPulse") 修正。

已知限制：互動式安裝精靈本身的點擊流程（歡迎頁 → 選安裝路徑 → 安裝 → 完成）沒有在這個環境裡用自動化工具驗證過——這個特定的 UI 操作在這裡沒辦法可靠地自動化操作。安裝檔本身建置成功，而上面說明的「打包後 App 實際運作行為」（真正重要的部分——它會不會啟動、會不會連線、會不會存好你的資料）已經完整驗證過。專案內部的 Phase 6 筆記裡附了一份安裝/解除安裝人工測試清單，給想親自再確認一次精靈本身的人參考。這個安裝檔也沒有數位簽章（沒有憑證），所以第一次執行時 Windows SmartScreen 會顯示「未知發行者」警告——這是未簽章開源建置的正常現象，不代表檔案被竄改過。

v0.5.4 — MIT license, disclaimer, and user notice

What's new

PixelPulse now has a formal open-source license and two new legal/practical documents, available both on GitHub and inside the app.

• LICENSE — the project is now formally licensed under the MIT License. Added to the repo root, and declared in pyproject.toml / gui/package.json metadata.
• DISCLAIMER (DISCLAIMER.md / DISCLAIMER.zh-TW.md) — a short, focused restatement of the key risk points: no warranty, screen-detection automation isn't perfect, and automating a third-party service (a game, a website) that prohibits it is entirely at your own risk.
• USER_NOTICE (USER_NOTICE.md / USER_NOTICE.zh-TW.md) — practical, non-legal notes worth knowing before you start: test with Dry Run first, what the built-in safety features (cooldown, max triggers, kill switch) do, what commonly breaks detection (resolution/DPI changes, UI updates), and where your data lives.
• Both new documents are also available as new tabs in the in-app Help panel (? button), right alongside the existing User Manual, Terms of Service, and Privacy Policy — same bilingual EN/繁體中文 toggle.

This closes a real gap: the app already described itself as "open-source" in its Terms of Service, but never actually shipped a license file declaring the terms of that.

---

新功能

PixelPulse 現在有正式的開源授權條款，以及兩份新文件——GitHub 上跟 App 內都看得到。

• LICENSE —— 本專案現在正式採用 MIT License。新增在 repo 根目錄，並在 pyproject.toml / gui/package.json 的中繼資料裡宣告。
• 免責聲明（DISCLAIMER.md / DISCLAIMER.zh-TW.md）—— 簡短、聚焦地重申幾個關鍵風險：不附帶保證、螢幕辨識自動化不會百分之百準確、把它用在禁止自動化的第三方服務（遊戲、網站）上風險完全自負。
• 使用者須知（USER_NOTICE.md / USER_NOTICE.zh-TW.md）—— 開始使用前值得知道的實務（非法律）提醒：先用 Dry Run 測試、內建安全機制（冷卻時間、最多觸發次數、緊急停止）的作用、常見會讓辨識失效的狀況（解析度/DPI 變動、介面改版），以及資料存放位置。
• 兩份新文件同時也是 App 內說明面板（? 按鈕）裡的新分頁，跟既有的教學手冊、使用條款、隱私權政策並列——一樣有英文／繁體中文切換。

這次補上了一個實際存在的落差：App 的使用條款裡早就自稱「開源」，但專案裡從來沒有真正附上宣告授權條款的 LICENSE 檔案。

v0.5.3 — Fully localize the engine_started backend message

What's new

Follow-up to v0.5.2's app-wide language switcher: the one remaining English-only string generated by the backend is now fully localized too.

• The engine_started activity-log entry used to bake the phrase "N active rule(s)" directly into the event sent over the WebSocket, so it always showed up in English regardless of the GUI's selected language.
• The Python core now sends a structured rule count (rule_count) instead of a pre-formatted English sentence. The GUI renders it using its own locale files, so it now correctly reads e.g. "Engine started (3 active rule(s))" or "引擎已啟動（3 條規則啟用中）" depending on the selected language.
• No other backend-generated strings needed this treatment — the only other free-text field (rule_error's exception message) is inherently untranslatable runtime error text and was already wrapped in a translated sentence around it.

This closes the one known limitation noted in the v0.5.2 release: the entire GUI is now fully bilingual, front-end and backend-sourced text alike.

---

新功能

接續 v0.5.2 的全應用程式語言切換：後端產生、原本唯一還是英文寫死的字串，這次也完整在地化了。

• 「引擎已啟動」這則活動紀錄，原本會把「N active rule(s)」這句英文直接寫死組進透過 WebSocket 傳送的事件內容，導致不管 GUI 選了哪種語言，這行都固定顯示英文。
• Python 核心現在改為傳送結構化的規則數量（rule_count），而不是組好的英文句子。GUI 端用自己的語言檔渲染這段文字，因此現在會依照所選語言正確顯示，例如「Engine started (3 active rule(s))」或「引擎已啟動（3 條規則啟用中）」。
• 其餘後端產生的字串不需要這樣處理——唯一另一個自由文字欄位（rule_error 的例外訊息）本身就是無法翻譯的執行期錯誤文字，且原本就已經包在翻譯好的句子裡顯示。

這次修正補上了 v0.5.2 版本說明裡提到的唯一已知限制：現在整個 GUI，不論是前端還是後端來源的文字，都已完整雙語化。