synartesis 0.6.0 → 0.6.2

package/CHANGELOG.md

@@ -2,6 +2,57 @@
 
 What changed, and why it mattered. Dates are release dates.
 
+## 0.6.2 — 2026-09-12
+
+### Fixed
+
+- **The application could not be built on Windows or Linux at all**, which the
+  first release build found out the hard way. On Windows, pnpm compiles
+  better-sqlite3 from source -- ignoring the `gypfile: false` that tells npm
+  not to bother -- and a runner whose Visual Studio is newer than node-gyp
+  knows about simply fails. It never needed compiling: the package ships a
+  prebuilt binary for every platform it supports, and its loader prefers one
+  over anything built locally, so what node-gyp produced here was never
+  loaded. On Linux, dpkg refuses to build a `.deb` without a maintainer, and
+  nothing named one.
+
+- **The release workflow can be rehearsed.** Run with the tag box empty, it
+  builds the branch on all three platforms and publishes nothing. Finding out
+  whether a build works should not cost a version number each time.
+
+## 0.6.1 — 2026-09-12
+
+### Added
+
+- **A `release` workflow** builds the application on macOS, Windows and Linux --
+  each on its own machine, since an installer cannot honestly be built anywhere
+  else -- and attaches the `.dmg`, `.exe`, AppImage and `.deb` to the release
+  for a `v*` tag. It signs and notarises where the secrets exist and produces
+  unsigned builds where they do not, so a fork of this repository can still
+  build it.
+
+### Fixed
+
+- **The packaging script could not have run on Windows.** It started
+  electron-builder through the shim in `node_modules/.bin`, which is a `.cmd`
+  there and something node will not spawn without a shell. It runs the
+  builder's own entry file instead -- the same file on every platform -- and
+  the check that refuses a stale bundle now knows where Windows and Linux keep
+  the archive as well as where macOS does.
+
+- **An empty secret is not a certificate.** A CI job passes every secret it was
+  told about whether the repository holds one or not, so a build with no
+  signing certificate was handed `CSC_LINK=""`. electron-builder reads
+  "defined" as "use it": it took the empty string for the path to a
+  certificate, resolved it against the project directory, and stopped with
+  "`<repo>/app not a file`" -- a message with no visible relationship to its
+  cause. Blank credentials are dropped before the builder starts, so a build
+  without a certificate is simply unsigned.
+
+- **A `.DS_Store` could make a current bundle look stale.** Finder leaves one in
+  any directory somebody has looked at, and the staleness check was counting it
+  as input to the bundle even though nothing packs it.
+
 ## 0.6.0 — 2026-09-12
 
 ### Added

package/README.md

@@ -110,8 +110,25 @@ the journal or a log. There is a parchment and a dark setting:
 **Getting it.** `synartesis desktop` opens it, and says where to get it if it is
 not installed. It is a separate download on purpose: shipping a browser engine
 inside a CLI would put 200 MB into every install of a command that is a few
-hundred kilobytes. Until there is a signed build to download, it is built from a
-clone:
+hundred kilobytes.
+
+On macOS it installs the way anything does — open the `.dmg`, drag Synartesis to
+Applications — and on Windows the `.exe` installer puts it where the Start menu
+can find it. After that, either the icon or `synartesis desktop` opens it; the
+command looks where each platform actually installs things rather than asking
+you to remember a path.
+
+**The builds are not signed yet, and the first launch says so.** macOS refuses
+an application it cannot check with Apple: open System Settings → Privacy &
+Security and press *Open Anyway*, or `xattr -dr com.apple.quarantine
+/Applications/Synartesis.app` to say the same thing in one line. Windows shows
+a SmartScreen warning, behind *More info*. Both of those are the operating
+system telling you the truth — nobody has vouched for this binary — and the
+honest fix is a Developer ID certificate rather than a page telling you to
+click past it. Building from the clone below avoids the question entirely,
+since an application you built is one you have already vouched for.
+
+To build it yourself instead:
 
 ```bash
 pnpm install && pnpm app:dist
@@ -121,8 +138,9 @@ That writes an installer for the machine it runs on to `app/release` — a `.dmg
 and a `.app` on macOS, an `.exe` on Windows, an AppImage and a `.deb` on Linux.
 It is unsigned, so it runs where it was built and Gatekeeper refuses it
 anywhere it has been downloaded to: signing and notarisation need an Apple
-developer account, and [`app/README.md`](app/README.md) lists the two
-environment variables that turn them on. Both the window and the terminal share
+developer account, and [`app/README.md`](app/README.md) lists exactly what they
+want. The `release` workflow builds all three platforms on their own machines
+and attaches the installers to the release for a tag. Both the window and the terminal share
 one journal, so either can undo what the other did.
 
 ## What it can and cannot do

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "synartesis",
-  "version": "0.6.0",
+  "version": "0.6.2",
   "description": "An undo layer for AI agents.",
   "type": "module",
   "private": false,
@@ -66,6 +66,12 @@
     "yaml": "^2.9.0",
     "zod": "^4.4.3"
   },
+  "//pnpm": "better-sqlite3 ships a prebuilt binary for every platform it supports, and its loader prefers one over anything compiled locally -- so what node-gyp builds here is never loaded. npm knows not to bother, because the package sets gypfile: false; pnpm builds it anyway, which needs a C toolchain on every machine that installs this and fails outright on a Windows runner whose Visual Studio is newer than node-gyp.",
+  "pnpm": {
+    "neverBuiltDependencies": [
+      "better-sqlite3"
+    ]
+  },
   "devDependencies": {
     "@anthropic-ai/sdk": "^0.125.0",
     "@electron/notarize": "^3.1.1",