Belajar Membuat Aplikasi Electron Menggunakan AI untuk Pemula

Asisten kode bisa menampilkan jendela Electron dalam hitungan menit, tetapi iterasi berikutnya sering menggandakan fungsi, mengganti label, memakai API usang, atau menunda packaging sampai akhir. Panduan ini fokus pada cara membuat aplikasi electron ai dengan Anda tetap sebagai penentu spesifikasi, auditor keamanan, dan gate rilis, bukan hanya pengetik prompt. Untuk prasyarat instalasi Node, gunakan tutorial prasyarat Electron resmi karena artikel ini sengaja tidak mengulang langkah instalasi dasar.

Bila Anda baru mengenal runtime-nya, baca dulu Apa Itu Electron JS? untuk arsitektur dasar dan perbedaan desktop versus web. Jadi alur di sini berjalan dari definisi selesai, pemilihan stack, kontrak proyek, arahan AI, pengujian, hingga format distribusi Windows.

Membuat aplikasi Electron AI: definisi selesai dulu

Sebelum prompt pertama, tulis platform target (misalnya Windows 10/11 x64), mode offline atau online, jumlah pengguna, sensitivitas data, dan cara distribusi akhir (installer, folder, atau portable jika tool mendukung). Pisahkan fitur wajib, non-goals, batasan teknis, dan acceptance criteria per fitur. Minta AI membangun semua modul sekaligus hampir selalu menghasilkan UI setengah jadi dan regressions tersembunyi.

Contoh ruang lingkup pemula yang cukup kaya untuk menguji state: aplikasi pengelola tugas desktop dengan tabel, form, pencarian, ekspor CSV, pengaturan, penyimpanan lokal, dialog konfirmasi, progress ekspor nyata, plus tiga skenario rilis Windows. Itu ilustrasi pedagogis, bukan produk siap pakai.

Definisi selesai per fitur harus mencakup uji sukses, gagal, input kosong, loading, pembatalan bila didukung, resize jendela, reload, restart aplikasi, dan eksekusi dari build packaged, bukan hanya `npm start`. Namun tanpa daftar ini, AI cenderung menutup task dengan toast sukses padahal data belum tersimpan.

Lapisan stack: Electron bukan sama dengan React

Electron adalah runtime desktop (Chromium + Node.js) untuk shell, lifecycle, dan integrasi OS. JavaScript atau TypeScript adalah bahasa implementasi. React, Vue, Svelte, atau HTML biasa berjalan di renderer untuk UI. Vite atau Webpack menangani bundling dan HMR. Tailwind atau CSS biasa mengatur gaya. Electron Forge atau electron-builder menangani packaging, bukan menggantikan keputusan framework UI.

Anda perlu cek kompatibilitas versi Node lokal, Node yang dibundel Electron, framework UI, plugin bundler, dan native addon (misalnya driver SQLite) lewat dokumentasi resmi dan build nyata, bukan asumsi otomatis. Major release upstream, seperti yang dilaporkan pada Electron 45, bisa mengubah perilaku Chromium dan Node, jadi audit ulang lockfile lama sebelum rilis.

Untuk form atau dashboard ber-state banyak, React atau Vue plus TypeScript sering masuk akal. Utility dua layar bisa cukup Vanilla JS. Data relasional offline umumnya SQLite di main process dengan path di app.getPath('userData'), bukan di folder instalasi atau di dalam ASAR read-only. Multi-user dengan login biasanya backend API plus database server, bukan credential DB di renderer.

Produk populer memakai pola serupa, dan daftar contoh terverifikasi ada di 36 Contoh Aplikasi Electron.js untuk membayangkan cakupan fitur tanpa menyalin arsitektur mereka.

Spesifikasi proyek aplikasi Electron AI

Drift AI pada proyek panjang sering berasal dari tidak adanya kontrak tertulis. Susun minimal file AGENTS plus docs berisi PROJECT_SPEC (fitur, persona, non-goals), ARCHITECTURE (main, preload, renderer, modul), UI_CONTRACT (token, label, state kosong atau loading), FEATURE_MATRIX (event, preconditions, transisi state, tes penerimaan), DECISIONS (versi stack dan alasan), dan RELEASE_CHECKLIST untuk rilis.

Aturan kerja untuk AI: baca docs sebelum mengubah kode, inventaris fungsi existing, usulkan diff terbatas, jangan ganti stack atau label tanpa persetujuan, cantumkan file terdampak dan cara uji, dan jangan klaim “sudah dites” tanpa log perintah. Prompt awal sebaiknya meminta rekomendasi stack tunggal dan matriks dependency sebelum scaffold, bukan langsung coding.

Main, preload, renderer, dan keamanan IPC

Main process mengelola lifecycle, jendela, dan operasi privileged seperti dialog file atau tray icon bila Anda menambahkannya. Preload mengekspos API terbatas lewat contextBridge, bukan ipcRenderer mentah ke UI, karena exposure mentah mempermudah script di renderer memanggil channel sembarang. Renderer menampilkan komponen web dan tidak boleh akses filesystem atau secret tanpa jalur yang diaudit, meskipun tampilan React terlihat seperti aplikasi web biasa.

Alur tipikal: tombol UI → aksi renderer → API preload → channel IPC eksplisit → service di main → hasil atau error aman → update state UI. Validasi argumen, pembatasan sender, dan pesan error yang tidak bocorkan path internal mengikuti panduan keamanan Electron dan tutorial context isolation serta IPC.

Simpan database dan cache pengguna di direktori data aplikasi lewat app.getPath, bukan di lokasi read-only paket. Selain itu, remote content, navigasi webContents, CSP, dan dependency rentan perlu review terpisah dari “tampilan sudah rapi”.

Kesalahan AI saat membuat aplikasi Electron

Berikut pola yang muncul berulang saat asisten kode mengerjakan Electron tanpa kontrak ketat. Untuk setiap gejala, minta bukti reproduksi, patch minimal, dan tes regressi packaged.

• Fungsi atau handler IPC duplikat dengan nama berbeda → code search, konsolidasi ownership, unit test service.
• Label dialog dan menu berubah tiap iterasi → dictionary label di UI contract, bukan string acak di komponen.
• Tombol aktif saat proses berjalan atau double submit → matriks state plus lock di service layer.
• Progress persen tanpa pekerjaan terukur → indeterminate spinner atau progress determinate dari byte/step nyata.
• Tombol Batalkan hanya menutup dialog → cancellation signal ke main atau teks jelas bahwa operasi tidak bisa dibatalkan.
• Toast sukses sebelum write selesai → await operasi, verifikasi read-back data.
• Popover menutupi teks atau keluar viewport → portal, collision test, keyboard dan scroll.
• API Electron deprecated masih dipakai → cek migration notes versi terkunci, tolak alasan “masih jalan di dev”.
• Path salah setelah packaging → uji dev versus folder out/ atau installer, perhatikan ASAR.
• Native module gagal di packaged build → rebuild ABI Electron untuk OS target.

Matriks state tombol membantu audit async UI:

Pengujian manual tetap perlu: double click cepat, form kosong, tutup jendela saat job berjalan, minimize atau restore, resize minimum, zoom 125% dan 150%, disk penuh simulasi, timeout jaringan, ulang setelah restart app.

Pengujian aplikasi Electron AI: quality gate

Saat workflow membuat aplikasi electron ai hampir selesai, jalankan rantai gate berikut: lint, typecheck, unit dan integration IPC, komponen UI bila ada, build packaged, lalu smoke test di VM atau PC tanpa Node terpasang. Manual QA tetap wajib untuk fokus keyboard, modal bertumpuk, DPI, dan installer.

npm audit atau setara memberi sinyal dependency, bukan sertifikat aman penuh. Akhirnya catat setiap gate dengan perintah, exit code, versi OS, hash commit, dan screenshot bila UI. Tolak klaim AI yang menulis “lulus tes” tanpa log pada review Anda.

Profiling memory dan CPU via Chromium DevTools relevan bila impor atau ekspor besar. Sebut angka benchmark hanya bila skenario dan hardware dapat direplikasi pembaca.

Git dan kontrol perubahan AI

Repo sebaiknya ada sebelum AI mengubah puluhan file. Commit kecil per fitur, branch eksperimen, dan rollback mudah mengurangi kerusakan saat asisten “refactor” tanpa izin. Biasanya Anda commit package-lock.json, sementara node_modules, .env, artefak release, dan database lokal dev tidak masuk repo.

Meskipun diff besar menggoda, jangan commit sertifikat signing, token API, atau password. Review PR manusia tetap perlu: diff fungsi, dependency baru, migrasi data, screenshot UI, output tes, dan risiko keamanan. Hindari git add . tanpa melihat staging list.

Distribusi aplikasi Electron AI di Windows

Bagian ini kerap terlewat padahal menentukan apakah pengguna akhir bisa menjalankan aplikasi desktop tanpa Node. Pilih satu pipeline packaging (misalnya Electron Forge sesuai Forge overview) dan jangan campur Forge dengan electron-builder tanpa alasan dokumentasi.

Urutan praktis: build packaged folder dulu, jalankan di luar dev machine, baru buat installer. Klaim portable satu file hanya setelah konfigurasi builder membuktikan format itu, bukan asumsi default Forge.

Contoh create-shortcut.bat relatif terhadap lokasi distribusi folder (ganti nama EXE, uji di Windows target):

@echo off
setlocal
set "APP_EXE=%~dp0MyApp.exe"
if not exist "%APP_EXE%" (
    echo ERROR: MyApp.exe tidak ditemukan.
    exit /b 1
)
powershell.exe -NoProfile -Command ^
  "$shell = New-Object -ComObject WScript.Shell; $shortcut = $shell.CreateShortcut((Join-Path ([Environment]::GetFolderPath('Desktop')) 'MyApp.lnk')); $shortcut.TargetPath = $env:APP_EXE; $shortcut.WorkingDirectory = Split-Path $env:APP_EXE; $shortcut.Save()"
if errorlevel 1 (
    echo ERROR: Gagal membuat shortcut.
    exit /b 1
)
echo Shortcut berhasil dibuat.
endlocal

Skrip BAT tidak menggantikan installer, tidak auto-update, dan shortcut hanya pointer ke EXE. README pengguna perlu menjelaskan syarat OS, cara hapus folder program, dan perbedaan data pengguna di userData.

Code signing mengurangi friksi SmartScreen tetapi punya biaya dan proses sertifikat. Tanpa signing, distribusi masih mungkin dengan edukasi pengguna, bukan janji “tanpa peringatan”.

Prompt pack membuat aplikasi Electron AI

Semua prompt di bawah adalah template. Bagian dalam [KURUNG SIKU] harus Anda isi dengan fakta proyek, bukan ditebak asisten. Jalankan tahap secara bertahap dan review output sebelum melanjutkan, karena rollback arsitektur jauh lebih mahal daripada menunda satu prompt.

Path file di template prompt ditulis tanpa ekstensi agar mudah disalin. Saat menyimpan di repo, tambahkan ekstensi markdown standar pada setiap file docs dan AGENTS.

Prompt 0: Inventarisasi kebutuhan dan memilih stack (jangan coding dahulu)

Anda berperan sebagai software architect, senior Electron developer, security reviewer, dan UX engineer.
Tujuan: merancang aplikasi desktop [NAMA], yang digunakan oleh [PENGGUNA] untuk [KASUS PENGGUNAAN].
Platform target: [WINDOWS 10/11 x64 / MAC / LINUX], offline: [YA/TIDAK], jaringan: [YA/TIDAK], metode distribusi akhir: [INSTALLER / PORTABLE EXE / FOLDER + SHORTCUT].
Kebutuhan fitur wajib: [DAFTAR RINCI]. Non-goals: [BATASAN]. Data sensitif: [JENIS ATAU TIDAK ADA].
Constraint: [VERSI NODE LOKAL], [VERSI ELEKTRON JIKA DIKETAHUI], [PACKAGE MANAGER], [OS BUILD], [TIM/DEADLINE].

JANGAN membuat kode atau memasang dependensi pada tahap ini.
1. Pisahkan runtime Electron, framework UI, styling, bundler, database, packaging dan testing.
2. Evaluasi Vanilla JS, React dan Vue untuk kebutuhan di atas; pilih SATU opsi paling rasional dan jelaskan alasan dan tradeoff. Jangan memberi daftar tanpa keputusan.
3. Pilih TypeScript atau JavaScript, CSS/Tailwind, database lokal atau backend API, dengan alasan.
4. Buat dependency matrix: package, fungsi, alasan, alternatif yang ditolak, kompatibilitas yang harus diverifikasi, dokumentasi resmi, dan risiko native module.
5. Verifikasi versi stabil/current dan status deprecated dari sumber resmi yang dapat Anda akses. Jika tidak mempunyai akses web, tulis 'BELUM DIVERIFIKASI' dan minta audit manual. Jangan mengarang nomor versi.
6. Tentukan arsitektur main, preload, renderer, IPC, data persistence, logging, security boundaries, release strategy.
7. Sajikan daftar keputusan yang memerlukan persetujuan sebelum scaffold dibuat.
Output: rekomendasi stack TUNGGAL, tabel keputusan, risiko, dan draft docs/DECISIONS.

Prompt 1: Membuat blueprint teknis, struktur folder dan kontrak UI (sebelum coding)

Gunakan keputusan stack yang SUDAH DISETUJUI pada docs/DECISIONS. Jangan mengganti framework/build tool atau dependency tanpa meminta persetujuan.

Buat file rancangan (semua berformat teks markdown di repo): AGENTS, docs/PROJECT_SPEC, docs/ARCHITECTURE, docs/UI_CONTRACT, docs/FEATURE_MATRIX, docs/DECISIONS, docs/RELEASE_CHECKLIST. Isi masing-masing: AGENTS = aturan permanen AI, PROJECT_SPEC = fitur dan non-goals, ARCHITECTURE = main/preload/renderer, UI_CONTRACT = token dan state UI, FEATURE_MATRIX = transisi state dan tes, DECISIONS = keputusan terkunci, RELEASE_CHECKLIST = installer, folder, portable bila ada.

Rancang struktur folder yang konsisten; setiap directory harus punya tanggung jawab.
Tampilkan tree dan alasan setiap folder. Bedakan sumber kode, hasil build, data pengguna, docs dan tests.
Jelaskan bagaimana main process dan preload diekspos secara aman ke renderer.
Buat daftar nama event IPC beserta payload, tipe return, validasi, dan timeout/error model.
Buat inventaris label UI. Tentukan aturan status enabled/disabled button, spinner/progress, modal dan confirmation.
Jika informasi belum cukup, tandai OPEN QUESTION; jangan berasumsi.
JANGAN implementasi fitur sebelum saya menyetujui blueprint ini.

Contoh struktur folder hanya referensi. Sesuaikan nama dengan toolchain yang Anda kunci.

my-electron-app/
├── AGENTS
├── .gitignore
├── .env.example
├── package.json
├── package-lock.json
├── tsconfig.json
├── docs/
│   ├── PROJECT_SPEC
│   ├── ARCHITECTURE
│   ├── UI_CONTRACT
│   ├── FEATURE_MATRIX
│   ├── DECISIONS
│   └── RELEASE_CHECKLIST
├── src/
│   ├── main/
│   │   ├── index.ts
│   │   ├── ipc/
│   │   ├── services/
│   │   └── storage/
│   ├── preload/
│   │   └── index.ts
│   ├── renderer/
│   │   ├── index.html
│   │   ├── src/
│   │   │   ├── components/
│   │   │   ├── pages/
│   │   │   ├── hooks/
│   │   │   ├── styles/
│   │   │   └── features/
│   │   └── assets/
│   └── shared/
│       ├── types/
│       └── contracts/
├── tests/
│   ├── unit/
│   ├── integration/
│   └── e2e/
├── scripts/
│   └── create-shortcut.bat
└── assets/
    └── icons/

Contoh .gitignore baseline. Sesuaikan dengan output generator atau scaffold yang dipakai.

node_modules/
dist/
out/
build/
release/
coverage/
playwright-report/
test-results/
*.log
npm-debug.log*
.DS_Store
Thumbs.db
.env
.env.*
!.env.example
*.local
*.sqlite
*.sqlite3
*.db
*.db-wal
*.db-shm
*.pem
*.p12
*.pfx
*.key
*.crt
*.cer

Lockfile npm tetap masuk version control. Pola sertifikat perlu disesuaikan agar tidak mengecualikan sertifikat publik yang memang sengaja dilacak, sementara file rahasia tetap jangan di-commit. Pola database lokal cocok bila file db hanya dipakai di dev, bukan fixture terkontrol. Jangan mengecualikan aset yang memang perlu dibundel.

Prompt 2: Kontrak AGENTS agar AI tidak melanggar aturan

Tulis file AGENTS untuk proyek berdasarkan dokumen pada folder docs/.
Aturan wajib:
- Baca docs/PROJECT_SPEC, docs/ARCHITECTURE, docs/UI_CONTRACT, dan docs/FEATURE_MATRIX sebelum mengubah kode.
- Jangan membuat duplikat fungsi, service, komponen, event IPC atau label; lakukan code search lebih dulu.
- Jangan gunakan API/dependency deprecated; verifikasi pada versi yang dikunci. Jangan mengarang hasil verifikasi.
- Jangan mengubah framework, bundler, database, arsitektur, folder atau nama komponen tanpa persetujuan.
- Renderer hanya mengakses kemampuan OS melalui preload API terbatas; jangan expos IPC mentah.
- Setiap tindakan UI harus menentukan idle, invalid, running, success, error, dan cancelled (jika relevan).
- Setiap operasi async harus mempertimbangkan double submit, lock, cancellation, timeout, state cleanup, dan feedback.
- Jangan membuat progress persen bila tidak ada ukuran nyata.
- Gunakan komponen UI yang ada; hormati design tokens, label dictionary, viewport collision, focus dan keyboard navigation.
- Sebelum merge: lint, typecheck, tes sesuai perubahan, manual UI review, dan catat bukti yang benar-benar dijalankan.
- Jangan menyatakan 'sudah lulus tes' jika tes belum dijalankan.
- Berikan ringkasan file diubah, alasan, risiko, cara verifikasi, dan hal yang belum dites.
Buat dokumen ringkas, imperatif, tidak saling bertentangan.

Prompt 3: Scaffold minimal dan dependency gate

Gunakan stack versi terkunci yang disetujui. Buat scaffold MINIMAL yang dapat dijalankan.
Hanya buat main window, preload API aman, renderer awal, lint/typecheck/test scripts, .gitignore, .env.example.
Jangan membuat fitur domain dahulu.
Sebelum install, tampilkan dependency install list beserta alasan dan klasifikasi dependencies vs devDependencies.
Periksa scripts package.json untuk development, lint, typecheck, test, package, make sesuai toolchain nyata.
Jangan mencampur Electron Forge dan electron-builder tanpa izin.
Setelah membuat scaffold, jalankan perintah yang tersedia dan tampilkan log/exit status; jika tool tidak bisa dieksekusi, nyatakan jelas tidak diuji.

Prompt 4: Implementasi satu fitur dan audit fungsi lama

Implementasikan HANYA fitur [FITUR] sesuai docs/FEATURE_MATRIX.
Sebelum mengubah file: cari fungsi/komponen/service/IPC eksisting yang serupa, laporkan reuse versus pembuatan baru.
Tuliskan acceptance tests untuk valid, invalid, loading, error, success, retry, double click, cancellation jika didukung.
Pastikan loading feedback dan progress yang jujur; jangan gunakan timer palsu sebagai progress nyata.
Pertahankan label, komponen dan token dari docs/UI_CONTRACT; periksa resize, popup collisions, focus dan modal layering.
Ubah file seminimal mungkin, tambahkan tes, jalankan lint/typecheck/tests yang tersedia, lalu berikan diff summary serta apa yang belum diverifikasi.

Prompt 5: Audit UI/UX menyeluruh

Lakukan audit GUI untuk SELURUH layar dengan matriks:
- buttons: enabled/disabled per state, loading state, double submit, cancellation;
- forms: validation, errors, keyboard tab order;
- overlay: modal/popover/tooltip collision, z-index, focus trap, Escape/backdrop;
- layout: window resize, min-size, zoom 100/125/150%, overflow, long labels;
- feedback: loading/success/error/empty, progress determinate hanya bila terukur;
- consistency: label dictionary, ikon, padding, typography, color tokens;
- accessibility: semantic labels, visible focus, contrast, reduced motion.
Untuk setiap temuan: screen/komponen, langkah reproduksi, expected vs actual, severity, usulan patch, test. Jangan mengklaim screenshot atau tes telah dilakukan tanpa benar-benar menjalankannya.
Jangan mengubah apa pun sebelum memberikan daftar prioritas temuan.

Prompt 6: Audit security dan deprecated dependencies

Audit proyek Electron sesuai versi yang terkunci.
Periksa: contextIsolation, sandbox, nodeIntegration, preload exposure, sender validation IPC, CSP, navigation, external links, download/file access, credential storage, package vulnerabilities, deprecated APIs, native addon rebuild, dependency license dan data paths.
Gunakan dokumentasi resmi yang sesuai versi; sertakan URL/section. Jika tidak bisa mengakses internet, tandai bagian yang memerlukan verifikasi.
Hasil berupa tabel severity, lokasi file, bukti, dampak, perbaikan paling kecil, regression test.
Jangan menginstal package baru tanpa persetujuan.

Prompt 7: Finalisasi build dan tiga opsi distribusi

Aplikasi telah melewati quality gates. Target OS [WINDOWS 10/11 x64]. Packaging tool terkunci: [NAMA dan VERSI].
Jangan mengubah framework, toolchain atau dependency secara sepihak.
Saya ingin membandingkan dan bila didukung menghasilkan:
A. Installer (Setup/format maker yang sesuai),
B. portable EXE satu file HANYA jika target builder mendukungnya,
C. folder lengkap executable/resources yang berjalan tanpa Node/npm terpasang.
Buat tabel konfigurasi, perintah build, nama file hasil, lokasi artifact, prasyarat, dan cara uji.
Untuk mode C buat scripts/create-shortcut.bat yang membuat .lnk di desktop user saat dijalankan, relatif terhadap lokasi file BAT, tidak memakai administrator, dan melaporkan error jika EXE tidak ditemukan.
Pastikan code signing policy, icon, app ID, versioning, data storage, user permissions, native modules, ASAR, logging dan update strategy dipertimbangkan.
Jangan mengatakan format B tersedia sebelum dibuktikan dengan konfigurasi/tool terkait.
Lakukan fresh-machine validation checklist: tanpa Node, path berspasi, tanpa admin, login user berbeda, pindah folder, data persist, uninstaller, Windows warnings, update dan rollback.
Laporkan artifact dan hasil nyata; jika environment tidak mendukung pengujian Windows, tulis 'BELUM DIUJI DI WINDOWS'.

Prompt 8: Release gate: keputusan GO/NO-GO

Buat release audit GO/NO-GO berdasarkan evidence, bukan opini.
Input: docs/RELEASE_CHECKLIST, test log, paket build, screens UI, dependency lockfile, git diff/changelog.
Kelompokkan semua temuan: blocker, major, minor, documentation.
Setiap isu wajib punya reproduksi, dampak, pemilik, langkah perbaikan dan verification status.
Tidak boleh status GO jika ada blocker pada data loss, IPC/security, fungsi inti, storage atau packaged startup.
Tuliskan jelas tes yang belum dikerjakan dan risiko tersisa.
Jangan menutup issue hanya berdasarkan pernyataan AI tanpa verifikasi.

Checklist rilis berbasis bukti

Kelompokkan verifikasi sebelum GO: fungsional (validasi, cancel nyata, persist data, import atau export), visual (token, state tombol, progress jujur, collision overlay, resize dan zoom), teknis (console bersih, tes otomatis, native deps, IPC dan secret), release (packaged run, icon dan versi, installer uninstall, integritas folder, BAT shortcut, changelog). Dokumentasikan screenshot, log terminal, versi dependency, dan daftar bug terbuka.

Tolak status GO bila masih ada blocker kehilangan data, kebocoran secret di renderer, atau gagal startup packaged meskipun dev server lancar.

FAQ pemula Electron dan AI

Berikut jawaban singkat untuk pertanyaan yang sering muncul setelah membaca prompt pack di atas.

• Harus kuat JavaScript dulu? Dasar JavaScript dan npm sangat membantu membaca diff AI dan menolak patch berbahaya. Tanpa itu, Anda tetap bisa memakai asisten, tetapi review manusia menjadi lebih lambat dan riskan.
• Apa beda Electron, React, Vue, dan Tailwind? Electron membungkus desktop dan OS. React atau Vue mengatur komponen UI di renderer. Tailwind utility CSS di renderer, bukan engine desktop.
• Bisa pakai PHP, Laravel, MySQL langsung di app? Database server umumnya diakses via backend API, bukan credential langsung dari UI. SQLite lokal cocok offline-first di main process.
• Kenapa UI bagus tetapi Cancel atau progress gagal? Umumnya state UI tidak terikat job async di main, atau cancel hanya menutup view. Perbaiki kontrak feature matrix dan tes double submit.
• Apa beda npm start, folder app, portable, installer? Dev server hanya untuk pengembangan, folder packaged membawa runtime bundel, installer mengatur path dan uninstall, sedangkan portable single file hanya valid bila tool dan konfigurasi Anda benar-benar menghasilkan format itu.
• Apakah pengguna perlu Node.js, dan kenapa packaged sering gagal? Pengguna akhir tidak perlu Node bila artefak release sudah benar karena Node sudah dibundel Electron. Kegagalan packaged setelah dev lancar umumnya berasal dari path ASAR, native module, atau variabel lingkungan yang hanya ada di mesin pengembang, jadi uji build folder packaged sedini mungkin.
• Bagaimana maintain app buatan AI? Kunci versi, jadwalkan audit dependency, pakai feature matrix sebagai regressions guide, dan jangan merge diff besar tanpa tes.

Langkah berikutnya setelah membaca: kunci versi Electron dari dokumentasi supported releases, isi PROJECT_SPEC satu halaman, jalankan prompt tahap 0 tanpa kode, lalu scaffold minimal dan build packaged folder sebelum menambah fitur besar. Anggap klaim AI tentang kompatibilitas versi atau format portable sebagai hipotesis yang perlu diverifikasi di mesin Anda.