playwright was declared but referenced nowhere in the source — no import, no
require, no script. Its postinstall downloads several hundred MB of browsers
on every install, which setup-windows.bat had been working around with
PLAYWRIGHT_SKIP_BROWSER_DOWNLOAD. Removing the dependency removes the need for
the workaround, so that goes too.
Nothing else depends on it; the remaining lockfile mentions are Next declaring
@playwright/test as an optional peer, which installs nothing.
Instances pick this up through the normal update path: package-lock.json
changed, so update-check runs npm install and playwright disappears from
node_modules. Any browsers already downloaded on a machine live outside
node_modules and are not removed by this — see README.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
winget installed Python successfully and the very next line reported it
missing. The re-probe only checked `py -3` and `python` on PATH, and a
just-installed interpreter is not on the PATH this session inherited at start
— the same failure Git and Node already had directory probes for. Python
never got them.
Probe the standard install homes before giving up:
%LOCALAPPDATA%\Programs\Python\Python3* (per-user, winget's default)
%ProgramFiles%\Python3* (all-users)
...\Python\Launcher\py.exe, %SystemRoot%\py.exe
Globbed rather than version-pinned so a 3.13 install is found too, and the
loop body uses %%~D: a quoted for /d pattern carries its quotes through, which
would otherwise mangle every path built from "C:\Program Files\Python312".
This also covers Python installed without "Add python.exe to PATH" ticked,
which is the more common way to end up here without winget involved.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Instances were started by hand and updated by hand, so they drifted behind
master silently. Now: PM2 supervises the dashboard and the clicker, a logon
task brings them up, and a 5-minute task pulls, rebuilds and restarts when
master moves.
Restarting on every push is only safe because the scheduler now survives it.
It was pure in-memory state (_global.__autoTrader), so any restart silently
stopped automated trading with the dashboard simply showing it as off. It now
mirrors running/action/symbol/stopAfterAll to the settings table, and
resumeSchedulerIfPersisted() picks it back up from the getClients() bootstrap.
No sync-wait was needed there: tick() already skips while a client reports
!syncComplete and while any account holds a position.
A failed build is never deployed — the build runs before anything restarts, so
a broken push leaves the previous build serving.
start-all and update-check both warm the app with a request afterwards. That is
load-bearing: getClients() is lazily bootstrapped, so until something makes an
HTTP request the Tradovate clients, the reporter and the resumed schedule never
start. That was already true of manual restarts.
Logic lives in Node so a macOS or Linux port only needs an equivalent of
install-autostart.ps1. Python deps are hash-guarded, so the common path is one
hash and one import with no network, and failure is non-fatal since only the
clicker needs them.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A bare `git clone` follows whatever the remote advertises as its default
branch. Pushing --all to a fresh Gitea repo left that default pointing at
autobuyer, so setup cloned a branch predating the build fixes and failed at
`next build` on an error that had already been fixed on master.
The Gitea default is corrected, but the script no longer depends on it:
clone passes --branch master, and the update path fetches, checks out master
and pulls it by name. That also recovers a checkout already stranded on the
wrong branch, rather than needing the folder deleted.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Each prerequisite now follows probe -> offer install -> probe again. The
second probe matters: a freshly installed tool is never visible to `where`
in the session that installed it, since the process inherited its PATH at
start. A *_TRIED guard stops the loop at one attempt.
Node installs from the LTS package on purpose - better-sqlite3 publishes
prebuilt binaries for LTS, so this sidesteps the node-gyp compile that the
existing Node >= 23 warning covers.
Python detection runs the interpreter instead of calling `where python`.
Windows ships a stub python.exe under WindowsApps that only opens the
Microsoft Store; `where` finds it but it cannot execute anything. Asking for
sys.version_info distinguishes the two, and the py launcher is preferred
because the stub does not shadow it.
Dependency install now upgrades pip first and verifies pyautogui actually
imports, rather than trusting pip's exit code alone.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Git for Windows only adds itself to PATH when "Git from the command line"
is selected during install, and an already-open Command Prompt keeps its
old PATH regardless — so a correct install still failed the check.
Probe the standard install locations before giving up, and when that also
fails, say which directories were searched and call out the just-installed
case explicitly.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Standalone batch file: clones (or pulls), installs, builds, seeds the
reporter settings, and writes a start-autofirmer.bat. Prompts for the master
dashboard URL and instance name, defaulting to %COMPUTERNAME%.
Two install hazards it handles:
- better-sqlite3 has no prebuilt binary above Node 22, so install silently
falls back to node-gyp and dies without Visual Studio Build Tools. The
script warns first and names the fix if install fails anyway
- playwright is declared but referenced nowhere in the source, so its
postinstall browser download is skipped
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
