ENGINEERING VERSION LOG · 2026.10.04
Desktop state feedback and local recognition + optional AI editing
Restoring visible system-icon state while separating local recognition, progressive preview, and optional text editing. This is a 2.0.37 candidate progress record, not a signed public-release announcement.
01 · THE SYMPTOM
The app was recording, but the system icon stayed the same.
The complete InkTyper logo remained visible in the menu bar or system tray, yet it did not show whether the client was recording, transcribing, editing, or delivering text. A floating overlay helped, but hiding it removed the easiest state cue.
The decisive code trace was a presentation gap: the Electron path updated the tooltip and menu, but did not update the tray image after creation. The older native client had changed icons. This regression was not evidence that the recognition API was idle.
02 · THE FIX
One state machine, independent of the floating overlay.
The shared desktop client now keeps the complete brand artwork and adds a shape-based badge. The tooltip and menu name the actual processing stage. There is no flashing animation.
| State | Visible badge | Reset behavior |
|---|---|---|
| Ready | Original brand icon | Until recording starts |
| Recording | Red record dot | Until stop or cancel |
| Uploading / transcribing / editing / pasting | Amber clock | Until completion, cancel, or error |
| Done | Green check | Returns to ready after 1.8 seconds |
| Error | Coral exclamation mark | Returns to ready after 3.5 seconds; details remain in the main window |
Trusted recording and pipeline events drive this state; floating-window visibility does not. Late audio-level updates cannot restore a stopped session to “recording.” A new recording supersedes old completion timers. Live insertion remains marked as recording while the microphone is active.
03 · PERFORMANCE GUARDRAILS
A state change is not a waveform animation.
Images are cached per state and prepared for multiple display scales. Repeated volume frames do not rebuild the tray icon or menu. Cancel, account switching, window closure, and exit clean up timers. This reduces avoidable UI work; it does not establish a measured memory or latency improvement.
04 · LOCAL RECOGNITION IS NOT LOCAL AI EDITING
Progressive Preview shows recognition, not rolling AI polish.
In the checked local path, words appearing during recording are ASR output. Basic cleanup and user-maintained correction rules are distinct from a semantic editing model. The candidate code can optionally send final text for API editing after recording stops; it does not install a local editing model.
| Path | AI editing | Data boundary |
|---|---|---|
| Local recognition · Raw | No independent AI editing | Recognition audio is not uploaded for cloud ASR |
| Local recognition · Progressive Preview + API editing | Optional after stop; no rolling AI in local preview | With permission, text, vocabulary, correction rules, and custom instructions are sent; not audio |
| Live instant insertion | Skipped; already inserted text is not rewritten | Recognition uses the selected supported local or cloud path |
Text editing requires a non-Raw mode, sign-in, a network connection, upload permission, and available AI-edit quota. A request accepts up to 4000 characters. Declining permission leaves local recognition available. Missing prerequisites, timeouts, and editing failures preserve the original transcript.
AI editing is not a guarantee of recognition accuracy. It cannot replace correct segment boundaries, duplicate prevention, or final-tail delivery.
05 · VERIFICATION
Code, package, and isolated GUI checks—not installed-user acceptance.
| Check | Observed result | Boundary |
|---|---|---|
| 2026-10-03 desktop test baseline | 177 tests: 175 passed, 0 failed, 2 skipped | The skipped checks require Windows signature verification |
| 2026-10-04 2.0.37 macOS recheck | 178 tests: 176 passed, 0 failed, 2 skipped; TypeScript / renderer build passed | Includes a signing-probe regression; platform-specific checks still require Windows |
| Windows CI 37137401715 | 178 / 178 tests passed, 0 failures, 0 skips; x64 NSIS installer built | The installer and application remain NotSigned; no physical installation or input acceptance |
| Packaged local ASR · four targets | win32-x64, darwin-arm64, darwin-x64, and linux-x64 passed five-language / six-scenario checks | Renderer adapter and native worker only—not real microphone IPC, hotkeys, or target-app paste |
| macOS arm64 package candidate | Developer ID build completed; strict signature, stable developer / bundle identity, architecture, entitlements, and packaged ASR checks passed | Gatekeeper reports Unnotarized Developer ID; notarization preflight is blocked by the account-agreement requirement |
| Linux package candidates | AppImage and deb built; both packaged ASR checks passed; AppImage isolated GUI smoke check passed | The GUI ran under Xvfb and its main screen was visually checked, not installed on a physical user desktop |
| Independent native Tray probes | macOS and Linux probes passed; macOS exercised five states and multi-scale images | Separate test contexts; Windows native tray and third-party menu-bar integration remain unverified |
The ASR fixtures cover Chinese (zh), English (en), Cantonese (yue), Japanese (ja), and Korean (ko). The six scenarios are a complete sentence, progressive preview, live instant emission, a pause followed by resumed speech and its final tail, cancellation during native decoding, and silence. Passing these controlled fixtures is not a general accuracy claim for every accent or real input target.
The state regression tests include 1000 repeated audio-level events, stopped-session races, old-timer cancellation, terminal-state recovery, and lifecycle cleanup. The checks above do not establish new production p50/p90/p95 measurements, real microphone / hotkey / paste acceptance, or an updated installed app.
06 · RELEASE BOUNDARY
A report going live does not update an installed binary.
At the checked baseline, the installed Mac app was 2.0.32 and did not contain the optional local-recognition + API-editing path. That capability was in 2.0.36 candidate code and is carried into the 2.0.37 release candidate alongside the tray-state fix.
The download audit found Windows version 2.0.3 behind the fixed website alias while the update feed offered 2.0.19. The 2.0.36 package was an internal unsigned candidate. These were separate distribution states, not one synchronized release.
The 2.0.37 candidates have now been built: macOS arm64 has a checked Developer ID signature but remains unnotarized; Windows x64 is explicitly INTERNAL-UNSIGNED; Linux AppImage / deb have passed packaged ASR and an isolated AppImage GUI check. None of these results means a new package has been installed for users or promoted to the stable release channel.
07 · NEXT ACCEPTANCE GATES
Verify the actual packages and the ordinary download path.
- Retain same-version, traceable candidates and finish final artifact hash, signature, and installation acceptance checks.
- Complete Apple notarization / Gatekeeper checks and Windows publisher / timestamp / public-chain checks.
- Test native tray states, microphone capture, target-app paste, and session restore after restart.
- Test Windows third-party menu-bar behavior and Linux tray behavior on their real systems.
- Align fixed website downloads, versioned artifacts, update feeds, and release notes without requiring a page-version query parameter.
Until those gates pass, internal unsigned builds stay internal. Later release evidence should update the dated record explicitly, rather than silently turning candidate checks into production claims.