snapme

Publik

Branch: master
Commit terakhir: 130fdb828 Oktober 2026

Keputusan teknis snapme

Dicatat saat pengerjaan milestone. Satu entri: tanggal, keputusan, alasan, bukti.

M0 Fondasi (8 Oktober 2026)

Registry neobrutalism: dipakai sebagai titik awal `button`, `badge`, `card`

Keputusan ARCHITECTURE §3. Bukti pemeriksaan:

Repo neobrutalism/neobrutalism (situs retroui.dev, sekarang mengarah ke neobrutalism.com): push terakhir 2026-08-03T09:28:45Z, 1.616 bintang, 60 fork, lisensi MIT, tidak diarsipkan. Lolos syarat aktivitas ARCHITECTURE §2 (rilis/commit dalam 12 bulan terakhir). Sumber: https://api.github.com/repos/neobrutalism/neobrutalism.
Perintah registry yang dipakai: npx shadcn@latest add https://neobrutalism.com/r/radix/button.json https://neobrutalism.com/r/radix/card.json https://neobrutalism.com/r/radix/badge.json -y -o. Varian radix dipilih karena shadcn/ui di proyek ini memakai primitif Radix.
Kriteria kelayakan (ARCHITECTURE §3 langkah M0):
1. Terpasang bersih pada Tailwind v4 + React 19: ya. CLI hanya menulis tiga berkas, tanpa dependensi baru (radix-ui dan class-variance-authority sudah ada dari shadcn init).
2. Varian CVA bisa dipetakan ke token snapme tanpa menulis ulang struktur: ya. Struktur cva + Slot sama dengan shadcn/ui; yang diganti hanya kelas.
3. Tanpa dependensi runtime tambahan: ya.
Yang diganti ke token snapme (DESIGN-SYSTEM §9): border-black menjadi border-ink, shadow-md/shadow-lg (bayangan lunak bawaan Tailwind) menjadi shadow-hard/shadow-hard-hover, rounded/rounded-xl menjadi rounded-pill/rounded-card, font-head menjadi font-display/font-sans, ukuran menjadi 44 px (sm) dan 56 px (lg), plus cincin fokus outline-violet 3 px jarak 3 px.
Ketiga berkas itu sekarang bergaya snapme, jadi tidak ada kode registry yang tersisa apa adanya. Registry dicatat di sini supaya perbandingan berikutnya tahu asalnya.

Penyimpangan dari dokumen

Hal	Dokumen	Kenyataan	Tindakan
Struktur `globals.css`	DESIGN-SYSTEM §13 menampilkan blok `@theme` dan `:root`	Keluaran `shadcn init` (preset `nova`, primitif `radix`) kini juga menambah `@import "tw-animate-css"`, `@import "shadcn/tailwind.css"`, `@custom-variant dark`, `@theme inline`, dan skala radius turunan	Struktur keluaran dipertahankan sesuai perintah §13 ("pertahankan strukturnya, ganti nilainya"), nilainya diambil dari §13
`--color-muted` ganda	§2 memakai `muted` sebagai warna teks, `:root` §13 memetakan `--muted` ke `cream`	shadcn memetakan `bg-muted` ke permukaan netral. Dua arti untuk satu nama	`--color-muted` tetap #5E5E57 (teks sekunder). Permukaan netral memakai `bg-cream`. Pemetaan `--color-muted` dari shadcn dihapus dari `@theme inline`
Bayangan hover 5 px	§7 mewajibkan bayangan 5 px saat hover, tapi §4 tidak punya tokennya	Tanpa token, nilainya harus ditulis di komponen, melanggar §14	Ditambah token `--shadow-hard-hover: 5px 5px 0 var(--color-ink)` di `globals.css`
Radius tooltip	§9 menyebut radius 8 px	§4 hanya punya `radius-thumb` 10 px sebagai nilai terdekat	Tooltip memakai `rounded-thumb` (10 px). Perlu satu kalimat di §9 atau token baru
Blok `.dark` bawaan shadcn	§0 dan §12: tema terang saja di v1	`shadcn init` menulis blok `.dark` dengan nilai oklch tersendiri serta pemetaan `--color-sidebar-` dan `--color-chart-`	Blok `.dark` dan token `sidebar`/`chart` dihapus (tidak ada komponen yang memakainya). `@custom-variant dark` dipertahankan supaya utilitas `dark:` tidak pernah aktif tanpa kelas `.dark`
Ikon di `components.json`	§8: ikon selalu Phosphor	shadcn menulis `"iconLibrary": "lucide"` dan memasang `lucide-react`	Diubah ke `"phosphor"` supaya komponen yang ditambah kemudian memakai `@phosphor-icons/react`; `lucide-react` dilepas dari dependensi
`next-themes`	Tidak ada di ARCHITECTURE §3	`shadcn init` memasangnya untuk `sonner`	Pemakaian `useTheme` di `sonner.tsx` dihapus (tema terang saja), paket dilepas
Halaman `/`	MILESTONES M1 membangun Welcome	Bawaan `create-next-app` menampilkan halaman contoh Next.js	Diganti placeholder kecil (judul snapme + penunjuk ke `/dev/ui`); aset contoh `public/*.svg` dihapus
Penanda baca `tests/`	ARCHITECTURE §4 menaruh uji di `tests/` dan `e2e/`	Uji menjalankan matcher bawaan Vitest, bukan `@testing-library/jest-dom`	Tidak menambah dependensi; asersi memakai `expect` bawaan
Nama berkas konfigurasi Vitest	Rencana menyebut `vitest.config.ts`	Vite memuat berkas `.ts` sebagai CommonJS karena `package.json` tanpa `"type": "module"`, dan memperingatkannya	Berkas dinamai `vitest.config.mts`; `tsconfig.json` sudah memuat `*/.mts`

Penyesuaian pada kode registry shadcn/ui

Semua perubahan berikut hanya menyentuh kelas Tailwind dan susunan internal komponen; struktur, nama ekspor, data-slot, dan perilaku Radix tidak diubah.

Hal	Kenyataan di kode registry	Tindakan
`react-hooks/set-state-in-effect` pada `carousel.tsx`	Registry memanggil `onSelect(api)` di dalam `useEffect`, dan ESLint Next 16 menandainya sebagai galat	Nilai `canScrollPrev`/`canScrollNext` dibaca saat render dari embla; langganan `select`/`reInit` hanya memicu render ulang. Perilaku sama, aturan tidak dimatikan
Prop cadangan	`Switch` punya prop `size`, `ToggleGroup` punya `variant` dan `spacing`, `Tabs` punya `variant="line"` dan ekspor `tabsListVariants`	Dihapus karena DESIGN-SYSTEM §9 hanya menspesifikasikan satu gaya dan tidak ada pemakainya
Thumb sakelar	§9 menetapkan track 56 x 32 px tanpa ukuran thumb	Berkas acuan `customize.html` memakai thumb 28 px yang mengisi tinggi track; komponen disamakan ke ukuran itu, dengan jarak jalan 24 px
Tombol tutup lembar bawah	Registry tidak menyediakan tombol tutup	Ditambah `Button` ghost 44 px dengan ikon `X`, konsisten dengan `dialog.tsx`
Panah tooltip	Registry memakai `rounded-[2px]` (radius mentah di luar token)	Kelas radius dihapus; panah memakai `bg-ink` sehingga menyatu dengan garis tepi
Durasi dialog	Registry memakai `duration-100`	Diganti `duration-[120ms]` mengikuti DESIGN-SYSTEM §7
Impor `cn`	Berkas registry sebagian mengimpor dari paket `cn`, sebagian dari `@/lib/utils`	Dibiarkan seperti aslinya; `src/lib/utils.ts` hanya me-re-export dari paket `cn`, jadi keduanya sama
Overlay dialog dan lembar bawah	§9 tidak menetapkan warna overlay	Dipakai `bg-ink/60`, warna token yang sudah ada, tanpa efek kaca atau blur

M1 Welcome dan kerangka booth (9 Oktober 2026)

Audit aksesibilitas M1

Otomatis. e2e/a11y.spec.ts menjalankan axe-core 4.14 lewat @axe-core/playwright pada empat halaman M1 (/, /privasi, /booth/layout, /booth/capture) di dua lebar (360 dan 1280 px), dengan tag wcag2a, wcag2aa, wcag21a, wcag21aa, wcag22aa. Hasil: nol pelanggaran pada delapan pemindaian. Uji ini permanen, jadi regresi aksesibilitas M1 akan ketahuan.

Manual (skrip sekali pakai di luar repo, karena alat otomatis hanya menangkap sebagian hambatan):

Pemeriksaan	Hasil
Urutan fokus	Logis dan mengikuti urutan visual di keempat halaman. `/booth/capture` hanya punya dua sasaran (wordmark dan Kembali) karena isinya masih kerangka
Penanda fokus terlihat	Ada di setiap elemen yang bisa difokus (cincin `violet` 3 px atau garis tepi `ink`)
Ukuran sasaran (2.5.8 AA)	Sasaran terkecil 40 x 40 px (kotak wordmark), batas 24 x 24 px. Tombol 44 sampai 56 px
Landmark	`header`, `nav`, `main`, dan `footer` di `/` dan `/privasi`; `header` dan `main` di halaman booth
Hierarki judul	`h1` lalu `h2` lalu `h3`, tanpa lompatan, di keempat halaman
Bahasa halaman	`lang="id"` di akar dokumen

Perbaikan yang lahir dari audit: / sebelumnya tidak punya landmark main; konten hero sampai panel langkah sekarang dibungkus main, dan kaki privasi tetap di luarnya. Pemeriksaan pembaca layar nyata (NVDA atau VoiceOver) dan zoom 200 persen tetap dijadwalkan di M9.

Penyimpangan dan keputusan M1

Hal	Dokumen	Kenyataan	Tindakan
CTA di baris atas	§10.1 dan `welcome.html` memakai tombol `primary sm`	§1 melarang dua tombol jingga per layar dan §14 menuntut tepat satu aksi `primary`	Welcome dan booth: CTA header varian `secondary`. `/privasi` tidak punya aksi lain: CTA header varian `primary`. `SiteHeader` menerima prop `ctaVariant`
`display-lg`	§3: pink + bayangan keras, tanpa garis tepi huruf. Berkas acuan `capture.html` menambah `-webkit-text-stroke: 1px`	Dokumen menang	Tanpa garis tepi huruf. Dengan begitu 22 px pada layar sempit tetap lolos sebagai teks besar (3,36 : 1, batas 3 : 1)
Judul ubin Gesture Snap	`welcome.html` memakai 28 px	§3 membatasi `title` pada 16 sampai 22 px	Semua judul kartu memakai `title` 22 px. Perbedaan tampak saat dibandingkan berdampingan, disengaja
Judul panel "Dari kamera sampai cetak"	`welcome.html` memakai `clamp(18px, 2vw, 24px)`	§3 tidak punya gaya di rentang itu	Memakai `title` 22 px
Kotak wordmark	`welcome.html` memakai radius 12 px	§4 hanya punya `radius-thumb` 10 px	Memakai `rounded-thumb`. Perlu satu kalimat di §4 atau token baru bila 12 px memang disengaja
Slot kosong pada diagram hero	§4 menetapkan `border-empty` 2 px putus-putus `muted`	`muted` di atas `violet-soft` hanya 2,89 : 1, di bawah batas 3 : 1 untuk komponen nonteks	Diagram hero memakai garis putus-putus `ink` (8,3 : 1). Slot kosong di atas `cream` atau `paper` tetap memakai `muted`
Pilihan layout	§9 hanya menspesifikasikan "Swatch terpilih"	Radio asli perlu bisa diklik di seluruh kartu	Radio ditumpuk selebar kartu dengan `opacity-0`, kartu jadi sasaran klik, nama aksesibel dari `aria-labelledby` dan `aria-describedby`. Dibuktikan uji Playwright
Tombol "Pakai Foto Galeri"	§10.1 menampilkannya di hero	FR-13 masuk P1 dan MILESTONES M1 menundanya	Belum ditampilkan. Perbedaan tunggal pada pembandingan teks dengan `welcome.html`
Utilitas baru di `globals.css`	§3, §5, §6, §9	Gaya ini dipakai lebih dari satu halaman	Ditambah `page-container`, `checker-ribbon`, `display-xl`, `display-lg`, `heading`, `title`, `ring-selected` supaya tidak ada nilai mentah di komponen
Cakupan `/booth/capture`	§10.2 menggambarkan kamera, baki foto, HUD gesture	M2 sampai M4 yang mengerjakannya	M1 hanya kerangka: area kamera kosong, slot kosong, aksi utama nonaktif. `CameraStage`, `ShotTray`, `ShutterButton`, `CountdownOverlay` belum dibuat
Cakupan `stores/booth.ts`	§5 mencantumkan `shots`, `editor`, `live`, `share`, `relay`	Milestone M1 belum memakainya	Hanya `layoutId` dan `settings` yang dibuat, sisanya menyusul bersama milestone pemiliknya supaya tidak ada tipe spekulatif
Halaman `/booth/layout`	§5 menamai rute ini	Nama folder segmen sama dengan berkas konvensi `layout.tsx`	Next 16 menerimanya: `src/app/booth/layout.tsx` dan `src/app/booth/layout/page.tsx` berdampingan. Dibuktikan build dan uji Playwright

M2 Kamera (10 Oktober 2026)

Mesin keadaan pemotretan: `src/features/capture/machine.ts`

Fase: idle, requesting, denied, ready, holding, countdown, capturing, pause, complete (ARCHITECTURE §5). Peristiwa: PERMISSION_REQUEST, PERMISSION_GRANTED, PERMISSION_DENIED{reason}, SHOOT{target?}, HOLD_START, HOLD_CANCEL, TICK, SHOT_SAVED, FLASH_DONE, PAUSE_DONE{allFilled}.
reduce adalah fungsi murni: peristiwa yang datang di fase yang salah mengembalikan objek state yang sama, jadi tidak ada render ulang yang sia-sia. Diuji 8 uji di tests/capture-machine.test.ts, termasuk tabel "peristiwa diabaikan" untuk tujuh fase.
Timer ada di useCaptureMachine.ts, bukan di reducer: 1000 ms per angka hitung mundur (COUNTDOWN_STEP_MS), jeda 300 ms setelah jepret (PAUSE_MS), kilat 160 ms (FLASH_MS). PAUSE_DONE membaca ulang store saat timer berbunyi, jadi keputusan "lengkap atau kembali siap" selalu memakai jumlah foto terbaru.
Flag kilat ikut state mesin, bukan state halaman: React 19 lewat ESLint Next 16 melarang setState langsung di dalam efek (react-hooks/set-state-in-effect), dan kilat harus tetap menyala saat fase sudah berpindah ke pause. Timer kilat karena itu bergantung pada flash, bukan pada phase, supaya tidak dibersihkan saat fase berganti.
Yang sudah disiapkan untuk M3: HOLD_START/HOLD_CANCEL sudah bertransisi ready ke holding dan kembali, CameraStage sudah punya slot hud, dan isBusy/canShoot adalah tabel per fase yang bisa dipakai HUD tanpa menebak.

Kamera: `src/features/camera/`

useCamera.ts adalah satu-satunya tempat react-webcam dipakai. <Webcam> baru dipasang setelah requested bernilai true, dan useCamera.requestPermission() menolak lebih dulu bila navigator.mediaDevices.getUserMedia tidak ada (unavailable), jadi konteks tidak aman tidak membuat halaman gagal render.
Pemetaan galat: NotAllowedError dan SecurityError menjadi denied; sisanya (NotFoundError, NotReadableError, OverconstrainedError, dan string "getUserMedia not supported" dari react-webcam) menjadi unavailable. Dua pesan berbeda ditampilkan, keduanya menyebut langkah berikutnya (DESIGN-SYSTEM §12).
captureFrame.ts memotong bingkai tengah ke rasio slot lalu mencerminkannya (translate + scale(-1, 1)) supaya hasilnya sama dengan pratinjau yang dicerminkan (FR-05). Hasil disimpan sebagai dataURL JPEG mutu 0,92; resolusi hasil sama dengan resolusi sumber yang dipotong (1280 x 720 menjadi 1022 x 720 pada Strip 4), penurunan skala baru terjadi di kanvas hias M4.
ref ke <Webcam> wajib. react-webcam menaruh HTMLVideoElement di properti instans (webcamRef.current.video); tanpa ref di pemakaian komponen, webcamRef.current selalu null dan tidak ada foto yang tersimpan. Ketahuan dari uji Playwright pertama yang gagal.
Video yang dicerminkan punya stacking context sendiri. Karena mirrored memasang transform: scaleX(-1), elemen video dicat setelah elemen berposisi absolut yang datang lebih dulu di DOM, sehingga braket bidik tertutup. Braket diberi z-10.
Perangkat: enumerateDevices() dipanggil ulang di onUserMedia (label baru terbaca setelah izin), disaring ke videoinput, dan pilihannya disimpan di settings.cameraDeviceId (hanya di memori, tanpa penyimpanan lintas muat ulang). Mengganti perangkat mengubah videoConstraints, dan react-webcam meminta ulang stream saat videoConstraints berubah; shots tidak tersentuh.

Kamera palsu di uji Playwright

playwright.config.ts menambah launchOptions.args --use-fake-ui-for-media-stream dan --use-fake-device-for-media-stream pada proyek chromium (ARCHITECTURE §10). Berlaku untuk seluruh berkas uji; uji M1 tidak terpengaruh karena tidak membuka kamera.

Catatan dari penulisan uji:

Hal	Kenyataan	Tindakan
Menunggu izin benar-benar selesai	Elemen `<video>` sudah ada beberapa ratus milidetik sebelum stream mengalir, jadi menunggu elemennya terlihat adalah balapan	Helper `izinkanKamera` menunggu `video.videoWidth > 0`
Stream sintetis untuk uji cermin	`react-webcam` memanggil `getUserMedia` lebih dari sekali (mount ganda di mode pengembangan) dan menghentikan stream yang dianggap basi, sehingga stream bersama mati sebelum dipakai	Skrip uji membuat stream baru tiap panggilan, dan kanvas sumbernya terus digambar ulang supaya bingkai mengalir
Klik "Izinkan Kamera" gagal	Baris tombol jepret (absolut, selebar panggung) menutupi tombol izin pada panggung yang pendek	Kontrol jepret hanya dirender saat kamera sudah diminta dan izin bukan `denied`, dan pembungkusnya `pointer-events-none`

Penyimpanan foto di M2

stores/booth.ts menyimpan shots: (Shot | null)[] dengan Shot = { still: string; capturedAt: number }, still berupa dataURL JPEG di memori. setLayout mengganti seluruh array sehingga invarian shots.length === shotCount selalu berlaku, dan mengganti layout mengosongkan foto. Penyimpanan lintas muat ulang (FR-14, IndexedDB) tetap milik M5.

useRequireShots() menutup prasyarat langkah setelah foto: /booth/customize dialihkan ke /booth/capture selama masih ada slot kosong. Halaman Hias sendiri masih placeholder karena M4 yang membangunnya.

Penyimpangan M2

Hal	Dokumen atau acuan	Kenyataan	Tindakan
Tombol jepret dan chip "Spasi" saat belum ada kamera	`capture.html` selalu menampilkan keduanya	Keduanya menutupi tombol "Izinkan Kamera" pada panggung yang pendek, dan tidak ada gunanya sebelum kamera hidup	Baris kontrol hanya dirender setelah kamera diminta dan izin bukan `denied`
Sudut braket bidik	`capture.html` memakai radius 6 px	§4 tidak punya token 6 px dan §6 hanya menyebut "empat sudut garis 4 px lime"	Sudut tegak tanpa radius. Dokumen menang
Radius chip pintasan "Spasi"	`capture.html` memakai 8 px	§4 hanya punya `radius-thumb` 10 px; `rounded-sm` memetakan ke 8,4 px	Memakai `rounded-sm` (8,4 px), token terdekat
Judul kartu "Senyum, kamera siap!"	Acuan memakai Unbounded 800 16 px	§3 mengizinkan `title` 16 sampai 22 px, tetapi utilitas `title` dipatok 22 px	Kartu ini memakai `font-display text-base font-extrabold` (16 px) supaya sama dengan acuan
Slot terisi di baki foto	Acuan memakai blok warna berlabel "Foto 1", "Foto 2"	Produk menampilkan foto hasil kamera (FR-05)	Foto asli dengan lencana centang; teks demo tidak dipakai
Legenda gesture, sakelar Gesture Snap, GestureHUD, RelayInviteCard, kata "gesture" di baris privasi	§10.2 menggambarkannya lengkap	Milik M3 dan M8	Tidak dirender di M2; baris privasi berbunyi "Kamera berjalan di perangkat ini." Kartu tip lime tetap ada dengan tiga baris yang benar untuk M2
Tombol pemilih kamera di kepala panel	Tidak ada di acuan	FR-08 (P1) menambahkannya	Tombol `neutral sm` berlabel perangkat + daftar tombol perangkat (pola disclosure, bukan komponen baru). Hanya dirender bila perangkat lebih dari satu
Aksi utama jingga ganda saat semua slot terisi	§2: satu aksi utama jingga per layar	Tombol jepret dan "Lanjut Hias" sama-sama jingga, persis seperti acuan	Diikuti acuan; keduanya memang disebut di §2 dan §9
Jeda antar angka hitung mundur	§7 menetapkan animasi angka 500 ms, tidak menetapkan jeda antar angka. `capture.html` memakai 800 ms	FR-06 menyebut hitung mundur 3 detik	1000 ms per angka (3, 2, 1) supaya totalnya pas 3 detik seperti FR-06; animasi masuknya tetap 500 ms dengan lewatan 1,08 seperti §7. 800 ms di acuan hanya pacing demo

M3 Gesture Snap (9 Oktober 2026)

Aset wasm dan model

public/mediapipe/wasm/ berisi enam berkas salinan node_modules/@mediapipe/tasks-vision/wasm/ (vision_wasm_internal.{js,wasm}, vision_wasm_module_internal.{js,wasm}, vision_wasm_nosimd_internal.{js,wasm}). Disalin apa adanya, tidak ada CDN (ARCHITECTURE §4, §8). Berkas-berkas ini dikecualikan dari ESLint lewat globalIgnores karena ditulis Emscripten dan gagal aturan proyek (require(), alias this). Sejak pengecilan repo (17 Oktober 2026) penyalinannya dikerjakan scripts/copy-mediapipe-wasm.mjs dari postinstall, jadi enam berkas itu tidak lagi ikut di git; model di baris berikut tetap di-commit karena tidak bisa dibuat ulang dari paket.
public/models/gesture_recognizer.task (8.373.332 bita) diunduh dari URL resmi dokumentasi GestureRecognizer Web: https://storage.googleapis.com/mediapipe-tasks/gesture_recognizer/gesture_recognizer.task.
FilesetResolver.forVisionTasks("/mediapipe/wasm") dan modelAssetPath: "/models/gesture_recognizer.task": tidak ada permintaan ke luar origin saat deteksi berjalan. Dibuktikan uji Playwright GS-01.

Ambang awal dan satu penyimpangan rumus laju

src/features/gesture/thresholds.ts memuat nilai awal PRD §7.2: skor 0,6, tahan 800 ms, jeda 1.500 ms setelah foto, interval deteksi 80 ms (sekitar 12,5 kali per detik), bingkai diperkecil 320 px.

Penyimpangan dari rencana M3. Rencana menjadwalkan tik berikutnya max(0, 80 - elapsed). Diukur di Chromium headless tanpa GPU: satu inferensi memakan ratusan milidetik, sehingga jadwal itu berubah menjadi loop tanpa jeda yang memenuhi main thread. Akibatnya klik "Ambil foto" tertunda rata-rata 1,2 detik dan timer hitung mundur meleset. Perbaikannya: jeda minimal sama dengan durasi inferensi itu sendiri (max(80 - elapsed, elapsed)), jadi perangkat lambat turun ke siklus 50 persen dan timer UI tetap jalan. Perangkat yang sanggup inferensi di bawah 80 ms tetap 12,5 kali per detik.

Penyimpangan M3

Hal	Dokumen atau acuan	Kenyataan	Tindakan
Keadaan HUD "siap"	`capture.html` merendernya sebagai tombol demo `onClick=`	Klik tidak punya makna di produk, dan §11 meminta HUD memakai `role="status"`	Dirender sebagai `role="status"` noninteraktif
Durasi indikator tahan	Animasi `hold` di `capture.html` 900 ms	PRD GS-02 menetapkan 0,8 detik	800 ms (`HOLD_DURATION_MS`); batang mengikuti progres sampel, bukan animasi tetap
Keadaan "Menyiapkan gesture..."	§9 menyebut empat keadaan HUD	GS-07 meminta status memuat	Ditambah keadaan kelima `loading` di luar empat keadaan acuan
Delegate model	Rencana: GPU dengan fallback CPU	Di headless tanpa WebGL, `createFromOptions` gagal dan fallback CPU dipakai otomatis	GPU dulu, satu percobaan ulang dengan CPU; kegagalan keduanya memicu jalur GS-07 (sakelar disembunyikan, satu toast)
`numHands`	GS-10 (P1) meminta dua tangan	Konfigurasi model tidak bisa diubah tanpa memuat ulang model	`numHands: 2` dipasang sejak P0 supaya GS-10 tidak mengubah konfigurasi
Legenda gesture di kartu lime	Acuan memakai tiga baris (dua jari, telapak, jempol)	GS-08 dan GS-09 adalah P1	P0 sempat memakai dua baris; setelah P1 dikerjakan, legenda kembali ke tiga baris acuan persis (`HandPeace`, `HandPalm`, `ThumbsUp`)
Penanganan gesture P1	GS-08 (telapak mengulang foto terakhir), GS-09 (jempol lanjut ke hias), GS-10 (dua tangan)	Dikerjakan setelah P0 tuntas	`useGestureSnap` menangani aksi `retake` pada fase `ready` dan `complete` (dispatch `SHOOT` dengan target) dan `proceed` pada fase `complete` (`onProceed`). Loop juga berjalan di fase `complete` saat ada foto yang bisa diulang; kedua aksi tidak menyentuh fase `holding` mesin. GS-10 hanya konfigurasi `numHands: 2`
Uji kamera di Playwright	Rencana: seluruh uji memakai bawaan sakelar menyala	Chromium headless tanpa GPU butuh ratusan milidetik per inferensi, sehingga hitung mundur pada uji alur kamera bisa meleset	`e2e/capture.spec.ts` mematikan sakelar lewat localStorage (berkas ini menguji kamera, bukan gesture); `e2e/gesture.spec.ts` menguji sakelar menyala dan menunggu model siap sebelum memotret
Batas `expect` Playwright	Bawaan 5 detik	Inisialisasi model dan inferensi pertama di headless memblokir main thread beberapa detik	`expect.timeout` 15 detik di `playwright.config.ts`, dengan komentar alasan
Wrapper `foto`/`sampel` uji	Uji M2 memakai `getByRole("status")` untuk hitung mundur	HUD gesture juga `role="status"` sehingga selektornya ambigu	`CountdownOverlay` diberi `data-testid="countdown"`; helper uji memakai selektor itu
Pil HUD di 360 px	`capture.html` satu baris (252 x 44 px)	Dengan fon yang sama (Space Grotesk 700 15 px) produk butuh sekitar 264 px, jadi teks membungkus dua baris dan pil menjadi 49 px	Dibiarkan membungkus: min-height 44 px tetap terpenuhi dan pil tetap di tengah. Perbedaan lebar berasal dari rupa fon acuan di lingkungan uji, bukan dari token

Perbandingan berdampingan dengan `capture.html`

Dijalankan dengan Playwright pada 1280 dan 360 px, memakai getComputedStyle dan getBoundingClientRect; tangkapan layarnya sementara dan tidak disimpan di repo.

Bagian	Acuan	Produk
Pil siap 1280 px	297 x 44, `paper`, garis 2 `ink`, radius 999, 15 px/700, padding 0 16, gap 10	297 x 44, nilai sama persis
Pil siap 360 px	252 x 44, satu baris	244 x 49, dua baris (lihat penyimpangan di atas)
Pil selesai	187 px, `lime`, radius 999, 15 px/700, gap 8	187 px, `lime`, radius 999, 15 px/700, gap 8
Pil menahan	`lime`, radius 16, padding 10 16, gap 6, batang 8 px `violet` di rel `paper`	Nilai sama dari `GestureHUD`; keadaan menahan hanya bisa dipicu tangan sungguhan, jadi dibuktikan uji komponen `tests/gesture-hud.test.tsx` (lebar batang mengikuti progres)
Sakelar Gesture Snap	`paper`, garis 2 `ink`, radius 999, min-height 44, padding 0 8 0 16, 15 px/700, chip `lime` "Nyala" / `cream` "Mati"	Sama persis sampai ukuran chip; `aria-pressed` mengikuti keadaan
Legenda	"Dua jari: mulai hitung mundur", "Telapak: ulang foto terakhir", "Jempol: lanjut ke hias"	Sama persis
Baris privasi	"Kamera dan deteksi gesture berjalan di perangkat ini. Tidak ada yang diunggah."	Sama persis

Sumber satu-satunya modul MediaPipe

src/features/gesture/gestureSource.ts adalah satu-satunya pengimpor @mediapipe/tasks-vision, dan impornya dinamis (await import(...)) sesuai ARCHITECTURE §9, jadi bundel Welcome dan langkah lain tidak ikut berat. Impor statis sengaja dihindari; alasannya ditulis di komentar berkas itu.

Perkakas: createGestureSource mengembalikan start (mulai loop), stop (jeda loop, model tetap hidup), dan close (tutup model). Pemisahan ini penting: menghentikan loop selama hitung mundur tidak boleh membuang model, kalau tidak setiap foto menunggu muat ulang model.

Uji manual (diisi pengguna)

Deteksi gesture tidak bisa diverifikasi dengan kamera palsu: kamera palsu tidak punya tangan. Isi tabel ini setelah mencoba di perangkat nyata: buka /booth/capture, nyalakan Gesture Snap, lakukan 10 kali tanda dua jari di bawah cahaya yang biasa dipakai, dan catat berapa yang memicu hitung mundur.

Perangkat	Browser	Cahaya	Berhasil dari 10	Catatan
HP (pengguna)	tidak dirinci	tidak dirinci	tidak dihitung; pengguna melaporkan "bisa"	Laporan pengguna 16 Oktober 2026
Laptop	-	-	belum diuji	Tidak dilaporkan pengguna

Ambang akhir yang dipakai: skor 0,6, tahan 800 ms, jeda 1.500 ms, interval 80 ms. Bila hasil uji manual menunjukkan lemah, ubah hanya src/features/gesture/thresholds.ts (satu berkas konstanta, ARCHITECTURE §6) dan ulangi tabel di atas.

Laporan pengguna 16 Oktober 2026 hanya menyebut "sudah saya coba di HP dan hasilnya bisa", tanpa jumlah keberhasilan dari 10 percobaan dan tanpa uji laptop. Ambang karena itu tidak diubah: tidak ada keluhan deteksi yang perlu dijawab angka baru, dan menurunkan ambang tanpa data akan menaikkan risiko pemicu tak sengaja. M3 dicentang atas konfirmasi pengguna itu, dengan dua kekurangan yang dicatat apa adanya: jumlah "berhasil dari 10" dan uji laptop tidak tersedia.

M4 Hias strip (9 Oktober 2026)

12 stiker: SVG ditulis tangan

Keputusan pengguna untuk M4. DESIGN-SYSTEM §8 mengizinkan stiker berupa gambar buatan yang ditinjau manusia; menulis SVG langsung menghindari langkah tinjauan gambar dan menjaga berkas tetap kecil (247 sampai 1.213 bita per berkas).

Spesifikasi seragam: viewBox="0 0 256 256", isian warna datar dari palet §2, stroke="#141414" stroke-width="14" stroke-linejoin="round", tanpa gradasi, tanpa teks, tanpa defs/style/filters, dan gambar dijaga di dalam batas 10 px supaya garis tepi 14 px tidak terpotong bingkai. Nilai heks di public/stickers/ boleh ada karena kriteria M0 memindai src/ saja.

Satu berkas diperbaiki setelah render pertama: cloud.svg semula tersusun dari tiga lingkaran bergaris; garis lingkaran yang tertimpa lingkaran berikutnya tetap terlihat sebagai busur hitam di dalam badan awan. Sekarang satu <path> tertutup yang menelusuri gabungan siluet (tiga busur atas plus alas membulat), jadi tidak ada garis dalam.

Frame sebagai data, bukan berkas di `public/frames/`

ARCHITECTURE §4 mencantumkan public/frames/, tetapi frame di M4 adalah kombinasi warna geometris (latar, garis slot, warna wordmark) yang digambar Konva dari data. Aset raster akan menambah bobot dan kabur saat diskalakan ke 600 x 1800. public/frames/ karena itu tidak dibuat, dan frame ditunda sebagai keputusan yang perlu dikonfirmasi: bila nanti frame bergambar memang diinginkan, ia masuk sebagai aset tambahan di samping enam frame warna ini.

Enam pasangan warna yang dipakai semuanya ada di tabel kontras §2: klasik (paper/ink), malam (ink/paper/lime), limau (lime/ink), gulali (pink/ink), ungu (violet/paper), permen (violet-soft/ink).

Warna kanvas: token dibaca saat dipakai

Konva butuh nilai warna konkret, sedangkan DESIGN-SYSTEM §14 melarang nilai mentah di komponen. src/features/editor/tokenColor.ts membaca variabel token dari elemen akar (getComputedStyle(document.documentElement).getPropertyValue("--color-paper")), dan canvasFonts.ts membaca nama keluarga fon hasil next/font dari elemen probe berkelas font-display/font-sans/font-mono. Jadi token tetap satu sumber kebenaran, dan kanvas tidak menyimpan salinan heks.

Dibuktikan uji Playwright: piksel latar strip di kanvas sama dengan paper pada frame bawaan dan berubah jadi ink setelah memilih frame "Malam". Bila token tidak terbaca, nilainya kosong dan strip akan tembus pandang, sehingga pemeriksaan piksel ini menangkap kesalahan itu.

Cache filter Konva: `pixelRatio` 1, bukan 600 / lebar panggung

Rencana M4 menetapkan cachePixelRatio = 600 / lebar tampilan panggung. Setelah membaca Node.cache() di konva 10, ternyata rect cache dihitung dengan getClientRect({ skipTransform: true, relativeTo: parent }), yaitu di ruang induk node dan tidak terpengaruh skala panggung. Artinya pixelRatio: 1 sudah menghasilkan kanvas cache sebesar ukuran strip (mis. 528 x 372) dan tetap tajam saat ekspor, sedangkan nilai dari rencana akan membengkakkan memori tanpa menambah ketajaman. Dipakai pixelRatio: 1 di src/features/editor/filters.ts.

Pemetaan efek ke filter bawaan Konva: pop = HSV (saturation 1,6) + Contrast (1,15), piksel = Pixelate (pixelSize 12), lembut = Blur (1,2) + Brighten (0,08), sisanya Grayscale, Sepia, dan Invert tanpa parameter. Diuji di browser dengan membandingkan sidik jari piksel kanvas sebelum dan sesudah efek dipasang; Retro mengubahnya besar, Piksel mengubahnya kecil tetapi konsisten (foto uji berupa gradien halus, jadi blok 12 px hampir sama dengan aslinya).

Ekspor PNG (FR-11)

exportStrip bekerja dengan mengubah ukuran panggung di tempat menjadi 600 x 1800 lalu memulihkannya. Stage.toDataURL merender ulang layer ke kanvas baru, jadi kanvas yang terlihat tidak tersentuh, dan ukuran/skala dipulihkan secara imperatif karena prop React-nya tidak berubah sehingga react-konva tidak akan memasangnya lagi. Transformer di dalam panggung disembunyikan selama ekspor lewat nama editor-overlay.

Jalur kedua untuk batas 2 MB: bila PNG masih melebihi 2.097.152 bita, tiap foto slot digambar ulang lewat JPEG mutu 0,8 (menghaluskan derau yang tidak bisa dipadatkan PNG), lalu ekspor diulang sekali. Pada uji dengan foto gradien hasilnya 51 sampai 62 KB, jadi jalur ini belum pernah terpicu; ia tetap ada sebagai pagar untuk foto kamera sungguhan dan diuji manual pada M9.

Nama berkas snapme-YYYYMMDD-HHmm.png memakai waktu lokal. Unduhan dibuat lewat Blob + URL.createObjectURL (bukan data: langsung) supaya tidak menyentuh batas panjang URL, dan URL-nya dilepas setelah 10 detik.

Ukuran strip di panggung dan tata letak kaki strip

Empat angka yang lahir dari pembandingan berdampingan dengan customize.html:

Lebar panggung dijepit 180 sampai 216 px (rencana menulis 320). Acuan memakai strip 210 px pada semua lebar. Pada 216 px panel produk setinggi 879 px dan halaman 987 px, hampir sama dengan acuan (871 dan 998 px), sehingga tombol "Selesai & Unduh" tetap dekat lipatan layar. Pada 320 px strip menjadi 960 px dan aksi utama terdorong jauh ke bawah.
Warna seluruh teks kaki strip mengikuti warna wordmark frame. Semula teks pengguna memakai ink dan tanggal memakai muted; di frame "Malam" keduanya tidak terbaca (ink di atas ink) atau hanya 2,85 : 1 (muted di atas ink, di bawah batas 4,5 : 1 untuk teks 28 px yang dicetak sekitar 6,7 pt). Warna wordmark sudah dijamin lolos kontras §2 untuk setiap frame.
Kaki strip dibagi dua baris. Baris atas 100 px untuk wordmark dan tanggal, sisanya untuk teks pengguna. Sebelumnya teks bawaan di y 1698 menimpa wordmark yang tegak di tengah kaki.
Posisi bawaan teks pengguna y 1696, tepat di bawah baris atas kaki. Konva memakai lineHeight 1, jadi teks 44 px sepanjang 24 karakter paling banyak dua baris (88 px) dan tetap muat di dalam strip.

Penyimpangan M4

Hal	Dokumen atau acuan	Kenyataan	Tindakan
Kartu "Strip Hidup" dan "QR di strip" di rel kanan	§10.3 dan `customize.html` menampilkannya	Milik M6 dan M7	Tidak dirender di M4 sesuai keputusan pengguna. Rel kanan: ringkasan dan aksi utama saja
Tombol "Cetak 4R"	§10.3 dan acuan menampilkannya	FR-12 milik M5	Belum dirender
Frame sebagai berkas aset	ARCHITECTURE §4 mencantumkan `public/frames/`	Frame adalah data warna geometris	Folder tidak dibuat; alasannya di atas
Tombol stiker	Acuan: "Ketuk untuk menempel atau melepas" (toggle demo)	Stiker bisa ditempel berkali-kali dan dihapus dari kanvas atau daftar	Tombol berarti tempel; kalimat bantu diubah mengikuti perilaku produk
Tab "Teks"	Tidak ada di acuan	FR-10 (P1) menambah teks dan tanggal	Tab keempat ditambahkan; susunannya sama dengan tiga tab lain
Daftar "Isi strip" di bawah kanvas	Tidak ada di acuan	§11 mewajibkan padanan daftar untuk kanvas	Bagian baru di kolom tengah, hanya dirender bila ada isi
Pembacaan ukuran di daftar "Isi strip"	Rencana: `x · y · rotasi`	Kriteria M4 menuntut "Perbesar" terbukti menaikkan lebar, dan tak ada tempat lain yang menampilkannya	Pembacaan ditambah ukuran (`120 px`) dan tinggi fon (`44 px`)
Pilihan hias di layar sempit	Acuan menampilkan rel pilihan secara inline pada 360 px	§9 menetapkan Drawer sebagai lembar bawah untuk pilihan hias di layar sempit	Di bawah 768 px rel kiri menjadi tombol "Hiasan" yang membuka lembar bawah. Diuji Playwright pada 360 px
Chip "4 foto siap" di kepala panel	§10.3: "di kanan chip lime"	`BoothPanel` menaruh `chip` tepat setelah judul dan `actions` di kanan	Halaman Hias memakai `actions`, jadi chip berada di kanan seperti acuan; ditambah ikon centang seperti acuan
Hook `useHtmlImage`	Rencana: paket `use-image` dihindari, ditulis sendiri	Satu berkas 30 baris tanpa dependensi baru	Ditulis di `src/features/editor/useHtmlImage.ts`
Kembalian `exportStrip`	Rencana: `{ dataUrl, bytes }`	Jumlah bita hanya dipakai di dalam fungsi untuk memutuskan jalur kedua	Mengembalikan `dataUrl` saja; ambang 2 MB dijaga di dalam
Impor tipe Konva	`konva` hanya mengekspor default	Tipe kelas diambil dari submodul (`konva/lib/Stage`, `konva/lib/shapes/Image`)	Sesuai peta ekspor paket; tidak ada impor nilai tambahan
Peran ARIA tab pil	§9: `toggle-group` tunggal	Radix merender `radiogroup` dengan `radio` di dalamnya	Tidak diubah (perilaku dan aksesibilitas Radix tidak disentuh, ARCHITECTURE §2); uji memakai peran `radio`
Utilitas `page-container`	§5: `max-width: 1280px` + `margin-inline: auto`	`margin-inline: auto` mematikan peregangan flex pada sumbu silang (CSS Flexbox §9.4), sehingga wadah mengecil mengikuti isi: panel 962 px, bukan 1203 px seperti acuan	Ditambah `width: 100%` di utilitas. Berlaku juga untuk Welcome dan Privasi, yang kini selebar acuan

Perbandingan berdampingan dengan `customize.html`

Diukur dengan getBoundingClientRect di Chromium pada 1280 x 900 dan 360 x 640; tangkapan layar tidak disimpan di repo.

Bagian	Acuan 1280	Produk 1280	Acuan 360	Produk 360
Panel utama	1203 x 871	1203 x 879	328 x 1941	328 x 1149
Lebar kolom (kiri	tengah	kanan)	289	538
Strip	210 x 639	216 x 648	210 x 639	216 x 648
Tinggi dokumen	998	987	2158	1341
Pil tab	106 / 94 / 105, tinggi 44	114 / 102 / 113, tinggi 44	sama	tombol "Hiasan" (panel di lembar bawah)
Swatch frame (rasio 2 : 3)	87 x 131	79 x 118	85 x 127	panel di lembar bawah
Jarak kisi swatch	14 px	14 px	14 px	14 px

Selisih yang tersisa punya sebab yang sudah dicatat: panel pada 360 px lebih pendek karena kartu Strip Hidup dan QR belum ada, dan pil tab sedikit lebih lebar karena rupa fon yang berbeda dari berkas acuan (yang memuat Google Fonts lewat <link>).

Uji manual yang perlu dilengkapi pengguna

Dua hal tidak bisa diverifikasi dengan kamera palsu:

Foto kamera sungguhan dan batas 2 MB. Foto gradien menghasilkan PNG 51 sampai 62 KB, jadi jalur kedua rekompresi JPEG belum terpicu. Buka /booth/capture di perangkat nyata, ambil empat foto, lalu "Selesai & Unduh": catat ukuran berkasnya. Bila di atas 2 MB, turunkan JPEG_QUALITY di captureFrame.ts (satu konstanta) dan catat di sini.
Cetak dan pindai QR. Bagian ini milik M6 dan M9 (QR belum ada di strip).

Id preset dipisah dari data preset

stores/booth.ts semula mengimpor DEFAULT_FRAME_ID dan DEFAULT_EFFECT_ID dari presets.ts. Akibatnya seluruh data preset (enam frame, tujuh efek, dua belas stiker beserta labelnya) ikut masuk bundel halaman yang tidak memakai kanvas: uji "konva tidak ikut termuat" menemukan teks presets.ts di salah satu skrip / lewat GalleryPicker, yang memakai store.

Id bawaan sekarang tinggal di src/features/editor/defaults.ts (dua string), dan presets.ts serta store membacanya dari sana. Tidak ada nilai yang digandakan.

Bentuk asersi "Konva tidak dimuat"

Rencana memakai pemeriksaan substring "Konva" pada teks skrip. Asersi itu memberi positif palsu: kata "Konva" juga muncul di komentar biasa, termasuk komentar presets.ts yang menjelaskan bahwa berkas itu tidak mengimpor Konva.

Asersi diganti menjadi pemeriksaan perilaku: Konva memanggil _injectGlobal saat modulnya dievaluasi (node_modules/konva/lib/Global.js), jadi "Konva" in window bernilai true begitu pustakanya termuat. Uji memeriksa itu di / dan /booth/capture, ditambah pemeriksaan teks skrip untuk penanda milik kami sendiri (editor-overlay) yang hanya ada di potongan kode penyunting.

Dua uji lain yang gagal pada jalannya pertama juga diperbaiki, keduanya karena kesalahan uji, bukan kode produk: helper masukHias sekarang menunggu kanvas penyunting yang dimuat dinamis, dan uji keyboard membuka tab "Stiker" lebih dulu (tab bawaan adalah "Frame", jadi tombol tempel belum dirender).

Yang diperiksa di browser selain uji otomatis

Selama pengerjaan, alur berikut dijalankan langsung di Chromium (dengan empat foto galeri sebagai pengganti kamera) dan hasilnya diperiksa:

Pemeriksaan	Hasil
Ganti frame "Malam"	Latar strip, garis slot, dan wordmark berubah sesuai data frame; piksel latar panggung `ink`
Efek "Retro"	Keempat foto berubah warna (sepia); sidik jari kanvas berubah besar
Efek "Piksel"	Sidik jari kanvas berubah kecil tetapi konsisten dan kembali persis saat efek dikembalikan ke "Asli"
Seret stiker di kanvas	Posisi di daftar "Isi strip" berpindah dari (300, 900) ke (408, 1006), sama dengan jarak seret dikali skala panggung
Tombol Transformer	Pegangan ubah ukuran dan putar muncul di sekeliling node terpilih, tetap berukuran layar karena Transformer berada di luar grup berskala
Tombol Delete	Menghapus stiker terpilih dan barisnya hilang dari daftar
Ekspor saat stiker terpilih	PNG bersih tanpa kotak pilihan dan pegangan Transformer
Ekspor dengan teks 24 karakter dan tanggal	Teks membungkus dua baris dan tetap di dalam strip; tanggal rata kanan di baris atas kaki strip
Unduhan	Berkas `snapme-20261009-0936.png` dan seterusnya, 600 x 1800 px, 51 sampai 62 KB, tanpa penanda EXIF

M5 Hasil dan cetak (9 Oktober 2026)

Pencetakan 4R: portal ke `body`, bukan pola `visibility`

Rencana awal memakai pola body * { visibility: hidden } dengan lembar cetak diletakkan di dalam pohon halaman. Pola itu lolos pemeriksaan dimensi, tetapi gagal pada jumlah halaman: visibility: hidden tidak menghilangkan kotak tataletaknya, jadi dokumen tetap setinggi halaman produk dan page.pdf({ preferCSSPageSize: true }) menghasilkan 3 halaman, bukan 1. Terbukti di uji pertama e2e/result.spec.ts uji 2.

Perbaikan: lembar cetak dirender lewat createPortal ke document.body (ResultView), dan @media print di globals.css menyembunyikan seluruh isi halaman dengan body > * { display: none }. Aturan [data-print-sheet] (spesifisitas atribut) menang atas body > *, jadi hanya lembar cetak yang tersisa; tingginya nol karena position: fixed, sehingga PDF tepat satu halaman. @page { size: 4in 6in; margin: 0 } menjaga halaman 4 x 6 inci tanpa margin tambahan.

page.pdf({ preferCSSPageSize: true }) menghasilkan 1 halaman; kotak gambar 384 x 576 px (4 x 6 inci pada 96 dpi) diuji pada strip, jumlah halaman diuji juga pada grid.
Hitungan halaman di uji memakai pola /\/Type\s*\/Page[^s]/g atas PDF keluaran Chromium. [^s] menjaga /Type /Pages tidak ikut terhitung.
@page tidak bisa dibatalkan per halaman; satu-satunya cetakan v1 adalah lembar 4R, jadi ukuran itu berlaku global dan diterima.
Pemeriksaan visual dialog cetak sungguhan (Ctrl+P) tetap diserahkan ke pengguna.

Ekspor dikerjakan sekali saat mount

ResultView mengekspor strip sekali saat dipasang, bukan saat tombol ditekan: tombol "Selesai & Unduh" dan "Cetak 4R" harus langsung menyerahkan berkas, dan aturan yang sama sudah dipakai jalur unduh M4. Komposisi lembar cetak (src/features/editor/sheet.ts) adalah Canvas2D murni: menyalin PNG strip dua kali berdampingan pada 1200 x 1800 px plus garis potong putus-putus 4 px di x = 600, warnanya dari token --color-ink.

Dua hal yang lahir dari kenyataan runtime:

Gambar slot bisa belum terdekode saat ekspor mount. exportStrip menyalin kanvas apa adanya, sedangkan useHtmlImage memuat gambar secara asinkron. waitForSlotPhotos menunggu setiap node .slot-photo punya gambar (batas 8 detik) sebelum ekspor; tanpa itu strip bisa keluar dengan slot kosong.
Efek React StrictMode. Mode pengembangan memasang efek dua kali. Tanpa penjaga, ekspor kedua bisa menyetel ukuran panggung di tengah ekspor pertama. startedRef memastikan ekspor berjalan sekali; jalur gagal menampilkan pesan galat di rel kanan dan menonaktifkan kedua tombol.

Grid 2 x 2 dicetak sebagai lembar itu sendiri

lib/layouts.ts di parameterkan: buildLayout menerima canvas, margin, gap, footer, slotWidth, dan columns dengan bawaan nilai strip lama, jadi geometri strip-4 dan strip-3 tidak berubah sedikit pun (diuji: tests/layouts.test.ts lama tetap lolos). Grid memakai kanvas 1200 x 1800 px, margin 48, slot 540 x 744, gap 24, kaki 240, dan dua kolom.

composePrintSheet mengenali lembar yang sudah selebar 4R (canvas.width >= 1200) dan mengembalikan hasil ekspor apa adanya: menggambar strip 1200 px dua kali berdampingan hanya akan memotong gambar. FR-12 menyebut "dua strip berdampingan" untuk strip 2 x 6 inci; FR-03 menyebut ekspor 1200 x 1800 untuk grid.

FOOTER_WORDMARK_ROW = 100 pindah ke lib/layouts.ts sebagai satu sumber: StripStage memakainya untuk menggambar wordmark dan tanggal, store memakainya untuk menaruh teks pengguna (strip: y 1696, grid: y 1660). Posisi bawaan stiker dan teks sekarang dihitung dari kanvas layout aktif, bukan angka tetap 300/900.

"Mulai dari awal" mengarah ke pemilih layout

Bukan ke Welcome: pengguna yang baru selesai langsung memulai alur baru tanpa melewati halaman pemasaran, dan tombol Kembali di setiap langkah tetap menyediakan jalan ke atas. Handler memanggil clearSession() (hapus rekaman FR-14), reset() (kosongkan store), lalu router.replace("/booth/layout").

`idb` sebagai klien penyimpanan (FR-14)

Dipasang idb@8.0.4 (MIT, terawat) alih-alih menulis pembungkus IndexedDB sendiri, sesuai ARCHITECTURE §2 ("klien penyimpanan" ada di daftar yang tidak boleh ditulis sendiri). Satu basis data snapme-session, satu object store state, satu kunci "current".

Rekaman menyimpan layoutId, shots, dan slice editor; settings tidak ikut karena gesture sudah punya jalurnya sendiri (GS-06 di localStorage) dan pemilihan kamera memang tidak disimpan (M2).
validateRecord adalah satu-satunya pintu dari penyimpanan ke store: hanya version === 1, layout dikenal, jumlah slot sama dengan shotCount, dan tipe tiap bidang benar yang diterima. Rekaman rusak dihapus, bukan ditebak.
SessionSync dipasang di src/app/booth/layout.tsx: membaca penyimpanan, mengisi store hanya bila store masih segar (layoutId === null dicek ulang setelah await, supaya alur galeri dari Welcome tidak tertimpa), lalu berlangganan dengan jeda simpan 400 ms.
Store mendapat bidang sessionReady (awal false, tidak ikut reset()). useRequireLayout dan useRequireShots menunda pengalihan selama sessionReady masih false, jadi muat ulang di tengah langkah tidak memantul ke pemilih layout sebelum IndexedDB terbaca.
DataURL JPEG ditulis apa adanya. Uji e2e "foto pulih setelah dimuat ulang" lolos tanpa penyesuaian waktu, jadi kontingensi menyimpan Blob tidak dijalankan.

Penyimpangan M5

Hal	Dokumen atau acuan	Kenyataan	Tindakan
Baris "Ekspor" di halaman Hias	§10.3 dan rencana M5 hanya menyebut baris statis "Ekspor 600 x 1800 px (2 x 6 inci, 300 dpi)"	Setelah FR-03 ada, baris itu salah untuk grid	Dibuat mengikuti layout: `Ekspor {canvas.width} x {canvas.height} px ({inci} x {inci} inci, 300 dpi)`. Angka inci diturunkan dari 300 dpi, bukan ditulis tetap
Label kartu dan ringkasan di pemilih layout	Rencana M5: ganti teks rel kanan jadi mengikuti kanvas	Kartu layout juga menampilkan "Ekspor 600 x 1800 px"	Keduanya mengikuti `LAYOUTS[id].canvas`
Diagram layout di kartu pemilih	Acuan lama: satu kolom `flex`	Grid butuh dua kolom	Kontainer diagram menjadi `grid` dengan jumlah kolom dari `layout.columns`; strip tetap satu kolom
Aksi utama di halaman Hias	Sebelumnya tombol unduh langsung (M4)	M5 memindahkan unduhan ke halaman Hasil	Tombol "Selesai & Unduh" di Hias menjadi tautan ke `/booth/result` (label tetap §12); unduhan dan cetak dijalankan di Hasil
Halaman Hasil	§10 belum punya berkas acuan untuk `/booth/result`	Halaman tetap harus punya susunan	Disusun dari Booth Shell (§5) dan komponen §9: rel kiri ringkasan, tengah pratinjau dan baris privasi, rel kanan tiga aksi. Chip kepala panel "4 foto" gaya `lime` seperti Hias
Rel kiri halaman Hasil	Hias memakai rel kiri untuk pilihan hias	Hasil tidak punya pilihan	Rel kiri dipakai ringkasan `dl` (Layout, Frame, Efek, Stiker) dalam kartu `radius-card`
Permintaan `__nextjs_font` di uji privasi	Daftar putih uji: `/_next/`, `/mediapipe/`, `/models/`, `/stickers/`, `/favicon.ico`	Server pengembangan Next melayani fon lewat `__nextjs_font` (di produksi semuanya di bawah `/_next/`)	Awalan itu ditambahkan ke daftar putih dengan komentar; keduanya aset statis milik aplikasi
`page.pdf` pada uji	Rencana: hitung halaman dari regex PDF	Regex bisa meleset bila Chromium memadatkan objek	Regex dipakai (berhasil untuk 1 halaman di semua uji); bila meleset di lingkungan lain, asersi kotak 384 x 576 px tetap menjadi bukti dan pemeriksaan dialog cetak menjadi uji manual
`masukAmbilFoto` di `e2e/helpers.ts`	Rencana M5 menambah helper `masukHasil`	Verifikasi grid juga butuh masuk dengan layout lain	Helper `masukAmbilFotoLayout(page, label)` ditambah; `masukAmbilFoto` memanggilnya dengan "Strip 4 foto"

Bukti browser untuk halaman Hasil

Selain uji yang sudah disebut di atas, alur berikut dijalankan langsung di Chromium lewat Playwright (kamera palsu, foto galeri sebagai pembanding):

Pemeriksaan	Bukti
Unduhan strip	PNG IHDR 600 x 1800, di bawah 2 MB, nama `snapme-\d{8}-\d{4}.png`; toast "Strip tersimpan di perangkatmu." tampil
Unduhan grid	PNG IHDR 1200 x 1800
Lembar cetak	Media cetak: satu halaman, kotak gambar 384 x 576 px; grid juga satu halaman
Privasi alur dasar	Tidak ada permintaan ke origin lain, tidak ada `/api/`; hanya halaman aplikasi dan aset statis (uji 1 `result.spec.ts`)
Muat ulang di tengah langkah	2 foto pulih beserta isinya, frame "Malam" pulih, alur galeri 4 foto tidak tertimpa rekaman lama
"Mulai dari awal"	Kembali ke pemilih layout dengan "Belum dipilih"; rekaman lama tidak kembali setelah muat ulang
Halaman Hasil	Masuk daftar `e2e/a11y.spec.ts`: nol pelanggaran axe pada 360 dan 1280 px

Uji manual yang perlu dilengkapi pengguna

Dialog cetak sungguhan. page.pdf membuktikan satu halaman 4 x 6 inci, tetapi dialog cetak sistem (margin printer, "fit to page") tidak bisa diverifikasi secara otomatis. Cetak satu lembar 4R dari Chrome dan pastikan tidak ada margin tambahan.
Cetak grid. Pastikan hasil cetak grid 2 x 2 pas di kertas 4R tanpa skala tambahan dari driver printer.

M6 Link strip dan QR (9 Oktober 2026)

Proyek Supabase: dibuat dan dimigrasi lewat CLI (9 Oktober 2026)

Proyek snapme dibuat dengan Supabase CLI atas persetujuan pengguna (npx supabase projects create snapme --org-id ahxywelellcukhlekfqa --region ap-southeast-1), ref owdjkpzywzljnvuyfiui. CLI sudah terautentikasi di mesin ini, jadi tidak ada token yang perlu ditempel ke repo. Selanjutnya:

npx supabase link --project-ref owdjkpzywzljnvuyfiui (kata sandi basis data dibuat acak).
npx supabase db push → Applying migration 20261012000000_strips_bucket.sql … Finished supabase db push.
.env.local diisi empat variabel dari .env.example plus SUPABASE_DB_PASSWORD (kata sandi basis data, hanya untuk db push berikutnya). Berkas itu diabaikan .gitignore (diperiksa dengan git check-ignore), jadi tidak ada rahasia yang masuk repo.

Bukti pemeriksaan langsung ke proyek (klien REST dengan kunci service role):

Pemeriksaan	Hasil
`insert` baris uji dengan service role	201
Baca `strips` dengan kunci `anon`	200 `[]` → RLS menolak `anon` (kriteria M6)
Baca `strips` dengan service role	200, barisnya terlihat
`GET /storage/v1/bucket/snapme`	`public: false`, `file_size_limit: 2097152`, `allowed_mime_types: ["image/png"]`
Baris uji dihapus	204

supabase/config.toml ikut di-commit; supabase/.temp diabaikan .gitignore bawaan CLI.

Pembatasan laju di basis data, bukan di memori fungsi serverless

Keputusan pengguna. Setiap instans fungsi serverless punya memorinya sendiri, jadi hitungan di memori tidak mengikat. Yang disimpan pada baris strip adalah rate_key = 16 karakter pertama SHA-256 dari alamat IP + ":" + RATE_LIMIT_SALT, dan rute POST /api/strips menghitung baris satu jam terakhir dengan rate_key yang sama (CREATE_LIMIT 10, CREATE_WINDOW_MS 1 jam). Satu kalimat ditambahkan ke halaman Privasi bagian "Kapan foto diunggah". x-forwarded-for diambil hop pertama; tanpa header itu (pengembangan lokal) semua permintaan memakai satu keranjang "lokal".

Unggahan langsung ke Storage, verifikasi di rute `complete`

URL unggah bertanda tangan tidak bisa membatasi isi berkas, jadi batas 2 MB dan jenis PNG ditegakkan setelah unggah: rute complete membuat URL baca 60 detik lalu HEAD ke berkasnya dan memeriksa content-length dan content-type. Klien juga mengirim contentType: "image/png" saat mengunggah. @supabase/storage-js ditambahkan sebagai dependensi langsung (versi 2.117.3, MIT): StorageClient dipakai di browser untuk uploadToSignedUrl, dan paket itu tidak di-ekspor ulang oleh @supabase/supabase-js (diperiksa di dist/index.d.mts baris 829). Kunci service role tetap tidak pernah masuk klien.

Ekspor ulang ber-QR: antrean satu jalur di `ResultView`

Panggung diubah ukurannya saat ekspor, jadi dua ekspor tidak boleh berjalan bersamaan (catatan M4). M6 menambah satu antrean: runExport dijalankan satu per satu, kunci layoutId|effectId|qrImageUrl menjaga ekspor yang sama tidak diulang, dan permintaan yang datang di tengah ekspor dijalankan sekali lagi setelahnya. Rencana menaruh seluruh alur di features/share/createStripLink.ts; kenyataannya QR harus lebih dulu dirender React (data URL dari useQrImageUrl), jadi yang dipisah adalah lapisan jaringannya (features/share/api.ts) dan orkestrasinya tinggal di ResultView. Urutannya: POST /api/strips → token hapus disimpan di perangkat → QR digambar → ekspor ulang → unggah → POST complete → tanggal kedaluwarsa masuk store. Kegagalan setelah id dibuat membuang token di perangkat, mengosongkan share.strip, dan menampilkan toast pesan server; baris draf yatim dibersihkan cron setelah 24 jam.

Kotak QR: 168 px, zona tenang 4 modul, sudut membulat

Acuan customize.html menggambar kotak QR 56 px pada strip 210 px (≈ 27 persen) dengan ikon Phosphor di dalamnya, dan StripStage mengikuti proporsi itu (168 px pada kanvas 600 px). Dua penyesuaian dari rencana:

Zona tenang 4 modul di dalam kotak 168 px (margin: 4 pada qrcode), bukan 2 modul. Kotak QR tepat sebesar gambarnya, sedangkan latar strip bisa gelap (frame "Malam"), jadi zona tenang tidak boleh bergantung pada latar luar.
Sudut kotak membulat 16 px dengan gambar QR terjepit mengikutinya, sama seperti acuan. Jepitan itu hanya memakan zona tenang, jadi modul QR tidak tersentuh.

Glif penanda di dalam kotak disalin dari atribut d ikon QrCode bobot bold @phosphor-icons/react (viewBox 0 0 256 256) dengan komentar asalnya: Konva tidak bisa merender komponen React, dan §8 melarang menggambar path ikon sendiri. Glif hanya muncul di kanvas Hias (perilaku acuan); di langkah Hasil kotak QR baru digambar setelah QR sungguhan ada, supaya strip yang diunduh tanpa link tidak pernah berisi glif penanda.

Penyimpangan M6

Hal	Dokumen atau acuan	Kenyataan	Tindakan
Status 410 dari halaman `/s/[id]`	SH-05 dan MILESTONES M6: "jawaban 410 bila kedaluwarsa"	App Router tidak bisa memasang status pada halaman yang sudah dirender	Halaman merender tampilan kedaluwarsa ber-`noindex`; status 410 harfiah dijawab rute API (`complete` dan `DELETE`, diuji unit). Fallback `middleware` tidak dipakai karena tidak ada kebutuhan nyata. Dikonfirmasi pengguna 9 Oktober 2026
Rute blocking `/s/[id]`	Rencana: `await connection()` di halaman	Next 16 Cache Components menolak akses data runtime di luar `<Suspense>`; halaman ini isinya seluruhnya satu baris basis data, jadi tidak ada bagian statis yang berguna untuk di-stream	`export const instant = false` (rute blocking) supaya `notFound()` benar-benar menjawab 404, bukan 200 yang menyusul tampilan tidak ditemukan di tengah aliran. Dibuktikan `curl -i /s/abc` → 404. Dikonfirmasi pengguna 9 Oktober 2026
Tipe konteks route handler	Rencana: `RouteContext<'/jalur'>`	`RouteContext` baru ada setelah `.next/types` dibuat (`.next` tidak di-commit)	Konteks ditulis `{ params: Promise<{ id: string }> }` seperti contoh dokumentasi Next, jadi `npm run typecheck` tidak bergantung hasil typegen
Tombol "Unduh" di `/s/[id]`	Rencana: `secondary lg`	§14 menuntut tepat satu aksi `primary` per layar, dan halaman ini tidak punya aksi lain	"Unduh" menjadi `primary lg`
Baris atas `/s/[id]` dan 404	Rencana: `SiteHeader`	`SiteHeader` selalu membawa CTA "Mulai Foto", jadi labelnya muncul dua kali di layar yang aksinya sudah dipegang panel	`SiteHeader` menerima `ctaVariant="none"`; kedua halaman memakainya
Nama berkas unduhan di `/s/[id]`	FR-11: `snapme-YYYYMMDD-HHmm.png`	Halaman ini tidak tahu waktu pengambilan foto; yang diketahui hanya id strip	`snapme-{id}.png` lewat parameter `download` URL bertanda tangan
Kartu bagikan di langkah Hasil	§9 dan acuan tidak memuat kartu untuk langkah Hasil	SH-04 menuntut persetujuan unggah dan link yang bisa disalin	Kartu `radius-card` bergaris sama seperti kartu QR di Hias: keadaan belum ada link, sedang dibuat, dan sudah jadi (alamat, salin, tanggal kedaluwarsa). Tidak ada aksi `tangerine` baru
CSP	ARCHITECTURE §8 menyebut CSP	MediaPipe butuh `wasm-unsafe-eval`; tanpa CSP pun wasm satu origin sudah berjalan, dan aturan penuh dijadwalkan M9	Yang dipasang sekarang: `Permissions-Policy: camera=(self)`, `X-Content-Type-Options: nosniff`, `Referrer-Policy` (khusus `/s` dan `/r`: `no-referrer`), `X-Robots-Tag: noindex`, dan `Content-Security-Policy: frame-ancestors 'none'` untuk `/s` dan `/r`. CSP penuh menyusul di M9
Tombol hapus di `/s/[id]`	Rencana: `readStripToken(id)` lalu `null` bila tidak ada	Membaca localStorage saat render membuat penanda server dan hasil hidrasi berbeda	Token dibaca lewat `useSyncExternalStore` (snapshot server `null`), lalu token diteruskan sebagai argumen ke handler hapus
Placeholder QR di Hias vs Hasil	Acuan menampilkan kotak QR begitu sakelarnya nyala	Strip yang diunduh tidak boleh berisi glif penanda	Kanvas Hias menampilkan glif (perilaku acuan), kanvas ekspor di Hasil hanya menampilkan QR sungguhan

Bukti browser M6

Pemeriksaan	Bukti
Sakelar QR di Hias	Sakelar `switch` "QR di strip" menyala, pemberitahuan lime "Kamu akan dimintai izin unggah saat mengunduh." tampil, dan sidik jari kanvas berubah (kotak QR + glif tergambar). Uji 1 `e2e/share.spec.ts`
Persetujuan unggah	Dialog "Unggah strip?" menyebut apa yang diunggah, siapa yang bisa melihat, dan masa 7 hari. Uji 2 `e2e/share.spec.ts`
Tanpa proyek Supabase	Klik "Buat Link dan Unggah" menjawab 503 dan menampilkan "Pembuatan link belum tersedia."; kartu kembali menawarkan unggah. Uji 2 `e2e/share.spec.ts` (dilewati saat `.env.local` sudah ada)
Alur ber-link sungguhan	`SUPABASE_E2E=1 npx playwright test share.spec.ts` → 3 lolos, 1 dilewati (uji 503). Uji 4: buat link (unggah PNG ber-QR ke Storage lewat URL bertanda tangan), toast "Link strip dibuat.", alamat `/s/{id}` dan tanggal kedaluwarsa tampil, konteks browser kedua membuka alamat itu dan melihat stripnya tanpa tombol "Hapus strip", lalu pemilik menghapus dan halaman menjawab 404. Baris `complete` dan batu nisan `deleted` terlihat di basis data setelah uji
Berkas sisa uji dibersihkan	Setelah uji, sisa baris dan berkas di Storage dihapus manual lewat klien REST; `strips` kembali kosong
Halaman strip yang tidak ada	`curl -i http://localhost:3000/s/abc` → `404 Not Found` dengan `Referrer-Policy: no-referrer`, `X-Robots-Tag: noindex`, `Content-Security-Policy: frame-ancestors 'none'`, `Permissions-Policy: camera=(self)`; `/` tetap `strict-origin-when-cross-origin`
Kunci service role tidak di bundel klien	Build dengan `.env.local` sungguhan: 50 berkas di `.next/static` dipindai, nol memuat kunci service role, sedangkan `NEXT_PUBLIC_SUPABASE_URL` memang ada (memang publik, jadi pemindaiannya terbukti sanggup menemukan nilai yang bocor). `tests/client-bundle-secrecy.test.ts` juga memeriksa tidak ada berkas `"use client"` yang mengimpor `lib/supabase/server`

Perbandingan berdampingan kartu QR dengan `customize.html`

Diukur dengan getComputedStyle di Chromium pada 360 dan 1280 px (skrip sementara, tidak disimpan di repo).

Bagian	Acuan	Produk
Kartu	`paper`, garis 2 `ink`, radius 14, padding 16	sama persis
Judul	Unbounded 800 16 px	sama persis
Paragraf isi	Space Grotesk 400 15 px, tinggi baris 21 px	Space Grotesk 500 15 px, tinggi baris 21 px. §3 menetapkan teks isi 500, jadi dokumen yang menang
Pemberitahuan izin	`lime`, garis 2 `ink`, radius 10, padding 8 10, 14 px	sama persis
Sakelar	56 x 32, radius 999	sama persis

Tinjauan keamanan

Berkas yang ditinjau: src/app/api, src/lib/supabase, src/lib/tokens.ts, src/lib/rateLimit.ts, src/lib/expiry.ts, src/features/share, migrasi, next.config.ts, dan vercel.json. Delapan temuan, semuanya ditangani sebelum commit:

#	Tingkat	Temuan	Tindakan
1	blocker	`POST /api/strips` menghitung `still_path` hanya untuk URL unggah dan tidak menulisnya ke baris, sedangkan rute `complete` menolak baris ber-`still_path` null. Alur ber-link selalu gagal 422, dan berkas yang terunggah tidak punya jejak untuk dihapus. Uji unit tidak menangkapnya karena klien palsu menambal `still_path` di setiap baris	`still_path` ditulis sejak pembuatan. Klien palsu tidak lagi menambal kolom itu (hanya nilai bawaan kolom), dan uji "membuat baris draf" sekarang memeriksanya
2	major	Bucket tidak punya `file_size_limit` dan `allowed_mime_types`, jadi URL unggah menerima berkas jauh di atas 2 MB dan berkas yang ditolak 422 tidak dibuang	Migrasi memasang `file_size_limit` 2 MB dan `allowed_mime_types` `image/png` (dengan `on conflict do update`); rute `complete` membuang berkas yang ditolak dan membandingkan jenis persis (`image/pngx` tidak lolos lagi)
3	major	Token unggah berlaku sekitar 2 jam dan Storage tidak melihat tabel: berkas bisa diunggah setelah barisnya dihapus, dan tidak ada yang pernah membersihkannya	`DELETE` tidak lagi menghapus barisnya, melainkan menjadikannya batu nisan `status = 'deleted'` dengan `expires_at = now + 3 jam` (lebih lama dari token unggah). Pembersih harian membuang baris dan berkasnya setelah masa tenggang itu; `/s/[id]` hanya menerima `complete`, jadi strip yang dihapus tetap 404
4	major	Kuota pembatasan laju dihitung dari baris `strips`, sedangkan `DELETE` menghapus baris itu: siklus buat-hapus-buat mengembalikan kuota tanpa batas	Batu nisan temuan 3 sekaligus menutup ini: baris `deleted` tetap ikut dihitung selama jendela satu jam, dan masa tenggangnya (3 jam) lebih panjang dari jendela
5	major	Periksa-dulu-lalu-sisip tidak atomik: permintaan serentak semuanya melihat hitungan di bawah batas	Urutannya dibalik menjadi hitung-setelah-sisip: baris baru disisipkan, dihitung, dan dibuang lagi bila kuota sudah lewat. Overshoot hanya mungkin beberapa baris pada balapan sempit, bukan seluruh burst
6	minor	Sidang alamat IP diambil dari hop pertama `x-forwarded-for`, yang bisa dipalsukan klien bila proxy hanya menambahkan	`x-real-ip` (diisi platform hosting, Vercel menimpanya) dipakai lebih dulu; `x-forwarded-for` hop pertama hanya cadangan. Diuji: header `x-forwarded-for` palsu tidak memindahkan keranjang saat `x-real-ip` ada. Bila kelak di-host sendiri, semantik proxy-nya wajib diperiksa lagi
7	minor	`POST /api/strips` menerima `content-type` apa pun, jadi halaman lintas situs bisa membakar kuota pengunjung lewat `fetch` `no-cors` atau form biasa	Rute menolak permintaan yang bukan `application/json`
8	minor	Garam pembatasan laju kosong diam-diam memakai `"dev-garam"`, dan sidangnya bisa dibalik dengan menebak ruang alamat IPv4	`rateKeyFor` mengembalikan `null` tanpa garam, dan rutenya menjawab 503 (aplikasi tetap jalan tanpa proyek maupun garam)

Kategori yang dinyatakan bersih oleh peninjau: entropi dan perbandingan token, pemeriksaan otorisasi tiap rute, RLS dan model kapabilitas URL bertanda tangan, autentikasi cron, XSS/injeksi di halaman /s/[id] (id dan URL bertanda tangan dirender sebagai atribut), dan kebocoran pesan galat.

Uji manual yang perlu dilengkapi pengguna

Pindai QR dari cetakan. Pengguna melaporkan sudah mencoba cetak dan pindai (9 Oktober 2026), tanpa rincian perangkat dan berapa yang berhasil. Karena strip ber-QR baru bisa diekspor setelah alur link berjalan hari ini, ulangi sekali dengan strip ber-link sungguhan (frame "Malam" sekaligus frame terang) dan catat perangkatnya; hasilnya menggantikan baris ini. Tetap syarat rilis M9.
Jadwal cron. vercel.json memasang pembersih harian 03:00 UTC. Deploy baru terjadi di M9, jadi jalannya cron belum pernah terlihat. Pembersihnya sendiri sudah diuji unit (baris kedaluwarsa, draf basi, batu nisan).
Kata sandi basis data. Dibuat acak dan disimpan di .env.local (tidak di-commit). Simpan di pengelola kata sandi pengguna; kalau hilang, reset dari dasbor Supabase lalu perbarui .env.local.

M7 Strip Hidup (9 Oktober 2026)

Klip hanya di memori, tidak ikut IndexedDB

Bingkai SH-01 disimpan sebagai ImageBitmap di Shot.clip (src/stores/booth.ts). serializeSession sengaja menyalin ulang tiap foto menjadi { still, capturedAt }, jadi ImageBitmap tidak pernah menyentuh IndexedDB. Alasannya: structured clone ImageBitmap tidak seragam antar browser, dan rekaman 40 bingkai 480 px akan membengkakkan penyimpanannya. Akibatnya yang terlihat pengguna: memuat ulang halaman mematikan Strip Hidup untuk kunjungan itu, dan kartu Hias menampilkan sakelar nonaktif dengan penjelasan "Klip hanya terekam saat memotret lewat kamera." Bila kelak ingin persisten, konversinya ke Blob dikerjakan di M9.

Store juga melepas bingkainya (close()) setiap kali foto diganti, layout diganti, atau "Mulai dari awal" ditekan (butir "Lepas ImageBitmap saat booth dimulai ulang" di MILESTONES.md). Dijaga uji tests/booth-live.test.ts.

Bucket naik ke 5 MB, batas 2 MB still ditegakkan rute `complete`

MILESTONES.md M7 dan PRD §8 menuntut klip di bawah 5 MB, sedangkan bucket snapme dipasang 2 MB untuk PNG (M6). Batas bucket hanya satu angka untuk semua berkas, jadi migrasi 20261013000000_live_video.sql menaikkannya ke 5 MB dan menambah video/webm serta video/mp4 ke daftar jenis. Batas 2 MB untuk still tidak hilang: rute complete sudah memeriksanya sendiri (pagar kedua) dan tetap menolak PNG di atas 2 MB. Versi hidup juga tetap diperiksa di rute itu (≤ 5 MB, jenis persis video/webm atau video/mp4). Migrasinya sudah dijalankan ke proyek snapme lewat supabase db push setelah pengguna menyetujui 9 Oktober 2026, jadi uji ber-jaringan M7 memakai bucket yang sebenarnya.

Versi hidup best-effort di rute `complete`

Rekaman bisa gagal di perangkat pengguna (kodek, tab di latar, kehabisan memori), jadi klip tidak pernah memblokir stripnya. POST /api/strips menulis live_path sejak baris dibuat dan mengembalikan liveUpload kedua; bila setelah unggah ternyata berkasnya tidak ada atau tidak lolos pemeriksaan, rute complete membuang berkas itu, mengosongkan live_path, dan tetap menandai stripnya complete. Pengguna melihat toast "Versi hidup tidak ikut terunggah." dan strip diamnya tetap utuh. Kehadiran live di CREATE_STRIP_SCHEMA adalah satu-satunya penanda bahwa klien menginginkan jalur ini.

Lencana "Klip" dan label baru

LiveStripPlayer di DESIGN-SYSTEM §9 diwujudkan sebagai prop live di StripStage (ditambah useClipTicker dan LiveStripVideo untuk /s/[id]), bukan komponen panggung terpisah. Alasannya: panggung Konva yang sama dipakai tiga hal yang harus identik (hias, ekspor PNG, rekam video), dan komponen kedua akan menduplikasi susunan strip yang sudah ada di satu berkas. Nama "LiveStripPlayer" tetap dipakai untuk pemutarnya di halaman strip (src/features/live/LiveStripVideo.tsx, tanpa Konva supaya halaman itu ringan).

Lencana digambar manual (Rect + Text) supaya angkanya sama persis dengan acuan: acuan memakai kiri dan bawah 6 px, tinggi 16 px, lebar 42 px, Space Mono 700 10 px, jarak huruf 0.06em pada strip 210 px. Ruang kanvas strip 600 px berarti 17 px, 46 px, 120 px, 28 px, dan 1.7. Label/Tag bawaan react-konva tidak dipakai karena padding-nya seragam, sedangkan acuan berpadding 2 px tegak dan 8 px datar.

Label antarmuka baru yang belum ada di DESIGN-SYSTEM §12: "Unduh Video", "Putar", "Jeda", "Versi hidup tidak ikut terunggah.", dan "Video strip tersimpan di perangkatmu." Semuanya dicatat di sini mengikuti presedem M6; bila pengguna setuju, tambahkan ke tabel §12 dokumen (dokumen tidak diubah diam-diam).

Perbandingan berdampingan lencana "Klip" dengan `customize.html`

Diukur pada tangkapan layar 1280 px (skrip sementara, tidak disimpan di repo).

Bagian	Acuan (strip 210 px)	Produk (kanvas 600 px)
Posisi lencana	kiri 6 px, bawah 6 px	17 px, 17 px
Ukuran	42 x 16 px	120 x 46 px
Huruf	Space Mono 700 10 px, jarak 0.06em	Space Mono 700 28 px, jarak 1.7
Isi	`ink` dengan teks `paper`, radius 999	sama

Bukti browser M7

Pemeriksaan	Bukti
Perekaman tidak mengubah waktu foto utama	`tests/clip-recorder.test.ts`: tabel peristiwa yang sama dijalankan dengan dan tanpa pengamat perekam, urutan fasenya identik, dan offset sampling terakhir 2850 ms < 3000 ms
Klip benar-benar terekam dan berputar	`e2e/live.spec.ts` uji 1: setelah sakelar dinyalakan, sidik jari kanvas berubah tiap 500 ms; saat sakelar mati, dua sampel identik
`prefers-reduced-motion`	Uji 2: pratinjau diam, tetap berbeda dari keadaan sakelar mati (lencana "Klip"), tombol "Putar" menjalankan animasi, "Jeda" menghentikannya
Tanpa klip	Uji 3 (foto galeri): sakelar nonaktif dan teks "Klip hanya terekam saat memotret lewat kamera."
Unduh video (SH-03)	Uji 4: berkas `snapme-YYYYMMDD-HHmm.webm` terunduh di Chromium headless, ukurannya di atas 0 dan di bawah 5 MB
Unggah klip dan rute `complete`	`tests/api-strips.test.ts` (20 lolos): POST dengan `live` mengembalikan `liveUpload` dan menulis `live_path`; complete menyimpannya bila klipnya lolos, dan mengosongkan `live_path` bila berkasnya 404, jenisnya salah, atau lebih dari 5 MB
Alur ber-jaringan sungguhan	Setelah `npx supabase db push` (disetujui pengguna 9 Oktober 2026), `SUPABASE_E2E=1 npx playwright test share.spec.ts live.spec.ts` → 8 lolos, 1 dilewati. Konteks kedua membuka `/s/{id}` dan melihat `<video>` bertanda tangan dari `/storage/`; pemilik menghapus lalu halaman menjawab 404. Strip tanpa klip (uji lama) nol `video`
Lencana "Klip" dan kartu Hias	Tangkapan layar 1280 dan 360 px dibandingkan dengan `docs/ui-reference/customize.html`: kartu Strip Hidup duduk di urutan pertama rel kanan (judul Unbounded 800 16, sakelar 56 x 32, pemberitahuan lime), lencana menempati 20 persen lebar slot di kiri bawah seperti acuan
Perintah pemeriksaan	`npm run lint`, `npm run typecheck`, `npm test` (120 lolos, 18 berkas), `npm run build` (13 rute), dan `npx playwright test` (50 lolos, 3 dilewati) semuanya hijau

Uji manual yang perlu dilengkapi pengguna

Perangkat dan browser di luar Chromium headless belum pernah menjalankan versi hidup. Isi tabel ini setelah mencoba; hasilnya menggantikan status "menunggu pengguna". Kolom Chrome diisi di M9 dari jalankan headless (Chromium dengan kamera palsu); kolom Firefox dan Safari sebagian: yang bisa dipastikan lewat uji otomatis adalah kemampuan merekamnya, sedangkan pratinjau berputar dan pemutaran /s/{id} tetap butuh kamera dan perangkat sungguhan.

Pemeriksaan	Chrome	Firefox	Safari
Kemampuan merekam (M9, headless)	`MediaRecorder` ada, `video/webm` dan `video/mp4` didukung, `canvas.captureStream` ada (Chromium 156)	`MediaRecorder` ada, `video/webm` didukung, `video/mp4` tidak, `canvas.captureStream` ada (Firefox 157) → `pickLiveKind` memilih webm	Build WebKit milik Playwright tidak membawa `MediaRecorder` maupun `canvas.captureStream` (WebKit 27.2), jadi tombol SH-03 memang tersembunyi di sana; Safari sungguhan (14.1 ke atas) punya keduanya dan belum diperiksa
Pratinjau berputar di Hias	Lolos headless (`e2e/live.spec.ts`, kamera palsu): sakelar menyala, klip berputar, dan saat sakelar mati kanvas kembali ke foto tetap	menunggu pengguna	menunggu pengguna
Rekam lalu unduh video (SH-03)	Lolos headless (`e2e/live.spec.ts` "unduh video versi hidup", di bawah 5 MB)	menunggu pengguna	menunggu pengguna
Pemutaran di `/s/{id}` (SH-05)	Lolos ber-jaringan (`SUPABASE_E2E=1`, `<video>` bertanda tangan dari Storage)	menunggu pengguna	menunggu pengguna

Catatan: tombol "Unduh Video" dan pemutar di /s/[id] hanya muncul bila MediaRecorder mendukung video/webm atau video/mp4; di Safari yang merekam MP4, jenis berkas unduhannya .mp4.

M8 Strip Estafet (9 Oktober 2026)

Pembagian slot dan pemetaan foto pembuat

Aturan tunggal untuk semua layout: indeks 0-based genap milik pembuat, ganjil milik teman (src/lib/relaySlots.ts). Strip 4 → pembuat [0, 2], teman [1, 3]; Strip 3 → pembuat [0, 2], teman [1]; Grid 2 x 2 → sama seperti Strip 4. Pembuat selalu mengisi tepat setengah slot, jadi syarat SE-01 ("minimal setengah") terpenuhi di semua layout. Dua foto terisi pertama sesi lokal dipetakan berurutan ke slot pembuat; sesi lokal pembuat tidak diubah setelah link dibuat, jadi foto yang diulang setelahnya tidak mengubah berkas yang sudah diunggah (itu snapshot saat link dibuat).

Slot teman diunggah saat penuntasan, bukan saat jepret

Rencana awal tidak menyebut kapan berkas slot teman naik ke Storage. Yang dipilih: saat penuntasan, dengan mekanisme penyembuhan sendiri. Rute complete memeriksa semua berkas slot; slot teman yang belum ada dijawab 422 beserta URL unggah baru untuk slot yang kurang, lalu klien mengunggah foto yang ada di sesinya dan mencoba sekali lagi (RelaySlotsNeededError + finishRelayOnce di src/features/editor/ResultView.tsx).

Alasan: URL unggah bertanda tangan berlaku sekitar 2 jam sedangkan link estafet hidup 48 jam, jadi menyimpan URL itu di sesi (atau di IndexedDB) akan kedaluwarsa di tengah jalan. Dengan cara ini URL-nya selalu segar, dan sesi yang pulih dari perangkat lain (foto lokal sudah ada di IndexedDB) bisa menambal berkas yang hilang tanpa endpoint tambahan. Akibat yang terlihat pengguna: unggahan terjadi sekali di "Selesai & Unduh", dan bila foto lokalnya juga tidak ada, pesannya "Isi ulang foto yang kurang."

Token satu header, giliran sekali di basis data

Token pembuat dan tamu lewat header x-relay-token; hanya hash SHA-256-nya ada di baris relays. Di perangkat, token disimpan per id (localStorage snapme:relay-token:{id}) bersama perannya, karena satu perangkat bisa jadi pembuat di satu link dan tamu di link lain. Giliran sekali dijamin UPDATE ... WHERE id = ? AND status = 'waiting'; nol baris berubah berarti 409 "Estafet ini sudah diambil." (SE-06), dan penuntasan memakai pola yang sama dengan status = 'claimed'.

Strip estafet hanya PNG diam, tanpa klip dan tanpa QR

Klip Strip Hidup milik teman tetap bisa diputar dan diunduh di perangkatnya, tetapi tidak diunggah: PRD tidak meminta versi hidup untuk estafet, dan menambahkannya berarti satu berkas lagi per estafet. QR juga tidak ada di strip estafet karena teman tidak pernah membuat link sendiri. Karena itu kartu "QR di strip" disembunyikan untuk sesi teman dan sesi lokal (hidesUpload di CustomizeEditor/ResultView).

Tampilan `/r/[id]` setelah 48 jam

Kedaluwarsa diperiksa lebih dulu, jadi setelah 48 jam halaman estafet menampilkan "Estafet ini sudah kedaluwarsa." walau strip hasilnya masih hidup 7 hari (SE-08). Konsekuensinya tautan /s/{id} tidak lagi terjangkau dari /r setelah 48 jam; teman yang menuntaskan tetap disimpan di halamannya saat itu, dan pembuat bisa memintanya. Ini mengikuti rencana yang disetujui; bila pengguna ingin tautan strip tetap tampil selama 7 hari, itu perubahan perilaku kecil di halaman /r/[id].

Pembuat bisa membatalkan setelah estafet selesai

SE-09 tidak membatasi status, jadi tombol "Batalkan dan Hapus" ada di RelayJoinView (menunggu/diambil) dan RelayCompleteView (selesai) lewat komponen bersama RelayCancel.tsx. Satu permintaan menghapus berkas slot, strip hasilnya (bila ada), lalu menandai baris estafet cancelled dengan masa tenggang batu nisan yang sama dengan strip. Ini juga yang dipakai uji e2e untuk bersih-bersih.

`localOnly` ikut tersimpan di rekaman sesi

Salinan lokal pembuat (SE-10) ditandai localOnly di store dan ikut disimpan di IndexedDB sebagai bidang opsional (versi rekaman tetap 1; rekaman lama tanpa bidang itu diterima). Tanpa itu, memuat ulang halaman akan mengubah salinan lokal menjadi sesi biasa yang menawarkan unggahan lagi.

Refactor kecil yang menyertai M8

countRecentCreations menerima nama tabel ("strips" | "relays") supaya kuota estafet terpisah dari kuota strip; pemanggil lama di POST /api/strips diperbarui. Pemeriksaan berkas hasil unggahan diekstrak ke verifyStoredFile (src/lib/supabase/storage.ts) dan dipakai rute complete strip, claim, dan complete estafet; tingkah laku rute strip tidak berubah (uji lama tetap hijau).

Label antarmuka baru

Belum ada di DESIGN-SYSTEM §12, dicatat di sini mengikuti presedem M6/M7 (dokumen tidak diubah diam-diam): "Butuh 2 foto dulu.", "Bagikan tautan", "Lihat status", "Lengkapi strip ini", "Ambil Giliran", "Lanjut isi slot", "Menunggu teman", "Teman sudah mulai", "Bayangan pose teman", "Hias ulang salinanmu", "Batalkan dan Hapus", "Estafet ini sudah diambil.", "Estafet ini sudah selesai.", "Estafet sudah dibatalkan pembuatnya.", "Estafet ini sudah kedaluwarsa.", "Slot teman {n}", "Slot {n}, sudah terisi", "Link estafet dibuat.", "Tautan disalin.", "Tautan dibagikan.", "Tautan belum bisa dibagikan. Salin manual dari alamat di atas.", "Menyelesaikan estafet...", dan "Menyiapkan salinan...". "Slot teman {n}" dipakai untuk slot milik pihak lain di baki foto teman (lencana gembok); di pratinjau /r slotnya diberi nomor netral ("Slot {n}") karena yang melihat bisa pembuat maupun teman.

Bukti browser M8

Pemeriksaan	Bukti
Kartu Strip Estafet di rel kanan	Tangkapan layar `/booth/capture` 1280 dan 360 px dibandingkan dengan `docs/ui-reference/capture.html`: kartu `violet-soft` duduk antara kartu lime dan blok aksi, judul berikon `Users`, tombol "Estafet ke Teman" nonaktif bergaris putus-putus dengan teks bantu "Butuh 2 foto dulu." saat foto belum cukup
Halaman `/r` yang tidak ada	`curl`/Playwright: 404 + "Halaman tidak ditemukan." (tanpa gerbang env, ikut pola uji 404 M6)
Overlay bayangan dan slot terkunci	`e2e/relay.spec.ts` (ber-jaringan, lihat baris berikutnya)
Penyembuhan berkas slot teman (422 + URL pengganti)	Diuji langsung ke proyek: estafet dibuat, teman mengambil giliran, `complete` pertama dijawab 422 dengan URL unggah untuk slot 1 dan 3, setelah keduanya diunggah `complete` kedua dijawab 200 beserta `stripId`; PNG strip diunggah lalu `POST /api/strips/{id}/complete` dijawab 200 (`expiresAt` 7 hari)
SE-09 di proyek sungguhan	`DELETE /api/relays/{id}` dengan token pembuat → 204; halaman `/s/{id}` berikutnya 404 (berkas dan barisnya hilang); `DELETE` tanpa token → 401; halaman `/r/{id}` menampilkan "Estafet sudah dibatalkan pembuatnya."
Gate token di server	HTML halaman `/r/{id}` tanpa token (diambil lewat `fetch`) tidak memuat path `/s/{id}` maupun `storage/v1/object/sign`
Unit	`npm test`: 152 lolos, 21 berkas; di antaranya `tests/relay-slots.test.ts` (5), `tests/booth-relay.test.ts` (5), dan `tests/api-relays.test.ts` (22 kasus rute)
Perintah pemeriksaan	`npm run lint`, `npm run typecheck`, `npm test` (152), `npm run build` (rute `/api/relays`, `/api/relays/[id]`, `/api/relays/[id]/claim`, `/api/relays/[id]/complete`, `/api/relays/[id]/strip`, dan `/r/[id]` terdaftar), dan `npx playwright test` penuh (51 lolos, 6 dilewati) semuanya hijau

Catatan uji ber-jaringan: kuota per sidang

e2e/relay.spec.ts membuat satu estafet per uji, dan POST /api/relays dibatasi 10 pembuatan per jam per sidang alamat IP. Kalau semua uji memakai sidang yang sama, menjalankan berkasnya beberapa kali dalam satu jam akan gagal dengan 429. Karena itu tiap uji memasang x-real-ip sendiri (198.51.100.x acak) lewat page.setExtraHTTPHeaders; header itu memang yang dibaca clientKeyFromRequest (di produksi diisi platform hosting), jadi tiap uji mendapat keranjang kuotanya sendiri dan hasilnya tidak bergantung pada jalankan sebelumnya. Uji klaim bersamaan memakai request.post tanpa header itu, dan rute claim memang tidak dibatasi.

Catatan uji: kompilasi dingin server pengembangan

Dua uji M8 pernah gagal hanya karena server pengembangan baru dinyalakan: kompilasi rute pertama memicu muat ulang halaman setelah goto, sehingga pemilihan radio di e2e/helpers.ts kadang jatuh sebelum React terhidrasi (tombol "Mulai Foto" tetap nonaktif) dan asersi halaman 404 berlomba dengan navigasi yang berulang. Perbaikannya: masukAmbilFotoLayout mengulang pemilihan radio sampai tombolnya menyala (expect(...).toPass), dan uji 404 mengulang goto + asersinya. Keduanya berlaku untuk seluruh berkas e2e, bukan hanya M8; sesudah itu npx playwright test penuh hijau dari server yang baru dinyalakan.

Uji ber-jaringan M8

Alur dua konteks, konteks ketiga, dan klaim bersamaan ada di e2e/relay.spec.ts dengan gerbang SUPABASE_E2E=1. Setelah migrasi diterapkan atas persetujuan pengguna: SUPABASE_E2E=1 npx playwright test relay.spec.ts → 4 lolos, 0 dilewati, 0 gagal (52 detik).

Uji	Bukti
Alur utama dua konteks	Pembuat mengisi 2 foto, membuat link lewat dialog persetujuan, dan membacanya dari kartu (`/r/{id}`). Teman membuka link di konteks kedua: melihat 2 foto pembuat sebagai "Slot 1/3 sudah terisi" dan slot 2/4 putus-putus, mengambil giliran lewat dialog, mengisi 2 foto (baki menampilkan slot terkunci bergembok + sakelar bayangan menyala + lapisan `stage-overlay` terlihat), hias tanpa kartu QR, lalu "Selesai & Unduh" → mendarat di `/s/{id}` dan `<img alt="Strip">` memuat PNG bertanda tangan dari `storage/v1/object/sign`. Konteks ketiga tanpa token melihat "Estafet ini sudah selesai." tanpa tautan, dan payload halamannya tidak memuat path `/s/{id}` maupun URL bertanda tangan (regresi untuk temuan major). Pembuat membuka `/r` lagi: tautan "Lihat strip" menunjuk path yang sama, lalu "Batalkan dan Hapus" menghapus stripnya (halaman `/s/{id}` berikutnya menjawab 404)
Giliran sekali (SE-06)	Konteks ketiga setelah klaim API: "Estafet ini sudah diambil." dan tombol "Ambil Giliran" tidak ada
Klaim bersamaan	Dua `POST /api/relays/{id}/claim` paralel: tepat satu 200 dan satu 409 (bukan mock: Postgres sungguhan)
SE-10 (P1) hias ulang salinan pembuat	Di uji yang sama, setelah melihat tautan strip, pembuat menekan "Hias ulang salinanmu" → mendarat di `/booth/customize`, kanvas tampil, lencana kepala panel menunjukkan "4 foto siap" (semua slot termuat dari URL bertanda tangan), dan kartu "QR di strip" tidak ada
404	`/r/tidakada1234` → 404 + "Halaman tidak ditemukan." (tanpa gerbang env)

Tiga kegagalan awal yang ditemukan dan diperbaiki selama pengujian ini: (1) useSyncExternalStore di view relay mengembalikan objek baru tiap panggilan → render tanpa henti dan halaman teman tidak pernah siap (sekarang snapshot-nya string mentah + useMemo); (2) reset() sebelum router.push("/s/{id}") membuat gerbang langkah booth mengalihkan ke pemilih layout lebih dulu (sekarang hanya rekaman perangkat dan irisan estafet yang dilepas); (3) kuota pembuatan 10 link per jam per sidang dipakai bersama antar-uji (sekarang tiap uji memasang x-real-ip sendiri, lihat catatan di atas).

Hasil tinjauan keamanan (temuan major diperbaiki, sisanya dicatat)

Peninjauan baca-saja atas src/app/api/relays/**, src/lib/supabase/{relays,storage}.ts, src/lib/{relaySlots,rateLimit,schemas,tokens,expiry}.ts, src/app/r/[id]/page.tsx, src/features/relay/**, dan migrasi relays (tanpa blocker).

Tingkat	Temuan	Tindakan
major	Gate token di `/r/[id]` status `complete` hanya presentasional: halaman server mengirim `stripId` dan URL baca bertanda tangan untuk semua slot ke props komponen klien, jadi siapa pun pemegang link estafet bisa membacanya dari payload RSC/HTML tanpa token (desain M8 keputusan 7 menjanjikan sebaliknya)	Diperbaiki. Rute baru `POST /api/relays/[id]/strip` memverifikasi `x-relay-token` terhadap hash pembuat/tamu di server, lalu mengembalikan `stripId`, `expiresAt`, peran, dan URL slot berumur 1 jam. Halaman `/r/[id]` status `complete` tidak lagi membaca tabel `strips` maupun menandatangani apa pun; `RelayCompleteView` meminta datanya sendiri setelah tokennya terbaca (keadaan memuat/gagal/siap). Dijaga 4 kasus unit baru di `tests/api-relays.test.ts`
minor	`claim` tanpa gate jenis isi: POST sederhana (form/`no-cors`) lintas situs bisa membakar giliran sekali pakai	Diperbaiki. `claim` menolak permintaan yang bukan `application/json` (400), klien resmi mengirim body JSON kosong, dan e2e mengirim `data: {}`. Dijaga uji unit baru
minor	Tidak ada validasi runtime baris DB (`slots` diasumsikan array; `row.layout in LAYOUTS` menembus rantai prototipe)	Diperbaiki sebagian. `relaySlotsOf(row)` memeriksa bentuk tiap slot dan dipakai semua konsumen (halaman `/r`, rute claim/complete/strip, pembersih), dan `Object.hasOwn(LAYOUTS, …)` menggantikan `in`. Constraint `check (jsonb_typeof(slots) = 'array')` dan daftar layout tertutup diusulkan untuk M9 (perlu migrasi baru)
minor	Balapan di jalur pemulihan: dua `complete` bersamaan saat stripnya sudah dihapus sama-sama membuat draf baru → dua baris `strips` ber-`relay_id` sama (tanpa unique index); jalur utamanya sendiri sudah aman (tepat satu pemenang)	Diterima, dicatat. Perbaikannya butuh kolom `strip_id` di `relays` + UPDATE bersyarat (migrasi baru). Dampaknya: satu baris yatim yang dibersihkan cron, dan pilihan tautan yang nondeterministik pada kasus langka itu
minor	Tanpa rate limit untuk `claim`/`complete`: (i) pemegang id bisa membebani Storage lewat HEAD berulang di `claim`; (ii) loop `complete` → `DELETE /api/strips/[id]` bisa mencetak baris `strips` tanpa kuota (`rate_key` kosong)	Diterima, dicatat. (i) terbatas 2 permintaan HEAD per panggilan dan berhenti begitu status bukan `waiting`; (ii) id dan token tetap diperlukan, dan tiap putaran butuh token tamu yang sah. Bila kelak perlu, tambahkan hitungan baris per `relay_id` di `complete`
—	Catatan non-keamanan: ARCHITECTURE §7 menyebut field "waktu isi" di `slots` yang tidak ada di implementasi	Dicatat. Slot menyimpan `{ index, owner, path }`; waktu isi tidak dipakai fitur mana pun hari ini. Dokumen tidak diubah diam-diam

Titik yang dinyatakan benar oleh peninjau: token 32 bita acak + SHA-256 + perbandingan waktu tetap; RLS tanpa policy; bucket privat; verifikasi HEAD pasca-unggah; UPDATE bersyarat sekali-pakai untuk claim/complete; balasan API tidak membocorkan hash maupun path slot teman; balasan 422 berisi URL unggah tidak menaikkan hak (token diperiksa lebih dulu dan hanya slot guest yang ditandatangani); halaman /s dan /r sudah noindex + no-referrer.

Batas aman

Migrasi 20261014000000_relays.sql sudah diterapkan ke proyek Supabase snapme (ref owdjkpzywzljnvuyfiui) lewat npx supabase db push atas persetujuan pengguna; npx supabase migration list mengonfirmasi 20261014000000 ada di remote. Isinya: tabel relays (RLS menyala tanpa policy), dua indeks, dan image/jpeg ditambahkan ke daftar jenis bucket. Perubahan skema berikutnya mengikuti aturan yang sama: pengguna yang menjalankan, atau pihak lain setelah ada persetujuan.

M9 Pengerasan (9 Oktober 2026)

Satu milestone, satu putaran kerja. Urutan kerjanya: pengerasan data (sisa M8), analitik, CSP penuh, audit aksesibilitas, kinerja, uji lintas peramban, dokumen.

Pengerasan tabel `relays` (sisa temuan M8)

Migrasi 20261015000000_relays_hardening.sql: kolom strip_id pada relays, constraint relays_layout_check (daftar layout tertutup, sejalan LayoutId di src/lib/layouts.ts), constraint relays_slots_array_check (jsonb_typeof(slots) = 'array'), dan indeks unik parsial relays_strip_id_key.

Butir	Keputusan dan bukti
Bentuk tiap elemen slot	Tetap di `relaySlotsOf` (runtime), bukan check constraint: satu elemen cacat tidak boleh menjatuhkan seluruh baris
Balapan jalur pemulihan (temuan minor M8)	Rute `POST /api/relays/[id]/complete` memakai `relays.strip_id` sebagai gerbang pemenang tunggal: UPDATE bersyarat `strip_id is null` yang hanya boleh berhasil sekali. Yang kalah membuang draf yatimnya (barisnya saja, belum ada berkas terunggah) lalu menjawab draf pemenang. Jalur utama (claimed → complete) kini lewat jalur yang sama, jadi penuntasan dan pemulihan yang berbarengan tetap satu draf
Bukti	`tests/api-relays.test.ts` (27 lolos) menambah kasus: gerbang dibuka lagi bila strip pemenang dihapus, dua penuntasan pemulihan berbarengan → tepat satu baris `strips`, `stripId` kedua jawaban sama, dan draf yang kalah benar-benar terhapus (dilacak `fake.log.droppedStrips`); strip yang dipakai selalu yang ditunjuk gerbang, bukan draf sisa ber-`relay_id` sama, di tiga rute (`complete`, `strip`, dan `DELETE`)

Analitik first-party (PRD §4)

Keputusan pengguna: endpoint peristiwa first-party, bukan alat pihak ketiga. Migrasi 20261016000000_events.sql membuat tabel events (id identity, name, rate_key, created_at; RLS menyala tanpa policy; dua indeks). Yang tersimpan hanya nama peristiwa, sidang pembatasan laju (SHA-256 alamat IP + RATE_LIMIT_SALT, sama seperti tabel lain), dan waktu: tidak ada cookie, kolom sidang, perangkat, atau jalur. Retensi 90 hari, dibuang GET /api/cron/purge.

Bagian	Keputusan
Daftar peristiwa	Tertutup di `src/lib/analyticsEvents.ts` (16 nama), dipakai klien dan server. Rute `POST /api/events` menolak nama di luar daftar (400), badan bukan JSON (400), dan batch di luar 1 sampai 20 butir
Pembatasan laju	Anggaran 200 peristiwa per jam per sidang (`EVENT_LIMIT`), pola hitung-setelah-sisip yang sama dengan rute POST lain: batch yang melewati batas dibuang lagi sebelum menjawab 429
Tanpa env Supabase	Rute menjawab 503 diam-diam dan aplikasinya tetap jalan (pola M6 temuan 8)
Pengiriman klien	`src/lib/analytics.ts`: antrean di memori, dikirim `navigator.sendBeacon` saat mencapai 8 peristiwa, saat halaman disembunyikan, dan saat `pagehide`. Best-effort: tanpa retry, tanpa cookie, tidak pernah melempar
Bucket "cepat dipakai"	`snapme:t0` di sessionStorage diisi `SessionStartPing` di Welcome; ambang 15/30/60 detik ada di `src/lib/analyticsEvents.ts`
Bukti unit	`tests/api-events.test.ts` (7 lolos) dan `tests/analytics-queue.test.ts` (6 lolos): ambang batch, kirim saat disembunyikan dan `pagehide`, jatuh ke `fetch` bila beacon tidak ada atau menolak, batas bucket, pembatalan batch yang melewati anggaran, dan penolakan permintaan lintas situs. Pembersih: `tests/api-events.test.ts` juga menguji kelompok `events` di cron
Bukti ber-jaringan	Setelah migrasi diterapkan, `welcome_loaded` dari kunjungan sungguhan muncul di `events` (diperiksa lewat REST dengan kunci service role)

Kueri rasio ukuran PRD §4 (dijalankan manual; dashboard tidak dibuat):

-- 1. Alur dasar selesai tanpa bantuan (target >= 60%)
select (select count(*) from events where name = 'download_png')::float
     / nullif((select count(*) from events where name = 'camera_granted'), 0);

-- 2. Gesture Snap benar-benar dipakai (target >= 50%)
select (select count(*) from events where name = 'photo_taken_gesture')::float
     / nullif((select count(*) from events
               where name in ('photo_taken_gesture', 'photo_taken_button')), 0);

-- 3. Estafet tuntas (target >= 40%)
select (select count(*) from events where name = 'relay_completed')::float
     / nullif((select count(*) from events where name = 'relay_created'), 0);

-- 4. Strip Hidup menambah nilai (target >= 30%)
select (select count(*) from events where name = 'live_enabled')::float
     / nullif((select count(*) from events where name = 'customize_reached'), 0);

-- 5. Cepat dipakai (median < 30 detik): sebaran bucket sebagai ganti durasi
select name, count(*) from events
where name like 'first\_photo\_%' group by name order by name;

Catatan kejujuran angka: rasio dihitung dari hitungan peristiwa, bukan sesi. welcome_loaded, camera_granted/camera_denied, live_enabled, relay_created, dan download_png dijaga agar hanya tercatat sekali per kunjungan halaman (temuan tinjauan M9: tombol unduh tetap hidup setelah unduhan pertama, jadi tanpa penjaga itu rasio #1 bisa melewati 100%), dan photo_taken_* memang dihitung per foto. relay_completed tercatat sekali per penuntasan; rasio #2 memakai semua foto, sedangkan PRD membatasinya pada sesi dengan gesture menyala, sehingga nilainya adalah batas bawah. Rasio-rasio ini juga baru bermakna untuk lalu lintas setelah rilis: jalankan pengembangan dan suite ber-jaringan (SUPABASE_E2E=1) menulis ke tabel yang sama.

CSP penuh dan status halaman `/s` serta `/r`

next.config.ts memasang satu CSP untuk /:path* (menggantikan Content-Security-Policy: frame-ancestors 'none' yang dulu hanya di /s dan /r), disusun dari env: host Supabase ditambahkan hanya bila NEXT_PUBLIC_SUPABASE_URL ada.

default-src 'self'; script-src 'self' 'unsafe-inline' 'wasm-unsafe-eval';
style-src 'self' 'unsafe-inline'; img-src 'self' blob: data: {SUPABASE};
media-src 'self' blob: data: {SUPABASE}; connect-src 'self' blob: data: {SUPABASE};
font-src 'self' data:; worker-src 'self' blob:; object-src 'none';
base-uri 'self'; form-action 'self'; frame-ancestors 'none'

Direktif	Alasan
`script-src 'unsafe-inline'`	Skrip bootstrap App Router ditulis inline tanpa nonce. Nonce memaksa render dinamis setiap permintaan, bertabrakan dengan `cacheComponents` dan target LCP Welcome (PRD §8)
`script-src 'wasm-unsafe-eval'`	Gesture Snap menjalankan model MediaPipe yang di-host sendiri (ARCHITECTURE §6)
`'unsafe-eval'` hanya di pengembangan	React memakainya untuk menyusun ulang jejak galat di peramban; produksi tidak membutuhkannya. CSP produksi tidak memuat `'unsafe-eval'`
`img-src`/`media-src` `blob:` dan `data:`	Ekspor kanvas (`toDataURL`), bingkai klip sebagai ImageBitmap, dan hasil `MediaRecorder` sebagai URL blob
`connect-src` `blob:` dan `data:`	Konversi hasil ekspor menjadi Blob lewat `fetch(dataUrl)`; keduanya lokal, tidak keluar jaringan
`worker-src 'self' blob:`	MediaPipe membuat worker dari berkasnya sendiri dan dari blob
`font-src 'self' data:`	Fon di-host sendiri lewat `next/font`
`{SUPABASE}`	Unggahan langsung ke Storage dan URL bertanda tangan saat membaca

Temuan selama verifikasi, semuanya dicatat:

Temuan	Tindakan
`next dev` sudah memakai CSP ini sejak M9; seluruh suite chromium tetap hijau di server produksi (`npm run build && npm start`): 57 lolos, 11 dilewati, 0 gagal (yang dilewati: uji ber-jaringan ber-gerbang `SUPABASE_E2E`, dan dua audit galeri `/dev/ui` yang memang tidak dirender di produksi). Suite kanonik di server pengembangan (semua proyek, `npx playwright test`) 64 lolos, 8 dilewati, 0 gagal	Tidak ada perubahan direktif
`curl -I /` dan `/s/x` memperlihatkan satu CSP, tanpa `'unsafe-eval'`	Bukti: keluaran `curl`
Zod (lewat `src/lib/schemas.ts` yang ikut bundel klien) menjalankan uji kemampuan `Function("")` di dalam `try/catch`; di bawah CSP tanpa `'unsafe-eval'` uji itu memicu satu laporan `securitypolicyviolation` di konsol	Dibiarkan. Zod menangkapnya dan turun ke jalur validasi non-JIT: tidak ada perilaku yang berubah. Menambahkan `'unsafe-eval'` ke produksi demi menghilangkan satu laporan konsol bukan pertukaran yang sepadan
Halaman `/s/[id]` dan `/r/[id]` menjawab 200 di server produksi untuk id yang tidak ada (di server pengembangan 404). Cangkang PPR dikirim lebih dulu, jadi `notFound()` tidak bisa lagi mengubah status	Diperbaiki dengan `htmlLimitedBots: /.*/` di `next.config.ts`: semua permintaan dirender blocking seperti crawler, sehingga `notFound()` benar-benar menjawab 404 di produksi (`curl` membuktikan 404 + "Halaman tidak ditemukan."). Biayanya: metadata tidak lagi dialirkan, dan halaman `/s` serta `/r` menunggu satu baris basis data sebelum HTML pertama (memang begitu maksud `instant = false`)
Tiga uji e2e gagal di server produksi karena membandingkan piksel kanvas tepat setelah klik (penggambaran ulang Konva tidak sinkron dengan klik); di server pengembangan kebetulan lolos	Uji diperbaiki dengan `expect.poll`/`expect.poll(...).not.toBe(...)` di `customize.spec.ts`, `live.spec.ts` (dua tempat), dan `share.spec.ts`
`e2e/result.spec.ts` mengaudit "tanpa permintaan non-statis" pada alur dasar; analitik M9 memang sengaja memanggil `/api/events`	Daftar rute yang diizinkan ditambah `/api/events` dengan komentar: isinya hanya nama peristiwa, tanpa gambar

Hasil tinjauan kode dan keamanan

Tinjauan dijalankan baca-saja atas seluruh perubahan M9 setelah semua pemeriksaan hijau. Tidak ada blocker. Temuan yang bisa dikerjakan di ruang lingkup M9 langsung diperbaiki; sisa yang bukan lingkup M9 dicatat apa adanya.

Tingkat	Temuan	Tindakan
major	`firstPhotoBucketEvent()` membaca sessionStorage tanpa penjaga; di peramban yang memblokir penyimpanan, galatnya melempar di dalam efek jepret setidaknya sebelum `SHOT_SAVED`, sehingga fase `capturing` tidak pernah maju dan bingkai klipnya tidak pernah dilepas. `markSessionStart()` juga melempar dari effect halaman Welcome	Diperbaiki. Keduanya dibungkus `try/catch` (pola yang sama dengan `track()` dan `relayToken.ts`), dan pemanggilan analitik di halaman Ambil Foto dipindah ke SETELAH `dispatch({ type: "SHOT_SAVED" })` supaya mesin keadaan selalu maju lebih dulu
medium	`POST /api/events` memakai pola hitung-setelah-sisip, jadi setelah anggaran habis setiap permintaan tetap melakukan INSERT 20 baris + COUNT + DELETE sebelum menjawab 429: yang dibatasi hanya baris tersimpan, bukan kerja tulis basis datanya	Diperbaiki. Gerbang murah sebelum sisip ditambahkan di `events`, `strips`, dan `relays` (tolak tanpa menulis bila jendela kuotanya sudah penuh), sementara pemeriksaan setelah sisip tetap jadi gerbang resmi untuk permintaan serentak
low	Rute `POST /api/events` hanya bergantung gate jenis isi untuk menutup permintaan lintas situs	Diperbaiki. Helper `isCrossSite()` (`src/lib/rateLimit.ts`) menolak permintaan yang membawa `Sec-Fetch-Site: cross-site` atau `Origin` yang bukan origin sendiri, dipakai di `events`, `strips`, dan `relays`
low	`rate_key` peristiwa memakai garam dan bentuk hash yang sama dengan `strips`/`relays`, sehingga pemegang akses basis data bisa menyambungkan timeline peristiwa ke baris strip berisi foto lewat kunci pseudonim yang stabil; teks halaman Privasi tidak menyebut konsekuensi itu	Diperbaiki. `rateKeyFor()` menerima `scope`; rute peristiwa memakai scope `events` sehingga hashnya berbeda untuk alamat yang sama (nilai lama tidak berubah karena scope bawaannya kosong). Halaman Privasi mendapat bagian "Hitungan peristiwa": apa yang dicatat, tanpa cookie, dan retensi 90 hari sidang terpisah
low	Peramban/permintaan ketiga yang bersamaan pada estafet `complete` bisa menerima draf yang kalah balapan (id + URL unggah) sebelum draf itu dibuang; berkas yang diunggah ke path itu menjadi yatim permanen karena pembersih hanya menghapus path yang dirujuk baris	Diperbaiki. Gerbang `relays.strip_id` dibaca lebih dulu daripada pencarian lewat `relay_id` di `complete`, `strip`, dan `DELETE`; baris yang belum terlihat dibaca ulang beberapa kali sebelum gerbangnya dibuka (pemenang menulis gerbang sebelum barisnya), dan pembuangan draf yang kalah jadi best-effort supaya jawabannya tidak jatuh jadi 500. Konsekuensinya dicatat: satu estafet boleh punya lebih dari satu baris `strips` bila baris lamanya batu nisan, yang dijaga adalah satu strip aktif per estafet
low	Tiga uji ber-link (`share`, `live`, `a11y`) memakai sidang pembatasan laju bawaan yang sama, sehingga 3 baris per jalankan terhadap kuota 10 per jam bisa habis setelah empat jalankan dalam satu jam	Diperbaiki. Ketiganya memanggil `pasangSidangBaru()` seperti uji estafet
note	CSP, `noindex`, dan `no-referrer` tidak punya asersi otomatis: satu suntingan bisa menghapusnya tanpa ada uji yang gagal	Diperbaiki. Uji baru di `e2e/crossbrowser.spec.ts` memeriksa CSP di `/` (memuat `frame-ancestors 'none'`, `object-src 'none'`, `base-uri 'self'`, `wasm-unsafe-eval`, dan tanpa `'unsafe-eval'` di server produksi) serta `X-Robots-Tag` dan `Referrer-Policy` di `/s/[id]`. Uji ini berjalan di chromium, firefox, dan webkit
note	Komentar dan dokumen mengklaim "satu estafet hanya punya satu strip", padahal batu nisan penghapusan memang boleh menyisakan baris kedua	Diperbaiki. Komentar rute dan kalimat `docs/DECISIONS.md`/`ARCHITECTURE.md` diubah menjadi "satu strip aktif per estafet"
note	Angka rasio PRD §4 lebih longgar daripada yang disiratkan: `download_png` dan `relay_completed` dihitung per klik (bukan per sesi), jadi rasio #1 dan #3 bisa melewati 100%; rasio #2 memakai semua foto, sedangkan PRD menyebut sesi dengan gesture menyala	Diperbaiki sebagian. `download_png` kini dijaga sekali per kunjungan halaman Result (seperti `live_enabled`); rasio #2 tetap batas bawah dan itu dicatat di kalimat "Catatan kejujuran angka", bersama catatan bahwa jalankan pengembangan dan pengujian gated menulis ke tabel yang sama sehingga rasio baru bermakna setelah rilis
note	Siklus `POST complete` → `DELETE /api/strips/[id]` → `POST complete` mencetak baris `strips` baru tanpa menyentuh kuota, karena draf relay memakai `rate_key: ""`	Diterima, dicatat. Sama dengan penerimaan M8: barisnya tetap dibersihkan (batu nisan 3 jam, draf basi 24 jam) dan untuk berputar tetap dibutuhkan token estafet plus token hapus. Bila kelak perlu, tambahkan hitungan baris per `relay_id` di rute `complete`
note	Larangan lintas situs pada rute lama belum menutup permintaan tanpa header (`Origin`/`Sec-Fetch-Site` tidak ada) dan pembatasan laju tetap per alamat, bukan global	Diterima, dicatat. Pola yang sama sudah dicatat sejak M6 (`x-forwarded-for` hop pertama bisa dipalsukan bila proxy hanya menambahkan); di Vercel `x-real-ip` ditimpa platform

Titik yang dinyatakan benar oleh peninjau: gerbang pemenang tunggal tidak bisa macet dan tidak bisa dipakai mengambil alih strip estafet lain; indeks unik parsial mencegah dua relay berbagi strip; bentuk balasan claimed → complete tidak berubah; token diverifikasi sebelum semua pembacaan; CSP memuat setiap origin dan jenis sumber yang benar-benar dipakai aplikasi dan gagal-tertutup bila env Supabase cacat; 'unsafe-eval' hanya ada di pengembangan; frame-ancestors kini berlaku di seluruh rute tanpa menimpa header halaman pribadi; tabel events tidak menyimpan identitas langsung dan anggaran baris tersimpannya tidak bisa dilewati permintaan serentak; satu-satunya host luar adalah Supabase milik aplikasi sendiri; dan kode klien baru tidak pernah mengirim foto, klip, teks, atau isi strip.

Audit aksesibilitas (axe, keyboard, zoom)

Pemeriksaan	Hasil
axe otomatis	`npx playwright test e2e/a11y.spec.ts` → 18 lolos, 2 dilewati di server produksi. Cakupannya 9 halaman × 2 viewport (360 dan 1280 px): welcome, privasi, pilih layout, ambil foto, hias, hasil, `/s` 404, `/r` 404, dan galeri `/dev/ui` (dua uji itu dilewati di produksi karena galerinya memang tidak dirender). Batasnya nol pelanggaran, lebih ketat daripada syarat "tanpa tingkat serius atau kritis"
axe pada halaman ber-link	Dua uji baru di bawah gerbang `SUPABASE_E2E=1`: `/s/{id}` strip lengkap dan `/r/{id}` status menunggu teman, memakai alur pembantu yang sama dengan `share.spec.ts` dan `relay.spec.ts` (dipindah ke `e2e/helpers.ts` supaya tidak diduplikasi). Hasil: 20 lolos, 0 gagal di server pengembangan. Halaman estafet diaudit dari konteks browser kedua tanpa token, karena konteks pembuat menampilkan keadaan "menunggu teman"
Temuan axe di galeri `/dev/ui`	Galeri komponen hanya dirender di server pengembangan, dan di sanalah auditnya menemukan pelanggaran kritis `button-name`: dua sakelar contoh tanpa nama aksesibel (`#gesture` dan satu sakelar nonaktif). Diperbaiki: keduanya diberi `aria-label` ("Gesture Snap", "Strip Hidup"), sejalan DESIGN-SYSTEM §9 yang mewajibkan sakelar punya teks keadaan dan kontrol punya nama. Dua uji audit galeri (360 dan 1280 px) hijau setelahnya, dan di server produksi keduanya dilewati karena galerinya memang tidak dirender
Keyboard seluruh alur	`e2e/keyboard-flow.spec.ts` (baru): Welcome → pilih layout → izin kamera → 4 foto lewat Spasi → hias → hasil → dialog persetujuan QR ditutup dengan Esc → unduh PNG, tanpa satu pun `page.mouse`. Fokus dipindah dengan Tab; radio layout dan pil pilihan hiasan digerakkan panah
Temuan keyboard	Grup pil `ToggleGroup` Radix hanya menjadikan pil terpilih sebagai tab stop, dan panahnya bergerak dengan satu tekanan tersendat. Uji karena itu memakai panah sampai fokus benar-benar pindah (loop berbatas) dan kembali ke pil lain dengan fokus terprogram, pola yang sama dengan uji keyboard lama di `customize.spec.ts`. Tidak ada masalah aksesibilitas yang ditemukan: pil bisa dicapai dan diaktifkan dengan keyboard
Zoom 200%	Diperiksa dengan CDP `Emulation.setPageScaleFactor(2)` (browser tool) pada `/`, lalu setara zoom desktop (jendela 1280 px melihat ruang CSS 640 px) dan pembesaran teks 200% pada `/`, `/booth/capture`, `/booth/customize`. Hasil: `scrollWidth == clientWidth` di semua kombinasi (tidak ada luber horizontal) dan aksi utama tetap di dalam layar. Tangkapan layar: `test-results/zoom-*.png`
Pembaca layar	Belum diverifikasi (tidak ada pembaca layar di mesin ini); langkahnya masuk tabel manual pengguna di bawah

Kinerja (PRD §8)

Alat: Lighthouse 13 dengan preset bawaan seluler (CPU 4× lebih lambat, jaringan 4G lambat tersimulasi) di server produksi. Skrip baru: npm run perf:lcp.

Ukuran	Target PRD §8	Hasil	Selisih
LCP Welcome	di bawah 2,5 detik	3,17 detik (median tujuh jalankan di server produksi lokal `next start`: 3028 sampai 3188 ms; angka terakhir 3062 ms)	+670 ms di server lokal; di produksi Cloudflare targetnya tercapai (median 2,4 detik, lihat "Langkah 1 rencana" di bawah)
Skor kinerja Lighthouse	—	92 sampai 94	—
FCP / TBT / CLS	—	917 ms / 76 sampai 116 ms / 0	—
Ekspor strip sampai siap unduh	di bawah 2 detik	895 sampai 971 ms (median 922 ms dari enam jalankan `e2e/perf.spec.ts` di server produksi; jalankan di server pengembangan 1135 ms)	Tercapai
Unduh setelah klik	—	22 sampai 43 ms	—

Satu putaran optimasi terbatas sudah dijalankan sesuai rencana: font-display keluarga display diubah ke optional (LCP elemennya judul hero display-xl dari Unbounded). Hasilnya tidak berbeda (median 3,17 detik), karena yang menahan LCP bukan penggantian fon melainkan biaya gambar judul hero (1170 ms element render delay di jejak dengan CPU 4× lebih lambat) plus rebutan lebar pita dengan bundel JS. Pengaturannya dikembalikan ke swap supaya tipografi merek tidak jatuh ke fon cadangan di kunjungan pertama yang lambat.

Rencana untuk selisih 670 ms (dipilih pengguna sebelum dianggap selesai):

Kurangi JS Welcome. Terukur: 182 KB dari 304 KB total. Dua potongan terbesar 71 KB (runtime React/Next) dan 45 KB (kerangka + UI bersama). Kandidat: pindahkan <Toaster /> dari root layout ke layout booth (sonner tidak dipakai Welcome), dan muat GalleryPicker di belakang interaksi seperti CustomizeEditor.
Uji di perangkat sungguhan (HP Android kelas menengah + 4G) sebelum mengubah desain. Preset seluler Lighthouse mensimulasikan 4G lambat (1,6 Mbps, RTT 150 ms), lebih pesimistis daripada definisi "4G" di PRD; median di perangkat sungguhan bisa saja sudah di bawah 2,5 detik.
Bila masih lewat: hero display-xl memakai -webkit-text-stroke dan text-shadow keras yang mahal digambar. Menggantinya adalah perubahan DESIGN-SYSTEM, jadi harus diusulkan ke pengguna dulu, bukan dikerjakan diam-diam.

Status 16 Oktober 2026: langkah 1 dikerjakan, dan setelah pengukuran di produksi targetnya ternyata sudah tercapai di sana sehingga langkah 2 dan 3 tidak diperlukan untuk memenuhi target. Rincian, angka, dan bukti bundelnya di subbagian "Langkah 1 rencana" di bawah.

Ukuran bundel per rute (transfer terkompresi, cache dimatikan, server produksi):

Rute	JS	CSS	Fon	Lain	Total
`/`	182 KB	14 KB	91 KB	17 KB	304 KB
`/privasi`	182 KB	14 KB	91 KB	24 KB	312 KB
`/booth/layout`	178 KB	14 KB	91 KB	17 KB	301 KB
`/booth/capture`	301 KB	14 KB	91 KB	24 KB	431 KB
`/booth/customize`	307 KB	14 KB	91 KB	44 KB	457 KB
`/booth/result`	307 KB	14 KB	91 KB	27 KB	439 KB
`/s/{id}` (404)	233 KB	14 KB	91 KB	27 KB	366 KB
`/r/{id}` (404)	238 KB	14 KB	91 KB	27 KB	371 KB

Catatan: Next.js 16 menghapus metrik size dan First Load JS dari keluaran next build (dokumentasinya menyebut keduanya tidak akurat untuk arsitektur server-driven). Karena itu tabel di atas diukur dari peramban sungguhan (performance.getEntriesByType("resource") dengan Network.setCacheDisabled), bukan disalin dari keluaran build. Yang tetap terjaga: modul kamera/gesture (301 KB) dan Konva (307 KB) hanya muncul di rutenya sendiri, dan uji "konva tidak ikut termuat di / dan /booth/capture" tetap hijau.

Langkah 1 rencana (dikerjakan 16 Oktober 2026)

Perubahan: sonner dikeluarkan dari jalur kritis Welcome. Root layout kini merender DeferredToaster (src/components/ui/deferred-toaster.tsx: next/dynamic dengan ssr: false), dan GalleryPicker mengimpor sonner secara dinamis di dalam handleFiles alih-alih di tingkat modul. Toaster tetap di root layout supaya toast yang dipicu tepat sebelum navigasi (Welcome → /booth/capture) tampil di halaman tujuan; e2e/customize.spec.ts ("dua foto galeri dilengkapi di kamera") menguji jalur itu dan tetap hijau. Tidak ada warna, token, tata letak, atau teks yang berubah.

Bukti bundel (pratinjau, Network.setCacheDisabled, snapshot pada load dan 2 detik sesudahnya):

Ukuran	Sebelum	Sesudah
JS sebelum `load`	165,9 KB (8 berkas)	153,9 KB (7 berkas)
Chunk sonner	9,9 KB, diunduh sebelum `load`	9,9 KB (`3o_zaba4nwz_y.js`, 35.924 bita mentah), mulai 844 ms, sesudah `loadEventEnd` 823 ms
JS sampai 2 detik sesudah `load`	179,1 KB	181,2 KB

Ukuran transfer per jenis (CSS, fon) tidak berubah. Di HTML produksi (9 skrip awal) tidak satu pun chunk memuat data-sonner-toaster.

Lighthouse preset seluler, lima jalankan per sel, angka median:

Target	LCP sebelum	LCP sesudah	FCP sesudah	TBT sesudah	CLS sesudah	Skor sesudah
Produksi (`https://snapme.ikhsandyy-dev.workers.dev`)	2.388 ms	2.416 ms	1.066 ms	62 ms	0	97 (sebelum 98)
Pratinjau Cloudflare (`wrangler dev`)	3.737 ms	3.680 ms	1.104 ms	51 ms	0	88 (sebelum 87)

Kesimpulan yang bisa dipertanggungjawabkan: target LCP Welcome PRD §8 tercapai di produksi (median 2,4 detik terhadap batas 2,5 detik), dan itu berlaku juga sebelum langkah 1. Dua angka lama berasal dari server lokal, bukan CDN: 3,17 detik dari next start dan 3,745 detik dari wrangler dev. Keduanya melebih-lebihkan selisihnya, jadi kalimat "selisih 670 ms" di bagian atas harus dibaca sebagai sifat server lokal. Langkah 1 tetap dikerjakan dan hasilnya nyata pada jalur kritis (JS sebelum load turun 12,0 KB dan chunk sonner tidak lagi ikut pra-load), tetapi tidak mengubah median produksi secara terukur: sebaran antarjalankan produksi 2.317 sampai 2.517 ms, jadi selisih 28 ms antara sebelum dan sesudah ada di dalam derau. Lima jalankan produksi "sebelum" memuat satu pencilan 3.897 ms pada jalankan pertama (cache kosong di mesin uji), yang tidak menggeser mediannya.

Langkah 2 (uji di perangkat sungguhan) dan langkah 3 (mengganti -webkit-text-stroke/text-shadow hero, perubahan DESIGN-SYSTEM) karena itu tidak diperlukan untuk memenuhi target ini; keduanya tetap tersedia sebagai rencana lanjutan bila pengukuran di perangkat nyata kelak menunjukkan sebaliknya.

Uji lintas peramban

Proyek Playwright baru: firefox dan webkit (keduanya testMatch: **/crossbrowser.spec.ts). Berkas e2e/crossbrowser.spec.ts sengaja tidak menyentuh kamera (perangkat media palsu adalah bendera Chromium): alurnya lewat foto galeri sampai unduh PNG, plus pemeriksaan judul halaman statis dan dua panggung 404.

Peramban	Hasil
Chromium (Desktop Chrome)	Lolos: berkas ini ikut proyek `chromium` yang memuat semua spec
Firefox	2 lolos
WebKit (Safari)	2 lolos (unduhan lewat `waitForEvent("download")` bekerja; `MediaRecorder` tidak diperlukan karena alur galeri tidak punya klip). Kemampuan merekamnya diperiksa terpisah: build WebKit milik Playwright tidak membawa `MediaRecorder` maupun `canvas.captureStream`, jadi tombol SH-03 di sana tersembunyi sesuai rancangan; Safari sungguhan belum diperiksa dan masuk tabel manual pengguna
Edge	Dilepas dari suite: `npx playwright install msedge` gagal di mesin ini ("insufficient privileges") dan Edge tidak terpasang. Mesinnya sama dengan Chromium (tercakup proyek `chromium`); verifikasi di Edge sungguhan masuk tabel manual pengguna

Daftar periksa DESIGN-SYSTEM §14

Butir	Hasil
Komponen dari dasar §9	Lolos: tidak ada komponen baru di M9; halaman yang disentuh (`/`, `/booth/capture`, `/booth/customize`, `/booth/result`) memakai komponen yang sudah ada
Tidak ada nilai mentah di luar `globals.css`	Lolos: penjaga token lama tetap hijau, dan perubahan M9 tidak menambah nilai mentah (CSP dan `htmlLimitedBots` di `next.config.ts` bukan token tampilan)
Tepat satu aksi `primary` per layar	Lolos: tidak ada tombol baru; `/dev/ui` tetap galeri komponen di server pengembangan
Pasangan warna dari §2	Lolos: tidak ada warna baru; audit axe nol pelanggaran termasuk kontras
Keadaan memuat, kosong, galat, nonaktif	Lolos: kartu bagikan, dialog, dan halaman strip tetap punya keempatnya (diuji M6 sampai M8, suite tetap hijau)
Keyboard dan cincin fokus	Lolos: `e2e/keyboard-flow.spec.ts` menuntaskan seluruh alur tanpa mouse, ringkasan temuan panah ada di atas
`prefers-reduced-motion`	Lolos: uji `e2e/live.spec.ts` dan `e2e/capture.spec.ts` tetap hijau; tiga asersinya kini menunggu penggambaran ulang, bukan membandingkan tepat setelah klik
Rapi pada 360, 768, 1280 px	Lolos: audit axe pada 360 dan 1280 px nol pelanggaran; 768 px tercakup uji lembar bawah `customize.spec.ts` dan pemeriksaan zoom 200% (640 px setara). Perbandingan berdampingan dengan berkas acuan di `docs/ui-reference/` tidak diulang di M9 karena perubahan M9 memang tidak menyentuh tampilan: seluruh diff bekerja di `git diff --stat` tidak memuat berkas CSS atau token, dan suntingan JSX hanya berupa penangan peristiwa, atribut `aria-label`, serta pemanggilan analitik. Perbandingan berdampingan terakhir ada di M6 untuk halaman ber-acuan dan hasilnya tidak berubah
Label §12, tanpa emoji dan em dash	Lolos: label baru tidak ditambahkan; teks yang disentuh M9 hanya komentar kode
Pemeriksaan tampilan Welcome dan `/s/{id}`	Dijalankan di M6 dan tetap berlaku: M9 tidak mengubah hero, susunan, atau teksnya (perubahan hanya CSP, analitik, dan judul dokumen)

Tabel manual pengguna (belum diverifikasi)

Butir	Langkah	Status
Gesture Snap (M3)	Buka `npm run dev`, pilih layout, izinkan kamera, angkat dua jari dan tahan 0,8 detik → hitung mundur mulai; telapak untuk ulang foto terakhir; jempol setelah semua slot terisi untuk lanjut ke hias. Uji di cahaya redup dan terang	Dikonfirmasi pengguna 16 Oktober 2026 di HP (rincian di tabel M3)
Chrome Android / Safari iOS / Edge dan Firefox sungguhan	Buka `/`, jalankan alur galeri sampai unduh di tiap peramban, catat yang gagal. Mesin WebKit dan Gecko sudah tercakup otomatis oleh proyek `webkit` dan `firefox`; yang belum diperiksa adalah sentuhan, kamera sungguhan, dan unduhan di perangkat	Menunggu pengguna
QR pada cetakan asli (M9 "Selesai bila")	`npm run dev`, buat strip dengan "QR di strip" menyala, tekan "Cetak 4R" pada kertas 4R, lalu pindai QR-nya dengan kamera HP → harus membuka `/s/{id}` dan menampilkan stripnya. Ulangi sekali di kertas biasa untuk membandingkan	Lolos: dikonfirmasi pengguna 16 Oktober 2026, QR cetakan terbaca kamera HP (printer/kertas tidak dirinci)
Pembaca layar	NVDA (Windows) atau VoiceOver (macOS) atau TalkBack (Android): jalankan alur dasar, periksa hitung mundur dan penghitung foto terumumkan (`aria-live`), HUD gesture terbaca (`role="status"`), dan padanan daftar stiker bisa dipakai tanpa kanvas	Menunggu pengguna
Deploy	Digantikan M10: Worker Cloudflare `snapme` ter-deploy (lihat Bukti verifikasi M10)	Selesai lewat M10

M10 Migrasi Cloudflare (9 Oktober 2026)

Perintah pengguna: pindahkan seluruh backend snapme dari Supabase/Vercel ke Cloudflare (D1, KV, R2) dan deploy ke Workers. Repo ini belum pernah dideploy (baris "Deploy ke Vercel" M9 masih "menunggu pengguna"), jadi tidak ada data produksi yang dimigrasikan: skema D1 dibuat segar dari migrations/0001_init.sql.

Runtime: OpenNext, bukan `next-on-pages` atau vinext

Kandidat	Kenapa tidak dipakai
Cloudflare Pages + `next-on-pages`	Adapter itu deprecated: Cloudflare memensiunkan alur Pages untuk Next.js SSR dan mengarahkan ke Workers
vinext (Vite + Next di Workers)	Masih beta; fon lewat CDN pihak ketiga (melanggar syarat "fon di-host sendiri" ARCHITECTURE §8) dan dukungan `cacheComponents`/PPR belum lengkap, padahal halaman `/s` dan `/r` bergantung padanya
`@opennextjs/cloudflare` + `wrangler` (dipakai)	Adapter matang milik tim OpenNext, mendukung `cacheComponents`/PPR dan `next/font` self-hosted, dikonfigurasi manual lewat `wrangler.jsonc` dan `open-next.config.ts`

Worker-nya kustom (worker.ts) mengikuti panduan resmi OpenNext: fetch dari keluaran build, scheduled untuk Cron Trigger. Tidak ada cache tambahan di open-next.config.ts karena tidak ada ISR (Welcome statis, /s dan /r dinamis). Catatan penting: cacheComponents/PPR semula dipertahankan, tetapi runtime Worker menolaknya di bawah permintaan bersamaan sehingga opsi itu dilepas (lihat bagian "Cache Components/PPR dilepas" di bawah).

Pemetaan Supabase/Vercel → Cloudflare

Supabase/Vercel	Cloudflare	Catatan
Postgres + RLS (`service role` saja)	D1 (`binding DB`)	D1 hanya bisa dijangkau lewat binding Worker; RLS tidak dipindahkan karena tidak ada jalur anon. Seam-nya `src/lib/cloudflare.ts` dengan perilaku lama: env kosong → null → rute menjawab 503
Storage bucket `snapme`	Bucket R2 `snapme`	Akses hanya lewat URL presigned; CORS bucket dari `r2-cors.json` (origin 3000, 8787, produksi)
Signed upload / signed URL Supabase	`presignPut`/`presignGet` (aws4fetch, Signature V4 di query string)	Content-Type ikut ditandatangani pada PUT, jadi R2 menolak unggahan jenis lain; rute complete tetap memverifikasi hasilnya dengan `bucket.head` (pengganti "URL bertanda tangan lalu HEAD" yang dulu memakai jaringan)
RPC/kueri builder	Prepared statement D1 (`src/lib/db/*`)	Tiga gerbang atomik tetap: `claimRelayOnce`, `completeRelayOnce`, `setRelayStripOnce`, kebenarannya dibaca dari `meta.changes === 1`
Vercel Cron	Cron Trigger Workers (`triggers.crons` di `wrangler.jsonc`, `scheduled` di `worker.ts`)	Tanpa HTTP dan tanpa rahasia bersama; rute `GET /api/cron/purge` dipertahankan untuk pemicu manual dengan `Authorization: Bearer CRON_SECRET`
Env Vercel + `.env.local`	`vars`/`secrets` wrangler + `.dev.vars` + `R2_ACCOUNT_ID` di `.env.local`	`R2_ACCOUNT_ID` harus ada saat `next build` (CSP) dan saat runtime (`vars` wrangler) supaya direktif CSP produksi identik dengan hasil build

Dialek SQL dan skema

Timestamp disimpan sebagai TEXT ISO-8601 UTC yang selalu diisi aplikasi (new Date().toISOString()), bukan default DB: perbandingan leksikografis pada format itu sama dengan kronologis, jadi indeks kedaluwarsa tetap bekerja tanpa fungsi.
Lima migrasi Postgres digantikan satu migrations/0001_init.sql; DDL lamanya tetap ada di riwayat git. Perbedaan yang disengaja: status strips ikut memuat deleted (batu nisan M6), relays.layout dibatasi daftar tertutup, dan slots dijaga check json_valid(slots) AND json_type(slots) = 'array' (padanan jsonb).
relaySlotsOf kini mem-parse teks JSON selain menyaring elemen cacat; perilakunya sama bagi pemanggil (baris cacat tidak menjatuhkan halaman atau menyandera pembersih).
rate_key ditambahkan sebagai kolom penuh di strips dan relays (di Postgres pun ada sejak M6/M8) dengan indeks (rate_key, created_at) supaya hitungan kuota tidak memindai tabel.

Kuota: tetap persis di D1 untuk strip/estafet, pindah ke KV untuk peristiwa

strips dan relays tetap memakai pola M6/M9: hitung-setelah-sisip, pra-cek murah, lalu rollback baris bila kuota terlampaui. Hasilnya identik dengan versi Supabase, termasuk baris batu nisan yang tetap dihitung.
Peristiwa analitik pindah ke KV dengan jendela tetap per jam (kunci ev:{rateKey}:{floor(now/3600000)}, TTL 2 jam). Alasan: tabel events terus tumbuh, sedangkan anggarannya telemetri; memindai tabel itu setiap beacon adalah biaya yang tidak sebanding. Konsekuensi yang diterima: (a) batasnya bergeser dari jendela bergulir ke batas jam, dan (b) dua permintaan serentak bisa melewati batas paling banyak satu batch (maksimal 20 peristiwa) karena penambahan dilakukan setelah INSERT tanpa rollback. Keduanya tidak menyentuh data pengguna dan tidak mengubah kuota strip/estafet.
rate_key untuk peristiwa tetap memakai scope events (temuan M9), jadi nilai yang tersimpan tidak bisa disambungkan ke sidang strips/relays.

Uji basis data: `getPlatformProxy`, bukan `@cloudflare/vitest-pool-workers`

Rencana awal memakai @cloudflare/vitest-pool-workers. Paket itu (0.23.0) masih mensyaratkan peer vitest ^4.1.0 sementara proyek ini vitest 5.0.3, dan ia memaku wrangler 4.124.0 sebagai dependensi sendiri. Memaksanya lewat --legacy-peer-deps berarti menjalankan pool yang tidak didukung vitest 5, jadi pool-nya dilepas.

Gantinya: harness tests/db/harness.ts memakai getPlatformProxy dari wrangler, API resmi untuk mengakses binding dari Node. Hasilnya real miniflare/workerd tanpa mock SQL: tests/db/{strips,relays,events}.test.ts menguji rute sungguhan di atas D1/R2/KV sungguhan, dengan migrasi yang sama (migrations/0001_init.sql) diterapkan di awal berkas uji. Berkas lama yang memakai klien Supabase palsu dihapus, bukan dipinjamkan.

Catatan teknis: D1Database.exec() memecah masukan per baris, jadi harness merapatkan pernyataan (dan membuang komentar penuh-baris) sebelum menjalankan migrasi.

Penghapusan jalur lama

vercel.json, supabase/ (config + lima migrasi), src/lib/supabase/, dan dependensi @supabase/supabase-js serta @supabase/storage-js dihapus, tanpa shim atau alias. Klien unggah (features/share/api.ts, features/relay/api.ts) sekarang PUT ke URL presigned; kontrak respons rute berubah dari { path, token } menjadi { path, url }. next.config.ts menyusun CSP dari R2_ACCOUNT_ID (bukan NEXT_PUBLIC_SUPABASE_URL), dan uji rahasia (tests/client-bundle-secrecy.test.ts) menjaga dua hal baru: tidak ada berkas "use client" yang mengimpor @/lib/cloudflare, @/lib/db/, @/lib/r2/, @/lib/purge, atau @/lib/tokens; dan tidak ada lagi process.env.NEXT_PUBLIC_ di src/.

Proyek Supabase (ref owdjkpzywzljnvuyfiui) dan kaitan Vercel di dasbor dibongkar pengguna pada 10 Oktober 2026 setelah semua pemeriksaan hijau; tidak ada lagi layanan lama yang menagih atau menyimpan data. .env.local di mesin ini dibersihkan mengikuti itu: hanya R2_ACCOUNT_ID yang tersisa, karena kata sandi basis data Supabase sudah tidak ada gunanya (rahasia runtime ada di .dev.vars dan wrangler secret).

Celah upstream OpenNext: manifest `preview-props.json` (tambalan kecil)

@opennextjs/cloudflare 1.20.10 (dan @opennextjs/aws 4.1.9) menyisipkan isi manifest Next ke dalam bundel Worker, karena workerd tidak punya readFileSync. Daftar manifestnya dibaca dari pola glob **/{*-manifest,required-server-files,prefetch-hints}.json. Next 16.4 menambah manifest baru, preview-props.json, yang dimuat saat NextNodeServer disusun: tanpa tambalan, setiap permintaan di Worker gagal dengan Unexpected loadManifest(/.next/server/preview-props.json) call! (terbukti saat putaran pratinjau pertama; seluruh rute menjawab 500).

Yang dipilih: scripts/patch-opennext.mjs, dijalankan dari postinstall dan dari setiap skrip build Cloudflare (preview, preview:e2e, deploy lewat cf:patch). Sifatnya idempoten, gagal berisik bila polanya berubah (tanda versi paket berganti), dan boleh dihapus begitu upstream memuat preview-props di polanya. Alternatif yang ditolak: memakai patch-package (menambah dependensi untuk satu baris) atau memakukan Next ke versi lama (belum tentu bebas masalah yang sama).

Catatan operasional Windows

wrangler dev memegang berkas di .open-next. opennextjs-cloudflare build menghapus folder itu di awal (initOutputDir) sehingga build selalu gagal dengan EPERM: rmSync .open-next bila ada pratinjau yang sedang jalan. Karena itu: hentikan npm run preview/preview:e2e (Ctrl+C) sebelum menjalankan npm run test:e2e:cf atau npm run deploy, dan jangan menjalankan dua proses pratinjau bersamaan.
Jangan menyunting berkas atau menjalankan next build/wrangler types selama build OpenNext atau pratinjau berjalan. Satu putaran verifikasi pernah rusak karena build lain menghapus .open-next di bawah server yang sedang melayani: seluruh rute menjawab hang/500 dengan Could not resolve ./.build/durable-objects/... sampai server dihentikan dan dibangun ulang.
wrangler dev bind ke 127.0.0.1, bukan ::1, jadi playwright.cf.config.ts memakai http://127.0.0.1:8787 (alamat localhost bisa menembak IPv6 yang tidak ada isinya).

Cache Components/PPR dilepas: runtime Worker menolaknya di bawah beban

Rencana M10 mempertahankan cacheComponents: true, partialPrefetching: true, htmlLimitedBots: /.*/ , dan dua export const instant = false (keputusan M6/M9), lalu menguji jalur PPR itu di wrangler dev. Putaran e2e Cloudflare membuktikan kombinasi itu tidak layak di runtime Worker:

next build dan opennextjs-cloudflare build hijau, /s/[id] dan /r/[id] keluar sebagai PPR, dan permintaan tunggal dilayani normal (putaran pratinjau 31 pemeriksaan lulus dengan konfigurasi itu).
Begitu beberapa permintaan berjalan bersamaan (4 worker Playwright), log wrangler dev mencatat galat dari mesin Cache Components Next (nama CacheSignal ada di jejaknya), yang memakai penanda waktu lintas permintaan sementara workerd melarangnya:

Error: Cannot perform I/O on behalf of a different request. I/O objects (such as
streams, request/response bodies, and others) created in the context of one request
handler cannot be accessed from a different request's handler. (I/O type: IoContext)
  at patchedClearImmediate
  at CacheSignal.pendingTimeoutCleanup
  at CacheSignal.beginRead
  at CacheSignal.trackRead
  at trackPendingImport

Setelah galat pertama, Worker menjawab 500 Internal Server Error untuk permintaan berikutnya (snapshot halaman Playwright menunjukkannya) atau menggantung: 30 dari 33 uji e2e gagal. Jadi ini bukan satu permintaan yang tersendat, melainkan Worker yang rusak setelah galat itu. Peringatan Next sendiri sudah menyebutkannya: "Next.js cannot guarantee that Cache Components will run as expected due to the current runtime's implementation of setTimeout()".

Tindakan (persis kontingensi yang disiapkan di rencana M10): cacheComponents, partialPrefetching, dan htmlLimitedBots dilepas dari next.config.ts, dua export const instant = false dihapus, dan await connection() di /s/[id] serta /r/[id] dipertahankan supaya keduanya dirender dinamis per permintaan. Tanpa cangkang PPR, notFound() menjawab 404 sungguhan tanpa trik crawler, jadi htmlLimitedBots tidak lagi diperlukan. Konsekuensi yang diterima: tidak ada PPR/streaming metadata. Keputusan yang digantikan (tetap tercatat sebagai riwayat di M6 dan M9): instant = false dan htmlLimitedBots: /.*/ .

Kesiapan uji e2e: TCP, bukan permintaan HTTP

playwright.cf.config.ts menunggu port TCP (webServer.port), bukan permintaan HTTP ke /. Sebabnya temuan berikut di wrangler dev --env e2e:

Permintaan ke `/` di pratinjau	Hasil
`curl` (mengirim `User-Agent` dan `Accept`)	200
Node `http` dengan `User-Agent`	200
Node `http` tanpa header apa pun	500 atau menggantung
Node `http` hanya `Accept: /`	menggantung
Node `http` hanya `Connection: close`	menggantung

Artinya permintaan tanpa header User-Agent (persis yang dikirim pemeriksaan kesiapan Playwright) tidak dilayani dengan benar oleh proksi pratinjau, sedangkan peramban dan curl selalu mengirim UA. / dilayani dari aset tanpa kode snapme, jadi ini bukan jalur kode aplikasi. Pemeriksaan UA-less terhadap Worker produksi ditambahkan di putaran verifikasi produksi (hasilnya di tabel di bawah) supaya klaimnya tidak bergantung pada simulasi lokal.

Sidang pembatasan laju: `cf-connecting-ip` lebih dulu

clientKeyFromRequest di src/lib/rateLimit.ts sekarang membaca cf-connecting-ip sebelum x-real-ip/x-forwarded-for, karena header itulah yang diisi Cloudflare di tepi dan tidak bisa dipalsukan klien (warisan x-real-ip dari penyedia sebelumnya tetap dibaca sebagai cadangan). Dampaknya pada uji: wrangler dev mengisi cf-connecting-ip untuk semua pemanggil, jadi helper pasangSidangBaru yang semula hanya memalsukan x-real-ip kehilangan efeknya dan seluruh uji berbagi satu kuota. Gejalanya: setelah 10 pembuatan link dalam satu jam, POST /api/strips menjawab 429 dan tujuh uji ber-jaringan gagal dengan pesan yang tidak menyebut kuota ("Link strip dibuat." tidak pernah muncul). Helper sekarang mengirim kedua header (cf-connecting-ip dan x-real-ip) supaya tiap uji punya sidang sendiri di pratinjau maupun di next dev; di produksi Cloudflare menimpa cf-connecting-ip di tepi, jadi pengiriman header itu oleh klien tidak bisa dipakai menipu pembatasan laju. Baris uji di D1 lokal dihapus sekali untuk mengembalikan kuota.

Origin peramban versus host pratinjau (`isCrossSite`)

Rute POST menolak permintaan yang jelas datang dari situs lain dengan membandingkan Origin peramban terhadap origin request.url. Di wrangler dev, URL permintaan dinormalkan ke host localhost, jadi uji yang memakai http://127.0.0.1:8787 membuat peramban mengirim Origin: http://127.0.0.1:8787 sementara Worker melihat http://localhost:8787, dan setiap POST dijawab 400 (Permintaan tidak valid). Gejalanya menyesatkan: tombol "Buat Link dan Unggah" hanya tidak pernah selesai, tanpa pesan yang menyebut sebabnya (tujuh uji ber-jaringan gagal begitu).

Bukti terukur dari POST /api/strips: tanpa header Origin → 201; Origin: http://localhost:8787 → 201; Origin: http://127.0.0.1:8787 → 400; Origin: https://snapme.example.workers.dev → 400. playwright.cf.config.ts karena itu memakai http://localhost:8787. Kode produk tidak diubah: di produksi request.url adalah URL publik yang sama dengan yang dipakai peramban, dan itu diuji ulang di putaran produksi (POST dengan Origin workers.dev → 201, dengan Origin situs lain → 400).

Unggahan R2 diblokir: header sidang ikut terbawa ke preflight CORS

Gejala: tujuh uji ber-jaringan gagal dengan pesan yang tidak menyebut CORS ("Link strip dibuat." dan "Link estafet dibuat." tidak pernah muncul), padahal POST /api/strips sendiri sudah dijawab 201. Konsol peramban akhirnya menyebut sebabnya:

Access to fetch at 'https://<account>.r2.cloudflarestorage.com/snapme/strips/<id>/still.png?...'
from origin 'http://localhost:8787' has been blocked by CORS policy: Response to preflight request
doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the
requested resource.

Sebabnya bukan daftar origin (preflight dari curl/node dengan Origin: http://localhost:8787 dijawab 204 + ACAO), melainkan header sidang uji: helper pasangSidangBaru memakai page.setExtraHTTPHeaders, yang berlaku untuk semua permintaan halaman, termasuk PUT lintas origin ke R2. Preflight-nya jadi meminta content-type, cf-connecting-ip, x-real-ip, sedangkan r2-cors.json hanya mengizinkan Content-Type; R2 menolak preflight, dan peramban memblokir PUT. Terbukti dari header permintaan yang dicatat Playwright: {"content-type":"image/png","cf-connecting-ip":"198.51.100.42","x-real-ip":"198.51.100.42"}.

Perbaikan: helper menyisipkan header sidang hanya ke panggilan /api/** milik aplikasi (page.route), bukan ke semua permintaan. Daftar origin r2-cors.json tetap harus memuat origin aplikasi yang dipakai (http://localhost:3000, http://localhost:8787, http://127.0.0.1:8787, dan origin produksi setelah deploy pertama).

Foto slot teman tidak termuat: respons `<img>` yang ter-cache menghalangi `fetch` CORS

Gejala: uji estafet gagal di stage-overlay (SE-05) dan tray teman kosong (0/4, "Butuh 4 foto lagi"), padahal halaman /r/[id] menampilkan foto pembuat dengan normal (permintaan <img> ke R2 dijawab 200) dan POST /api/relays/claim/complete semuanya berhasil.

Isolasi memakai satu URL presigned yang sama di satu peramban:

Dari mana `fetch(url)` dijalankan	Hasil
Konteks teman, halaman `/r/[id]` (foto sudah tampil sebagai `<img>`)	`TypeError: Failed to fetch`
Konteks teman, halaman `/booth/capture`	`TypeError: Failed to fetch`
Konteks teman, halaman lain di konteks yang sama	`TypeError: Failed to fetch`
Konteks pembuat yang belum pernah memuat URL itu	200

Sebabnya cache HTTP, bukan CORS bucket: /r/[id] memuat foto slot lewat <img> (mode no-cors, respons tanpa Access-Control-Allow-Origin), peramban menyimpannya, dan fetch() berikutnya ber-mode cors tidak boleh memakai entri cache itu sehingga gagal tanpa mencoba ulang ke jaringan. Permintaan sungguhan di konteks yang bersih dijawab 200, jadi preflight dan Access-Control-Allow-Origin R2 memang benar. Ini jalur yang nyata dialami pengguna (foto pembuat selalu tampil dulu di /r/[id] sebelum teman menekan "Ambil Giliran"), bukan gejala uji.

Perbaikan: fetchSlotShots di src/features/relay/bootstrap.ts memakai fetch(url, { cache: "no-store" }), jadi foto slot selalu diambil dengan permintaan cors yang sungguhan. URL-nya presigned dan berumur pendek, jadi tidak ada yang rugi dengan tidak di-cache.

Bukti verifikasi M10

Statis dan uji:

Pemeriksaan	Hasil
`npm run cf-typegen`	`cloudflare-env.d.ts` dibuat ulang dari `wrangler.jsonc` (termasuk binding `DB`, `BUCKET`, `RATE_LIMIT_KV`, `ASSETS`)
`npm run lint`	Hijau (berkas jadi `.open-next/` dan `cloudflare-env.d.ts` masuk daftar abaikan; `worker.ts` memakai satu komentar izin eksplisit untuk `@ts-ignore` yang memang disyaratkan adapter)
`npm run typecheck`	Hijau
`npm test`	23 berkas, 179 uji hijau, termasuk 63 uji basis data baru di `tests/db/` (strips 23, relays 30, events 10) yang berjalan di atas D1/R2/KV miniflare sungguhan
`npm run build`	Hijau; `/s/[id]` dan `/r/[id]` keluar sebagai rute dinamis (ƒ) karena PPR dilepas di bagian di atas
`opennextjs-cloudflare build`	Hijau; bundel Worker tersimpan di `.open-next/worker.js`
`npm run test:e2e:cf`	30 lolos, 3 dilewati, 0 gagal terhadap `wrangler dev --env e2e` (D1/KV lokal, R2 remote). Tiga yang dilewati adalah jalur "server tanpa binding" yang memang tidak berlaku saat binding ada. Perbaikan yang menyertainya: assertion Supabase-era di `e2e/live.spec.ts` (`/\/storage\//` menjadi host R2), URL dev yang di-hardcode di `e2e/relay.spec.ts` (`http://localhost:3000` menjadi relatif terhadap baseURL), dan helper `pasangSidangBaru` yang kini menyisipkan header sidang hanya ke `/api/**`
`npm run perf:lcp` (Lighthouse preset seluler, 5 jalankan)	Median LCP 3,745 detik, FCP 1,11 detik, TBT 44 ms, CLS 0, skor 0,87. Pembanding M9 di `next start`: LCP 3,17 detik. Angka ini diukur terhadap `wrangler dev` (workerd lokal dan koneksi R2 jarak jauh), bukan CDN produksi, jadi selisihnya indikatif dan bukan regresi yang terbukti. Tidak ada syarat target baru di milestone ini. Produksi Cloudflare sendiri diukur 16 Oktober 2026: median LCP 2,416 detik (5 jalankan, 2.317 sampai 2.517 ms), FCP 1,066 detik, TBT 62 ms, CLS 0, skor 97, jadi di CDN target LCP PRD §8 tercapai (rinciannya di "Langkah 1 rencana" M9)
cron harian di dasbor	Dikonfirmasi pengguna 16 Oktober 2026: Cron Trigger `0 3 * * *` terlihat di Workers & Pages > snapme > Settings > Triggers. Pencatatannya milik pengguna karena dasbor tidak dibuka dari CLI
Deploy ulang (16 Oktober 2026)	Version ID `2dc38bdb-25ce-4016-a0ad-34423c94cbf9` (menggantikan `26c7f70b-…`), `schedule: 0 3 * * *` terdaftar ulang saat deploy, `GET /` 200, 9 skrip awal di HTML produksi tidak ada yang memuat `data-sonner-toaster`. Deploy ini membawa perubahan langkah 1 LCP dan perbaikan `e2e/share.spec.ts`

Putaran pratinjau (wrangler dev --env e2e: D1/KV lokal, R2 remote sungguhan) memakai skrip buang yang menjalankan 31 pemeriksaan, semuanya lulus:

Pemeriksaan	Hasil
`POST /api/strips` 201 + `upload.url`/`liveUpload.url` presigned (R2 + `X-Amz-Signature`)	Lulus
`PUT` presigned still (PNG) dan klip (WebM) ke R2 sungguhan	200 / 200
`POST complete` 200 + `expiresAt`; `GET /s/{id}` 200 memuat `<img>` dan `<video>`	Lulus
Tautan unduh ber-`response-content-disposition`: GET 200, `attachment; filename="snapme-<id>.png"`, isi bita identik dengan yang diunggah	Lulus
`DELETE` 204; `GET /s/{id}` ulang 404; objek R2 sudah tidak ada (GET presigned 404)	Lulus
Estafet: `POST /api/relays` 201 + URL presigned hanya slot pembuat; PUT slot 0/2	Lulus
Dua `claim` serentak → tepat satu 200 dan satu 409	Lulus
`complete` pertama 422 + URL segar slot tamu; PUT slot 1/3; `complete` kedua 200 + `stripId` + URL PNG; strip hasil diunggah dan dilengkapi; `GET /s/{stripId}` 200	Lulus
`POST /api/relays/{id}/strip` 200 untuk token pembuat, `role: host`, empat slot ber-URL presigned	Lulus
`POST /api/events` 25 batch × 8 = 200 peristiwa → 204 semua, batch ke-26 → 429	Lulus
`GET /api/cron/purge` tanpa bearer 401, dengan bearer 200 `{"purged":0}`	Lulus
Cron Trigger lokal (`/cdn-cgi/local/scheduled`) menjalankan `scheduled` di `worker.ts` → 200	Lulus
Bit identik setelah unggah: PUT presigned 200, objek dibaca kembali lewat S3 API, 68 bita sama, `content-type: image/png` (Content-Type yang ditandatangani tersimpan)	Lulus
Bucket dibersihkan setelah verifikasi (17 objek uji dihapus, sisa 0)	Lulus

Putaran produksi setelah npm run deploy (Worker snapme, URL https://snapme.ikhsandyy-dev.workers.dev, Version ID 26c7f70b-1280-4066-aaca-826f9e8f7c0c, cron 0 3 * * * terdaftar di keluaran deploy): 15 pemeriksaan, 14 lulus pada jalankan pertama. Satu yang gagal adalah kesalahan skrip verifikasi (objek yang dibaca memang belum pernah diunggah), bukan temuan aplikasi; bukti bit-identiknya diambil ulang dan lulus.

Pemeriksaan produksi	Hasil
`GET /` 200 dengan isi	47.206 bita
`GET /s/{id-acak}` 404 + halaman "Halaman tidak ditemukan."	Lulus (404 sungguhan dari Worker)
`POST /api/strips` dengan `Origin` situs lain	400
`POST /api/strips` dengan `Origin` workers.dev	201
`PUT` presigned lalu `complete` lalu `GET /s/{id}` dengan `<img>`	200 / 200 / 200
Preflight R2 dari origin produksi	204 dengan `Access-Control-Allow-Origin: https://snapme.ikhsandyy-dev.workers.dev`
`POST /api/relays` lalu dua `claim` serentak	201, lalu 200 dan 409
`POST /api/events`	204
`GET /api/cron/purge` tanpa bearer lalu dengan bearer	401 lalu 200 `{"purged":0}`
`GET /` tanpa header `User-Agent`	200, jadi hambatan UA-less sebelumnya memang hanya proksi `wrangler dev`, bukan Worker produksi
`DELETE /api/strips/{id}`	204
`PUT` presigned lalu dibaca kembali lewat S3 API	200 dan bit identik (68 bita, `image/png`)
`npx wrangler d1 execute snapme-db --remote`	`strips` 3, `relays` 1, `events` 1 (baris uji nyata dari Worker produksi)
cron harian	Terdaftar saat deploy (`schedule: 0 3 * * *`); jalur `scheduled`-nya sudah dibuktikan di pratinjau lewat `/cdn-cgi/local/scheduled`

Daftar periksa DESIGN-SYSTEM §14: M10 tidak menambah atau mengubah tampilan apa pun (pekerjaannya backend, konfigurasi deploy, dan dua perbaikan perilaku klien: cache: "no-store" pada pengambilan foto slot serta penyempitan header sidang uji). Tidak ada komponen, token, warna, label, atau teks baru, jadi daftar periksa M9 tetap berlaku dan tidak ada butir baru untuk diperiksa.

Catatan alat: npx wrangler r2 object get snapme/<kunci-ber-garis-miring> melaporkan The specified key does not exist di wrangler 4.149.0 walau objeknya ada dan terbaca lewat S3 API maupun URL presigned (kunci tanpa / tidak diuji). Karena itu bukti bit identik memakai S3 API (aws4fetch) dengan kredensial yang sama; ini celah CLI, bukan celah R2, dan tidak memengaruhi aplikasi.

Catatan uji: `share.spec.ts` tidak mematikan Gesture Snap (16 Oktober 2026)

Gejala: npm run test:e2e:cf gagal di [cloudflare] › share.spec.ts:43:7 ("sakelar QR menyalakan kotak QR di kanvas dan pemberitahuan izin"). Dua jalankan penuh gagal pada langkah berbeda di uji yang sama (page.waitForURL("**/booth/customize") di masukHias, lalu expect(sakelar).toBeChecked()), keduanya dengan Test timeout of 30000ms exceeded; menjalankan share.spec.ts sendirian selalu hijau.

Isolasi: setiap berkas spek lain mematikan Gesture Snap lewat matikanGesture di test.beforeEach (a11y, capture, customize, live, relay, result, session). share.spec.ts satu-satunya yang tidak, jadi alur kamera empat fotonya menjalankan model MediaPipe di Chromium headless tanpa GPU. Inferensi gesture menahan main thread, dan uji 30 detik itu melewati batasnya saat mesin sibuk (spek ini berjalan terakhir di proyek cloudflare, sesudah estafet).

Bukti ini bukan regresi kode baru: dengan perubahan langkah 1 LCP di-git stash, npm run test:e2e:cf pada kode sebelum perubahan gagal pada uji yang sama, di langkah yang berbeda lagi.

Perbaikan: test.beforeEach + matikanGesture di e2e/share.spec.ts, sama seperti spek lain. Cakupan gesture tidak berkurang: e2e/gesture.spec.ts tetap menguji model dimuat dari origin sendiri tanpa membawa gambar, sakelar mati, pilihan diingat, dan jalur gagal muat. Setelah perbaikan, npm run test:e2e:cf hijau dua kali berturut-turut (30 lolos, 3 dilewati, 0 gagal).

Repositori publik: lisensi MIT, permukaan repo, dan artefak lokal (16 Oktober 2026)

Keputusan: repositori ini dinyatakan open source dengan lisensi MIT dan dilengkapi permukaan repo yang layak dibaca orang luar, tanpa menyentuh kode produk. Pekerjaan ini di luar daftar milestone, jadi tidak ada kotak centang MILESTONES.md yang berubah.

Keputusan	Isi	Alasan
Lisensi	`LICENSE` (MIT), `license`, `author`, `homepage`, `repository`, `bugs`, `keywords`, dan `engines` di `package.json`	Permintaan pengguna. Pemegang hak cipta awalnya diambil dari `PRD.md` ("Pemilik: Rori Setiawan"), lalu dikoreksi menjadi Ikhsan Dyy pada catatan paling bawah berkas ini; `private: true` dipertahankan karena paket ini aplikasi dan tidak diterbitkan ke npm
README	`README.md` baru, bahasa Inggris, dengan lencana, demo, fitur, privasi, perintah, konfigurasi, tata letak repo, dan tautan dokumen	Sebelumnya root repo tidak punya README sama sekali. Mengikuti pola `paperdraw`: README berbahasa Inggris, dokumen kerja berbahasa Indonesia
Berkas komunitas	`.github/CONTRIBUTING.md`, `CODE_OF_CONDUCT.md` (Contributor Covenant 2.1), `SECURITY.md`, `pull_request_template.md`, `dependabot.yml`, dan tiga `ISSUE_TEMPLATE`	Pola yang sama dengan `paperdraw`. Isinya disesuaikan: perintah npm snapme, gerbang `DESIGN-SYSTEM.md §14`, label tetap §12, dan larangan pihak ketiga
CI	`.github/workflows/ci.yml`: job `checks` (lint, typecheck, `npm test`, build) dan job `e2e` (`npx playwright test` di chromium, firefox, webkit)	Gerbang "Selesai berarti" (lint, typecheck, uji, build) dijalankan otomatis. Unggahan artefak laporan hanya saat gagal
Versi Node	`.nvmrc` berisi `24`, `engines.node` `>=20`	Mesin pengembangan memakai Node 24 dan CI memakai versi yang sama
CHANGELOG	`CHANGELOG.md` merangkum M0 sampai M10 per milestone beserta hash commit	Satu milestone satu commit, jadi riwayatnya bisa diaudit dari changelog
Gambar referensi pihak ketiga	`docs/ui-reference/referensi_uiux.webp` dilepas dari indeks git (`git rm --cached`), berkasnya tetap ada di perangkat, dan alasannya dicatat di `docs/ui-reference/README.md`	Isinya kumpulan tangkapan layar produk photobooth lain, lengkap dengan merek Fujifilm, harga, foto pelanggan, dan tangkapan layar pembayaran. Menyebarkannya ulang bertentangan dengan batasan "Batas aman" repo (tanpa nama, logo, atau aset Fujifilm; tanpa wajah orang tanpa izin) dan berisiko hak cipta. Arah gayanya sudah terkunci di token `DESIGN-SYSTEM.md §2` dan berkas HTML di folder yang sama

Yang tidak diubah dan alasannya:

wrangler.jsonc memuat ID akun, ID basis data D1, dan ID namespace KV yang sungguhan. Ketiganya pengenal, bukan kredensial: tanpa API token tidak ada yang bisa dibuka, dan SECURITY.md menyatakannya. cloudflare-env.d.ts dulu ikut di-commit supaya npm run typecheck jalan di klon bersih; sejak pengecilan repo (17 Oktober 2026) berkas itu justru tidak di-commit dan dibangun ulang dari wrangler.jsonc, jadi tidak ada salinan tipe yang bisa basi.

Bukti pemeriksaan:

Pemeriksaan	Hasil
`git log --all --diff-filter=A -- .dev.vars .env.local`	Kosong: kedua berkas tidak pernah masuk riwayat git
`git grep -IE 'eyJ[A-Za-z0-9_-]{10,}\.'` pada seluruh revisi	Tidak ada token mirip JWT di riwayat
Pola kredensial (`AKIA`, `sk-`, `ghp_`, `glpat-`, `service_role`, `api_key`, `password` dengan nilai) pada seluruh revisi	Satu-satunya hasil adalah nilai uji di `tests/db/relays.test.ts` (`"rahasia-pembersih"`), bukan kredensial
URL `*.supabase.co` pada seluruh revisi	Tidak ada. Berkas `src/lib/supabase/*` dari M6 memang ada di riwayat lama, tetapi tanpa URL, kunci, atau `.env`
`git status --porcelain --ignored`	`test-results/`, `tsconfig.tsbuildinfo`, dan `docs/ui-reference/referensi_uiux.webp` sekarang terabaikan
`npm run lint`, `npm run typecheck`, `npm test`, `npm run build`	Lolos: 23 berkas uji, 179 tes lulus, build sukses
`npx playwright test` (chromium, firefox, webkit)	66 lulus, 8 dilewati (spek ber-binding dijalankan `npm run test:e2e:cf`), 0 gagal

Yang perlu diputuskan pengguna:

Riwayat git masih memuat referensi_uiux.webp dari commit M0. Melepasnya dari indeks hanya membersihkan versi berikutnya; menghapusnya dari riwayat butuh penulisan ulang riwayat dan git push --force. Selama belum ditulis ulang, berkasnya masih bisa diunduh dari commit lama.
Nama pemegang hak cipta di LICENSE memakai nama di PRD.md. Ganti bila yang berlaku adalah nama lain atau nama badan.
DESIGN-SYSTEM.md §10 masih mencantumkan referensi_uiux.webp sebagai berkas di folder acuan. Penyelarasannya menunggu keputusan pengguna. README.md (baru) sudah tidak menyebut berkas itu.

CI pertama gagal: tipe rute Next belum dibuat, jeda 300 ms, dan jalur artefak (16 Oktober 2026)

Gejala: run pertama di GitHub Actions (38905443112, commit 46faf03) merah di kedua job. Job checks berhenti di langkah Typecheck dengan dua galat yang sama: src/app/booth/layout.tsx(9,44): error TS2304: Cannot find name 'LayoutProps' dan src/app/layout.tsx(37,50). Job e2e berhenti di e2e/keyboard-flow.spec.ts:122 (seluruh alur selesai hanya dengan keyboard): getByTestId('countdown') tidak pernah muncul dalam 15 detik; sisanya 66 lulus, 7 dilewati, 0 galat lain.

Tiga sebab, terpisah:

Sebab	Bukti	Perbaikan
`LayoutProps` dan `PageProps` dihasilkan Next 16 ke `.next/types`, dan `tsconfig.json` memasukkannya. Di mesin pengembangan berkas itu sudah ada dari `next dev`/`next build`, jadi `tsc --noEmit` hijau di sana, tetapi klon bersih dan CI gagal	Direproduksi lokal: `.next` dipindahkan, `npm run typecheck` mengeluarkan tepat dua galat TS2304 yang sama; `npx next typegen` (perintah resmi Next 16, "Types generated successfully") lalu `tsc --noEmit` hijau	Skrip `typegen` (`next typegen`) ditambahkan, dan `typecheck` menjalankannya lebih dulu. Perintah dokumentasi `npm run typecheck` kini berdiri sendiri di klon bersih, tanpa langkah tambahan di CI
Mesin keadaan hanya menerima `SHOOT` pada fase `ready` (`SHOOTABLE_PHASES` di `machine.ts`), sedangkan `PAUSE_MS` 300 ms berjalan setelah tiap foto (GS-04). Spasi yang ditekan di dalam jeda itu hilang tanpa galat, jadi hitung mundur tidak pernah dimulai. Di runner CI, tekanan Spasi jatuh di jendela 300 ms itu	`machine.ts`: `pause: false` pada `SHOOTABLE_PHASES`, `PAUSE_MS = 300`, `FLASH_MS = 160`. Kegagalan hanya di CI, bukan di mesin pengembangan	Uji menunggu tombol "Ambil foto" aktif (`isBusy(phase)` bernilai salah hanya di luar `countdown`, `capturing`, dan `pause`) sebelum menekan Spasi
`handleKeyDown` di `CameraStage.tsx` mengabaikan Spasi yang datang dari elemen anak (`event.target !== event.currentTarget`). Tab bisa mendarat di elemen lain setelah video menyala, dan tekanannya lalu tidak melakukan apa pun	Kode `CameraStage.tsx`; kegagalan yang sama tanpa galat apa pun di halaman	Sebelum Spasi, fokus dipasang ke kontainer `role="group"` bernama "Area kamera" dan dipastikan dengan `toBeFocused()`. Pola memfokuskan elemen terprogram sudah dipakai uji yang sama untuk pil hiasan

Tambahan: unggahan artefak gagal dengan "No files were found with the provided path: playwright-report", karena reporter line tidak menulis laporan HTML. Jalur unggahannya sekarang memuat test-results (trace, error context, tangkapan layar) dan if-no-files-found: ignore.

Retry Playwright sengaja tidak dipasang: uji yang gagal diperbaiki sebabnya, bukan ditutupi. Kalau nanti muncul flake baru tanpa sebab yang jelas, retry boleh dipertimbangkan sebagai jaring sementara dengan catatan di sini.

CI kedua: langkah panah pil hiasan (16 Oktober 2026)

Gejala: run 38916264025 (commit 36cd264). Job checks hijau (perbaikan next typegen bekerja). Job e2e masih merah, tetapi di tempat lain: Error: Panah ArrowRight tidak sampai ke "Stiker" dari panahKe (e2e/keyboard-flow.spec.ts:64, dipanggil dari baris 157). Langkah pemotretan yang sebelumnya gagal kini lulus; sisanya 66 lulus, 7 dilewati, 1 gagal.

Sebab: panahKe yang lama menekan panah sampai 12 kali berturut-turut lalu membandingkan nama fokus. Fokus roving Radix berpindah pada render berikutnya, jadi tekanan beruntun bisa habis tanpa satu pun berpindah. Ini bukan cacat produk: alur yang sama lulus di mesin pengembangan, dan lulus juga saat seluruh suite berjalan. Yang berbeda hanya beban runner.

Perbaikan yang dikerjakan:

Perubahan	Alasan
`panahKe` berjalan satu pil tiap langkah: satu tekanan, lalu asersi bahwa pil tujuan langkah itu benar-benar fokus, diulang lewat `expect(...).toPass` sampai 15 detik	Tekanan yang hilang dicoba lagi, bukan dihitung sebagai kemajuan. Asersi per langkah juga menangkap fokus yang melompat dua pil
Fokus pil asal dipasang ulang di dalam tiap percobaan	Kalau fokusnya jatuh ke badan halaman, tekanan panah tidak melakukan apa pun dan percobaan sebelumnya hanya menghabiskan jatah
Urutan pil dibaca dari DOM (pil yang sedang fokus), bukan dari asumsi pil pertama	Walker-nya benar dari keadaan mana pun, jadi tekanan panah yang datang lebih awal dari tempat lain tidak merusaknya

Bukti: satu tekanan panah nyasar disisipkan sementara sebelum pemanggilan panahKe untuk menguji daya pulihnya, dan uji tetap mendarat di pil Stiker (3 dari 3 jalankan berulang lulus); setelah tekanan nyasar dilepas, 3 jalankan berulang dan seluruh suite hijau (66 lulus, 8 dilewati, 0 gagal), npm run lint dan npm run typecheck hijau.

Pola yang terbaca dari dua kegagalan CI berturut-turut di uji yang sama: input keyboard yang datang sebelum render atau transisi selesai dianggap hilang oleh aplikasi, bukan salah. Uji yang menekan tombol lalu langsung mengasersi keadaan berikutnya sebaiknya menunggu keadaan antara, seperti yang kini dilakukan di langkah pemotretan dan langkah panah.

Permintaan lanjutan: pemegang hak cipta, riwayat, proteksi branch (16 Oktober 2026)

Keputusan atas permintaan pengguna, semuanya di luar daftar milestone:

Tindakan	Isi	Bukti
Pemegang hak cipta	Ikhsan Dyy, menggantikan nama yang tertulis di `PRD.md`. `LICENSE`, `author` di `package.json`, dan bagian License di `README.md` diperbarui (commit `5d867ed`)	`git show HEAD:LICENSE`
Rujukan gambar referensi	Tabel berkas di `DESIGN-SYSTEM.md §0` dan diagram folder `ARCHITECTURE.md §4` kini menyatakan `referensi_uiux.webp` tidak ikut di-commit	kedua dokumen
PR Dependabot #1	Di-merge (squash) sebagai `8e42e33`: konva 10.8.0, motion 14.2.0, radix-ui 1.8.1, zod 4.6.7, @types/node 26.6.5, vitest 5.0.4, wrangler 4.150.0	CI pada branch PR hijau sebelum merge; CI `master` hijau sesudahnya
Riwayat git ditulis ulang	`git filter-branch --index-filter 'git rm --cached --ignore-unmatch docs/ui-reference/referensi_uiux.webp' -- --all`, lalu `refs/original` dihapus, `git reflog expire --expire=now --all`, `git gc --prune=now`	`git log --all -- docs/ui-reference/referensi_uiux.webp` kosong; `git rev-list --objects --all \| grep -c referensi_uiux` = 0; blob `851e3ac` hilang dari basis objek; tree M0 hanya berisi `README.md`, `welcome.html`, `capture.html`, `customize.html`
Hash di dokumen	Penulisan ulang mengubah seluruh 23 hash, jadi 11 rujukan di `CHANGELOG.md` dan 2 rujukan commit di catatan CI diperbarui dari log hasil penulisan ulang (commit `1c9beca`)	`git log --format='%h %s'`
Force push	Diblokir kebijakan lokal: pola `git push--force` ditolak, dan guardrail itu sengaja tidak dilewati. Perintah untuk pengguna: `git push --force origin master`	percobaan push ditolak: `Blocked by bash pattern: git push--force`
Proteksi branch `master`	Wajib dua check CI ("Lint, typecheck, unit tests, build" dan "End-to-end (Playwright)", `strict` mati), tolak force push, tolak penghapusan, `enforce_admins` mati supaya pemilik tetap bisa push langsung dan menulis ulang riwayat bila memang perlu	`gh api repos/ikhsanddy/snapme/branches/master/protection`
Deskripsi dan topik repo	Satu kalimat deskripsi dan enam topik (`photobooth`, `nextjs`, `cloudflare-workers`, `mediapipe`, `konva`, `privacy`) dipasang lewat `gh repo edit`	API repo: `description` dan `topics` terisi
Cache Turbopack basi	Setelah `npm ci` mengganti `node_modules`, `npm run build` gagal dengan 15 galat `Module not found: @vercel/turbopack-next/internal/font/google/font`. Itu cache `.next` yang basi, bukan regresi paket: dengan `.next` dihapus, build hijau (exit 0), dan CI pada commit yang sama juga hijau. Jadi: setelah `npm ci`, hapus `.next` bila build lokal mendadak gagal di `next/font`	dua jalankan `npm run build`: exit 1 dengan `.next` lama, exit 0 sesudah `rm -rf .next`
Check "Workers Builds: snapme"	Merah di setiap commit. Itu pipeline build integrasi Git Cloudflare dari dasbor (`app: cloudflare-workers-and-pages`), bukan CI repo ini	`gh api repos/ikhsanddy/snapme/commits/<sha>/check-runs`

Verifikasi tip hasil penulisan ulang sebelum push: npm run lint, npm run typecheck, npm test (179 lulus), npm run build (exit 0), dan npx playwright test (66 lulus, 8 dilewati, 0 gagal).

Yang belum diverifikasi: isi kegagalan "Workers Builds: snapme", karena tautannya hanya bisa dibuka dari dasbor Cloudflare. Pilihannya memperbaiki build command-nya di dasbor atau melepas integrasi Git untuk Worker snapme dan membiarkan npm run deploy dari CLI seperti yang ditulis ARCHITECTURE.md §3.

Pengecilan repo dan nama aksesibel slider (17 Oktober 2026)

Keputusan	Alasan	Bukti
`cloudflare-env.d.ts` tidak lagi di-commit. `scripts/cf-typegen.mjs` membangkitkannya dari `wrangler.jsonc` lewat `postinstall` dan lewat `npm run cf-typegen`; tanpa `wrangler` terpasang, skrip berhenti dengan peringatan, bukan galat	Berkas 625 KB yang sepenuhnya turunan: isinya seluruh tipe runtime Cloudflare, termasuk katalog Workers AI, dan bisa basi setiap `wrangler.jsonc` berubah	klon bersih menjalankan `npm ci` lalu `npm run typecheck` dan `npm run build` tanpa langkah tambahan (lihat tabel verifikasi di bawah)
Isi tipe itu mengikuti keadaan mesin: di repo yang punya `.dev.vars`, empat nama rahasia ikut tertulis; di klon tanpa `.dev.vars`, tidak. Keduanya lolos `npm run typecheck` dan `npm run build` karena kode membaca binding lewat seam `getBindings()`	Cermin dari keputusan di atas, bukan sesuatu yang dikejar: kalau kelak ada kode yang menyentuh `env.CRON_SECRET` secara bertipe, berkas `.dev.vars` (atau penanda tipe manual) menjadi syarat	`diff cloudflare-env.d.ts` antara repo dan klon bersih: 12 baris, semuanya nama rahasia dan hash header
`public/mediapipe/wasm/` tidak lagi di-commit. `scripts/copy-mediapipe-wasm.mjs` menyalinnya dari paket yang dikunci lockfile, idempoten (berkas dengan ukuran sama tidak disalin ulang)	Enam berkas sekitar 39 MB, byte-identik dengan `node_modules/@mediapipe/tasks-vision/wasm` (dibandingkan sha256 seluruh berkas: sama), jadi menaruhnya di git hanya menggandakan bobot klon. Model gesture tetap di-commit	`sha256sum public/mediapipe/wasm/` sebelum dilepas sama dengan `sha256sum node_modules/@mediapipe/tasks-vision/wasm/`; setelah dihapus dari disk, `npm ci` mengembalikan enam berkas itu
Gagang `Slider` menerima nama aksesibel dari prop root, dan galeri `/dev/ui` menamai kedua slidernya	Radix hanya menamai sendiri saat ada dua gagang atau lebih ("Minimum"/"Maximum"); dengan satu gagang `role="slider"` tanpa nama, dan axe melaporkannya sebagai `aria-input-field-name` tingkat serius di galeri 360 px	CI cabang dependabot 16 Oktober 2026 gagal dengan dua simpul itu; setelah perbaikan, `[role="slider"]` di `/dev/ui` membawa `aria-label` "Ukuran stiker" dan "Ukuran stiker, nonaktif", dan `npx playwright test e2e/a11y.spec.ts -g "galeri komponen"` hijau
Diagram folder ARCHITECTURE §4 hanya menyebut `public/stickers/`	`public/frames/` memang tidak pernah dibuat: frame diwujudkan sebagai data warna di `src/features/editor/presets.ts` (keputusan M4)	`git ls-files public`

Yang tidak diubah: riwayat git masih memuat blob wasm dari M3. Melepasnya dari indeks hanya membersihkan versi berikutnya; mengecilkan klon butuh penulisan ulang riwayat dan git push --force. Diukur git count-objects -vH: paketnya 12,15 MiB untuk seluruh riwayat, karena wasm terkompresi baik, jadi labanya hanya beberapa MiB sementara 29 rujukan hash pendek di CHANGELOG.md dan berkas ini akan ikut berubah. Pekerjaan itu ditunda sampai ada alasan lain untuk menulis ulang riwayat.

Pembersihan repo dan batas server (18 Oktober 2026)

Sesudah 0.1.0, seluruh repo diaudit untuk mencari berkas yang tidak terpakai, lalu strukturnya dirapikan. Tidak ada perilaku produk yang berubah; pagar ujinya sama seperti sebelumnya.

Audit: apa yang ternyata tidak ada

Diperiksa	Cara	Hasil
Modul yatim	Graf impor dari seluruh titik masuk (`src/app`, `tests/`, `e2e/`, `scripts/`, konfigurasi), spesifier relatif dan alias `@/` diselesaikan	Nol berkas `src/**` yang tidak terjangkau
Aset yatim	Nama berkas di `public/` dicocokkan dengan `STICKERS` di `presets.ts` dan `gesture_recognizer.task` di `gestureSource.ts`	12 stiker, 12 entri; satu-satunya aset lain adalah wasm MediaPipe yang disalin saat pemasangan
Dependensi nganggur	Tiap nama di `package.json` dicari di seluruh kode, skrip, dan konfigurasi	Nol. `shadcn` memang dipakai saat runtime lewat `@import "shadcn/tailwind.css"`, dan `lighthouse` dipakai skrip `perf:lcp`
Sisa pekerjaan	`TODO`, `FIXME`, `HACK`, penanda "sementara" di `src/`, `scripts/`, `tests/`, `e2e/`	Nol
Berkas di disk yang tidak dilacak git	`git status --porcelain --ignored`	Semuanya hasil turunan (`next-env.d.ts`, `cloudflare-env.d.ts`, `tsconfig.tsbuildinfo`, `public/mediapipe/`) atau rahasia lokal; tidak ada sampah

Kesimpulan: yang bisa dihapus bukan berkas, melainkan duplikasi dan ekspor yang tidak dipakai siapa pun.

Keputusan

Keputusan	Alasan	Bukti
Modul khusus server pindah ke `src/server/` (`cloudflare.ts`, `db/`, `r2/`, `purge.ts`, `rateLimit.ts`, `tokens.ts`, `expiry.ts`); `src/lib/` tinggal modul yang boleh dipakai klien dan server	Batas klien-server sebelumnya hanya daftar nama yang disimpan di dalam uji (`@/lib/cloudflare`, `@/lib/db/`, ...): modul server baru tidak terjaga sampai namanya ditambahkan. Sekarang batasnya satu folder	`tests/security/client-bundle-secrecy.test.ts` menelusuri spesifier impor tiap berkas `"use client"` dan menolak apa pun yang menuju `src/server/`, termasuk jalur relatif. Dibuktikan sanggup gagal: berkas probe ber-`"use client"` dengan impor `@/server/cloudflare` dan dengan impor `../server/cloudflare` sama-sama dilaporkan, lalu probe dihapus
`tests/` dicerminkan ke `src/` (`app/api`, `components/{ui,booth}`, `features/*`, `lib`, `server`, `stores`) plus `security/` untuk pagar lintas repo, dan `support/` untuk harness	Dua puluh tiga berkas dalam satu folder datar menyulitkan pencarian berkas uji untuk satu modul; nama berkasnya sendiri sudah mengandung area (`editor-store`, `hold-detector`)	`find tests -type d`: 16 folder (8 tingkat atas), dan tiap berkas uji mengimpor modul `src/` pada jalur yang sama dengan tempat berkasnya
Bantuan rute bersama pindah ke `tests/support/route.ts`: bentuk permintaan JSON, permintaan bearer, konteks rute, sidang pembatasan laju, dan pengosongan bucket	Empat bantuan yang sama disalin ke tiga berkas uji, dan salinannya sudah menyimpang: `strips.test.ts` memaginasi daftar bucket, `relays.test.ts` tidak, sehingga sisa objek di atas 1000 buah bisa membuat uji "berkas hilang" lulus palsu	`tests/app/api/*` hijau dengan 62 kasus sesudah penggabungan (sama dengan sebelum)
`messageFrom` dan PUT ke URL presigned dijadikan satu di `src/lib/http.ts`; `RelayUploadTarget` dan `StripUpload` menjadi satu tipe `SignedUpload`	Keduanya disalin utuh ke `features/relay/api.ts` dan `features/share/api.ts`; hanya nama tetapnya yang berbeda	`tsc --noEmit` hijau setelah `StripUpload` dan `RelayUploadTarget` hilang dari repo (`grep -r` kosong)
Sidik jari kanvas e2e menjadi satu fungsi `canvasChecksum` di `e2e/helpers.ts`	Tiga salinan dengan dua langkah cuplik berbeda (97 dan 997) dan dua penanda kanvas-hilang (-1 dan 0) untuk pekerjaan yang sama	`grep -rn sidikJariKanvas e2e` kosong; `customize.spec.ts` dan `live.spec.ts` memakai langkah 97 seperti sebelumnya, `share.spec.ts` ikut 97
Helper kamera di `e2e/gesture.spec.ts` dihapus, memakai `e2e/helpers.ts`	Komentarnya menyebut "disalin dari `capture.spec.ts`", padahal sumbernya sudah pindah ke `helpers.ts` di M3; salinannya juga kehilangan percobaan ulang `toPass` yang membuat alur tahan server yang baru dinyalakan	`npx playwright test e2e/gesture.spec.ts` (lihat tabel verifikasi)
`src/features/gallery/muatFotoGaleri.ts` menjadi `loadGalleryPhotos.ts`	Satu-satunya nama berkas produk yang tidak berbahasa Inggris, sementara CONTRIBUTING mewajibkan berkas berbahasa Inggris; `privasi/page.tsx` tetap karena itu URL	`git mv` lalu `grep -rn muatFotoGaleri src`: kosong; pemanggilnya satu, `GalleryPicker.tsx` (impor dinamis)
`--color-pink-700` dihapus dari `globals.css` dan dari tabel palet serta tabel kontras `DESIGN-SYSTEM §2`	Didefinisikan dan didokumentasikan, tetapi tidak dipakai satu komponen pun. §2 melarang `pink` untuk teks di bawah 24 px, dan larangan itu tetap berlaku tanpa token pengganti	`grep -rn pink-700` sebelum penghapusan: hanya definisi dan dua baris dokumen; sesudahnya kosong
Konstanta yang hanya dipakai di berkasnya tidak lagi diekspor: `REQUESTED_SIZE`, `PUT_URL_SECONDS`, `GET_URL_SECONDS`, `fetchSlotShots`, `masukAmbilFotoLayout`, `lengkapiEmpatFoto`	Nama itu ikut terlihat sebagai API modul padahal tidak ada pemanggil di luar berkasnya	`grep -r` tiap nama: hanya definisi dan pemakaian di berkas yang sama
Setiap komponen `src/components/ui` mengimpor `cn` dari `@/lib/utils`	Sepuluh komponen mengimpor langsung dari paket `cn`, tujuh lewat `@/lib/utils`; `components.json` menunjuk `@/lib/utils` sebagai alias, jadi berkas yang ditambah lewat `shadcn add` selalu memakai jalur itu	`grep -rn 'from "cn"' src` kosong

Struktur folder akar

Root hanya menyisakan titik masuk dan konfigurasi alat. Empat dokumen kerja, satu berkas infrastruktur, dan satu pohon uji dipindahkan; tidak ada berkas yang dihapus, semuanya git mv sehingga riwayatnya ikut.

Keputusan	Alasan	Bukti
`PRD.md`, `DESIGN-SYSTEM.md`, `ARCHITECTURE.md`, dan `MILESTONES.md` pindah ke `docs/`	Root memuat lima dokumen panjang dengan pembaca berbeda, dan `docs/` sudah ada untuk itu. Karena keempatnya kini bersebelahan dengan `docs/DECISIONS.md`, rujukan antar dokumen yang ditulis sebagai nama telanjang (`PRD.md §7`) tetap benar tanpa disunting	`git mv`; tautan yang menunjuk dari luar `docs/` hanya ada di `README.md`, `CHANGELOG.md`, `.github/CONTRIBUTING.md`, dan `.github/ISSUE_TEMPLATE/config.yml`, semuanya diperbarui ke `docs/...`
`r2-cors.json` pindah ke `infra/`	Itu satu-satunya sumber daya Cloudflare yang dipasang tangan, bukan hasil build (`wrangler r2 bucket cors put`), jadi tempatnya bukan di root bersama titik masuk aplikasi	`grep -rn r2-cors src tests scripts package.json`: kosong, jadi tidak ada kode yang bergantung pada jalurnya
`e2e/` pindah ke `tests/e2e/`	Dua akar uji membuat pertanyaan "di mana ujinya" punya dua jawaban. Sekarang satu akar: `tests/*/.test.{ts,tsx}` untuk Vitest dan `tests/e2e/*.spec.ts` untuk Playwright, dengan `tests/support/` dan `tests/e2e/helpers.ts` sama-sama di dalamnya	`npx playwright test --list` menemukan seluruh 14 berkas dari lokasi baru; `npm test` tetap 23 berkas dan 179 kasus
`tsconfig.tsbuildinfo` ditulis ke `.next/cache/` lewat `tsBuildInfoFile`	Artefak sekitar 900 KB di root yang sepenuhnya turunan. `.gitignore` sudah mengabaikannya, jadi ini soal kerapian, bukan kebocoran	`npx tsc --noEmit` hijau dan berkasnya muncul di `.next/cache/`; root tidak lagi memuatnya
Aturan akar ditulis di `.github/CONTRIBUTING.md` ("Repository conventions")	Tanpa aturan tertulis, root akan terisi berkas lepas lagi pada milestone berikutnya	Bagian itu menyebut apa yang boleh di root, tujuan `docs/`, `tests/`, `tests/e2e/`, dan `infra/`, serta syarat tidak ada artefak build yang tertinggal

Yang tidak diubah: entri MILESTONES.md dan entri docs/DECISIONS.md sebelum ini masih menyebut jalur lama (tests/db/, src/lib/db/, e2e/, r2-cors.json di root). Keduanya catatan sejarah per milestone; peta folder yang berlaku ada di ARCHITECTURE.md §4 dan di tabel "Repository layout" pada README.md.

Verifikasi

Perintah	Hasil
`npm run lint`	hijau, tanpa peringatan
`npm run typecheck`	hijau
`npm test`	23 berkas, 179 lulus, 0 gagal, 0 dilewati
`npx vitest run tests/app/api`	3 berkas, 62 kasus hijau di atas D1/R2/KV miniflare
`npm run build`	hijau
`npx opennextjs-cloudflare build`	hijau, `.open-next/worker.js` dihasilkan (membuktikan impor `./src/server/purge` di `worker.ts` benar-benar terbundel)
`npx playwright test --list`	74 uji dalam 14 berkas ditemukan dari `testDir` baru (`tests/e2e`), termasuk proyek firefox dan webkit
`npx playwright test customize.spec.ts capture.spec.ts --project=chromium`	17 lulus, 0 gagal (1,3 menit) di dev server: membuktikan `tests/e2e/helpers.ts` yang dipindah, `FIXTURE_DIR` baru, dan `testDir` baru benar-benar dipakai saat berjalan
`npx tsc --noEmit` (bagian dari `npm run typecheck`)	hijau; `tsconfig.tsbuildinfo` muncul di `.next/cache/`, dan `ls` root tidak lagi memuatnya
`ls` root	8 folder (`docs`, `infra`, `migrations`, `public`, `scripts`, `src`, `tests`, `.github`) dan 25 berkas: 3 hasil generate (`AGENTS.md`, `next-env.d.ts`, `cloudflare-env.d.ts`), 2 rahasia lokal (`.dev.vars`, `.env.local`), sisanya titik masuk dan konfigurasi alat
`npx playwright test --project=chromium`	60 lulus, 8 dilewati, 0 gagal (2,3 menit). Yang dilewati: uji ber-jaringan di balik gerbang `CLOUDFLARE_E2E`, satu uji jalur 503 karena `.dev.vars` ada di mesin ini, dan uji galeri `/dev/ui` yang hanya bermakna di server produksi
`npx playwright test --project=firefox`	3 lulus, 0 gagal (`crossbrowser.spec.ts`)
`npx playwright test --project=webkit`	3 gagal, semuanya di peluncuran peramban (`browserContext.newPage: Target page, context or browser has been closed`), bukan di asersi. Bukan akibat perubahan ini: skrip mandiri `webkit.launch()` dari `playwright-core` juga gagal di mesin ini, sementara `firefox.launch()` jalan

Catatan lingkungan: sekali di mesin Windows ini tiga berkas tests/app/api/* gagal di beforeAll (Cannot read properties of undefined (reading 'dispose')) saat npm test berjalan berdampingan dengan tsc dan eslint; ketiga instans miniflare-nya boot bersamaan dan berebut sumber daya. Dijalankan sendiri (dua kali) seluruh suite hijau, dan npx vitest run tests/app/api selalu hijau. Jadi ini rebutan sumber daya, bukan cacat uji.

Pembersihan lanjutan: komponen pindah ke fiturnya (18 Oktober 2026)

Putaran kedua audit hari yang sama. Yang pertama membereskan batas server, pohon uji, dan akar repo; yang ini membereskan penempatan komponen produk dan sisa permukaan ekspor. Tidak ada perilaku produk yang berubah.

Audit: apa yang ternyata tidak ada lagi

Diperiksa	Cara	Hasil
Modul yatim	Graf impor dari seluruh titik masuk (`src/app/**` yang berupa `page`/`layout`/`route`/`not-found`, `worker.ts`, konfigurasi, `tests/`, `scripts/`), spesifier relatif dan alias `@/` diselesaikan lewat compiler TypeScript	167 dari 169 berkas terjangkau. Dua sisanya bukan kode: `next-env.d.ts` (dibangkitkan Next) dan `src/app/globals.css`, yang diimpor `app/layout.tsx` sebagai efek samping dan diselesaikan bundler, bukan resolver modul
Modul yang hanya dipakai uji	Graf impor kedua dengan akar hanya berkas produksi	Nol. Tidak ada modul `src/**` yang hidupnya bergantung pada uji
Modul yatim di pohon uji	Graf impor ketiga dari `tests/` dan `scripts/`	Nol
Ekspor tanpa pemanggil	Nama ekspor tiap berkas `src/**` dicocokkan dengan seluruh berkas lain (kode, skrip, konfigurasi)	26 simbol dan 2 alias tipe. Sisanya terpakai; `src/components/ui` dikecualikan dengan sengaja (lihat keputusan di bawah)
Kode mati di dalam berkas	`npx tsc --noEmit --noUnusedLocals --noUnusedParameters`	Nol temuan
Token dan utilitas CSS mati	Setiap `@utility` di `globals.css` dan setiap token `@theme` dicocokkan dengan kelas yang benar-benar dipakai komponen	Nol. Delapan utilitas (`stage-grid`, `page-container`, `checker-ribbon`, `display-xl`, `display-lg`, `heading`, `title`, `ring-selected`) dan seluruh token punya pemakai
Aset yatim	Nama berkas di `public/stickers` dan `public/models` dicocokkan dengan `STICKERS` di `presets.ts` dan jalur model di `gestureSource.ts`	12 stiker berpasangan 1:1 dengan 12 entri; satu-satunya aset lain adalah wasm MediaPipe hasil salinan saat pemasangan
Dependensi nganggur	Tiap nama di `package.json` dicari di kode, gaya CSS, dan konfigurasi	Nol. `shadcn` dipakai runtime lewat `@import "shadcn/tailwind.css"` di `globals.css`, `@tailwindcss/turbopack` lewat `next.config.ts`, `tw-animate-css` lewat `@import`
Sisa pekerjaan	`TODO`, `FIXME`, `HACK`, penanda "sementara" di `src/`, `tests/`, `scripts/`	Nol
Berkas di disk yang tidak dilacak git	`git status --porcelain --ignored`	Hanya hasil turunan (`next-env.d.ts`, `cloudflare-env.d.ts`, `.next/`, `public/mediapipe/`, `test-results/`) dan rahasia lokal (`.dev.vars`, `.env.local`); tidak ada sampah

Kesimpulan putaran kedua sama dengan putaran pertama, dan itu alasan strukturnya yang diubah: yang masih bisa dibersihkan bukan berkas, melainkan penempatan komponen dan permukaan ekspor. Sapuan terakhir menemukan satu hal baru: tests/support/route.ts mengekspor ASAL_UJI yang hanya dipakai di dalam berkasnya sendiri.

Keputusan

Keputusan	Alasan	Bukti
Komponen produk keluar dari `src/components/booth` ke fitur pemiliknya: `BoothPanel` dan `Stepper` ke `features/booth`, `CameraPicker` ke `features/camera`, `CameraStage`, `CountdownOverlay`, `ShutterButton`, `ShotTray` ke `features/capture`, `GestureHUD`, `GestureToggle` ke `features/gesture`, `RelayInviteCard` ke `features/relay`	Sebelumnya satu layar punya dua rumah: logikanya di `features/*`, komponennya di `components/booth`. Aturan lama "komponen khas produk di `components/booth`" juga tidak pernah menjelaskan mengapa `features/editor`, `features/share`, dan `features/relay` sudah menyimpan komponennya sendiri. Sekarang `components/` hanya memuat primitif shadcn (`ui/`) dan kerangka bersama (`site/`), dan satu layar punya satu rumah	`git mv` untuk seluruh berkas sehingga riwayatnya ikut; `grep -rn "@/components/booth" src tests` kosong; `npm run typecheck`, `npm run lint`, dan `npm test` hijau
`ResultView`, `exportStrip.ts`, dan `sheet.ts` pindah dari `features/editor` ke `features/result`	Langkah editor adalah menghias; layar hasil adalah unduh, cetak, dan bagikan. Namanya pun sudah menyebut "result", dan berkasnya 611 baris di dalam folder yang isinya kanvas hias	Impor relatif yang menyeberang folder diubah ke alias (`@/features/editor/StripStage`, `@/features/editor/presets`), `tests/features/editor/export-filename.test.ts` pindah mengikuti modulnya ke `tests/features/result/`
`GalleryPicker` pindah dari `components/site` ke `features/gallery`	Fitur galeri hanya berisi `loadGalleryPhotos.ts` yang satu-satunya pemanggil adalah komponen itu; memisahkannya membuat fitur tanpa wajah di pohon folder	Impor di `src/app/page.tsx` menjadi `@/features/gallery/GalleryPicker`
Uji komponen ikut komponennya: `tests/features/gesture/gesture-hud.test.tsx`, `tests/features/capture/shot-tray.test.tsx`, `tests/features/result/export-filename.test.ts`	Cermin `tests/` ke `src/` baru berguna kalau berkas uji duduk di jalur yang sama dengan modulnya	23 berkas uji, 179 kasus, semuanya hijau sesudah pemindahan
Ekspor yang hanya dipakai di dalam berkasnya sendiri kehilangan kata kunci `export` (26 simbol, di antaranya `StripLayout`, `CropRect`, `ClipPlan`, `GESTURE_ACTIONS`, `SessionRecord`, `BoothSettings`), dan `ASAL_UJI` di `tests/support/route.ts` jadi konstanta lokal	Nama itu terlihat sebagai API modul padahal tidak ada pemanggil di luar berkasnya; pembaca berikutnya harus menelusuri seluruh repo untuk tahu	`grep -rn` tiap nama: hanya definisi dan pemakaian di berkas yang sama; `tsc --noEmit` hijau sebelum dan sesudah
Dua alias tipe mati dihapus: `CreateStripPayload` dan `CreateRelayPayload`	Keduanya didefinisikan sebagai `z.infer` dari schema yang rutenya sudah memakai tipenya langsung; tidak ada satu pun pemakai	`grep -rn "CreateStripPayload\|CreateRelayPayload" .` (di luar `node_modules`): kosong sesudah penghapusan; `npm run typecheck` hijau
`src/components/ui` tidak disentuh	Berkas itu keluaran CLI `shadcn add`, dan keputusan M1 mempertahankan bentuk keluarannya supaya penambahan komponen berikutnya tetap bisa dibandingkan dengan upstream. Ekspor seperti `DialogPortal` atau `useCarousel` yang belum dipakai aplikasi tetap ada karena itu bagian API primitifnya, bukan kode mati milik produk ini	`git status src/components/ui`: hanya berkas yang memang sudah disentuh milestone sebelumnya (impor `cn`), tidak ada yang baru di putaran ini
Aturan penempatan ditulis di `ARCHITECTURE.md §4` dan di "Repository conventions" `.github/CONTRIBUTING.md`	Dua kali dalam satu hari pohon folder dirapikan; tanpa aturan tertulis, pohon ketiga akan lahir lagi pada milestone berikutnya, termasuk folder `components/booth` yang baru saja dibubarkan	Kedua dokumen menyebut: `src/app` hanya rute, `components/ui` hanya primitif CLI, `components/site` hanya kerangka bersama, komponen produk di `features/<area>`

Yang tidak diubah: src/app/dev/ui/page.tsx tetap ada. Galeri komponen itu memang hanya dirender di server pengembangan (ARCHITECTURE §4, DESIGN-SYSTEM §10), tetapi ia adalah alat kerja M1 yang masih dipakai untuk membandingkan komponen dengan berkas acuan di docs/ui-reference/, dan audit axe serta uji e2e-nya menyebut halaman itu. Menghapusnya berarti menghapus pemeriksaan, bukan sampah. Enam primitif UI yang hanya dipakai galeri itu (card, carousel, skeleton, slider, tabs, tooltip) karena itu ikut dipertahankan.

Sisa yang diketahui tetapi sengaja tidak dikerjakan di putaran ini: nama pengenal di dalam tests/ masih banyak yang berbahasa Indonesia (masukHias, sidangLaju, kosongkanBucket), sementara CONTRIBUTING.md mewajibkan pengenal berbahasa Inggris. Itu pekerjaan penamaan, bukan struktur, dan jumlahnya sekitar 150 pengenal yang tersebar di 20 berkas; menggantinya setengah jalan akan meninggalkan pohon yang lebih tidak konsisten daripada sebelum disentuh. Pindah berkas putaran ini sudah mengikuti aturan itu (tidak ada nama berkas baru yang berbahasa Indonesia).

Verifikasi

Perintah	Hasil
`npm run lint`	hijau, tanpa peringatan
`npm run typecheck`	hijau (`next typegen` lalu `tsc --noEmit`)
`npm test`	23 berkas, 179 lulus, 0 gagal, 0 dilewati
`npm run build`	hijau; tabel rutenya tetap memuat kesebelas rute API dan delapan halaman, termasuk `/dev/ui`
`npx tsc --noEmit --noUnusedLocals --noUnusedParameters`	nol temuan (dipakai untuk audit, bukan syarat CI)
`npx playwright test tests/e2e/capture.spec.ts tests/e2e/customize.spec.ts tests/e2e/result.spec.ts tests/e2e/dev-ui.spec.ts tests/e2e/gesture.spec.ts tests/e2e/live.spec.ts --project=chromium`	25 lulus, 1 dilewati, 0 gagal (1,7 menit). Keenam berkas itu yang paling bergantung pada komponen yang dipindah: kamera, hias, hasil, galeri komponen, gesture, dan Strip Hidup. Yang dilewati adalah uji ber-jaringan di `live.spec.ts` (`test.skip(process.env.CLOUDFLARE_E2E !== "1", ...)`); galeri `/dev/ui` justru ikut dirender karena server ini server pengembangan, jadi uji a11y-nya tidak dilewati

Lambang merek dan ikon turunannya (18 Oktober 2026)

Permintaannya: lambang untuk snapme, kreatif karena produknya photobooth yang berwarna. Sebelum ini "lambang"-nya hanya kotak violet 40 px berisi ikon Sparkle dari Phosphor di dalam Wordmark.tsx, dan favicon-nya masih bawaan create-next-app (tiga bingkai bitmap, 15.086 bita).

Lambang yang dipakai: ubin paper bergaris tepi ink berisi kipas empat kartu foto. Tiga kartu belakang violet, tangerine, pink; kartu depan paper bergaris tepi dengan bidang foto lime, satu sparkle ink, dan satu baris keterangan ink. Aturan lengkapnya di DESIGN-SYSTEM.md §8.

Keputusan	Alasan	Bukti
Kipas kartu foto, bukan kamera, bukan huruf, bukan ledakan flash	Produknya menghasilkan cetakan foto: kartunya adalah keluarannya sendiri, sedangkan ikon kamera sudah dipakai hampir semua aplikasi foto. Sparkle di kartu depan meneruskan ikon wordmark lama supaya mereknya tidak pindah total	Tiga arah digambar sebagai SVG lalu dirender pada 180, 96, 40, 22, dan 16 px di atas `lime` dan `ink`: kamera dengan ledakan delapan sinar (ubin `paper` dan ubin `violet`), kipas kartu foto (empat iterasi bentuk dan skala), dan ubin berisi satu kartu (dua iterasi). Kipas di dalam ubin `paper` dipakai karena satu-satunya yang tetap terbaca sebagai susunan kartu di 40 px
Kartunya berbentuk cetakan foto (bidang foto hampir persegi, kaki lebar), bukan layar ponsel	Kartu 26 x 34 px yang ramping dengan bingkai tipis dan kaki sempit terbaca sebagai ponsel, bukan cetakan	Perbandingan render 180 px dari dua bentuk kartu: yang ramping (26 x 34 px, bidang foto 18 x 20 px, kaki 3 px) terbaca sebagai ponsel; yang dipakai (28 x 32 px, bidang 20 x 20 px, kaki lebar) terbaca sebagai cetakan
Ubinnya `paper`, bukan `violet`	Lambang dipakai di tiga latar: panggung `lime`, panel `paper`, dan sebagai avatar persegi di luar aplikasi. Ubin `violet` membuat kartu belakang `violet` hilang ke latarnya; ubin `paper` sama dengan bahasa panel §1 (panel krem bergaris tepi hitam tebal)	Tangkapan 4x dari header saat aplikasi berjalan (`http://localhost:3000`): kartu belakang `violet` tetap terbaca karena ubinnya `paper`
Warnanya hanya dari palet §2, datar, bergaris tepi `ink`, tanpa gradasi	§1 melarang gradasi sebagai hiasan dan mewajibkan garis tepi `ink` 2 sampai 3 px di semua komponen. Lambangnya bukan pengecualian	Kedua SVG hanya memuat `#141414`, `#FFFDF7`, `#C3F53C`, `#F0562B`, `#5038D6`, `#F2479B`; pada ukuran tampil 40 px garis tepi ubin 1,9 px dan garis kartu 2,1 px
Lambangnya 64 x 64 di dalam kotak 64, dengan kipasnya diskalakan 0,9 dan digeser ke atas 0,5	Pada skala 0,975 sudut kartu paling luar menyentuh garis tepi ubin sampai keduanya menyatu jadi satu gumpalan hitam; pada 0,9 masih ada jarak 3,6 satuan dan komposisinya tetap memenuhi lebar ubin	Rentang kipas pada skala 0,9 dihitung dari sudut kartunya: x 6,6 sampai 57,4 dan y 12,3 sampai 51,7, semuanya di dalam 3 sampai 61
Favicon memakai satu kartu besar, bukan kipasnya	Pada 16 px empat kartu yang bertumpuk menjadi bercak warna; bingkai 16 px terakhir kipasnya tidak lagi terbaca sebagai kartu	Tiga bingkai `favicon.ico` diperiksa pada 16, 32, dan 48 px dan diperbesar 5x dengan `nearest`: kipasnya bercak, satu kartunya tetap terbaca
`src/app/favicon.ico` ditulis ulang dengan muatan PNG	Muatan PNG didukung Windows Vista ke atas dan seluruh peramban yang memasang favicon; berkas lama memakai bitmap mentah	15.086 bita (tiga bingkai 48/32/16, bitmap, dari `create-next-app`) menjadi 4.610 bita; pembacaan direktori ICO memastikan tiga entri dan tanda muatan `89504e47`
`apple-icon.png` dan `favicon.ico` ikut di-commit, berbeda dari `cloudflare-env.d.ts` dan `public/mediapipe/wasm` yang dibangkitkan saat pemasangan	Ukurannya 10,2 KB dan 4,6 KB, bukan ratusan megabita, sementara `next build` membacanya lewat konvensi berkas `app/`: menjadikan `sharp` syarat pemasangan untuk dua berkas sekecil itu menambah satu titik gagal tanpa menambah apa pun	`git status`: dua berkas itu muncul sebagai berkas baru, bukan diabaikan; `sharp` hanya `devDependency`, dan `postinstall` tidak menyentuhnya
Berkas raster diturunkan `scripts/render-brand-icons.mjs`, bukan digambar dua kali	Favicon versi kecil dan ikon 180 px harus selalu berasal dari geometri yang sama dengan lambangnya; menggambar dua kali berarti dua gambar yang bisa menyimpang	Berkas raster dibangun ulang dari kedua SVG dan hasilnya identik tiap kali; skrip menggambar pada 600 dpi (64 px x 600/72 = 533 px) lalu memperkecil, jadi garis tepinya tetap tajam
`Wordmark.tsx` memakai `next/image` dengan `unoptimized`	`next/image` menolak SVG lewat pengoptimal bawaannya; `unoptimized` melewatkannya apa adanya. Pilihan alternatifnya, menggambar ulang lambangnya sebagai SVG inline, berarti salinan kedua yang harus ikut dijaga, padahal gambar yang sama juga dipakai favicon, ikon apel, dan README	Diperiksa di peramban: `src="/brand/snapme-mark.svg"`, `naturalWidth` 64, kotak tampil 40 x 40 px, nama tautannya tetap "snapme" (gambar `alt` kosong, teksnya yang membawa nama)

Yang tidak diubah:

Ikon antarmuka tetap seluruhnya dari @phosphor-icons/react (§8). Lambang merek bukan ikon antarmuka: ia satu gambar, bukan keluarga ikon, dan §8 melarang menggambar path ikon sendiri untuk antarmuka.
Namanya tetap "snapme" pada Unbounded 900, tanpa huruf yang digambar ulang. Yang berubah hanya kotak di sebelah kirinya.
Halaman acuan di docs/ui-reference/ tidak disentuh. Ketiganya menggambarkan tata letak dan keadaan komponen; baris atas di sana menyebut "wordmark" tanpa menggambar lambangnya, jadi tidak ada yang bertentangan dengan §8.

Verifikasi

Perintah	Hasil
`npm run brand:icons`	`src/app/favicon.ico` (16, 32, 48 px) 4.610 bita dan `src/app/apple-icon.png` 10.203 bita, keduanya dibangun ulang dari `public/brand/snapme-mark.svg` dan `src/app/icon.svg`
`npm run lint`	hijau, tanpa peringatan
`npm run typecheck`	hijau (`next typegen` lalu `tsc --noEmit`)
Aplikasi berjalan di `http://localhost:3000`	`<link>` yang dihasilkan Next: `icon` `/favicon.ico` 48x48, `icon` `/icon.svg` type `image/svg+xml` sizes `any`, `apple-touch-icon` `/apple-icon.png` 180x180. Gambar di header: `naturalWidth` 64, kotak 40 x 40 px. Tangkapan 4x memperlihatkan empat kartunya, sparkle, dan garis tepi ubinnya utuh
`npm test`	23 berkas, 179 lulus, 0 gagal
`npx playwright test tests/e2e/a11y.spec.ts --project=chromium`	18 lulus, 2 dilewati (yang butuh binding Cloudflare), 0 gagal. Gambar `alt` kosong tidak memicu temuan `image-alt`, dan nama tautan beranda tetap "snapme"
`npm run build`	hijau; tabel rutenya memuat `/icon.svg` dan `/apple-icon.png` sebagai rute statis, jadi Next membaca konvensi berkas `app/` yang baru
`npm run lint`	hijau. Keluaran `/brag` ditambahkan ke `globalIgnores` `eslint.config.mjs`: komposisi Hyperframes membawa `gsap.min.js` yang gagal aturan proyek (alias `this`), sama seperti wasm MediaPipe
Header di `/booth/layout` diperiksa di peramban	Lambang 40 x 40 px utuh di sebelah "snapme", berdampingan dengan stepper LAYOUT, FOTO, HIAS, HASIL

Pembongkaran backend Cloudflare (18 Oktober 2026)

Keputusan pengguna: cabut seluruh backend Cloudflare dari snapme (Workers dengan adapter OpenNext, D1, KV, R2, dan wrangler). snapme kini aplikasi klien murni: booth berjalan penuh di browser, tidak ada unggahan ke mana pun, dan tidak ada env yang dibutuhkan build. Alasan pengguna tidak dirinci di sini; yang dicatat adalah keputusannya, daftar yang dihapus, dan konsekuensinya.

Yang dihapus

Kelompok	Isi
Sisi server	`src/server/` seluruhnya (`cloudflare.ts`, `db/`, `r2/`, `rateLimit.ts`, `expiry.ts`, `purge.ts`, `tokens.ts`), `src/app/api/cron/`, `worker.ts`, `open-next.config.ts`, `wrangler.jsonc`, `playwright.cf.config.ts`, `infra/`, `migrations/`, `scripts/cf-typegen.mjs`, `scripts/patch-opennext.mjs`
Komponen dan modul di atas backend	`RelayJoinView`, `RelayCompleteView`, `RelayCancel`, `relay/bootstrap.ts`, `StripOwnerActions`, `LiveStripVideo`
Uji	`tests/support/` (harness miniflare), `tests/app/api/`, `tests/server/`, jalur e2e ber-binding (`CLOUDFLARE_E2E`) dan helper `pasangSidangBaru`/`undangEstafet`
Dependensi	`@opennextjs/cloudflare`, `aws4fetch`, `wrangler`, `lighthouse`
Skrip npm	`cf:patch`, `preview`, `preview:e2e`, `deploy`, `cf-typegen`, `test:e2e:cf`, `perf:lcp`
Berkas env	`.env.example`, `.dev.vars.example`, dan salinan lokalnya (`.env.local`, `.dev.vars` yang berisi kredensial R2) dihapus dari mesin pengembangan

Konsekuensi

Keputusan	Alasan	Bukti
Sembilan rute `/api` dipertahankan sebagai stub yang menjawab 503 dengan pesan tetap ("Pembuatan link belum tersedia." dan seterusnya), bukan dihapus	Klien (`features/share/api.ts`, `features/relay/api.ts`, antrean analitik) masih memanggil rute-rute itu; 503 membuat UI menampilkan pesan "belum tersedia" yang sudah ada jalurnya, bukan galat jaringan mentah atau 404	`src/app/api/**` sembilan berkas, masing-masing satu konstanta `UNAVAILABLE` dan satu handler
`/s/[id]` dan `/r/[id]` menjadi stub `notFound()` dengan metadata `robots: noindex`	Tidak ada strip atau estafet yang tersimpan, jadi tidak ada `id` yang sah; halaman yang mengambil data (`RelayJoinView`, `StripOwnerActions`, `LiveStripVideo`) sudah dihapus duluan	Kedua `page.tsx` hanya memanggil `notFound()`; header `noindex`/`no-referrer` untuk `/s/` dan `/r/` tetap di `next.config.ts`
UI bagikan/estafet dipertahankan: dialog persetujuan, kartu bagikan, kartu undang estafet, kotak QR di kanvas, sakelarnya	Alur foto dan dialog persetujuannya (PRD SE-02, SH-04) adalah perilaku produk, bukan milik backend; ia kini selalu berakhir di pesan "belum tersedia"	`features/share/` dan `features/relay/` utuh kecuali modul yang dihapus di atas
Antrean analitik tidak dihapus	`lib/analytics.ts` best-effort tanpa pengulangan: selama `POST /api/events` menjawab 503, batchnya dibuang diam-diam tanpa mengganggu alur foto	Antrean dan `analyticsEvents.ts` tetap ada; diuji `tests/lib/analytics-queue.test.ts`
CSP disusun ulang tanpa host luar; `postinstall` tinggal `copy-mediapipe-wasm.mjs`; `lib/schemas.ts` dipangkas ke ekspor yang dipakai klien	Tidak ada unggahan ke layanan luar, jadi CSP tidak punya host yang perlu diizinkan; penambal OpenNext dan tipe binding tidak ada gunanya tanpa Workernya	`next.config.ts`, `package.json`, `src/lib/schemas.ts`
Dokumen kondisi-kini ditulis ulang (README, ARCHITECTURE, PRD, CONTRIBUTING, SECURITY); entri lama CHANGELOG, DECISIONS, MILESTONES tidak disentuh	Dokumen kondisi-kini tidak boleh lagi mengklaim stack aktif yang sudah tidak ada; sejarah tetap sejarah	Pencarian `cloudflare

Verifikasi

Perintah	Hasil
Pemeriksaan berkas	`worker.ts`, `wrangler.jsonc`, `open-next.config.ts`, `playwright.cf.config.ts`, `infra/`, `migrations/`, `.env.example`, `.dev.vars.example` tidak ada lagi di repo; `scripts/` tinggal `copy-mediapipe-wasm.mjs` dan `render-brand-icons.mjs`
`package.json`	Skrip tinggal `dev`, `build`, `postinstall`, `brand:icons`, `lint`, `typegen`, `typecheck`, `test`; tidak ada lagi `@opennextjs/cloudflare`, `aws4fetch`, `wrangler`, `lighthouse`
Pencarian dokumen kondisi-kini	`grep -rniE "cloudflare

M0 Fondasi (8 Oktober 2026)

Registry neobrutalism: dipakai sebagai titik awal button, badge, card

Penyimpangan dari dokumen

Penyesuaian pada kode registry shadcn/ui

M1 Welcome dan kerangka booth (9 Oktober 2026)

Audit aksesibilitas M1

Penyimpangan dan keputusan M1

M2 Kamera (10 Oktober 2026)

Mesin keadaan pemotretan: src/features/capture/machine.ts

Kamera: src/features/camera/

Kamera palsu di uji Playwright

Penyimpanan foto di M2

Penyimpangan M2

M3 Gesture Snap (9 Oktober 2026)

Aset wasm dan model

Ambang awal dan satu penyimpangan rumus laju

Penyimpangan M3

Perbandingan berdampingan dengan capture.html

Sumber satu-satunya modul MediaPipe

Uji manual (diisi pengguna)

M4 Hias strip (9 Oktober 2026)

12 stiker: SVG ditulis tangan

Frame sebagai data, bukan berkas di public/frames/

Warna kanvas: token dibaca saat dipakai

Cache filter Konva: pixelRatio 1, bukan 600 / lebar panggung

Ekspor PNG (FR-11)

Ukuran strip di panggung dan tata letak kaki strip

Penyimpangan M4

Perbandingan berdampingan dengan customize.html

Uji manual yang perlu dilengkapi pengguna

Id preset dipisah dari data preset

Bentuk asersi "Konva tidak dimuat"

Yang diperiksa di browser selain uji otomatis

M5 Hasil dan cetak (9 Oktober 2026)

Pencetakan 4R: portal ke body, bukan pola visibility

Ekspor dikerjakan sekali saat mount

Grid 2 x 2 dicetak sebagai lembar itu sendiri

"Mulai dari awal" mengarah ke pemilih layout

idb sebagai klien penyimpanan (FR-14)

Penyimpangan M5

Bukti browser untuk halaman Hasil

Uji manual yang perlu dilengkapi pengguna

M6 Link strip dan QR (9 Oktober 2026)

Proyek Supabase: dibuat dan dimigrasi lewat CLI (9 Oktober 2026)

Pembatasan laju di basis data, bukan di memori fungsi serverless

Unggahan langsung ke Storage, verifikasi di rute complete

Ekspor ulang ber-QR: antrean satu jalur di ResultView

Kotak QR: 168 px, zona tenang 4 modul, sudut membulat

Penyimpangan M6

Bukti browser M6

Perbandingan berdampingan kartu QR dengan customize.html

Tinjauan keamanan

Uji manual yang perlu dilengkapi pengguna

M7 Strip Hidup (9 Oktober 2026)

Klip hanya di memori, tidak ikut IndexedDB

Bucket naik ke 5 MB, batas 2 MB still ditegakkan rute complete

Versi hidup best-effort di rute complete

Lencana "Klip" dan label baru

Perbandingan berdampingan lencana "Klip" dengan customize.html

Bukti browser M7

Uji manual yang perlu dilengkapi pengguna

M8 Strip Estafet (9 Oktober 2026)

Pembagian slot dan pemetaan foto pembuat

Slot teman diunggah saat penuntasan, bukan saat jepret

Token satu header, giliran sekali di basis data

Strip estafet hanya PNG diam, tanpa klip dan tanpa QR

Tampilan /r/[id] setelah 48 jam

Pembuat bisa membatalkan setelah estafet selesai

localOnly ikut tersimpan di rekaman sesi

Refactor kecil yang menyertai M8

Label antarmuka baru

Bukti browser M8

Catatan uji ber-jaringan: kuota per sidang

Catatan uji: kompilasi dingin server pengembangan

Uji ber-jaringan M8

Hasil tinjauan keamanan (temuan major diperbaiki, sisanya dicatat)

Batas aman

M9 Pengerasan (9 Oktober 2026)

Pengerasan tabel relays (sisa temuan M8)

Analitik first-party (PRD §4)

Registry neobrutalism: dipakai sebagai titik awal `button`, `badge`, `card`

Mesin keadaan pemotretan: `src/features/capture/machine.ts`

Kamera: `src/features/camera/`

Perbandingan berdampingan dengan `capture.html`

Frame sebagai data, bukan berkas di `public/frames/`

Cache filter Konva: `pixelRatio` 1, bukan 600 / lebar panggung

Perbandingan berdampingan dengan `customize.html`

Pencetakan 4R: portal ke `body`, bukan pola `visibility`

`idb` sebagai klien penyimpanan (FR-14)

Unggahan langsung ke Storage, verifikasi di rute `complete`

Ekspor ulang ber-QR: antrean satu jalur di `ResultView`

Perbandingan berdampingan kartu QR dengan `customize.html`

Bucket naik ke 5 MB, batas 2 MB still ditegakkan rute `complete`

Versi hidup best-effort di rute `complete`

Perbandingan berdampingan lencana "Klip" dengan `customize.html`

Tampilan `/r/[id]` setelah 48 jam

`localOnly` ikut tersimpan di rekaman sesi

Pengerasan tabel `relays` (sisa temuan M8)

CSP penuh dan status halaman `/s` serta `/r`

Runtime: OpenNext, bukan `next-on-pages` atau vinext

Uji basis data: `getPlatformProxy`, bukan `@cloudflare/vitest-pool-workers`

Celah upstream OpenNext: manifest `preview-props.json` (tambalan kecil)

Sidang pembatasan laju: `cf-connecting-ip` lebih dulu

Origin peramban versus host pratinjau (`isCrossSite`)

Foto slot teman tidak termuat: respons `<img>` yang ter-cache menghalangi `fetch` CORS

Catatan uji: `share.spec.ts` tidak mematikan Gesture Snap (16 Oktober 2026)