[115dkk]

Builds on #98. #98 is merged into this branch because it fixes the Windows tests that fail on main, so test (windows-latest) can pass here. Merge #98 first; until then this diff also shows its commits.

On Windows the router and the phone host ran below Normal priority, and a busy machine starved them. This PR runs them at Normal by default and adds a setting to choose the level.

What was measured (2026-10-29, Windows 11)

• ClaudeRippleRouter and ClaudeRippleHost are registered with Task Scheduler priority 7. New-ScheduledTaskSettingsSet without -Priority gives 7, which runs the action at BELOW_NORMAL_PRIORITY_CLASS. conhost, the PowerShell launcher and node …\router\src\index.js were all BelowNormal. CreateProcess gives a child its parent's class when the parent is Idle or BelowNormal.
• With cargo and rustc holding every core at Normal (8 cargo and 4 rustc processes, CPU at 100%):
  • The router took 1-3 s to answer /api/status.
  • The update from 0.12.14 to 0.12.22 failed. /api/status gave no answer within runningVersion's 10 s, so install skipped the version restart. The end-to-end probe then got connect ECONNREFUSED 127.0.0.1:8790 from a router that was listening: its accept queue was full.
  • clauderipple restart reported ! not restarted: the scheduled task belongs to another ClaudeRipple installation. The PowerShell listener lookup in router-state.ts (5 s timeout) had timed out, and its null answer counts as "other".
  • Run again once the load dropped, every ownership gate said "ours" and the restart worked.
• In a BelowNormal PowerShell, a child started by Start-Process was BelowNormal. Once the PowerShell raised itself to Normal, its next child was Normal.
• A Node process run by a normal user could set itself to each of BelowNormal, Normal, AboveNormal and High. Realtime silently became High.

Changes

A Normal baseline (first commit)

• schtasks.ts registers the task with -Priority 4 (Normal). readTaskDefinition reads Settings.Priority, and taskDefinitionMatches requires 4, so the next install registers an existing task again.
• If Register-ScheduledTask is refused (E_ACCESSDENIED), the headless and pre-headless fallbacks keep a task that differs only in its priority. Nothing else in that fallback is loosened.
• The launcher raises itself from BelowNormal or Idle to Normal before it starts the router, so the router starts at Normal even under an old registration. Every install rewrites the launcher, so existing installs get this with their next update. The phone host's task uses the same installAgent and renderLauncher.
• quiet() in router-state.ts waits 15 s instead of 5 s. What a null answer means is unchanged.

The setting (second commit)

• Config.processPriority is one of below-normal, normal, above-normal or high, the Task Manager levels. It is validated, and an absent value means normal. below-normal is what the router ran at before.
• process-priority.ts applies it on Windows and reads back what is in effect. That can also be idle or realtime when another program changed it. A level already in effect is left alone and logs nothing; a change logs one line.
• The router applies the setting after its logger starts and again on every config change. The phone host applies it when it starts and picks up a change at its next start, because the host does not read the router config again while it runs.
• Other platforms are left alone and report supported: false, because raising a priority there needs privileges.
• GET /api/status carries processPriority: { supported, setting, current, error? }.
• The dashboard's About view has a CPU priority menu under Automatic updates, shown when the router reports supported:
  • Choosing High opens a confirm() first, and the row shows a warning while High is on.
  • When Windows reports a level other than the setting, the row says which.
  • Strings exist in all six dashboard languages. The level names follow each language's Task Manager.
• docs/ARCHITECTURE.md gets a row in §5 for this failure and a section on the setting.

Tests

• process-priority.test.ts:
  • Each of the four levels is set on Windows, and undefined means normal.
  • A level already in effect is not set again and is not logged; a change logs one line.
  • Other platforms are never asked.
  • A failing setPriority is reported in the state and not thrown.
  • Windows' idle and realtime values read back as names.
  • The read-only state never sets anything.
• config.test.ts: the four levels pass validation; "realtime", "High" and 1 fail with the exact message.
• admin.test.ts: /api/status carries the field.
• schtasks-definition.test.ts:
  • The task matches only at priority 4, and the registration line carries -Priority 4.
  • The launcher raises itself before while ($true), keeps its BOM and CRLF, and never names AboveNormal, High or RealTime.
  • A refused registration keeps a task that differs only in priority and still throws for any other difference.
• ui-priority.test.ts (new) runs the page's own priorityRow and savePriority:
  • There is no row without supported.
  • The menu offers the four levels, and High carries its warning.
  • A level in effect that differs from the setting is named.
  • Declining the confirm saves nothing and puts the menu back; another level saves without asking.
  • Every dashboard language has every key, with {level} once.
• npm run typecheck and check:mod pass. The router process-priority, config, admin and ui-* tests, the CLI schtasks-definition, ownership, recovery and supervisor-start tests, and the remote platform and local-control tests give 349 tests: 347 passed, 2 skipped, 0 failed.
• launcher.test.ts passes with refactor(router): a request's kind and a provider's capabilities are each answered in one place, and the Windows suite is fixed #98 merged in.

Not done: registering the task again on a real machine, restarting the services with this branch installed, reproducing the CPU load against it, or opening the dashboard in a browser. The row was checked through the test harness only.

🤖 Generated with Claude Code