no-mistakes(document): replace dangling build-notes pointers, correct engine download sizes

Author: anvanster

jetbrains/src/main/kotlin/ai/codegraph/jetbrains/indexing/IndexingStartupActivity.kt

@@ -38,7 +38,7 @@ class IndexingStartupActivity : ProjectActivity {
 
         val resolved = CodeGraphServerResolver.resolve(project.basePath, settings.serverPath)
         if (resolved == null) {
-            // Offered rather than done automatically: this is a ~30 MB download
+            // Offered rather than done automatically: this is a ~120 MB download
             // of a native binary that will run with the user's permissions, and
             // starting that unasked on project open is not a decision the
             // plugin should make for them.

jetbrains/src/main/kotlin/ai/codegraph/jetbrains/server/EngineDownloader.kt

@@ -19,10 +19,10 @@ import java.util.Locale
  *
  * The plugin does not bundle engines: the JetBrains Marketplace serves one
  * artifact to every platform, so bundling every published engine would mean a
- * download several times the size of the one a given user can run. The
- * alternative for users without Node is worse - install a 498 MB npm package
- * for one binary - so the engine is fetched directly from the release that
- * `scripts/publish-release-assets.sh` produces.
+ * download several times the size of the one a given user can run. Sending
+ * users to the npm package instead is not an answer either: it needs Node, and
+ * it fetches the same engine from the same release. So the engine is fetched
+ * directly from the release that `scripts/publish-release-assets.sh` produces.
  *
  * Downloads are verified against the checksum published beside each asset. An
  * engine is a native binary that runs with the user's permissions; TLS says

scripts/publish-release-assets.sh

@@ -5,17 +5,19 @@
 # Publish the per-platform engine binaries as GitHub release assets.
 #
 # No channel bundles engines any more. Shipping all four platform binaries meant
-# a 118 MB VSIX and a 498 MB npm package for the ~30 MB a given user can
+# a 118 MB VSIX and a 498 MB npm package for the one binary a given user can
 # actually run, and the JetBrains Marketplace cannot ship per-platform artifacts
 # at all. The binaries are published here once, and each client fetches only
 # what it needs - which makes this release the single source of engines, so a
 # missing or mistagged one leaves every channel with no engine at all.
 #
 # This does not build anything. It uploads what ./scripts/package-*.sh already
-# expect to find in vscode/bin/, so it slots in after the existing
-# cross-platform build (see cross-platform-builds.md). The one exception is
-# linux-arm64, which has no build host of its own: ./scripts/build-linux-arm64.sh
-# builds it in a container and stages and stamps it into vscode/bin/ itself.
+# expect to find in vscode/bin/, so it slots in after the existing cross-platform
+# build. Each platform is built natively on its own host; those hosts are
+# internal machines, so they are recorded in the maintainer's private build notes
+# rather than here. The one exception is linux-arm64, which has no build host of
+# its own: ./scripts/build-linux-arm64.sh builds it in a container and stages and
+# stamps it into vscode/bin/ itself.
 #
 # Usage:
 #   ./scripts/publish-release-assets.sh              # stage + verify only
@@ -196,8 +198,8 @@ ERROR: not every platform artifact is present in vscode/bin/.
 
 A partial release is worse than none: a client that resolves its own platform
 and finds nothing has no way to tell "not built yet" from "never supported".
-Build the missing platforms first - see cross-platform-builds.md for the
-per-platform hosts - then re-run.
+Build the missing platforms first, each on its own build host - except
+linux-arm64, which ./scripts/build-linux-arm64.sh builds here - then re-run.
 EOF
   exit 1
 fi
@@ -254,8 +256,8 @@ if [ "$commit_mismatch" -ne 0 ]; then
 
 Everything in one release has to come from one tree, or the tag names a build
 that never existed as a whole. Rebuild the assets that disagree from the commit
-being released - see cross-platform-builds.md for the per-platform hosts - and
-re-stamp them with ./scripts/stamp-binary.sh.
+being released, each on its own build host, and re-stamp them with
+./scripts/stamp-binary.sh.
 EOF
   } >&2
   exit 1

vscode/src/engineDownload.ts

@@ -107,7 +107,7 @@ export async function downloadEngine(
  * built against a newer engine keeps talking to the old one.
  *
  * Offered rather than done, for the same reason `downloadEngine` is: this is
- * ~30 MB of native binary that will run with the user's permissions. It is also
+ * ~120 MB of native binary that will run with the user's permissions. It is also
  * deliberately not awaited by the caller - the engine on disk still works, so
  * blocking activation behind a transfer would cost every surface the extension
  * provides for an update that is not urgent.

vscode/src/extension.ts

@@ -330,7 +330,7 @@ export async function activate(context: vscode.ExtensionContext): Promise<void>
     //
     // Not awaited: the engine on disk still runs, and holding activation - and
     // with it the language client, the tree views and the lenses - behind a
-    // 30 MB transfer on a slow network is a far worse trade than one release of
+    // ~120 MB transfer on a slow network is a far worse trade than one release of
     // drift. The lifecycle callbacks read `client` lazily for the same reason:
     // by the time the user answers the prompt it has been created and started.
     if (serverInfo.path === managedEnginePath()) {