@withbuddi/buddi 0.1.0-pre.40 → 0.1.0-pre.42

package/node_modules/libmime/package.json

@@ -1,7 +1,7 @@
 {
     "name": "libmime",
     "description": "Encode and decode quoted printable and base64 strings",
-    "version": "5.4.6",
+    "version": "5.4.7",
     "main": "lib/libmime.js",
     "files": [
         "lib",
@@ -26,7 +26,7 @@
     "dependencies": {
         "encoding-japanese": "2.4.0",
         "iconv-lite": "0.7.3",
-        "libbase64": "1.3.1",
+        "libbase64": "1.3.2",
         "libqp": "2.1.2"
     },
     "devDependencies": {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@withbuddi/buddi",
-  "version": "0.1.0-pre.40",
+  "version": "0.1.0-pre.42",
   "type": "module",
   "description": "Your personal agents, on your computer",
   "repository": {
@@ -17,7 +17,7 @@
     "buddi": "packages/install/dist/launcher.js"
   },
   "buddi": {
-    "notes": "- buddi.app for Mac: the DMG downloads from the GitHub release (withbuddi.com/download/mac and the update feed point there), so a release larger than 300 MiB still publishes.\n- First run: accepting the agent a plugin proposes no longer blocks meeting your assistant. Your assistant becomes the default agent and mentions the teammates already there when it introduces itself; if you really do have an assistant already, the chapter says so with a link to Agents instead of a button that does nothing, while a taken name or an unusable model account stays a message you can fix and retry. Restoring a backup from the first-run screen still asks you to confirm once any agent of yours is here, an accepted teammate included, and changing your assistant from first run edits the assistant rather than a teammate you made the default."
+    "notes": "- buddi.app: the Dock icon and the menu-bar glyph are the Blob now, not a \"b\". The menu-bar Blob is dimmed while buddi starts or updates and carries a dot when it needs attention.\n- Pairing Chrome no longer goes stale half a minute in. Chrome put the extension to sleep while it waited for you to type its code, so the popup kept showing a code buddi was no longer waiting for (\"No browser is waiting to be paired\"). buddi now keeps the waiting extension awake, the extension keeps itself awake too, and the popup picks up a fresh code if the old one went.\n- Settings → Your Chrome always offers \"Enter the code\" until Chrome is paired: open the buddi icon in Chrome and type its six digits here, which is how you pair from the buddi.app window. Typing the code just as the page paired this Chrome by itself no longer shows an error. \"Install unpacked…\" shows only when buddi runs from a source checkout.\n- buddi's log has one line for every connection the Chrome extension makes: accepted or refused and why, waiting for its code, paired, or reconnected. Never the code or the token.\n- Settings → Where agents may look is now called **Browser & apps** in the sidebar and at the top of the page, with \"Where agents may look\" underneath. The extension popup, first run and the docs use the new name; old links still land there.\n- buddi.app answers `buddi://` links: `buddi://open` brings the window forward, `buddi://settings/<page>` opens that Settings page, and `buddi://settings/browser?code=123456` opens Browser & apps with the Chrome pairing code already typed in (you still press Pair). Any other link is ignored. The extension's **Open buddi settings** opens buddi.app this way on a Mac and falls back to the dashboard in a tab when the app doesn't answer; if that tab finds you signed out, it offers **Open buddi.app** first (on a Mac, for the buddi on the usual address; never on Linux or Windows) and shows the Terminal command only when the app didn't open, including after Cancel on Chrome's \"Open buddi.app?\" question (the popup says to allow it). The code travels only after the `#` in the address, never to the server, and leaves the address once Pair worked, so a reload or a restart of buddi.app doesn't type a used code in again. A link that arrives while the window is still loading is no longer lost, and a link with more than 8 parameters is ignored.\n- First run, linking your calendar: Sign in with Google opens Google's page on the first press (in buddi.app, in your default browser), instead of turning into \"Continue to Google\" and needing a second one. Its button carries an arrow out, not the \"unavailable\" circle. Opening the sheet no longer cancels a Google sign-in already waiting (it uses that one), leaving it never leaves a prepared sign-in behind, and a tab that sat in the background prepares a fresh one when you come back.\n- `buddi uninstall` with buddi stopped no longer refuses to take the last backup: it starts only the database for the backup (buddi itself stays stopped), then stops it again before removing anything — also when run through buddi.app's `buddi` command, and a Ctrl-C or a crash during that backup no longer leaves the database running (it stops within seconds, and after 30 minutes at most). A stray `BUDDI_SUPERVISE_BRIEFLY` in an env file can't keep the normal service from starting buddi. The Telegram bot's command menu is cleared before your secrets go, and even when the paired chats can't be read. While buddi.app is running the installation, uninstall says so and points you to buddi → Uninstall buddi… in the app (or quitting the app first); with the app quit, it ends by telling you to move buddi.app to the Trash.\n- Lock screen: a widget that couldn't refresh still shows its last good answer, but its title now says when that was (\"Top stories · from 9:12\", or \"from yesterday 9:12\" and \"from Mon 9:12\" when it wasn't today), so yesterday's headlines no longer pass for now. A widget that answers a little after its 5 seconds is kept for the next look instead of thrown away (never over a newer answer), and each widget that fails or times out leaves one line in buddi's log (which widget, how long it took)."
   },
   "files": [
     "packages",