What happened?
PawWork CI did not catch a packaged startup blocker before v0.2.6 shipped. #159 shows the concrete failure: the unpackaged Electron smoke path could start out/main/index.js, but the packaged app crashed because app.asar/out/main/index.js still imported @opencode-ai/util/file-extensions, and the packaged dependency exported that path to node_modules/@opencode-ai/util/src/file-extensions.ts.
Steps to reproduce
- Inspect
.github/workflows/desktop-smoke.yml.
- The workflow runs
bun run build and then bun run smoke:ci, which launches Electron against packages/desktop-electron/out/main/index.js.
- The workflow then runs
electron-builder --mac dir.
- The packaged app check verifies bundle structure,
app.asar, helper app presence, and ad hoc signing, but does not launch dist/mac-arm64/PawWork Dev.app and wait for CI smoke readiness.
What did you expect to happen?
PR smoke should launch the built app bundle after packaging, or otherwise fail when the packaged app.asar would crash at startup. The check should cover the same runtime shape users install from a DMG.
Current gap
bun run smoke:ci proves that the raw build output can start, but not that the packaged app bundle can start. A runtime import that only fails after app.asar dependency resolution can pass CI today. This is exactly why #159 escaped.
Suggested fix direction
Add a packaged-app smoke step after electron-builder --mac dir that launches the built .app executable with isolated PAWWORK_CI_SMOKE_HOME, waits for ci-smoke-ready.json, and fails if the process exits early. Add a static guard that scans packaged main/preload bundles for runtime imports to @opencode-ai/* packages whose exports point at .ts or .tsx source files. Consider the same guard for release packaging so release assets cannot be published with a startup-only packaged crash.
PawWork version
Observed while investigating v0.2.6 and #159.
OS version
macOS CI and local macOS packaged app path.
Can you reproduce it again?
Yes. The current workflow shape can be inspected directly, and v0.2.6 demonstrates the escaped failure.
Screenshots, recordings, or extra context
This issue tracks the CI and release guard gap, not the direct v0.2.6 startup fix. The direct product crash is tracked in #159.
What happened?
PawWork CI did not catch a packaged startup blocker before v0.2.6 shipped. #159 shows the concrete failure: the unpackaged Electron smoke path could start
out/main/index.js, but the packaged app crashed becauseapp.asar/out/main/index.jsstill imported@opencode-ai/util/file-extensions, and the packaged dependency exported that path tonode_modules/@opencode-ai/util/src/file-extensions.ts.Steps to reproduce
.github/workflows/desktop-smoke.yml.bun run buildand thenbun run smoke:ci, which launches Electron againstpackages/desktop-electron/out/main/index.js.electron-builder --mac dir.app.asar, helper app presence, and ad hoc signing, but does not launchdist/mac-arm64/PawWork Dev.appand wait for CI smoke readiness.What did you expect to happen?
PR smoke should launch the built app bundle after packaging, or otherwise fail when the packaged
app.asarwould crash at startup. The check should cover the same runtime shape users install from a DMG.Current gap
bun run smoke:ciproves that the raw build output can start, but not that the packaged app bundle can start. A runtime import that only fails afterapp.asardependency resolution can pass CI today. This is exactly why #159 escaped.Suggested fix direction
Add a packaged-app smoke step after
electron-builder --mac dirthat launches the built.appexecutable with isolatedPAWWORK_CI_SMOKE_HOME, waits forci-smoke-ready.json, and fails if the process exits early. Add a static guard that scans packaged main/preload bundles for runtime imports to@opencode-ai/*packages whoseexportspoint at.tsor.tsxsource files. Consider the same guard for release packaging so release assets cannot be published with a startup-only packaged crash.PawWork version
Observed while investigating v0.2.6 and #159.
OS version
macOS CI and local macOS packaged app path.
Can you reproduce it again?
Yes. The current workflow shape can be inspected directly, and v0.2.6 demonstrates the escaped failure.
Screenshots, recordings, or extra context
This issue tracks the CI and release guard gap, not the direct v0.2.6 startup fix. The direct product crash is tracked in #159.