Documentation Index

Fetch the complete documentation index at: https://docs.openclaw.ai/llms.txt

Use this file to discover all available pages before exploring further.

​

Rencana modernisasi aplikasi

​

Tujuan

​

Prinsip

• Pertahankan arsitektur saat ini kecuali suatu batas terbukti menyebabkan churn, biaya performa, atau bug yang terlihat oleh pengguna.
• Utamakan patch terkecil yang benar untuk setiap masalah, lalu ulangi.
• Pisahkan perbaikan yang wajib dari polesan opsional agar maintainer dapat merilis pekerjaan bernilai tinggi tanpa menunggu keputusan yang subjektif.
• Pertahankan perilaku yang berhadapan dengan Plugin tetap terdokumentasi dan kompatibel ke belakang.
• Verifikasi perilaku yang sudah dirilis, kontrak dependensi, dan pengujian sebelum mengklaim bahwa suatu regresi telah diperbaiki.
• Perbaiki jalur pengguna utama terlebih dahulu: onboarding, auth, chat, penyiapan penyedia, manajemen Plugin, dan diagnostik.

​

Fase 1: Audit baseline

• Identifikasi alur kerja pengguna utama dan permukaan kode yang memilikinya.
• Daftarkan affordance yang mati, pengaturan duplikat, status error yang tidak jelas, dan jalur render yang mahal.
• Catat perintah validasi saat ini untuk setiap permukaan.
• Tandai masalah sebagai wajib, direkomendasikan, atau opsional.
• Dokumentasikan blocker yang diketahui dan memerlukan tinjauan owner, terutama perubahan API, keamanan, rilis, dan kontrak Plugin.

• Satu daftar masalah dengan referensi file dari root repo.
• Setiap masalah memiliki tingkat keparahan, permukaan owner, dampak yang diharapkan bagi pengguna, dan jalur validasi yang diusulkan.
• Tidak ada item pembersihan spekulatif yang tercampur ke dalam perbaikan wajib.

​

Fase 2: Pembersihan produk dan UX

• Rapikan copy onboarding dan status kosong di sekitar auth model, status Gateway, dan penyiapan Plugin.
• Hapus atau nonaktifkan affordance mati saat tidak ada tindakan yang memungkinkan.
• Pertahankan tindakan penting tetap terlihat di berbagai lebar responsif, alih-alih menyembunyikannya di balik asumsi layout yang rapuh.
• Konsolidasikan bahasa status yang berulang agar error memiliki satu sumber kebenaran.
• Tambahkan progressive disclosure untuk pengaturan lanjutan sambil tetap menjaga penyiapan inti tetap cepat.

• Jalur happy path manual untuk penyiapan pertama kali dan startup pengguna yang sudah ada.
• Pengujian terfokus untuk logika routing, persistensi config, atau penurunan status.
• Screenshot browser untuk permukaan responsif yang diubah.

​

Fase 3: Pengetatan arsitektur frontend

• Pindahkan transformasi state UI yang berulang ke helper bertipe sempit.
• Pisahkan tanggung jawab pengambilan data, persistensi, dan presentasi.
• Utamakan hook, store, dan pola komponen yang sudah ada dibanding abstraksi baru.
• Pecah komponen yang terlalu besar hanya jika itu mengurangi coupling atau memperjelas pengujian.
• Hindari memperkenalkan state global yang luas untuk interaksi panel lokal.

• Jangan ubah perilaku publik sebagai efek samping dari pemecahan file.
• Pertahankan perilaku aksesibilitas untuk menu, dialog, tab, dan navigasi keyboard.
• Verifikasi bahwa status loading, kosong, error, dan optimistis masih dirender.

​

Fase 4: Performa dan keandalan

• Ukur biaya startup, transisi rute, daftar besar, dan transkrip chat.
• Ganti data turunan mahal yang berulang dengan selector termemoisasi atau helper tercache saat profiling membuktikan nilainya.
• Kurangi pemindaian network atau filesystem yang dapat dihindari pada jalur panas.
• Pertahankan urutan deterministik untuk input prompt, registri, file, Plugin, dan network sebelum konstruksi payload model.
• Tambahkan pengujian regresi ringan untuk helper hot dan batas kontrak.

• Setiap perubahan performa mencatat baseline, dampak yang diharapkan, dampak aktual, dan celah yang tersisa.
• Tidak ada patch performa yang dirilis hanya berdasarkan intuisi ketika pengukuran murah tersedia.

​

Fase 5: Penguatan type, kontrak, dan pengujian

• Ganti string runtime yang longgar dengan union terdiskriminasi atau daftar kode tertutup.
• Validasi input eksternal dengan helper schema yang ada atau zod.
• Tambahkan pengujian kontrak di sekitar manifest Plugin, katalog penyedia, pesan protokol Gateway, dan perilaku migrasi config.
• Pertahankan jalur kompatibilitas dalam alur doctor atau repair, bukan migrasi tersembunyi saat startup.
• Hindari coupling khusus pengujian ke internal Plugin; gunakan facade SDK dan barrel yang terdokumentasi.

• pnpm check:changed
• Pengujian terarah untuk setiap batas yang diubah.
• pnpm build saat batas lazy, packaging, atau permukaan yang dipublikasikan berubah.

​

Fase 6: Dokumentasi dan kesiapan rilis

• Perbarui dokumentasi untuk perubahan perilaku, API, config, onboarding, atau Plugin.
• Tambahkan entri changelog hanya untuk perubahan yang terlihat oleh pengguna.
• Pertahankan terminologi Plugin untuk pengguna; gunakan nama package internal hanya bila diperlukan untuk kontributor.
• Konfirmasikan bahwa instruksi rilis dan instalasi masih sesuai dengan permukaan perintah saat ini.

• Dokumentasi yang relevan diperbarui di branch yang sama dengan perubahan perilaku.
• Pemeriksaan drift dokumentasi atau API yang dihasilkan lulus saat disentuh.
• Handoff menyebutkan validasi apa pun yang dilewati dan alasan dilewati.

​

Irisan pertama yang direkomendasikan

• Audit penyiapan pertama kali, kesiapan auth penyedia, status Gateway, dan permukaan penyiapan Plugin.
• Hapus tindakan mati dan perjelas status kegagalan.
• Tambahkan atau perbarui pengujian terfokus untuk penurunan status dan persistensi config.
• Jalankan pnpm check:changed.

​

Pembaruan skill frontend

# Frontend Delivery Standards

Use this skill when implementing or reviewing user-facing React, Next.js,
desktop webview, or app UI work.

## Operating rules

- Start from the existing product workflow and code conventions.
- Prefer the smallest correct patch that improves the current user path.
- Separate required fixes from optional polish in the handoff.
- Do not build marketing pages when the request is for an application surface.
- Keep actions visible and usable across supported viewport sizes.
- Remove dead affordances instead of leaving controls that cannot act.
- Preserve loading, empty, error, success, and permission states.
- Use existing design-system components, hooks, stores, and icons before adding
  new primitives.

## Implementation checklist

1. Identify the primary user task and the component or route that owns it.
2. Read the local component patterns before editing.
3. Patch the narrowest surface that solves the issue.
4. Add responsive constraints for fixed-format controls, toolbars, grids, and
   counters so text and hover states cannot resize the layout unexpectedly.
5. Keep data loading, state derivation, and rendering responsibilities clear.
6. Add tests when logic, persistence, routing, permissions, or shared helpers
   change.
7. Verify the main happy path and the most relevant edge case.

## Visual quality gates

- Text must fit inside its container on mobile and desktop.
- Toolbars may wrap, but controls must remain reachable.
- Buttons should use familiar icons when the icon is clearer than text.
- Cards should be used for repeated items, modals, and framed tools, not for
  every page section.
- Avoid one-note color palettes and decorative backgrounds that compete with
  operational content.
- Dense product surfaces should optimize for scanning, comparison, and repeated
  use.

## Handoff format

Report:

- What changed.
- What user behavior changed.
- Required validation that passed.
- Any validation skipped and the concrete reason.
- Optional follow-up work, clearly separated from required fixes.