fix(coil): restore the release, and make two of its checks capable of failing by radroid · Pull Request #97 · radroid/t3code

radroid · 2026-08-12T16:49:44Z

Releases have been red since #53 landed. Build 106 was the last one published — every run after it failed before publishing anything, so #95 and #96 have not shipped to any user.

Three defects, all in the new bundle-size checks.

1. The exclusions CLI wrote nothing on Windows

All three new scripts guarded their CLI entry point with:

if(import.meta.url===`file://${process.argv[1]}`){

That is false on Windows. process.argv[1] is a native path there, so the template builds file://D:\a\... while import.meta.url is file:///D:/a/... — drive letter after three slashes, forward separators. Verified:

win builds: file://D:\a\t3code\t3code\scripts\coil\desktop-file-exclusions.mjs
win actual: file:///D:/a/t3code/t3code/scripts/coil/desktop-file-exclusions.mjs

It works on macOS and Linux only because an absolute POSIX path already begins with /, which is why it passed review and passed on one runner. So node desktop-file-exclusions.mjs parsed, ran nothing, wrote nothing, exited 0 — and the release step correctly refused an empty list.

The same guard is in verify-desktop-bundle.mjs, which the release invokes as a CLI. On Windows that verification would have exited 0 without running, even after the rest of this was fixed. All three now use pathToFileURL.

2. `app.asar` was never under `release/`

Both checks searched release/. The build copies only files out of its staging dir — if (!stat || stat.type !== "File") continue in build-desktop-artifact.ts — and the macOS .app and Windows win-unpacked/ are directories, so the trees holding app.asar are never copied there.

Worse, the staging dir was a scoped temp dir, deleted the moment the build process exits. There was nothing to find anywhere on disk.

T3CODE_DESKTOP_KEEP_STAGE (which Config.boolean accepts as "1") keeps it; one new step resolves it through os.tmpdir() rather than assuming /tmp or %TEMP%, folding backslashes so git-bash's find can take it; a cleanup step drops it again before the upload.

3. The `app-update.yml` guard had never been able to fail

Same wrong directory, opposite outcome. It searched release/ for a file that only exists inside the .app, found nothing, printed "No app-update.yml packaged", and passed — every run, unconditionally.

It was never checking the claim it is the only evidence for: that this fork's toast is the sole update surface and upstream's electron-updater is off. A check that fails loudly costs one red build; a check that cannot fail costs nothing until the day it was supposed to catch something.

Tests

Cover the shape that broke rather than the line: invoked as a CLI, these scripts must actually do something. One asserts non-empty stdout, one asserts a no-argument verify run does not exit 0.

They cannot run on Windows here — this fork has no Windows CI runner — so that platform's correctness rests on pathToFileURL being the right primitive, not on a green check. That asymmetry is the same one that let this ship, and it is stated in the test file rather than left implicit.

Verification

locate/cleanup logic exercised locally against a simulated two-stage tree, including a path with spaces; picks the newest stage
YAML parses; Config.boolean confirmed to accept "1" from Effect's TrueValues
new CLI tests pass; the rest of desktop-bundle-size.test.ts unchanged and passing

The real proof is the release run on merge, which is the one thing that cannot be tested beforehand.

🤖 Generated with Claude Code

coderabbitai · 2026-08-12T16:49:53Z

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 81df0dd3-4baf-4d3c-a0dc-f5f23385fd03

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

🔍 Trigger review

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

… failing Releases have been red since #53 landed. Build 106 was the last one published; every run after it failed before publishing anything. Three defects, all in the new bundle-size checks, and the third is the one worth reading twice. 1. The exclusions CLI wrote nothing on Windows. All three scripts guarded their CLI entry point with `import.meta.url === \`file://${process.argv[1]}\``. That is false on Windows, where argv[1] is a native path: the template builds `file://D:\a\...` while `import.meta.url` is `file:///D:/a/...`. It works on macOS and Linux only because an absolute POSIX path already begins with `/`, which is why it passed review and passed on one runner. So `node desktop-file-exclusions.mjs` parsed, ran nothing, wrote nothing and exited 0, and the release step correctly refused an empty exclusion list. The same guard is in verify-desktop-bundle.mjs, which the release invokes as a CLI — so on Windows that verification would have exited 0 without running even once the rest of this was fixed. Fixed with `pathToFileURL`, which is what Node provides for this conversion. 2. app.asar was never under release/. Both checks searched `release/`. The build copies only FILES out of its staging dir — `if (!stat || stat.type !== "File") continue` — and the macOS `.app` and Windows `win-unpacked/` are directories, so the trees holding app.asar are never copied there. The staging dir was also a SCOPED temp dir, deleted when the build exits, so there was nothing to find anywhere. T3CODE_DESKTOP_KEEP_STAGE keeps it, one new step resolves it through `os.tmpdir()` rather than assuming /tmp or %TEMP%, and a cleanup step drops it again before the upload. 3. The app-update.yml guard had never been able to fail. Same wrong directory, opposite outcome. It searched release/ for a file that only exists inside the .app, found nothing, printed "No app-update.yml packaged", and passed — every run, unconditionally. It was never checking the claim it is the only evidence for: that this fork's toast is the sole update surface and upstream's electron-updater is off. A check that fails loudly costs one red build. A check that cannot fail costs nothing until the day it was supposed to catch something. Tests cover the shape that broke rather than the line: invoked as a CLI, these scripts must actually do something. They cannot run on Windows here — this fork has no Windows CI runner — so that platform's correctness rests on pathToFileURL being the right primitive, not on a green check. That asymmetry is the same one that let this ship. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…annot see (#102) (#106) Upstream's Windows server.asar split (this sync) broke the release's bundle-verify gate both ways at once: the server graph silently stopped being scanned, and node-pty — mentioned only inside main.cjs's embedded WSL heredoc scripts, loadable from the sidecar where it genuinely lives — was reported unresolvable, failing a shippable build (release run 31837711136, publish skipped). The view now merges a sibling resources/server.asar (+ .unpacked) into the packaged-file map, so sidecar bundles are scanned again and sidecar packages resolve. And every FIRST_PARTY_BUNDLE_DIRS entry must contribute at least one scanned bundle — a packaging-topology change that hides a layer is now an error instead of an empty green result, which is the 'guard that cannot fail' shape #97 already taught us once. Also corrects the three comments still teaching the disproven GITHUB_REPOSITORY="" mechanism (main.ts, UpdateToast.tsx) and the workflow step's stale Windows-topology claim. Fixes#102. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

…lly disabled The check restored in #97 failed on its first real run, on both platforms, and it was right to. `app-update.yml` is in the bundle: .../T3 Coil (Alpha).app/Contents/Resources/app-update.yml .../win-unpacked/resources/app-update.yml It is in the installed build too — 0.0.33-coil.105 on disk carries `owner: radroid / repo: t3code / provider: github / releaseType: release`. So has every build before it. This is not a regression #97 introduced; it is what the old check could not see. WHY IT WAS NEVER DISABLED. The workflow set `GITHUB_REPOSITORY: ""` and its comment claimed that made `resolveGitHubPublishConfig` return undefined. Actions refuses to let a workflow set any `GITHUB_`-prefixed variable, so the line is inert. The build read the runner's real `radroid/t3code`, resolved a publish config, and electron-builder wrote the feed. The shipped file proves the path taken: those owner/repo values cannot come from any other branch of that function. `T3CODE_DESKTOP_UPDATE_REPOSITORY` is the fork's own hook, is read FIRST, and is not reserved. Set to `disabled` it short-circuits `GITHUB_REPOSITORY` before that is read, fails the `owner/repo` split, and returns undefined — the no-publish path. No publish config, no `app-update.yml`, `hasUpdateFeedConfig` false, and upstream's electron-updater switches itself off. Which is what the empty string was always meant to do. WHY THIS WAS URGENT RATHER THAN MERELY WRONG. `releaseType: release` kept the second updater inert by accident: every fork release was a GitHub prerelease, so it could never find anything to install. #96 has just made releases full releases with a real Latest pointer. The next successful publish would have been the first thing that dormant updater could see, in every installed build. Tests pin both directions — that the hook produces no config, and that GITHUB_REPOSITORY alone still produces one, so nobody later reads the hook as redundant. They live in the fork's test file; the function is exported, so this costs no seam row. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…annot see (#102) (#106) Upstream's Windows server.asar split (this sync) broke the release's bundle-verify gate both ways at once: the server graph silently stopped being scanned, and node-pty — mentioned only inside main.cjs's embedded WSL heredoc scripts, loadable from the sidecar where it genuinely lives — was reported unresolvable, failing a shippable build (release run 31837711136, publish skipped). The view now merges a sibling resources/server.asar (+ .unpacked) into the packaged-file map, so sidecar bundles are scanned again and sidecar packages resolve. And every FIRST_PARTY_BUNDLE_DIRS entry must contribute at least one scanned bundle — a packaging-topology change that hides a layer is now an error instead of an empty green result, which is the 'guard that cannot fail' shape #97 already taught us once. Also corrects the three comments still teaching the disproven GITHUB_REPOSITORY="" mechanism (main.ts, UpdateToast.tsx) and the workflow step's stale Windows-topology claim. Fixes#102. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

…lly disabled The check restored in #97 failed on its first real run, on both platforms, and it was right to. `app-update.yml` is in the bundle: .../T3 Coil (Alpha).app/Contents/Resources/app-update.yml .../win-unpacked/resources/app-update.yml It is in the installed build too — 0.0.33-coil.105 on disk carries `owner: radroid / repo: t3code / provider: github / releaseType: release`. So has every build before it. This is not a regression #97 introduced; it is what the old check could not see. WHY IT WAS NEVER DISABLED. The workflow set `GITHUB_REPOSITORY: ""` and its comment claimed that made `resolveGitHubPublishConfig` return undefined. Actions refuses to let a workflow set any `GITHUB_`-prefixed variable, so the line is inert. The build read the runner's real `radroid/t3code`, resolved a publish config, and electron-builder wrote the feed. The shipped file proves the path taken: those owner/repo values cannot come from any other branch of that function. `T3CODE_DESKTOP_UPDATE_REPOSITORY` is the fork's own hook, is read FIRST, and is not reserved. Set to `disabled` it short-circuits `GITHUB_REPOSITORY` before that is read, fails the `owner/repo` split, and returns undefined — the no-publish path. No publish config, no `app-update.yml`, `hasUpdateFeedConfig` false, and upstream's electron-updater switches itself off. Which is what the empty string was always meant to do. WHY THIS WAS URGENT RATHER THAN MERELY WRONG. `releaseType: release` kept the second updater inert by accident: every fork release was a GitHub prerelease, so it could never find anything to install. #96 has just made releases full releases with a real Latest pointer. The next successful publish would have been the first thing that dormant updater could see, in every installed build. Tests pin both directions — that the hook produces no config, and that GITHUB_REPOSITORY alone still produces one, so nobody later reads the hook as redundant. They live in the fork's test file; the function is exported, so this costs no seam row. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…annot see (#102) (#106) Upstream's Windows server.asar split (this sync) broke the release's bundle-verify gate both ways at once: the server graph silently stopped being scanned, and node-pty — mentioned only inside main.cjs's embedded WSL heredoc scripts, loadable from the sidecar where it genuinely lives — was reported unresolvable, failing a shippable build (release run 31837711136, publish skipped). The view now merges a sibling resources/server.asar (+ .unpacked) into the packaged-file map, so sidecar bundles are scanned again and sidecar packages resolve. And every FIRST_PARTY_BUNDLE_DIRS entry must contribute at least one scanned bundle — a packaging-topology change that hides a layer is now an error instead of an empty green result, which is the 'guard that cannot fail' shape #97 already taught us once. Also corrects the three comments still teaching the disproven GITHUB_REPOSITORY="" mechanism (main.ts, UpdateToast.tsx) and the workflow step's stale Windows-topology claim. Fixes#102. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

radroid · 2026-08-12T16:49:44Z

Releases have been red since #53 landed. Build 106 was the last one published — every run after it failed before publishing anything, so #95 and #96 have not shipped to any user.

Three defects, all in the new bundle-size checks.

1. The exclusions CLI wrote nothing on Windows

All three new scripts guarded their CLI entry point with:

if(import.meta.url===`file://${process.argv[1]}`){

That is false on Windows. process.argv[1] is a native path there, so the template builds file://D:\a\... while import.meta.url is file:///D:/a/... — drive letter after three slashes, forward separators. Verified:

win builds: file://D:\a\t3code\t3code\scripts\coil\desktop-file-exclusions.mjs
win actual: file:///D:/a/t3code/t3code/scripts/coil/desktop-file-exclusions.mjs

It works on macOS and Linux only because an absolute POSIX path already begins with /, which is why it passed review and passed on one runner. So node desktop-file-exclusions.mjs parsed, ran nothing, wrote nothing, exited 0 — and the release step correctly refused an empty list.

The same guard is in verify-desktop-bundle.mjs, which the release invokes as a CLI. On Windows that verification would have exited 0 without running, even after the rest of this was fixed. All three now use pathToFileURL.

2. `app.asar` was never under `release/`

Both checks searched release/. The build copies only files out of its staging dir — if (!stat || stat.type !== "File") continue in build-desktop-artifact.ts — and the macOS .app and Windows win-unpacked/ are directories, so the trees holding app.asar are never copied there.

Worse, the staging dir was a scoped temp dir, deleted the moment the build process exits. There was nothing to find anywhere on disk.

T3CODE_DESKTOP_KEEP_STAGE (which Config.boolean accepts as "1") keeps it; one new step resolves it through os.tmpdir() rather than assuming /tmp or %TEMP%, folding backslashes so git-bash's find can take it; a cleanup step drops it again before the upload.

3. The `app-update.yml` guard had never been able to fail

Same wrong directory, opposite outcome. It searched release/ for a file that only exists inside the .app, found nothing, printed "No app-update.yml packaged", and passed — every run, unconditionally.

It was never checking the claim it is the only evidence for: that this fork's toast is the sole update surface and upstream's electron-updater is off. A check that fails loudly costs one red build; a check that cannot fail costs nothing until the day it was supposed to catch something.

Tests

Cover the shape that broke rather than the line: invoked as a CLI, these scripts must actually do something. One asserts non-empty stdout, one asserts a no-argument verify run does not exit 0.

They cannot run on Windows here — this fork has no Windows CI runner — so that platform's correctness rests on pathToFileURL being the right primitive, not on a green check. That asymmetry is the same one that let this ship, and it is stated in the test file rather than left implicit.

Verification

locate/cleanup logic exercised locally against a simulated two-stage tree, including a path with spaces; picks the newest stage
YAML parses; Config.boolean confirmed to accept "1" from Effect's TrueValues
new CLI tests pass; the rest of desktop-bundle-size.test.ts unchanged and passing

The real proof is the release run on merge, which is the one thing that cannot be tested beforehand.

🤖 Generated with Claude Code

coderabbitai · 2026-08-12T16:49:53Z

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 81df0dd3-4baf-4d3c-a0dc-f5f23385fd03

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

🔍 Trigger review

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

… failing Releases have been red since #53 landed. Build 106 was the last one published; every run after it failed before publishing anything. Three defects, all in the new bundle-size checks, and the third is the one worth reading twice. 1. The exclusions CLI wrote nothing on Windows. All three scripts guarded their CLI entry point with `import.meta.url === \`file://${process.argv[1]}\``. That is false on Windows, where argv[1] is a native path: the template builds `file://D:\a\...` while `import.meta.url` is `file:///D:/a/...`. It works on macOS and Linux only because an absolute POSIX path already begins with `/`, which is why it passed review and passed on one runner. So `node desktop-file-exclusions.mjs` parsed, ran nothing, wrote nothing and exited 0, and the release step correctly refused an empty exclusion list. The same guard is in verify-desktop-bundle.mjs, which the release invokes as a CLI — so on Windows that verification would have exited 0 without running even once the rest of this was fixed. Fixed with `pathToFileURL`, which is what Node provides for this conversion. 2. app.asar was never under release/. Both checks searched `release/`. The build copies only FILES out of its staging dir — `if (!stat || stat.type !== "File") continue` — and the macOS `.app` and Windows `win-unpacked/` are directories, so the trees holding app.asar are never copied there. The staging dir was also a SCOPED temp dir, deleted when the build exits, so there was nothing to find anywhere. T3CODE_DESKTOP_KEEP_STAGE keeps it, one new step resolves it through `os.tmpdir()` rather than assuming /tmp or %TEMP%, and a cleanup step drops it again before the upload. 3. The app-update.yml guard had never been able to fail. Same wrong directory, opposite outcome. It searched release/ for a file that only exists inside the .app, found nothing, printed "No app-update.yml packaged", and passed — every run, unconditionally. It was never checking the claim it is the only evidence for: that this fork's toast is the sole update surface and upstream's electron-updater is off. A check that fails loudly costs one red build. A check that cannot fail costs nothing until the day it was supposed to catch something. Tests cover the shape that broke rather than the line: invoked as a CLI, these scripts must actually do something. They cannot run on Windows here — this fork has no Windows CI runner — so that platform's correctness rests on pathToFileURL being the right primitive, not on a green check. That asymmetry is the same one that let this ship. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…annot see (#102) (#106) Upstream's Windows server.asar split (this sync) broke the release's bundle-verify gate both ways at once: the server graph silently stopped being scanned, and node-pty — mentioned only inside main.cjs's embedded WSL heredoc scripts, loadable from the sidecar where it genuinely lives — was reported unresolvable, failing a shippable build (release run 31837711136, publish skipped). The view now merges a sibling resources/server.asar (+ .unpacked) into the packaged-file map, so sidecar bundles are scanned again and sidecar packages resolve. And every FIRST_PARTY_BUNDLE_DIRS entry must contribute at least one scanned bundle — a packaging-topology change that hides a layer is now an error instead of an empty green result, which is the 'guard that cannot fail' shape #97 already taught us once. Also corrects the three comments still teaching the disproven GITHUB_REPOSITORY="" mechanism (main.ts, UpdateToast.tsx) and the workflow step's stale Windows-topology claim. Fixes#102. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

…lly disabled The check restored in #97 failed on its first real run, on both platforms, and it was right to. `app-update.yml` is in the bundle: .../T3 Coil (Alpha).app/Contents/Resources/app-update.yml .../win-unpacked/resources/app-update.yml It is in the installed build too — 0.0.33-coil.105 on disk carries `owner: radroid / repo: t3code / provider: github / releaseType: release`. So has every build before it. This is not a regression #97 introduced; it is what the old check could not see. WHY IT WAS NEVER DISABLED. The workflow set `GITHUB_REPOSITORY: ""` and its comment claimed that made `resolveGitHubPublishConfig` return undefined. Actions refuses to let a workflow set any `GITHUB_`-prefixed variable, so the line is inert. The build read the runner's real `radroid/t3code`, resolved a publish config, and electron-builder wrote the feed. The shipped file proves the path taken: those owner/repo values cannot come from any other branch of that function. `T3CODE_DESKTOP_UPDATE_REPOSITORY` is the fork's own hook, is read FIRST, and is not reserved. Set to `disabled` it short-circuits `GITHUB_REPOSITORY` before that is read, fails the `owner/repo` split, and returns undefined — the no-publish path. No publish config, no `app-update.yml`, `hasUpdateFeedConfig` false, and upstream's electron-updater switches itself off. Which is what the empty string was always meant to do. WHY THIS WAS URGENT RATHER THAN MERELY WRONG. `releaseType: release` kept the second updater inert by accident: every fork release was a GitHub prerelease, so it could never find anything to install. #96 has just made releases full releases with a real Latest pointer. The next successful publish would have been the first thing that dormant updater could see, in every installed build. Tests pin both directions — that the hook produces no config, and that GITHUB_REPOSITORY alone still produces one, so nobody later reads the hook as redundant. They live in the fork's test file; the function is exported, so this costs no seam row. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…annot see (#102) (#106) Upstream's Windows server.asar split (this sync) broke the release's bundle-verify gate both ways at once: the server graph silently stopped being scanned, and node-pty — mentioned only inside main.cjs's embedded WSL heredoc scripts, loadable from the sidecar where it genuinely lives — was reported unresolvable, failing a shippable build (release run 31837711136, publish skipped). The view now merges a sibling resources/server.asar (+ .unpacked) into the packaged-file map, so sidecar bundles are scanned again and sidecar packages resolve. And every FIRST_PARTY_BUNDLE_DIRS entry must contribute at least one scanned bundle — a packaging-topology change that hides a layer is now an error instead of an empty green result, which is the 'guard that cannot fail' shape #97 already taught us once. Also corrects the three comments still teaching the disproven GITHUB_REPOSITORY="" mechanism (main.ts, UpdateToast.tsx) and the workflow step's stale Windows-topology claim. Fixes#102. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

…lly disabled The check restored in #97 failed on its first real run, on both platforms, and it was right to. `app-update.yml` is in the bundle: .../T3 Coil (Alpha).app/Contents/Resources/app-update.yml .../win-unpacked/resources/app-update.yml It is in the installed build too — 0.0.33-coil.105 on disk carries `owner: radroid / repo: t3code / provider: github / releaseType: release`. So has every build before it. This is not a regression #97 introduced; it is what the old check could not see. WHY IT WAS NEVER DISABLED. The workflow set `GITHUB_REPOSITORY: ""` and its comment claimed that made `resolveGitHubPublishConfig` return undefined. Actions refuses to let a workflow set any `GITHUB_`-prefixed variable, so the line is inert. The build read the runner's real `radroid/t3code`, resolved a publish config, and electron-builder wrote the feed. The shipped file proves the path taken: those owner/repo values cannot come from any other branch of that function. `T3CODE_DESKTOP_UPDATE_REPOSITORY` is the fork's own hook, is read FIRST, and is not reserved. Set to `disabled` it short-circuits `GITHUB_REPOSITORY` before that is read, fails the `owner/repo` split, and returns undefined — the no-publish path. No publish config, no `app-update.yml`, `hasUpdateFeedConfig` false, and upstream's electron-updater switches itself off. Which is what the empty string was always meant to do. WHY THIS WAS URGENT RATHER THAN MERELY WRONG. `releaseType: release` kept the second updater inert by accident: every fork release was a GitHub prerelease, so it could never find anything to install. #96 has just made releases full releases with a real Latest pointer. The next successful publish would have been the first thing that dormant updater could see, in every installed build. Tests pin both directions — that the hook produces no config, and that GITHUB_REPOSITORY alone still produces one, so nobody later reads the hook as redundant. They live in the fork's test file; the function is exported, so this costs no seam row. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…annot see (#102) (#106) Upstream's Windows server.asar split (this sync) broke the release's bundle-verify gate both ways at once: the server graph silently stopped being scanned, and node-pty — mentioned only inside main.cjs's embedded WSL heredoc scripts, loadable from the sidecar where it genuinely lives — was reported unresolvable, failing a shippable build (release run 31837711136, publish skipped). The view now merges a sibling resources/server.asar (+ .unpacked) into the packaged-file map, so sidecar bundles are scanned again and sidecar packages resolve. And every FIRST_PARTY_BUNDLE_DIRS entry must contribute at least one scanned bundle — a packaging-topology change that hides a layer is now an error instead of an empty green result, which is the 'guard that cannot fail' shape #97 already taught us once. Also corrects the three comments still teaching the disproven GITHUB_REPOSITORY="" mechanism (main.ts, UpdateToast.tsx) and the workflow step's stale Windows-topology claim. Fixes#102. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

radroid · 2026-08-12T16:49:44Z

Releases have been red since #53 landed. Build 106 was the last one published — every run after it failed before publishing anything, so #95 and #96 have not shipped to any user.

Three defects, all in the new bundle-size checks.

1. The exclusions CLI wrote nothing on Windows

All three new scripts guarded their CLI entry point with:

if(import.meta.url===`file://${process.argv[1]}`){

That is false on Windows. process.argv[1] is a native path there, so the template builds file://D:\a\... while import.meta.url is file:///D:/a/... — drive letter after three slashes, forward separators. Verified:

win builds: file://D:\a\t3code\t3code\scripts\coil\desktop-file-exclusions.mjs
win actual: file:///D:/a/t3code/t3code/scripts/coil/desktop-file-exclusions.mjs

It works on macOS and Linux only because an absolute POSIX path already begins with /, which is why it passed review and passed on one runner. So node desktop-file-exclusions.mjs parsed, ran nothing, wrote nothing, exited 0 — and the release step correctly refused an empty list.

The same guard is in verify-desktop-bundle.mjs, which the release invokes as a CLI. On Windows that verification would have exited 0 without running, even after the rest of this was fixed. All three now use pathToFileURL.

2. `app.asar` was never under `release/`

Both checks searched release/. The build copies only files out of its staging dir — if (!stat || stat.type !== "File") continue in build-desktop-artifact.ts — and the macOS .app and Windows win-unpacked/ are directories, so the trees holding app.asar are never copied there.

Worse, the staging dir was a scoped temp dir, deleted the moment the build process exits. There was nothing to find anywhere on disk.

T3CODE_DESKTOP_KEEP_STAGE (which Config.boolean accepts as "1") keeps it; one new step resolves it through os.tmpdir() rather than assuming /tmp or %TEMP%, folding backslashes so git-bash's find can take it; a cleanup step drops it again before the upload.

3. The `app-update.yml` guard had never been able to fail

Same wrong directory, opposite outcome. It searched release/ for a file that only exists inside the .app, found nothing, printed "No app-update.yml packaged", and passed — every run, unconditionally.

It was never checking the claim it is the only evidence for: that this fork's toast is the sole update surface and upstream's electron-updater is off. A check that fails loudly costs one red build; a check that cannot fail costs nothing until the day it was supposed to catch something.

Tests

Cover the shape that broke rather than the line: invoked as a CLI, these scripts must actually do something. One asserts non-empty stdout, one asserts a no-argument verify run does not exit 0.

They cannot run on Windows here — this fork has no Windows CI runner — so that platform's correctness rests on pathToFileURL being the right primitive, not on a green check. That asymmetry is the same one that let this ship, and it is stated in the test file rather than left implicit.

Verification

locate/cleanup logic exercised locally against a simulated two-stage tree, including a path with spaces; picks the newest stage
YAML parses; Config.boolean confirmed to accept "1" from Effect's TrueValues
new CLI tests pass; the rest of desktop-bundle-size.test.ts unchanged and passing

The real proof is the release run on merge, which is the one thing that cannot be tested beforehand.

🤖 Generated with Claude Code

coderabbitai · 2026-08-12T16:49:53Z

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 81df0dd3-4baf-4d3c-a0dc-f5f23385fd03

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

🔍 Trigger review

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

… failing Releases have been red since #53 landed. Build 106 was the last one published; every run after it failed before publishing anything. Three defects, all in the new bundle-size checks, and the third is the one worth reading twice. 1. The exclusions CLI wrote nothing on Windows. All three scripts guarded their CLI entry point with `import.meta.url === \`file://${process.argv[1]}\``. That is false on Windows, where argv[1] is a native path: the template builds `file://D:\a\...` while `import.meta.url` is `file:///D:/a/...`. It works on macOS and Linux only because an absolute POSIX path already begins with `/`, which is why it passed review and passed on one runner. So `node desktop-file-exclusions.mjs` parsed, ran nothing, wrote nothing and exited 0, and the release step correctly refused an empty exclusion list. The same guard is in verify-desktop-bundle.mjs, which the release invokes as a CLI — so on Windows that verification would have exited 0 without running even once the rest of this was fixed. Fixed with `pathToFileURL`, which is what Node provides for this conversion. 2. app.asar was never under release/. Both checks searched `release/`. The build copies only FILES out of its staging dir — `if (!stat || stat.type !== "File") continue` — and the macOS `.app` and Windows `win-unpacked/` are directories, so the trees holding app.asar are never copied there. The staging dir was also a SCOPED temp dir, deleted when the build exits, so there was nothing to find anywhere. T3CODE_DESKTOP_KEEP_STAGE keeps it, one new step resolves it through `os.tmpdir()` rather than assuming /tmp or %TEMP%, and a cleanup step drops it again before the upload. 3. The app-update.yml guard had never been able to fail. Same wrong directory, opposite outcome. It searched release/ for a file that only exists inside the .app, found nothing, printed "No app-update.yml packaged", and passed — every run, unconditionally. It was never checking the claim it is the only evidence for: that this fork's toast is the sole update surface and upstream's electron-updater is off. A check that fails loudly costs one red build. A check that cannot fail costs nothing until the day it was supposed to catch something. Tests cover the shape that broke rather than the line: invoked as a CLI, these scripts must actually do something. They cannot run on Windows here — this fork has no Windows CI runner — so that platform's correctness rests on pathToFileURL being the right primitive, not on a green check. That asymmetry is the same one that let this ship. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…annot see (#102) (#106) Upstream's Windows server.asar split (this sync) broke the release's bundle-verify gate both ways at once: the server graph silently stopped being scanned, and node-pty — mentioned only inside main.cjs's embedded WSL heredoc scripts, loadable from the sidecar where it genuinely lives — was reported unresolvable, failing a shippable build (release run 31837711136, publish skipped). The view now merges a sibling resources/server.asar (+ .unpacked) into the packaged-file map, so sidecar bundles are scanned again and sidecar packages resolve. And every FIRST_PARTY_BUNDLE_DIRS entry must contribute at least one scanned bundle — a packaging-topology change that hides a layer is now an error instead of an empty green result, which is the 'guard that cannot fail' shape #97 already taught us once. Also corrects the three comments still teaching the disproven GITHUB_REPOSITORY="" mechanism (main.ts, UpdateToast.tsx) and the workflow step's stale Windows-topology claim. Fixes#102. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

…lly disabled The check restored in #97 failed on its first real run, on both platforms, and it was right to. `app-update.yml` is in the bundle: .../T3 Coil (Alpha).app/Contents/Resources/app-update.yml .../win-unpacked/resources/app-update.yml It is in the installed build too — 0.0.33-coil.105 on disk carries `owner: radroid / repo: t3code / provider: github / releaseType: release`. So has every build before it. This is not a regression #97 introduced; it is what the old check could not see. WHY IT WAS NEVER DISABLED. The workflow set `GITHUB_REPOSITORY: ""` and its comment claimed that made `resolveGitHubPublishConfig` return undefined. Actions refuses to let a workflow set any `GITHUB_`-prefixed variable, so the line is inert. The build read the runner's real `radroid/t3code`, resolved a publish config, and electron-builder wrote the feed. The shipped file proves the path taken: those owner/repo values cannot come from any other branch of that function. `T3CODE_DESKTOP_UPDATE_REPOSITORY` is the fork's own hook, is read FIRST, and is not reserved. Set to `disabled` it short-circuits `GITHUB_REPOSITORY` before that is read, fails the `owner/repo` split, and returns undefined — the no-publish path. No publish config, no `app-update.yml`, `hasUpdateFeedConfig` false, and upstream's electron-updater switches itself off. Which is what the empty string was always meant to do. WHY THIS WAS URGENT RATHER THAN MERELY WRONG. `releaseType: release` kept the second updater inert by accident: every fork release was a GitHub prerelease, so it could never find anything to install. #96 has just made releases full releases with a real Latest pointer. The next successful publish would have been the first thing that dormant updater could see, in every installed build. Tests pin both directions — that the hook produces no config, and that GITHUB_REPOSITORY alone still produces one, so nobody later reads the hook as redundant. They live in the fork's test file; the function is exported, so this costs no seam row. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…annot see (#102) (#106) Upstream's Windows server.asar split (this sync) broke the release's bundle-verify gate both ways at once: the server graph silently stopped being scanned, and node-pty — mentioned only inside main.cjs's embedded WSL heredoc scripts, loadable from the sidecar where it genuinely lives — was reported unresolvable, failing a shippable build (release run 31837711136, publish skipped). The view now merges a sibling resources/server.asar (+ .unpacked) into the packaged-file map, so sidecar bundles are scanned again and sidecar packages resolve. And every FIRST_PARTY_BUNDLE_DIRS entry must contribute at least one scanned bundle — a packaging-topology change that hides a layer is now an error instead of an empty green result, which is the 'guard that cannot fail' shape #97 already taught us once. Also corrects the three comments still teaching the disproven GITHUB_REPOSITORY="" mechanism (main.ts, UpdateToast.tsx) and the workflow step's stale Windows-topology claim. Fixes#102. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

…lly disabled The check restored in #97 failed on its first real run, on both platforms, and it was right to. `app-update.yml` is in the bundle: .../T3 Coil (Alpha).app/Contents/Resources/app-update.yml .../win-unpacked/resources/app-update.yml It is in the installed build too — 0.0.33-coil.105 on disk carries `owner: radroid / repo: t3code / provider: github / releaseType: release`. So has every build before it. This is not a regression #97 introduced; it is what the old check could not see. WHY IT WAS NEVER DISABLED. The workflow set `GITHUB_REPOSITORY: ""` and its comment claimed that made `resolveGitHubPublishConfig` return undefined. Actions refuses to let a workflow set any `GITHUB_`-prefixed variable, so the line is inert. The build read the runner's real `radroid/t3code`, resolved a publish config, and electron-builder wrote the feed. The shipped file proves the path taken: those owner/repo values cannot come from any other branch of that function. `T3CODE_DESKTOP_UPDATE_REPOSITORY` is the fork's own hook, is read FIRST, and is not reserved. Set to `disabled` it short-circuits `GITHUB_REPOSITORY` before that is read, fails the `owner/repo` split, and returns undefined — the no-publish path. No publish config, no `app-update.yml`, `hasUpdateFeedConfig` false, and upstream's electron-updater switches itself off. Which is what the empty string was always meant to do. WHY THIS WAS URGENT RATHER THAN MERELY WRONG. `releaseType: release` kept the second updater inert by accident: every fork release was a GitHub prerelease, so it could never find anything to install. #96 has just made releases full releases with a real Latest pointer. The next successful publish would have been the first thing that dormant updater could see, in every installed build. Tests pin both directions — that the hook produces no config, and that GITHUB_REPOSITORY alone still produces one, so nobody later reads the hook as redundant. They live in the fork's test file; the function is exported, so this costs no seam row. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…annot see (#102) (#106) Upstream's Windows server.asar split (this sync) broke the release's bundle-verify gate both ways at once: the server graph silently stopped being scanned, and node-pty — mentioned only inside main.cjs's embedded WSL heredoc scripts, loadable from the sidecar where it genuinely lives — was reported unresolvable, failing a shippable build (release run 31837711136, publish skipped). The view now merges a sibling resources/server.asar (+ .unpacked) into the packaged-file map, so sidecar bundles are scanned again and sidecar packages resolve. And every FIRST_PARTY_BUNDLE_DIRS entry must contribute at least one scanned bundle — a packaging-topology change that hides a layer is now an error instead of an empty green result, which is the 'guard that cannot fail' shape #97 already taught us once. Also corrects the three comments still teaching the disproven GITHUB_REPOSITORY="" mechanism (main.ts, UpdateToast.tsx) and the workflow step's stale Windows-topology claim. Fixes#102. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

radroid · 2026-08-12T16:49:44Z

Releases have been red since #53 landed. Build 106 was the last one published — every run after it failed before publishing anything, so #95 and #96 have not shipped to any user.

Three defects, all in the new bundle-size checks.

1. The exclusions CLI wrote nothing on Windows

All three new scripts guarded their CLI entry point with:

if(import.meta.url===`file://${process.argv[1]}`){

That is false on Windows. process.argv[1] is a native path there, so the template builds file://D:\a\... while import.meta.url is file:///D:/a/... — drive letter after three slashes, forward separators. Verified:

win builds: file://D:\a\t3code\t3code\scripts\coil\desktop-file-exclusions.mjs
win actual: file:///D:/a/t3code/t3code/scripts/coil/desktop-file-exclusions.mjs

It works on macOS and Linux only because an absolute POSIX path already begins with /, which is why it passed review and passed on one runner. So node desktop-file-exclusions.mjs parsed, ran nothing, wrote nothing, exited 0 — and the release step correctly refused an empty list.

The same guard is in verify-desktop-bundle.mjs, which the release invokes as a CLI. On Windows that verification would have exited 0 without running, even after the rest of this was fixed. All three now use pathToFileURL.

2. `app.asar` was never under `release/`

Both checks searched release/. The build copies only files out of its staging dir — if (!stat || stat.type !== "File") continue in build-desktop-artifact.ts — and the macOS .app and Windows win-unpacked/ are directories, so the trees holding app.asar are never copied there.

Worse, the staging dir was a scoped temp dir, deleted the moment the build process exits. There was nothing to find anywhere on disk.

T3CODE_DESKTOP_KEEP_STAGE (which Config.boolean accepts as "1") keeps it; one new step resolves it through os.tmpdir() rather than assuming /tmp or %TEMP%, folding backslashes so git-bash's find can take it; a cleanup step drops it again before the upload.

3. The `app-update.yml` guard had never been able to fail

Same wrong directory, opposite outcome. It searched release/ for a file that only exists inside the .app, found nothing, printed "No app-update.yml packaged", and passed — every run, unconditionally.

It was never checking the claim it is the only evidence for: that this fork's toast is the sole update surface and upstream's electron-updater is off. A check that fails loudly costs one red build; a check that cannot fail costs nothing until the day it was supposed to catch something.

Tests

Cover the shape that broke rather than the line: invoked as a CLI, these scripts must actually do something. One asserts non-empty stdout, one asserts a no-argument verify run does not exit 0.

They cannot run on Windows here — this fork has no Windows CI runner — so that platform's correctness rests on pathToFileURL being the right primitive, not on a green check. That asymmetry is the same one that let this ship, and it is stated in the test file rather than left implicit.

Verification

locate/cleanup logic exercised locally against a simulated two-stage tree, including a path with spaces; picks the newest stage
YAML parses; Config.boolean confirmed to accept "1" from Effect's TrueValues
new CLI tests pass; the rest of desktop-bundle-size.test.ts unchanged and passing

The real proof is the release run on merge, which is the one thing that cannot be tested beforehand.

🤖 Generated with Claude Code

coderabbitai · 2026-08-12T16:49:53Z

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 81df0dd3-4baf-4d3c-a0dc-f5f23385fd03

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

🔍 Trigger review

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

… failing Releases have been red since #53 landed. Build 106 was the last one published; every run after it failed before publishing anything. Three defects, all in the new bundle-size checks, and the third is the one worth reading twice. 1. The exclusions CLI wrote nothing on Windows. All three scripts guarded their CLI entry point with `import.meta.url === \`file://${process.argv[1]}\``. That is false on Windows, where argv[1] is a native path: the template builds `file://D:\a\...` while `import.meta.url` is `file:///D:/a/...`. It works on macOS and Linux only because an absolute POSIX path already begins with `/`, which is why it passed review and passed on one runner. So `node desktop-file-exclusions.mjs` parsed, ran nothing, wrote nothing and exited 0, and the release step correctly refused an empty exclusion list. The same guard is in verify-desktop-bundle.mjs, which the release invokes as a CLI — so on Windows that verification would have exited 0 without running even once the rest of this was fixed. Fixed with `pathToFileURL`, which is what Node provides for this conversion. 2. app.asar was never under release/. Both checks searched `release/`. The build copies only FILES out of its staging dir — `if (!stat || stat.type !== "File") continue` — and the macOS `.app` and Windows `win-unpacked/` are directories, so the trees holding app.asar are never copied there. The staging dir was also a SCOPED temp dir, deleted when the build exits, so there was nothing to find anywhere. T3CODE_DESKTOP_KEEP_STAGE keeps it, one new step resolves it through `os.tmpdir()` rather than assuming /tmp or %TEMP%, and a cleanup step drops it again before the upload. 3. The app-update.yml guard had never been able to fail. Same wrong directory, opposite outcome. It searched release/ for a file that only exists inside the .app, found nothing, printed "No app-update.yml packaged", and passed — every run, unconditionally. It was never checking the claim it is the only evidence for: that this fork's toast is the sole update surface and upstream's electron-updater is off. A check that fails loudly costs one red build. A check that cannot fail costs nothing until the day it was supposed to catch something. Tests cover the shape that broke rather than the line: invoked as a CLI, these scripts must actually do something. They cannot run on Windows here — this fork has no Windows CI runner — so that platform's correctness rests on pathToFileURL being the right primitive, not on a green check. That asymmetry is the same one that let this ship. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…annot see (#102) (#106) Upstream's Windows server.asar split (this sync) broke the release's bundle-verify gate both ways at once: the server graph silently stopped being scanned, and node-pty — mentioned only inside main.cjs's embedded WSL heredoc scripts, loadable from the sidecar where it genuinely lives — was reported unresolvable, failing a shippable build (release run 31837711136, publish skipped). The view now merges a sibling resources/server.asar (+ .unpacked) into the packaged-file map, so sidecar bundles are scanned again and sidecar packages resolve. And every FIRST_PARTY_BUNDLE_DIRS entry must contribute at least one scanned bundle — a packaging-topology change that hides a layer is now an error instead of an empty green result, which is the 'guard that cannot fail' shape #97 already taught us once. Also corrects the three comments still teaching the disproven GITHUB_REPOSITORY="" mechanism (main.ts, UpdateToast.tsx) and the workflow step's stale Windows-topology claim. Fixes#102. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

…lly disabled The check restored in #97 failed on its first real run, on both platforms, and it was right to. `app-update.yml` is in the bundle: .../T3 Coil (Alpha).app/Contents/Resources/app-update.yml .../win-unpacked/resources/app-update.yml It is in the installed build too — 0.0.33-coil.105 on disk carries `owner: radroid / repo: t3code / provider: github / releaseType: release`. So has every build before it. This is not a regression #97 introduced; it is what the old check could not see. WHY IT WAS NEVER DISABLED. The workflow set `GITHUB_REPOSITORY: ""` and its comment claimed that made `resolveGitHubPublishConfig` return undefined. Actions refuses to let a workflow set any `GITHUB_`-prefixed variable, so the line is inert. The build read the runner's real `radroid/t3code`, resolved a publish config, and electron-builder wrote the feed. The shipped file proves the path taken: those owner/repo values cannot come from any other branch of that function. `T3CODE_DESKTOP_UPDATE_REPOSITORY` is the fork's own hook, is read FIRST, and is not reserved. Set to `disabled` it short-circuits `GITHUB_REPOSITORY` before that is read, fails the `owner/repo` split, and returns undefined — the no-publish path. No publish config, no `app-update.yml`, `hasUpdateFeedConfig` false, and upstream's electron-updater switches itself off. Which is what the empty string was always meant to do. WHY THIS WAS URGENT RATHER THAN MERELY WRONG. `releaseType: release` kept the second updater inert by accident: every fork release was a GitHub prerelease, so it could never find anything to install. #96 has just made releases full releases with a real Latest pointer. The next successful publish would have been the first thing that dormant updater could see, in every installed build. Tests pin both directions — that the hook produces no config, and that GITHUB_REPOSITORY alone still produces one, so nobody later reads the hook as redundant. They live in the fork's test file; the function is exported, so this costs no seam row. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…annot see (#102) (#106) Upstream's Windows server.asar split (this sync) broke the release's bundle-verify gate both ways at once: the server graph silently stopped being scanned, and node-pty — mentioned only inside main.cjs's embedded WSL heredoc scripts, loadable from the sidecar where it genuinely lives — was reported unresolvable, failing a shippable build (release run 31837711136, publish skipped). The view now merges a sibling resources/server.asar (+ .unpacked) into the packaged-file map, so sidecar bundles are scanned again and sidecar packages resolve. And every FIRST_PARTY_BUNDLE_DIRS entry must contribute at least one scanned bundle — a packaging-topology change that hides a layer is now an error instead of an empty green result, which is the 'guard that cannot fail' shape #97 already taught us once. Also corrects the three comments still teaching the disproven GITHUB_REPOSITORY="" mechanism (main.ts, UpdateToast.tsx) and the workflow step's stale Windows-topology claim. Fixes#102. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

…lly disabled The check restored in #97 failed on its first real run, on both platforms, and it was right to. `app-update.yml` is in the bundle: .../T3 Coil (Alpha).app/Contents/Resources/app-update.yml .../win-unpacked/resources/app-update.yml It is in the installed build too — 0.0.33-coil.105 on disk carries `owner: radroid / repo: t3code / provider: github / releaseType: release`. So has every build before it. This is not a regression #97 introduced; it is what the old check could not see. WHY IT WAS NEVER DISABLED. The workflow set `GITHUB_REPOSITORY: ""` and its comment claimed that made `resolveGitHubPublishConfig` return undefined. Actions refuses to let a workflow set any `GITHUB_`-prefixed variable, so the line is inert. The build read the runner's real `radroid/t3code`, resolved a publish config, and electron-builder wrote the feed. The shipped file proves the path taken: those owner/repo values cannot come from any other branch of that function. `T3CODE_DESKTOP_UPDATE_REPOSITORY` is the fork's own hook, is read FIRST, and is not reserved. Set to `disabled` it short-circuits `GITHUB_REPOSITORY` before that is read, fails the `owner/repo` split, and returns undefined — the no-publish path. No publish config, no `app-update.yml`, `hasUpdateFeedConfig` false, and upstream's electron-updater switches itself off. Which is what the empty string was always meant to do. WHY THIS WAS URGENT RATHER THAN MERELY WRONG. `releaseType: release` kept the second updater inert by accident: every fork release was a GitHub prerelease, so it could never find anything to install. #96 has just made releases full releases with a real Latest pointer. The next successful publish would have been the first thing that dormant updater could see, in every installed build. Tests pin both directions — that the hook produces no config, and that GITHUB_REPOSITORY alone still produces one, so nobody later reads the hook as redundant. They live in the fork's test file; the function is exported, so this costs no seam row. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…annot see (#102) (#106) Upstream's Windows server.asar split (this sync) broke the release's bundle-verify gate both ways at once: the server graph silently stopped being scanned, and node-pty — mentioned only inside main.cjs's embedded WSL heredoc scripts, loadable from the sidecar where it genuinely lives — was reported unresolvable, failing a shippable build (release run 31837711136, publish skipped). The view now merges a sibling resources/server.asar (+ .unpacked) into the packaged-file map, so sidecar bundles are scanned again and sidecar packages resolve. And every FIRST_PARTY_BUNDLE_DIRS entry must contribute at least one scanned bundle — a packaging-topology change that hides a layer is now an error instead of an empty green result, which is the 'guard that cannot fail' shape #97 already taught us once. Also corrects the three comments still teaching the disproven GITHUB_REPOSITORY="" mechanism (main.ts, UpdateToast.tsx) and the workflow step's stale Windows-topology claim. Fixes#102. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

radroid · 2026-08-12T16:49:44Z

Releases have been red since #53 landed. Build 106 was the last one published — every run after it failed before publishing anything, so #95 and #96 have not shipped to any user.

Three defects, all in the new bundle-size checks.

1. The exclusions CLI wrote nothing on Windows

All three new scripts guarded their CLI entry point with:

if(import.meta.url===`file://${process.argv[1]}`){

That is false on Windows. process.argv[1] is a native path there, so the template builds file://D:\a\... while import.meta.url is file:///D:/a/... — drive letter after three slashes, forward separators. Verified:

win builds: file://D:\a\t3code\t3code\scripts\coil\desktop-file-exclusions.mjs
win actual: file:///D:/a/t3code/t3code/scripts/coil/desktop-file-exclusions.mjs

It works on macOS and Linux only because an absolute POSIX path already begins with /, which is why it passed review and passed on one runner. So node desktop-file-exclusions.mjs parsed, ran nothing, wrote nothing, exited 0 — and the release step correctly refused an empty list.

The same guard is in verify-desktop-bundle.mjs, which the release invokes as a CLI. On Windows that verification would have exited 0 without running, even after the rest of this was fixed. All three now use pathToFileURL.

2. `app.asar` was never under `release/`

Both checks searched release/. The build copies only files out of its staging dir — if (!stat || stat.type !== "File") continue in build-desktop-artifact.ts — and the macOS .app and Windows win-unpacked/ are directories, so the trees holding app.asar are never copied there.

Worse, the staging dir was a scoped temp dir, deleted the moment the build process exits. There was nothing to find anywhere on disk.

T3CODE_DESKTOP_KEEP_STAGE (which Config.boolean accepts as "1") keeps it; one new step resolves it through os.tmpdir() rather than assuming /tmp or %TEMP%, folding backslashes so git-bash's find can take it; a cleanup step drops it again before the upload.

3. The `app-update.yml` guard had never been able to fail

Same wrong directory, opposite outcome. It searched release/ for a file that only exists inside the .app, found nothing, printed "No app-update.yml packaged", and passed — every run, unconditionally.

It was never checking the claim it is the only evidence for: that this fork's toast is the sole update surface and upstream's electron-updater is off. A check that fails loudly costs one red build; a check that cannot fail costs nothing until the day it was supposed to catch something.

Tests

Cover the shape that broke rather than the line: invoked as a CLI, these scripts must actually do something. One asserts non-empty stdout, one asserts a no-argument verify run does not exit 0.

They cannot run on Windows here — this fork has no Windows CI runner — so that platform's correctness rests on pathToFileURL being the right primitive, not on a green check. That asymmetry is the same one that let this ship, and it is stated in the test file rather than left implicit.

Verification

locate/cleanup logic exercised locally against a simulated two-stage tree, including a path with spaces; picks the newest stage
YAML parses; Config.boolean confirmed to accept "1" from Effect's TrueValues
new CLI tests pass; the rest of desktop-bundle-size.test.ts unchanged and passing

The real proof is the release run on merge, which is the one thing that cannot be tested beforehand.

🤖 Generated with Claude Code

coderabbitai · 2026-08-12T16:49:53Z

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 81df0dd3-4baf-4d3c-a0dc-f5f23385fd03

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

🔍 Trigger review

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

… failing Releases have been red since #53 landed. Build 106 was the last one published; every run after it failed before publishing anything. Three defects, all in the new bundle-size checks, and the third is the one worth reading twice. 1. The exclusions CLI wrote nothing on Windows. All three scripts guarded their CLI entry point with `import.meta.url === \`file://${process.argv[1]}\``. That is false on Windows, where argv[1] is a native path: the template builds `file://D:\a\...` while `import.meta.url` is `file:///D:/a/...`. It works on macOS and Linux only because an absolute POSIX path already begins with `/`, which is why it passed review and passed on one runner. So `node desktop-file-exclusions.mjs` parsed, ran nothing, wrote nothing and exited 0, and the release step correctly refused an empty exclusion list. The same guard is in verify-desktop-bundle.mjs, which the release invokes as a CLI — so on Windows that verification would have exited 0 without running even once the rest of this was fixed. Fixed with `pathToFileURL`, which is what Node provides for this conversion. 2. app.asar was never under release/. Both checks searched `release/`. The build copies only FILES out of its staging dir — `if (!stat || stat.type !== "File") continue` — and the macOS `.app` and Windows `win-unpacked/` are directories, so the trees holding app.asar are never copied there. The staging dir was also a SCOPED temp dir, deleted when the build exits, so there was nothing to find anywhere. T3CODE_DESKTOP_KEEP_STAGE keeps it, one new step resolves it through `os.tmpdir()` rather than assuming /tmp or %TEMP%, and a cleanup step drops it again before the upload. 3. The app-update.yml guard had never been able to fail. Same wrong directory, opposite outcome. It searched release/ for a file that only exists inside the .app, found nothing, printed "No app-update.yml packaged", and passed — every run, unconditionally. It was never checking the claim it is the only evidence for: that this fork's toast is the sole update surface and upstream's electron-updater is off. A check that fails loudly costs one red build. A check that cannot fail costs nothing until the day it was supposed to catch something. Tests cover the shape that broke rather than the line: invoked as a CLI, these scripts must actually do something. They cannot run on Windows here — this fork has no Windows CI runner — so that platform's correctness rests on pathToFileURL being the right primitive, not on a green check. That asymmetry is the same one that let this ship. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…annot see (#102) (#106) Upstream's Windows server.asar split (this sync) broke the release's bundle-verify gate both ways at once: the server graph silently stopped being scanned, and node-pty — mentioned only inside main.cjs's embedded WSL heredoc scripts, loadable from the sidecar where it genuinely lives — was reported unresolvable, failing a shippable build (release run 31837711136, publish skipped). The view now merges a sibling resources/server.asar (+ .unpacked) into the packaged-file map, so sidecar bundles are scanned again and sidecar packages resolve. And every FIRST_PARTY_BUNDLE_DIRS entry must contribute at least one scanned bundle — a packaging-topology change that hides a layer is now an error instead of an empty green result, which is the 'guard that cannot fail' shape #97 already taught us once. Also corrects the three comments still teaching the disproven GITHUB_REPOSITORY="" mechanism (main.ts, UpdateToast.tsx) and the workflow step's stale Windows-topology claim. Fixes#102. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

…lly disabled The check restored in #97 failed on its first real run, on both platforms, and it was right to. `app-update.yml` is in the bundle: .../T3 Coil (Alpha).app/Contents/Resources/app-update.yml .../win-unpacked/resources/app-update.yml It is in the installed build too — 0.0.33-coil.105 on disk carries `owner: radroid / repo: t3code / provider: github / releaseType: release`. So has every build before it. This is not a regression #97 introduced; it is what the old check could not see. WHY IT WAS NEVER DISABLED. The workflow set `GITHUB_REPOSITORY: ""` and its comment claimed that made `resolveGitHubPublishConfig` return undefined. Actions refuses to let a workflow set any `GITHUB_`-prefixed variable, so the line is inert. The build read the runner's real `radroid/t3code`, resolved a publish config, and electron-builder wrote the feed. The shipped file proves the path taken: those owner/repo values cannot come from any other branch of that function. `T3CODE_DESKTOP_UPDATE_REPOSITORY` is the fork's own hook, is read FIRST, and is not reserved. Set to `disabled` it short-circuits `GITHUB_REPOSITORY` before that is read, fails the `owner/repo` split, and returns undefined — the no-publish path. No publish config, no `app-update.yml`, `hasUpdateFeedConfig` false, and upstream's electron-updater switches itself off. Which is what the empty string was always meant to do. WHY THIS WAS URGENT RATHER THAN MERELY WRONG. `releaseType: release` kept the second updater inert by accident: every fork release was a GitHub prerelease, so it could never find anything to install. #96 has just made releases full releases with a real Latest pointer. The next successful publish would have been the first thing that dormant updater could see, in every installed build. Tests pin both directions — that the hook produces no config, and that GITHUB_REPOSITORY alone still produces one, so nobody later reads the hook as redundant. They live in the fork's test file; the function is exported, so this costs no seam row. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…annot see (#102) (#106) Upstream's Windows server.asar split (this sync) broke the release's bundle-verify gate both ways at once: the server graph silently stopped being scanned, and node-pty — mentioned only inside main.cjs's embedded WSL heredoc scripts, loadable from the sidecar where it genuinely lives — was reported unresolvable, failing a shippable build (release run 31837711136, publish skipped). The view now merges a sibling resources/server.asar (+ .unpacked) into the packaged-file map, so sidecar bundles are scanned again and sidecar packages resolve. And every FIRST_PARTY_BUNDLE_DIRS entry must contribute at least one scanned bundle — a packaging-topology change that hides a layer is now an error instead of an empty green result, which is the 'guard that cannot fail' shape #97 already taught us once. Also corrects the three comments still teaching the disproven GITHUB_REPOSITORY="" mechanism (main.ts, UpdateToast.tsx) and the workflow step's stale Windows-topology claim. Fixes#102. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

…lly disabled The check restored in #97 failed on its first real run, on both platforms, and it was right to. `app-update.yml` is in the bundle: .../T3 Coil (Alpha).app/Contents/Resources/app-update.yml .../win-unpacked/resources/app-update.yml It is in the installed build too — 0.0.33-coil.105 on disk carries `owner: radroid / repo: t3code / provider: github / releaseType: release`. So has every build before it. This is not a regression #97 introduced; it is what the old check could not see. WHY IT WAS NEVER DISABLED. The workflow set `GITHUB_REPOSITORY: ""` and its comment claimed that made `resolveGitHubPublishConfig` return undefined. Actions refuses to let a workflow set any `GITHUB_`-prefixed variable, so the line is inert. The build read the runner's real `radroid/t3code`, resolved a publish config, and electron-builder wrote the feed. The shipped file proves the path taken: those owner/repo values cannot come from any other branch of that function. `T3CODE_DESKTOP_UPDATE_REPOSITORY` is the fork's own hook, is read FIRST, and is not reserved. Set to `disabled` it short-circuits `GITHUB_REPOSITORY` before that is read, fails the `owner/repo` split, and returns undefined — the no-publish path. No publish config, no `app-update.yml`, `hasUpdateFeedConfig` false, and upstream's electron-updater switches itself off. Which is what the empty string was always meant to do. WHY THIS WAS URGENT RATHER THAN MERELY WRONG. `releaseType: release` kept the second updater inert by accident: every fork release was a GitHub prerelease, so it could never find anything to install. #96 has just made releases full releases with a real Latest pointer. The next successful publish would have been the first thing that dormant updater could see, in every installed build. Tests pin both directions — that the hook produces no config, and that GITHUB_REPOSITORY alone still produces one, so nobody later reads the hook as redundant. They live in the fork's test file; the function is exported, so this costs no seam row. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…annot see (#102) (#106) Upstream's Windows server.asar split (this sync) broke the release's bundle-verify gate both ways at once: the server graph silently stopped being scanned, and node-pty — mentioned only inside main.cjs's embedded WSL heredoc scripts, loadable from the sidecar where it genuinely lives — was reported unresolvable, failing a shippable build (release run 31837711136, publish skipped). The view now merges a sibling resources/server.asar (+ .unpacked) into the packaged-file map, so sidecar bundles are scanned again and sidecar packages resolve. And every FIRST_PARTY_BUNDLE_DIRS entry must contribute at least one scanned bundle — a packaging-topology change that hides a layer is now an error instead of an empty green result, which is the 'guard that cannot fail' shape #97 already taught us once. Also corrects the three comments still teaching the disproven GITHUB_REPOSITORY="" mechanism (main.ts, UpdateToast.tsx) and the workflow step's stale Windows-topology claim. Fixes#102. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

radroid · 2026-08-12T16:49:44Z

Releases have been red since #53 landed. Build 106 was the last one published — every run after it failed before publishing anything, so #95 and #96 have not shipped to any user.

Three defects, all in the new bundle-size checks.

1. The exclusions CLI wrote nothing on Windows

All three new scripts guarded their CLI entry point with:

if(import.meta.url===`file://${process.argv[1]}`){

That is false on Windows. process.argv[1] is a native path there, so the template builds file://D:\a\... while import.meta.url is file:///D:/a/... — drive letter after three slashes, forward separators. Verified:

win builds: file://D:\a\t3code\t3code\scripts\coil\desktop-file-exclusions.mjs
win actual: file:///D:/a/t3code/t3code/scripts/coil/desktop-file-exclusions.mjs

It works on macOS and Linux only because an absolute POSIX path already begins with /, which is why it passed review and passed on one runner. So node desktop-file-exclusions.mjs parsed, ran nothing, wrote nothing, exited 0 — and the release step correctly refused an empty list.

The same guard is in verify-desktop-bundle.mjs, which the release invokes as a CLI. On Windows that verification would have exited 0 without running, even after the rest of this was fixed. All three now use pathToFileURL.

2. `app.asar` was never under `release/`

Both checks searched release/. The build copies only files out of its staging dir — if (!stat || stat.type !== "File") continue in build-desktop-artifact.ts — and the macOS .app and Windows win-unpacked/ are directories, so the trees holding app.asar are never copied there.

Worse, the staging dir was a scoped temp dir, deleted the moment the build process exits. There was nothing to find anywhere on disk.

T3CODE_DESKTOP_KEEP_STAGE (which Config.boolean accepts as "1") keeps it; one new step resolves it through os.tmpdir() rather than assuming /tmp or %TEMP%, folding backslashes so git-bash's find can take it; a cleanup step drops it again before the upload.

3. The `app-update.yml` guard had never been able to fail

Same wrong directory, opposite outcome. It searched release/ for a file that only exists inside the .app, found nothing, printed "No app-update.yml packaged", and passed — every run, unconditionally.

It was never checking the claim it is the only evidence for: that this fork's toast is the sole update surface and upstream's electron-updater is off. A check that fails loudly costs one red build; a check that cannot fail costs nothing until the day it was supposed to catch something.

Tests

Cover the shape that broke rather than the line: invoked as a CLI, these scripts must actually do something. One asserts non-empty stdout, one asserts a no-argument verify run does not exit 0.

They cannot run on Windows here — this fork has no Windows CI runner — so that platform's correctness rests on pathToFileURL being the right primitive, not on a green check. That asymmetry is the same one that let this ship, and it is stated in the test file rather than left implicit.

Verification

locate/cleanup logic exercised locally against a simulated two-stage tree, including a path with spaces; picks the newest stage
YAML parses; Config.boolean confirmed to accept "1" from Effect's TrueValues
new CLI tests pass; the rest of desktop-bundle-size.test.ts unchanged and passing

The real proof is the release run on merge, which is the one thing that cannot be tested beforehand.

🤖 Generated with Claude Code

coderabbitai · 2026-08-12T16:49:53Z

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 81df0dd3-4baf-4d3c-a0dc-f5f23385fd03

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

🔍 Trigger review

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

… failing Releases have been red since #53 landed. Build 106 was the last one published; every run after it failed before publishing anything. Three defects, all in the new bundle-size checks, and the third is the one worth reading twice. 1. The exclusions CLI wrote nothing on Windows. All three scripts guarded their CLI entry point with `import.meta.url === \`file://${process.argv[1]}\``. That is false on Windows, where argv[1] is a native path: the template builds `file://D:\a\...` while `import.meta.url` is `file:///D:/a/...`. It works on macOS and Linux only because an absolute POSIX path already begins with `/`, which is why it passed review and passed on one runner. So `node desktop-file-exclusions.mjs` parsed, ran nothing, wrote nothing and exited 0, and the release step correctly refused an empty exclusion list. The same guard is in verify-desktop-bundle.mjs, which the release invokes as a CLI — so on Windows that verification would have exited 0 without running even once the rest of this was fixed. Fixed with `pathToFileURL`, which is what Node provides for this conversion. 2. app.asar was never under release/. Both checks searched `release/`. The build copies only FILES out of its staging dir — `if (!stat || stat.type !== "File") continue` — and the macOS `.app` and Windows `win-unpacked/` are directories, so the trees holding app.asar are never copied there. The staging dir was also a SCOPED temp dir, deleted when the build exits, so there was nothing to find anywhere. T3CODE_DESKTOP_KEEP_STAGE keeps it, one new step resolves it through `os.tmpdir()` rather than assuming /tmp or %TEMP%, and a cleanup step drops it again before the upload. 3. The app-update.yml guard had never been able to fail. Same wrong directory, opposite outcome. It searched release/ for a file that only exists inside the .app, found nothing, printed "No app-update.yml packaged", and passed — every run, unconditionally. It was never checking the claim it is the only evidence for: that this fork's toast is the sole update surface and upstream's electron-updater is off. A check that fails loudly costs one red build. A check that cannot fail costs nothing until the day it was supposed to catch something. Tests cover the shape that broke rather than the line: invoked as a CLI, these scripts must actually do something. They cannot run on Windows here — this fork has no Windows CI runner — so that platform's correctness rests on pathToFileURL being the right primitive, not on a green check. That asymmetry is the same one that let this ship. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…annot see (#102) (#106) Upstream's Windows server.asar split (this sync) broke the release's bundle-verify gate both ways at once: the server graph silently stopped being scanned, and node-pty — mentioned only inside main.cjs's embedded WSL heredoc scripts, loadable from the sidecar where it genuinely lives — was reported unresolvable, failing a shippable build (release run 31837711136, publish skipped). The view now merges a sibling resources/server.asar (+ .unpacked) into the packaged-file map, so sidecar bundles are scanned again and sidecar packages resolve. And every FIRST_PARTY_BUNDLE_DIRS entry must contribute at least one scanned bundle — a packaging-topology change that hides a layer is now an error instead of an empty green result, which is the 'guard that cannot fail' shape #97 already taught us once. Also corrects the three comments still teaching the disproven GITHUB_REPOSITORY="" mechanism (main.ts, UpdateToast.tsx) and the workflow step's stale Windows-topology claim. Fixes#102. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

…lly disabled The check restored in #97 failed on its first real run, on both platforms, and it was right to. `app-update.yml` is in the bundle: .../T3 Coil (Alpha).app/Contents/Resources/app-update.yml .../win-unpacked/resources/app-update.yml It is in the installed build too — 0.0.33-coil.105 on disk carries `owner: radroid / repo: t3code / provider: github / releaseType: release`. So has every build before it. This is not a regression #97 introduced; it is what the old check could not see. WHY IT WAS NEVER DISABLED. The workflow set `GITHUB_REPOSITORY: ""` and its comment claimed that made `resolveGitHubPublishConfig` return undefined. Actions refuses to let a workflow set any `GITHUB_`-prefixed variable, so the line is inert. The build read the runner's real `radroid/t3code`, resolved a publish config, and electron-builder wrote the feed. The shipped file proves the path taken: those owner/repo values cannot come from any other branch of that function. `T3CODE_DESKTOP_UPDATE_REPOSITORY` is the fork's own hook, is read FIRST, and is not reserved. Set to `disabled` it short-circuits `GITHUB_REPOSITORY` before that is read, fails the `owner/repo` split, and returns undefined — the no-publish path. No publish config, no `app-update.yml`, `hasUpdateFeedConfig` false, and upstream's electron-updater switches itself off. Which is what the empty string was always meant to do. WHY THIS WAS URGENT RATHER THAN MERELY WRONG. `releaseType: release` kept the second updater inert by accident: every fork release was a GitHub prerelease, so it could never find anything to install. #96 has just made releases full releases with a real Latest pointer. The next successful publish would have been the first thing that dormant updater could see, in every installed build. Tests pin both directions — that the hook produces no config, and that GITHUB_REPOSITORY alone still produces one, so nobody later reads the hook as redundant. They live in the fork's test file; the function is exported, so this costs no seam row. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…annot see (#102) (#106) Upstream's Windows server.asar split (this sync) broke the release's bundle-verify gate both ways at once: the server graph silently stopped being scanned, and node-pty — mentioned only inside main.cjs's embedded WSL heredoc scripts, loadable from the sidecar where it genuinely lives — was reported unresolvable, failing a shippable build (release run 31837711136, publish skipped). The view now merges a sibling resources/server.asar (+ .unpacked) into the packaged-file map, so sidecar bundles are scanned again and sidecar packages resolve. And every FIRST_PARTY_BUNDLE_DIRS entry must contribute at least one scanned bundle — a packaging-topology change that hides a layer is now an error instead of an empty green result, which is the 'guard that cannot fail' shape #97 already taught us once. Also corrects the three comments still teaching the disproven GITHUB_REPOSITORY="" mechanism (main.ts, UpdateToast.tsx) and the workflow step's stale Windows-topology claim. Fixes#102. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

…lly disabled The check restored in #97 failed on its first real run, on both platforms, and it was right to. `app-update.yml` is in the bundle: .../T3 Coil (Alpha).app/Contents/Resources/app-update.yml .../win-unpacked/resources/app-update.yml It is in the installed build too — 0.0.33-coil.105 on disk carries `owner: radroid / repo: t3code / provider: github / releaseType: release`. So has every build before it. This is not a regression #97 introduced; it is what the old check could not see. WHY IT WAS NEVER DISABLED. The workflow set `GITHUB_REPOSITORY: ""` and its comment claimed that made `resolveGitHubPublishConfig` return undefined. Actions refuses to let a workflow set any `GITHUB_`-prefixed variable, so the line is inert. The build read the runner's real `radroid/t3code`, resolved a publish config, and electron-builder wrote the feed. The shipped file proves the path taken: those owner/repo values cannot come from any other branch of that function. `T3CODE_DESKTOP_UPDATE_REPOSITORY` is the fork's own hook, is read FIRST, and is not reserved. Set to `disabled` it short-circuits `GITHUB_REPOSITORY` before that is read, fails the `owner/repo` split, and returns undefined — the no-publish path. No publish config, no `app-update.yml`, `hasUpdateFeedConfig` false, and upstream's electron-updater switches itself off. Which is what the empty string was always meant to do. WHY THIS WAS URGENT RATHER THAN MERELY WRONG. `releaseType: release` kept the second updater inert by accident: every fork release was a GitHub prerelease, so it could never find anything to install. #96 has just made releases full releases with a real Latest pointer. The next successful publish would have been the first thing that dormant updater could see, in every installed build. Tests pin both directions — that the hook produces no config, and that GITHUB_REPOSITORY alone still produces one, so nobody later reads the hook as redundant. They live in the fork's test file; the function is exported, so this costs no seam row. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…annot see (#102) (#106) Upstream's Windows server.asar split (this sync) broke the release's bundle-verify gate both ways at once: the server graph silently stopped being scanned, and node-pty — mentioned only inside main.cjs's embedded WSL heredoc scripts, loadable from the sidecar where it genuinely lives — was reported unresolvable, failing a shippable build (release run 31837711136, publish skipped). The view now merges a sibling resources/server.asar (+ .unpacked) into the packaged-file map, so sidecar bundles are scanned again and sidecar packages resolve. And every FIRST_PARTY_BUNDLE_DIRS entry must contribute at least one scanned bundle — a packaging-topology change that hides a layer is now an error instead of an empty green result, which is the 'guard that cannot fail' shape #97 already taught us once. Also corrects the three comments still teaching the disproven GITHUB_REPOSITORY="" mechanism (main.ts, UpdateToast.tsx) and the workflow step's stale Windows-topology claim. Fixes#102. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

radroid · 2026-08-12T16:49:44Z

Releases have been red since #53 landed. Build 106 was the last one published — every run after it failed before publishing anything, so #95 and #96 have not shipped to any user.

Three defects, all in the new bundle-size checks.

1. The exclusions CLI wrote nothing on Windows

All three new scripts guarded their CLI entry point with:

if(import.meta.url===`file://${process.argv[1]}`){

That is false on Windows. process.argv[1] is a native path there, so the template builds file://D:\a\... while import.meta.url is file:///D:/a/... — drive letter after three slashes, forward separators. Verified:

win builds: file://D:\a\t3code\t3code\scripts\coil\desktop-file-exclusions.mjs
win actual: file:///D:/a/t3code/t3code/scripts/coil/desktop-file-exclusions.mjs

It works on macOS and Linux only because an absolute POSIX path already begins with /, which is why it passed review and passed on one runner. So node desktop-file-exclusions.mjs parsed, ran nothing, wrote nothing, exited 0 — and the release step correctly refused an empty list.

The same guard is in verify-desktop-bundle.mjs, which the release invokes as a CLI. On Windows that verification would have exited 0 without running, even after the rest of this was fixed. All three now use pathToFileURL.

2. `app.asar` was never under `release/`

Both checks searched release/. The build copies only files out of its staging dir — if (!stat || stat.type !== "File") continue in build-desktop-artifact.ts — and the macOS .app and Windows win-unpacked/ are directories, so the trees holding app.asar are never copied there.

Worse, the staging dir was a scoped temp dir, deleted the moment the build process exits. There was nothing to find anywhere on disk.

T3CODE_DESKTOP_KEEP_STAGE (which Config.boolean accepts as "1") keeps it; one new step resolves it through os.tmpdir() rather than assuming /tmp or %TEMP%, folding backslashes so git-bash's find can take it; a cleanup step drops it again before the upload.

3. The `app-update.yml` guard had never been able to fail

Same wrong directory, opposite outcome. It searched release/ for a file that only exists inside the .app, found nothing, printed "No app-update.yml packaged", and passed — every run, unconditionally.

It was never checking the claim it is the only evidence for: that this fork's toast is the sole update surface and upstream's electron-updater is off. A check that fails loudly costs one red build; a check that cannot fail costs nothing until the day it was supposed to catch something.

Tests

Cover the shape that broke rather than the line: invoked as a CLI, these scripts must actually do something. One asserts non-empty stdout, one asserts a no-argument verify run does not exit 0.

They cannot run on Windows here — this fork has no Windows CI runner — so that platform's correctness rests on pathToFileURL being the right primitive, not on a green check. That asymmetry is the same one that let this ship, and it is stated in the test file rather than left implicit.

Verification

locate/cleanup logic exercised locally against a simulated two-stage tree, including a path with spaces; picks the newest stage
YAML parses; Config.boolean confirmed to accept "1" from Effect's TrueValues
new CLI tests pass; the rest of desktop-bundle-size.test.ts unchanged and passing

The real proof is the release run on merge, which is the one thing that cannot be tested beforehand.

🤖 Generated with Claude Code

coderabbitai · 2026-08-12T16:49:53Z

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 81df0dd3-4baf-4d3c-a0dc-f5f23385fd03

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

🔍 Trigger review

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

… failing Releases have been red since #53 landed. Build 106 was the last one published; every run after it failed before publishing anything. Three defects, all in the new bundle-size checks, and the third is the one worth reading twice. 1. The exclusions CLI wrote nothing on Windows. All three scripts guarded their CLI entry point with `import.meta.url === \`file://${process.argv[1]}\``. That is false on Windows, where argv[1] is a native path: the template builds `file://D:\a\...` while `import.meta.url` is `file:///D:/a/...`. It works on macOS and Linux only because an absolute POSIX path already begins with `/`, which is why it passed review and passed on one runner. So `node desktop-file-exclusions.mjs` parsed, ran nothing, wrote nothing and exited 0, and the release step correctly refused an empty exclusion list. The same guard is in verify-desktop-bundle.mjs, which the release invokes as a CLI — so on Windows that verification would have exited 0 without running even once the rest of this was fixed. Fixed with `pathToFileURL`, which is what Node provides for this conversion. 2. app.asar was never under release/. Both checks searched `release/`. The build copies only FILES out of its staging dir — `if (!stat || stat.type !== "File") continue` — and the macOS `.app` and Windows `win-unpacked/` are directories, so the trees holding app.asar are never copied there. The staging dir was also a SCOPED temp dir, deleted when the build exits, so there was nothing to find anywhere. T3CODE_DESKTOP_KEEP_STAGE keeps it, one new step resolves it through `os.tmpdir()` rather than assuming /tmp or %TEMP%, and a cleanup step drops it again before the upload. 3. The app-update.yml guard had never been able to fail. Same wrong directory, opposite outcome. It searched release/ for a file that only exists inside the .app, found nothing, printed "No app-update.yml packaged", and passed — every run, unconditionally. It was never checking the claim it is the only evidence for: that this fork's toast is the sole update surface and upstream's electron-updater is off. A check that fails loudly costs one red build. A check that cannot fail costs nothing until the day it was supposed to catch something. Tests cover the shape that broke rather than the line: invoked as a CLI, these scripts must actually do something. They cannot run on Windows here — this fork has no Windows CI runner — so that platform's correctness rests on pathToFileURL being the right primitive, not on a green check. That asymmetry is the same one that let this ship. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…annot see (#102) (#106) Upstream's Windows server.asar split (this sync) broke the release's bundle-verify gate both ways at once: the server graph silently stopped being scanned, and node-pty — mentioned only inside main.cjs's embedded WSL heredoc scripts, loadable from the sidecar where it genuinely lives — was reported unresolvable, failing a shippable build (release run 31837711136, publish skipped). The view now merges a sibling resources/server.asar (+ .unpacked) into the packaged-file map, so sidecar bundles are scanned again and sidecar packages resolve. And every FIRST_PARTY_BUNDLE_DIRS entry must contribute at least one scanned bundle — a packaging-topology change that hides a layer is now an error instead of an empty green result, which is the 'guard that cannot fail' shape #97 already taught us once. Also corrects the three comments still teaching the disproven GITHUB_REPOSITORY="" mechanism (main.ts, UpdateToast.tsx) and the workflow step's stale Windows-topology claim. Fixes#102. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

…lly disabled The check restored in #97 failed on its first real run, on both platforms, and it was right to. `app-update.yml` is in the bundle: .../T3 Coil (Alpha).app/Contents/Resources/app-update.yml .../win-unpacked/resources/app-update.yml It is in the installed build too — 0.0.33-coil.105 on disk carries `owner: radroid / repo: t3code / provider: github / releaseType: release`. So has every build before it. This is not a regression #97 introduced; it is what the old check could not see. WHY IT WAS NEVER DISABLED. The workflow set `GITHUB_REPOSITORY: ""` and its comment claimed that made `resolveGitHubPublishConfig` return undefined. Actions refuses to let a workflow set any `GITHUB_`-prefixed variable, so the line is inert. The build read the runner's real `radroid/t3code`, resolved a publish config, and electron-builder wrote the feed. The shipped file proves the path taken: those owner/repo values cannot come from any other branch of that function. `T3CODE_DESKTOP_UPDATE_REPOSITORY` is the fork's own hook, is read FIRST, and is not reserved. Set to `disabled` it short-circuits `GITHUB_REPOSITORY` before that is read, fails the `owner/repo` split, and returns undefined — the no-publish path. No publish config, no `app-update.yml`, `hasUpdateFeedConfig` false, and upstream's electron-updater switches itself off. Which is what the empty string was always meant to do. WHY THIS WAS URGENT RATHER THAN MERELY WRONG. `releaseType: release` kept the second updater inert by accident: every fork release was a GitHub prerelease, so it could never find anything to install. #96 has just made releases full releases with a real Latest pointer. The next successful publish would have been the first thing that dormant updater could see, in every installed build. Tests pin both directions — that the hook produces no config, and that GITHUB_REPOSITORY alone still produces one, so nobody later reads the hook as redundant. They live in the fork's test file; the function is exported, so this costs no seam row. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…annot see (#102) (#106) Upstream's Windows server.asar split (this sync) broke the release's bundle-verify gate both ways at once: the server graph silently stopped being scanned, and node-pty — mentioned only inside main.cjs's embedded WSL heredoc scripts, loadable from the sidecar where it genuinely lives — was reported unresolvable, failing a shippable build (release run 31837711136, publish skipped). The view now merges a sibling resources/server.asar (+ .unpacked) into the packaged-file map, so sidecar bundles are scanned again and sidecar packages resolve. And every FIRST_PARTY_BUNDLE_DIRS entry must contribute at least one scanned bundle — a packaging-topology change that hides a layer is now an error instead of an empty green result, which is the 'guard that cannot fail' shape #97 already taught us once. Also corrects the three comments still teaching the disproven GITHUB_REPOSITORY="" mechanism (main.ts, UpdateToast.tsx) and the workflow step's stale Windows-topology claim. Fixes#102. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

…lly disabled The check restored in #97 failed on its first real run, on both platforms, and it was right to. `app-update.yml` is in the bundle: .../T3 Coil (Alpha).app/Contents/Resources/app-update.yml .../win-unpacked/resources/app-update.yml It is in the installed build too — 0.0.33-coil.105 on disk carries `owner: radroid / repo: t3code / provider: github / releaseType: release`. So has every build before it. This is not a regression #97 introduced; it is what the old check could not see. WHY IT WAS NEVER DISABLED. The workflow set `GITHUB_REPOSITORY: ""` and its comment claimed that made `resolveGitHubPublishConfig` return undefined. Actions refuses to let a workflow set any `GITHUB_`-prefixed variable, so the line is inert. The build read the runner's real `radroid/t3code`, resolved a publish config, and electron-builder wrote the feed. The shipped file proves the path taken: those owner/repo values cannot come from any other branch of that function. `T3CODE_DESKTOP_UPDATE_REPOSITORY` is the fork's own hook, is read FIRST, and is not reserved. Set to `disabled` it short-circuits `GITHUB_REPOSITORY` before that is read, fails the `owner/repo` split, and returns undefined — the no-publish path. No publish config, no `app-update.yml`, `hasUpdateFeedConfig` false, and upstream's electron-updater switches itself off. Which is what the empty string was always meant to do. WHY THIS WAS URGENT RATHER THAN MERELY WRONG. `releaseType: release` kept the second updater inert by accident: every fork release was a GitHub prerelease, so it could never find anything to install. #96 has just made releases full releases with a real Latest pointer. The next successful publish would have been the first thing that dormant updater could see, in every installed build. Tests pin both directions — that the hook produces no config, and that GITHUB_REPOSITORY alone still produces one, so nobody later reads the hook as redundant. They live in the fork's test file; the function is exported, so this costs no seam row. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…annot see (#102) (#106) Upstream's Windows server.asar split (this sync) broke the release's bundle-verify gate both ways at once: the server graph silently stopped being scanned, and node-pty — mentioned only inside main.cjs's embedded WSL heredoc scripts, loadable from the sidecar where it genuinely lives — was reported unresolvable, failing a shippable build (release run 31837711136, publish skipped). The view now merges a sibling resources/server.asar (+ .unpacked) into the packaged-file map, so sidecar bundles are scanned again and sidecar packages resolve. And every FIRST_PARTY_BUNDLE_DIRS entry must contribute at least one scanned bundle — a packaging-topology change that hides a layer is now an error instead of an empty green result, which is the 'guard that cannot fail' shape #97 already taught us once. Also corrects the three comments still teaching the disproven GITHUB_REPOSITORY="" mechanism (main.ts, UpdateToast.tsx) and the workflow step's stale Windows-topology claim. Fixes#102. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

radroid · 2026-08-12T16:49:44Z

Releases have been red since #53 landed. Build 106 was the last one published — every run after it failed before publishing anything, so #95 and #96 have not shipped to any user.

Three defects, all in the new bundle-size checks.

1. The exclusions CLI wrote nothing on Windows

All three new scripts guarded their CLI entry point with:

if(import.meta.url===`file://${process.argv[1]}`){

That is false on Windows. process.argv[1] is a native path there, so the template builds file://D:\a\... while import.meta.url is file:///D:/a/... — drive letter after three slashes, forward separators. Verified:

win builds: file://D:\a\t3code\t3code\scripts\coil\desktop-file-exclusions.mjs
win actual: file:///D:/a/t3code/t3code/scripts/coil/desktop-file-exclusions.mjs

It works on macOS and Linux only because an absolute POSIX path already begins with /, which is why it passed review and passed on one runner. So node desktop-file-exclusions.mjs parsed, ran nothing, wrote nothing, exited 0 — and the release step correctly refused an empty list.

The same guard is in verify-desktop-bundle.mjs, which the release invokes as a CLI. On Windows that verification would have exited 0 without running, even after the rest of this was fixed. All three now use pathToFileURL.

2. `app.asar` was never under `release/`

Both checks searched release/. The build copies only files out of its staging dir — if (!stat || stat.type !== "File") continue in build-desktop-artifact.ts — and the macOS .app and Windows win-unpacked/ are directories, so the trees holding app.asar are never copied there.

Worse, the staging dir was a scoped temp dir, deleted the moment the build process exits. There was nothing to find anywhere on disk.

T3CODE_DESKTOP_KEEP_STAGE (which Config.boolean accepts as "1") keeps it; one new step resolves it through os.tmpdir() rather than assuming /tmp or %TEMP%, folding backslashes so git-bash's find can take it; a cleanup step drops it again before the upload.

3. The `app-update.yml` guard had never been able to fail

Same wrong directory, opposite outcome. It searched release/ for a file that only exists inside the .app, found nothing, printed "No app-update.yml packaged", and passed — every run, unconditionally.

It was never checking the claim it is the only evidence for: that this fork's toast is the sole update surface and upstream's electron-updater is off. A check that fails loudly costs one red build; a check that cannot fail costs nothing until the day it was supposed to catch something.

Tests

Cover the shape that broke rather than the line: invoked as a CLI, these scripts must actually do something. One asserts non-empty stdout, one asserts a no-argument verify run does not exit 0.

They cannot run on Windows here — this fork has no Windows CI runner — so that platform's correctness rests on pathToFileURL being the right primitive, not on a green check. That asymmetry is the same one that let this ship, and it is stated in the test file rather than left implicit.

Verification

locate/cleanup logic exercised locally against a simulated two-stage tree, including a path with spaces; picks the newest stage
YAML parses; Config.boolean confirmed to accept "1" from Effect's TrueValues
new CLI tests pass; the rest of desktop-bundle-size.test.ts unchanged and passing

The real proof is the release run on merge, which is the one thing that cannot be tested beforehand.

🤖 Generated with Claude Code

coderabbitai · 2026-08-12T16:49:53Z

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 81df0dd3-4baf-4d3c-a0dc-f5f23385fd03

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

🔍 Trigger review

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

… failing Releases have been red since #53 landed. Build 106 was the last one published; every run after it failed before publishing anything. Three defects, all in the new bundle-size checks, and the third is the one worth reading twice. 1. The exclusions CLI wrote nothing on Windows. All three scripts guarded their CLI entry point with `import.meta.url === \`file://${process.argv[1]}\``. That is false on Windows, where argv[1] is a native path: the template builds `file://D:\a\...` while `import.meta.url` is `file:///D:/a/...`. It works on macOS and Linux only because an absolute POSIX path already begins with `/`, which is why it passed review and passed on one runner. So `node desktop-file-exclusions.mjs` parsed, ran nothing, wrote nothing and exited 0, and the release step correctly refused an empty exclusion list. The same guard is in verify-desktop-bundle.mjs, which the release invokes as a CLI — so on Windows that verification would have exited 0 without running even once the rest of this was fixed. Fixed with `pathToFileURL`, which is what Node provides for this conversion. 2. app.asar was never under release/. Both checks searched `release/`. The build copies only FILES out of its staging dir — `if (!stat || stat.type !== "File") continue` — and the macOS `.app` and Windows `win-unpacked/` are directories, so the trees holding app.asar are never copied there. The staging dir was also a SCOPED temp dir, deleted when the build exits, so there was nothing to find anywhere. T3CODE_DESKTOP_KEEP_STAGE keeps it, one new step resolves it through `os.tmpdir()` rather than assuming /tmp or %TEMP%, and a cleanup step drops it again before the upload. 3. The app-update.yml guard had never been able to fail. Same wrong directory, opposite outcome. It searched release/ for a file that only exists inside the .app, found nothing, printed "No app-update.yml packaged", and passed — every run, unconditionally. It was never checking the claim it is the only evidence for: that this fork's toast is the sole update surface and upstream's electron-updater is off. A check that fails loudly costs one red build. A check that cannot fail costs nothing until the day it was supposed to catch something. Tests cover the shape that broke rather than the line: invoked as a CLI, these scripts must actually do something. They cannot run on Windows here — this fork has no Windows CI runner — so that platform's correctness rests on pathToFileURL being the right primitive, not on a green check. That asymmetry is the same one that let this ship. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…annot see (#102) (#106) Upstream's Windows server.asar split (this sync) broke the release's bundle-verify gate both ways at once: the server graph silently stopped being scanned, and node-pty — mentioned only inside main.cjs's embedded WSL heredoc scripts, loadable from the sidecar where it genuinely lives — was reported unresolvable, failing a shippable build (release run 31837711136, publish skipped). The view now merges a sibling resources/server.asar (+ .unpacked) into the packaged-file map, so sidecar bundles are scanned again and sidecar packages resolve. And every FIRST_PARTY_BUNDLE_DIRS entry must contribute at least one scanned bundle — a packaging-topology change that hides a layer is now an error instead of an empty green result, which is the 'guard that cannot fail' shape #97 already taught us once. Also corrects the three comments still teaching the disproven GITHUB_REPOSITORY="" mechanism (main.ts, UpdateToast.tsx) and the workflow step's stale Windows-topology claim. Fixes#102. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

…lly disabled The check restored in #97 failed on its first real run, on both platforms, and it was right to. `app-update.yml` is in the bundle: .../T3 Coil (Alpha).app/Contents/Resources/app-update.yml .../win-unpacked/resources/app-update.yml It is in the installed build too — 0.0.33-coil.105 on disk carries `owner: radroid / repo: t3code / provider: github / releaseType: release`. So has every build before it. This is not a regression #97 introduced; it is what the old check could not see. WHY IT WAS NEVER DISABLED. The workflow set `GITHUB_REPOSITORY: ""` and its comment claimed that made `resolveGitHubPublishConfig` return undefined. Actions refuses to let a workflow set any `GITHUB_`-prefixed variable, so the line is inert. The build read the runner's real `radroid/t3code`, resolved a publish config, and electron-builder wrote the feed. The shipped file proves the path taken: those owner/repo values cannot come from any other branch of that function. `T3CODE_DESKTOP_UPDATE_REPOSITORY` is the fork's own hook, is read FIRST, and is not reserved. Set to `disabled` it short-circuits `GITHUB_REPOSITORY` before that is read, fails the `owner/repo` split, and returns undefined — the no-publish path. No publish config, no `app-update.yml`, `hasUpdateFeedConfig` false, and upstream's electron-updater switches itself off. Which is what the empty string was always meant to do. WHY THIS WAS URGENT RATHER THAN MERELY WRONG. `releaseType: release` kept the second updater inert by accident: every fork release was a GitHub prerelease, so it could never find anything to install. #96 has just made releases full releases with a real Latest pointer. The next successful publish would have been the first thing that dormant updater could see, in every installed build. Tests pin both directions — that the hook produces no config, and that GITHUB_REPOSITORY alone still produces one, so nobody later reads the hook as redundant. They live in the fork's test file; the function is exported, so this costs no seam row. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…annot see (#102) (#106) Upstream's Windows server.asar split (this sync) broke the release's bundle-verify gate both ways at once: the server graph silently stopped being scanned, and node-pty — mentioned only inside main.cjs's embedded WSL heredoc scripts, loadable from the sidecar where it genuinely lives — was reported unresolvable, failing a shippable build (release run 31837711136, publish skipped). The view now merges a sibling resources/server.asar (+ .unpacked) into the packaged-file map, so sidecar bundles are scanned again and sidecar packages resolve. And every FIRST_PARTY_BUNDLE_DIRS entry must contribute at least one scanned bundle — a packaging-topology change that hides a layer is now an error instead of an empty green result, which is the 'guard that cannot fail' shape #97 already taught us once. Also corrects the three comments still teaching the disproven GITHUB_REPOSITORY="" mechanism (main.ts, UpdateToast.tsx) and the workflow step's stale Windows-topology claim. Fixes#102. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

…lly disabled The check restored in #97 failed on its first real run, on both platforms, and it was right to. `app-update.yml` is in the bundle: .../T3 Coil (Alpha).app/Contents/Resources/app-update.yml .../win-unpacked/resources/app-update.yml It is in the installed build too — 0.0.33-coil.105 on disk carries `owner: radroid / repo: t3code / provider: github / releaseType: release`. So has every build before it. This is not a regression #97 introduced; it is what the old check could not see. WHY IT WAS NEVER DISABLED. The workflow set `GITHUB_REPOSITORY: ""` and its comment claimed that made `resolveGitHubPublishConfig` return undefined. Actions refuses to let a workflow set any `GITHUB_`-prefixed variable, so the line is inert. The build read the runner's real `radroid/t3code`, resolved a publish config, and electron-builder wrote the feed. The shipped file proves the path taken: those owner/repo values cannot come from any other branch of that function. `T3CODE_DESKTOP_UPDATE_REPOSITORY` is the fork's own hook, is read FIRST, and is not reserved. Set to `disabled` it short-circuits `GITHUB_REPOSITORY` before that is read, fails the `owner/repo` split, and returns undefined — the no-publish path. No publish config, no `app-update.yml`, `hasUpdateFeedConfig` false, and upstream's electron-updater switches itself off. Which is what the empty string was always meant to do. WHY THIS WAS URGENT RATHER THAN MERELY WRONG. `releaseType: release` kept the second updater inert by accident: every fork release was a GitHub prerelease, so it could never find anything to install. #96 has just made releases full releases with a real Latest pointer. The next successful publish would have been the first thing that dormant updater could see, in every installed build. Tests pin both directions — that the hook produces no config, and that GITHUB_REPOSITORY alone still produces one, so nobody later reads the hook as redundant. They live in the fork's test file; the function is exported, so this costs no seam row. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…annot see (#102) (#106) Upstream's Windows server.asar split (this sync) broke the release's bundle-verify gate both ways at once: the server graph silently stopped being scanned, and node-pty — mentioned only inside main.cjs's embedded WSL heredoc scripts, loadable from the sidecar where it genuinely lives — was reported unresolvable, failing a shippable build (release run 31837711136, publish skipped). The view now merges a sibling resources/server.asar (+ .unpacked) into the packaged-file map, so sidecar bundles are scanned again and sidecar packages resolve. And every FIRST_PARTY_BUNDLE_DIRS entry must contribute at least one scanned bundle — a packaging-topology change that hides a layer is now an error instead of an empty green result, which is the 'guard that cannot fail' shape #97 already taught us once. Also corrects the three comments still teaching the disproven GITHUB_REPOSITORY="" mechanism (main.ts, UpdateToast.tsx) and the workflow step's stale Windows-topology claim. Fixes#102. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

radroid force-pushed the coil/fix-release-bundle-checks branch from 9875fcd to 5ee76a8Compare August 12, 2026 17:03

radroid merged commit deffbbc into mainAug 12, 2026
2 checks passed

radroid deleted the coil/fix-release-bundle-checks branch August 12, 2026 17:13