@withbuddi/buddi 0.1.0-pre.53 → 0.1.0-pre.54

package/node_modules/marked/man/marked.1

@@ -1,4 +1,4 @@
-.TH "MARKED" "1" "October 2026" "18.0.14"
+.TH "MARKED" "1" "October 2026" "18.1.0"
 .SH "NAME"
 \fBmarked\fR \- a javascript markdown parser
 .SH SYNOPSIS

package/node_modules/marked/package.json

@@ -2,7 +2,7 @@
   "name": "marked",
   "description": "A markdown parser built for speed",
   "author": "Christopher Jeffrey",
-  "version": "18.1.0",
+  "version": "18.1.1",
   "type": "module",
   "main": "./lib/marked.esm.js",
   "module": "./lib/marked.esm.js",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@withbuddi/buddi",
-  "version": "0.1.0-pre.53",
+  "version": "0.1.0-pre.54",
   "type": "module",
   "description": "Your personal agents, on your computer",
   "repository": {
@@ -17,7 +17,7 @@
     "buddi": "packages/install/dist/launcher.js"
   },
   "buddi": {
-    "notes": "### Added\n\n- Linux installs with one command and nothing from the host: `curl -fsSL https://withbuddi.com/install.sh | sh` (or `wget -qO-`) downloads `buddi-<version>-linux-<x64|arm64>.tar.gz` from the GitHub release (the Node buddi.app pins with npm beside it, the npm release, its embedded Postgres), checks its sha256, and installs it under `~/.local/share/buddi` with `buddi` in `~/.local/bin`, no sudo: a systemd user unit, lingering turned on when the system allows it (else the one sudo line), the dashboard link at the end. Running it again upgrades with a backup first and goes back if the new release does not start; updates from the dashboard or `buddi upgrade` go into `releases/` as in buddi.app; `buddi uninstall` removes the runtime, the releases, the command and the lingering too, keeping the last backup and its passphrase. An npm install in the same folder moves over with its data. The release workflow builds, smoke-installs and attaches both tarballs.\n- A desktop app for Linux, `buddi-desktop` (a .deb and an AppImage per architecture on the GitHub release; Tauri on WebKitGTK): the dashboard in its own window and a tray icon whose menu is buddi.app's (Open buddi, New Conversation, Settings…, Update to / Check for Updates…, Restart, Stop/Start, Lock, Start at Login, Advanced ▸ Open in Browser, Show Logs, Restart with the Previous Version…, Help, About, Uninstall buddi…, Quit), with New Conversation, Check for Updates and Lock on the launcher's right-click too, around the buddi `install.sh` installed, starting in the tray at login. It signs in with `buddi`'s link, shows \"Starting buddi…\" while the gateway restarts and comes back on the same page, gets a fresh link when the session expired, and shows the install line when `buddi` is missing. The microphone, notifications and the app's own calls are for the dashboard's exact origin only (another local port, such as a preview, opens in the browser); links leave for the browser on a click, http(s) only and rate-limited; downloads go to ~/Downloads. `install.sh` adds buddi to the app grid (the desktop app when it is installed, else the dashboard in the browser) and, with the desktop app installed, to autostart; `buddi uninstall` removes both.\n- `buddi doctor` says which Node runs buddi and which npm plugin installs use: the bundled runtime (buddi.app, the Linux install) or the machine's own.\n\n### Fixed\n\n- Settings → System and the owner menu say \"this computer\" instead of \"this Mac\" when buddi runs on Linux: \"Remove buddi from this computer?\", and the passphrase leaves \"buddi’s secret store\" rather than \"this Mac’s keychain\"."
+    "notes": "### Added\n\n- Windows (for testing, not public yet): `npm install -g @withbuddi/buddi` then `buddi` runs on Windows 10/11 x64, and on Windows on Arm with the x64 build of Node. The embedded Postgres runs there (initdb, start and a clean `pg_ctl` stop; a missing Visual C++ runtime is named with its download link), secrets live in the file vault, and the service is a Task Scheduler task of your own (no administrator), started at once and at every sign-in with no console window. The supervisor answers on a named pipe instead of a Unix socket; `buddi` and `buddi dashboard` open the link in your default browser; `buddi service logs` follows the logs with PowerShell; `buddi uninstall` removes the task and stops the supervisor and its database cleanly; `buddi upgrade` recognises npm's global tree on Windows. Not there yet on Windows: remote access through a Cloudflare tunnel, MCP programs run on this computer, skill bundle scripts, and Codex sign-ins handed to a plugin's native program (the image plugin). npm must sit beside node (Node's installer or zip, nvm-windows; Volta and Scoop shims are named, not used).\n- Windows setup (for testing, not public yet): `buddi-<version>-windows-x64-setup.exe`, one download that installs buddi for you with no administrator, no Node and no terminal, on Windows 10/11 x64 and Windows on Arm. It carries the Node buddi.app pins with npm beside it, the npm release with its embedded Postgres, and the Visual C++ runtime Postgres needs, copied beside the Postgres binaries (no redistributable to install). It lays buddi out as the Linux install does (`%LOCALAPPDATA%\\buddi\\node` and `releases\\current`, a junction), puts `buddi` on your PATH for Command Prompt and PowerShell (a `buddi.cmd`), adds buddi to the Start menu (it opens the dashboard with no console window), starts buddi and its sign-in task and opens the welcome page. Running a newer setup upgrades the same folder with a backup first, and puts everything back (files, links, command, state, the buddi that ran before) if anything fails or the new version does not start; an npm install serving the same data moves over, and the npm copy is removed only when no other buddi on the computer runs it. Run as administrator, the setup says to run it normally (Postgres refuses administrator rights). Updates from the dashboard and `buddi upgrade` go into `releases\\` as on Linux. Removing buddi in Settings → Apps runs `buddi uninstall` (one last backup with its passphrase kept in `buddi-backups`, then the task, the data and the secrets), and `buddi uninstall` removes the Apps entry too. The release workflow builds, smoke-installs and attaches the setup and the zip it is made from, with their sha256; unsigned for now.\n- Windows desktop app (for testing, not public yet): the Windows setup now carries buddi's window, the same app as on Linux on WebView2. The Start menu's buddi opens it on the dashboard instead of the browser; its tray icon (left click: the window; right click: the menu) has Check for Updates, the previous version, Restart, Stop/Start, Lock, Start at Login (a Run entry of its own, on at first start, changed and removed only when it is the one it wrote), About and Uninstall; the microphone is granted to the dashboard's own address only, notifications are Windows toasts, sign-in pages open in your default browser, and nothing it starts opens a console window. It talks to buddi's supervisor on its named pipe and believes only answers carrying that start's secret. A newer setup quits and restarts it; uninstalling removes it with its data. On Windows 10 without WebView2, the setup installs it.\n\n### Fixed\n\n- Reinstalling after removing buddi with \"Keep my data for a reinstall\" works: the Windows setup and the Linux install.sh used to refuse that data (no buddi left to back it up first) unless told to skip the backup. They now recognise data an uninstall kept (it leaves `kept-for-reinstall.json`; older ones are recognised by their shape), say plainly that no new backup is taken and where the last one is, leave the data folder as it is, and start buddi on it, on the dashboard with everything as it was. A data folder nothing kept still asks for the backup to be skipped explicitly. buddi.app on a Mac already started on kept data. On Windows the removal with \"Keep my data\" now finishes too: the setup's uninstaller used to stop at the kept data (program files missing), leaving buddi in Apps & Features and the desktop app on \"Removing buddi…\"; the app now ends on a page that says where the data and its last backup are kept.\n- On Windows, removing buddi no longer flashes a console window (\"ping -n 6 127.0.0.1\"): the copy of node the removal ran from is now really cleaned up (it stayed in TEMP), by a small script under wscript that tries every half second for up to a minute, with no window at all.\n- `buddi` (and the desktop app) no longer tries to restart a supervisor that is still starting: right after sign-in, while the service brought up its database and migrations, a `buddi` command found the lock held but no answer yet, took it for a dead service and failed with \"The running service could not be stopped to restart it\" (seen on Windows as an 18-second \"buddi needs attention\" in the desktop app after a restart). It now waits for that supervisor to answer, up to ninety seconds, and if it never does says so instead of starting another. The supervisor's lock also records the system's id for the boot it was taken in (`supervisor.boot` beside it; Windows' BootId, Linux's boot_id, macOS's boot session), so a lock left by a computer that restarted is stale at once even when Windows has given its pid to another program; a clock change never makes a live lock look stale.\n- In the desktop app (Linux, Windows): Settings → System no longer suggests installing the dashboard as an app from Edge; removing buddi lists the desktop app among what goes on Windows (and says how to remove the package on Linux); the app stops reconnecting once the removal is confirmed, says \"Removing buddi…\", then, once buddi is gone, keeps a last page with where the backup and its passphrase are until you close it, and never sets buddi up again under a removal started from a terminal. A silent uninstall from the setup's uninstaller writes what the removal said (where the backup is, its passphrase) into buddi-backups. On Windows its tray icon is the full-colour Blob, sharp at every display scale, grey while buddi starts or is stopped and with an amber dot when it needs attention; on Linux the glyph follows KDE's colour scheme as it changes.\n- On Windows, agents run commands on this computer (`host.exec`) in Windows PowerShell 5.1, with the same approvals as on macOS and Linux, no console window, and the command's whole process tree ended on a timeout, a stop or the output cap (and with the command, through a job object); before, the approval card was raised and the run then failed. Skill bundle scripts say they do not run on Windows yet and agents there are no longer told they can run them; `system.info` names Windows 11 by its build (\"Windows 11 Pro 24H2 (build 26100)\", not 10.0.26100) and says which shell host commands use. `artifacts.write` says plainly that Files is buddi's own storage, not the computer's desktop, and that the owner downloads Word or PDF there, so agents stop offering to convert with pandoc.\n- buddi names the browser you actually use instead of always saying Chrome: \"your Edge\" on Edge (also Brave, Opera, Vivaldi, Arc; \"your browser\" when it cannot tell), on Settings → Browser & apps, the chat's Use my … chip, the browser cards and notes, Missions and the Canvas. The extension tells buddi which browser it runs in when it connects (with the next Chrome Web Store update; an older extension or buddi simply leaves it out), and on Edge the store button reads \"Get the buddi extension (Chrome Web Store, works in Edge)\".\n\n…"
   },
   "files": [
     "packages",