You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Connector schedule installation is macOS-only: on any other platform installConnectorSchedule saves the cron expression but returns "Schedule saved, but native installation is currently macOS-only." (src/schedules.ts:142-149), so the personal-wiki "self-updating brain" pitch doesn't hold on Windows — the schedule silently never runs. All launchd-specific code is already cleanly isolated behind process.platform !== "darwin" early-returns (schedules.ts:142, 364, 488, 853-892), and the run command is stable and platform-neutral ([node, cli.js, "ingest", "all", "--scheduled", "--print"], schedules.ts:798-805), so a Windows backend slots into existing seams.
Proposed design (feedback wanted before I write code)
Mirror the launchd path with schtasks.exe (ships with every Windows edition; no PowerShell dependency):
Shim script instead of a plist.schtasks /TR has a ~261-char limit, no working-directory field, and no output redirection — so write %USERPROFILE%\.openwiki\ingestion.schedule.cmd that cds to the configured cwd and runs "<node>" "<cli.js>" ingest all --scheduled --print >> "%USERPROFILE%\.openwiki\logs\ingestion.schedule.log" 2>&1, mirroring createLaunchAgentPlist's ProgramArguments + log paths (schedules.ts:786-835).
Cron → trigger translation reuses the existing platform-agnostic parsers (parseSimpleCronFields, getSingleCronNumber) and supports exactly the subset parseLaunchdCalendarInterval accepts today: minute+hour → /SC DAILY /ST HH:MM; +weekday → /SC WEEKLY /D; +day-of-month → /SC MONTHLY /D; anything month-pinned keeps the existing "too complex for direct installation" warning (schedules.ts:156-158). The translation is a pure function, fully unit-testable.
Wake-from-sleep stays out of scope — schtasks.exe cannot set WakeToRun (needs task XML or Register-ScheduledTask); keep the existing "Wake setup is currently macOS-only." warning (schedules.ts:368). Can be a follow-up.
Open questions for maintainers
Naming:ScheduleInstallResult.launchAgentPath and ConnectorScheduleStatus.launchAgentLoaded/launchAgentPlistExists (schedules.ts:30, 39-41) are launchd-named and surface in the credentials UI and openwiki cron help text. Prefer (a) generalized field names (nativeJobPath, nativeJobInstalled — touches more files) or (b) keeping the launchd names and stretching semantics on Windows? I'd propose (a) as a separate preparatory PR if you agree.
Testing: CI has no Windows runner (checks.yml matrix is ubuntu-only), so the schtasks exec paths would ship CI-unexercised. I'd unit-test the cron→trigger translation + shim generation as pure functions (runs everywhere) and verify the exec paths on a real Windows 11 machine with before/after schtasks /Query output in the PR, same as fix: restrict ~/.openwiki ACLs on Windows where chmod is a no-op #367's icacls verification. Acceptable?
schtasks vs Register-ScheduledTask (PowerShell): schtasks is dependency-free and language-stable via exit codes; PowerShell unlocks WakeToRun but adds a runtime dependency. I'd start with schtasks.
Happy to implement once the direction is blessed — sizing is roughly 250-400 LOC plus ~100-150 LOC of pure-function tests, one PR (or two, if you want the type-renaming split out first).
Problem
Connector schedule installation is macOS-only: on any other platform
installConnectorSchedulesaves the cron expression but returns "Schedule saved, but native installation is currently macOS-only." (src/schedules.ts:142-149), so the personal-wiki "self-updating brain" pitch doesn't hold on Windows — the schedule silently never runs. All launchd-specific code is already cleanly isolated behindprocess.platform !== "darwin"early-returns (schedules.ts:142, 364, 488, 853-892), and the run command is stable and platform-neutral ([node, cli.js, "ingest", "all", "--scheduled", "--print"],schedules.ts:798-805), so a Windows backend slots into existing seams.Proposed design (feedback wanted before I write code)
Mirror the launchd path with
schtasks.exe(ships with every Windows edition; no PowerShell dependency):schtasks /TRhas a ~261-char limit, no working-directory field, and no output redirection — so write%USERPROFILE%\.openwiki\ingestion.schedule.cmdthatcds to the configured cwd and runs"<node>" "<cli.js>" ingest all --scheduled --print >> "%USERPROFILE%\.openwiki\logs\ingestion.schedule.log" 2>&1, mirroringcreateLaunchAgentPlist's ProgramArguments + log paths (schedules.ts:786-835).schtasks /Create /TN "OpenWiki Ingestion" /TR <shim> /SC ... /Finside the platform branch ofinstallConnectorSchedule;schtasks /Query /TN↔isLaunchAgentLoaded;schtasks /Delete /TN ... /F+ unlink shim ↔unloadLaunchAgent/removeLaunchAgentPlist.parseSimpleCronFields,getSingleCronNumber) and supports exactly the subsetparseLaunchdCalendarIntervalaccepts today: minute+hour →/SC DAILY /ST HH:MM; +weekday →/SC WEEKLY /D; +day-of-month →/SC MONTHLY /D; anything month-pinned keeps the existing "too complex for direct installation" warning (schedules.ts:156-158). The translation is a pure function, fully unit-testable.schtasks.execannot set WakeToRun (needs task XML orRegister-ScheduledTask); keep the existing "Wake setup is currently macOS-only." warning (schedules.ts:368). Can be a follow-up.Open questions for maintainers
ScheduleInstallResult.launchAgentPathandConnectorScheduleStatus.launchAgentLoaded/launchAgentPlistExists(schedules.ts:30, 39-41) are launchd-named and surface in the credentials UI andopenwiki cronhelp text. Prefer (a) generalized field names (nativeJobPath,nativeJobInstalled— touches more files) or (b) keeping the launchd names and stretching semantics on Windows? I'd propose (a) as a separate preparatory PR if you agree.checks.ymlmatrix is ubuntu-only), so theschtasksexec paths would ship CI-unexercised. I'd unit-test the cron→trigger translation + shim generation as pure functions (runs everywhere) and verify the exec paths on a real Windows 11 machine with before/afterschtasks /Queryoutput in the PR, same as fix: restrict ~/.openwiki ACLs on Windows where chmod is a no-op #367's icacls verification. Acceptable?schtasksvsRegister-ScheduledTask(PowerShell): schtasks is dependency-free and language-stable via exit codes; PowerShell unlocks WakeToRun but adds a runtime dependency. I'd start with schtasks.Happy to implement once the direction is blessed — sizing is roughly 250-400 LOC plus ~100-150 LOC of pure-function tests, one PR (or two, if you want the type-renaming split out first).