Commit Graph
10 Commits
Author SHA1 Message Date
Brandon LiandClaude Opus 5 35dd15d584 Enrol Chrome from the installers, and drop load-unpacked
Both setup scripts ended by telling you to load the folder unpacked, which is
the one install that cannot update itself - and the policy install they moved
to next does nothing on an unmanaged machine. Enrolment is the step that
actually matters: with it, the extension arrives from the Admin console already
force-installed, and there is nothing else to configure on the box.

So step 7 now asks for an enrolment token instead. The Windows script elevates
itself for it - the token is machine-scoped, and that is the only UAC prompt in
the whole install.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-31 16:14:14 -05:00
Brandon LiandClaude Opus 5 b820168afa Configure Edge and Brave too, not just Chrome
They are Chromium: same CRX, same update manifest, same policy — only the
registry vendor key differs. The script now defaults to every one of the three
it finds installed, which is what the Linux counterpart already did.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-31 13:08:29 -05:00
Brandon LiandClaude Opus 5 b9da419ebc Install the extension from the update server during setup
Both installers ended by telling you to load the folder unpacked, which is the
one install that can never update itself. They now offer the policy install as
a last step instead, and only fall back to those instructions when it is
declined or fails.

Windows writes to the user's own policy hive rather than HKLM, so the step
needs no elevation and no separate admin shell; -Scope Machine is still there
for every-account installs. Linux gets the counterpart script — a managed
policy file under /etc, which is root-only because Chrome reads policy from
nowhere else on that platform.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-31 13:06:29 -05:00
Brandon LiandClaude Opus 5 97ee03d13b Drop the unused playwright dependency
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>
2026-08-30 18:15:18 -05:00
Brandon LiandClaude Opus 5 a0ef06d933 Find Python after installing it, like Git and Node
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>
2026-08-30 18:13:43 -05:00
Brandon LiandClaude Opus 5 4288d8c298 Auto-start both processes at logon and self-update from master
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>
2026-08-30 17:36:25 -05:00
Brandon LiandClaude Opus 5 7e7bd985c2 Name the master branch explicitly when cloning and pulling
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>
2026-08-30 17:04:04 -05:00
Brandon LiandClaude Opus 5 a718caeb08 Auto-install Git, Node and Python via winget
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>
2026-08-30 16:55:29 -05:00
Brandon LiandClaude Opus 5 8e64d8a34f Find Git and Node when they are installed but off PATH
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>
2026-08-30 16:50:58 -05:00
Brandon LiandClaude Opus 5 9bdd20f83a Add Windows setup script for new instances
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>
2026-08-30 16:16:06 -05:00