Knowledge center

Dokumentasi operasional SABAR OS

Panduan terstruktur dari dokumen proyek: arsitektur, aturan trading, keamanan, AI, backup, release, dan readiness menuju live-small.

Panduan

Kategori

A–Z

Cakupan

10 panduan ditemukan

Buka glosarium

Fondasi• 4 menit•docs/00_PRD.md

Prinsip dan tujuan SABAR

Mengapa sistem mengutamakan disiplin, audit, dan pembatasan risiko dibanding frekuensi transaksi.

Inti panduan

SABAR berarti Secure, Adaptive, Backup-ready, AI-assisted, Risk-controlled.

Tidak ada sinyal berkualitas adalah alasan valid untuk HOLD.

AI bertindak sebagai analis pembanding, bukan eksekutor order.

Live trading hanya dibuka setelah bukti paper trading dan readiness lengkap.

HOLD Paper Trading Risk Gate Live-small

Fondasi• 6 menit•docs/01_ARCHITECTURE.md

Arsitektur dan aliran keputusan

Peta frontend, API, decision gate, engine analisis, database, AI gateway, dan exchange connector.

Inti panduan

Frontend tidak menyimpan secret dan hanya berkomunikasi dengan backend API.

Decision Gate menggabungkan Strategy, Risk, Patience, Learning, dan AI.

Risk dan Patience dapat memveto keputusan meskipun technical score tinggi.

Setiap keputusan, order, dan perubahan konfigurasi meninggalkan jejak audit.

Referensi

Market snapshot
→ Strategy score
→ Risk gate
→ Patience gate
→ Historical edge
→ AI consensus
→ Final decision
→ Audit log
→ Paper/live execution

Decision Gate Strategy Engine Patience Engine Audit Log

Trading• 7 menit•docs/06_TRADING_RULES.md

Aturan trading konservatif

Syarat entry, no-chase, position sizing, exit, dan penghitungan target bersih.

Inti panduan

Entry hanya boleh untuk pair whitelist dengan spread, volume, dan score yang memenuhi batas.

Risk gate, cooldown, historical edge, dan AI skeptic harus lolos.

Target take-profit memperhitungkan fee beli, fee jual, dan slippage.

Default membatasi dua posisi aktif dan tiga transaksi per hari.

Referensi

Technical 30% + Liquidity 20% + Risk 20%
+ Historical Edge 20% + AI Consensus 10%

BUY_SMALL Spread Slippage Take Profit Net Position Sizing

Trading• 6 menit•docs/07_AI_AGENT_ORCHESTRATION.md

Peran AI dan multi-agent

Cara 9Router mengoordinasikan analis teknikal, sentimen, risk officer, skeptic, dan judge.

Inti panduan

AI menerima data pasar terpilih, bukan API key, token server, atau identitas akun.

Risk Officer dan Skeptic dapat memaksa HOLD melalui veto.

Output agent wajib terstruktur agar dapat divalidasi dan diaudit.

Saat AI tidak tersedia atau timeout, sistem kembali ke rule-only.

Referensi

{
  "agent": "risk_officer",
  "decision": "HOLD",
  "confidence": 71,
  "veto": false,
  "reasons": ["spread aman"],
  "warnings": ["mendekati resistance"]
}

9Router AI Consensus Risk Officer Skeptic Rule-only

Fondasi• 5 menit•docs/14_AI_PAGE_EXPLAINER.md

AI menjelaskan halaman

Asisten read-only yang menerjemahkan data halaman tanpa membaca secret atau memiliki akses eksekusi.

Inti panduan

Browser hanya mengirim page key dan pertanyaan; konteks dibangun ulang oleh backend.

Setiap halaman memiliki allowlist field dan batas ukuran konteks.

9Router dipakai bila tersedia, dengan safe fallback deterministik saat tidak aktif atau error.

AI tidak dapat membuat order, mengubah settings, atau melewati risk dan readiness gate.

Urutan kerja

1Buka halaman yang ingin dipahami.
2Tekan tombol Jelaskan halaman.
3Pilih pertanyaan ringkas, alasan status, angka, risiko, atau langkah aman.
4Periksa bukti, waktu konteks, sumber AI/fallback, dan batasan jawaban.
5Buka istilah terkait melalui Glosarium.

Rule-only Allowlist Audit Log Market Freshness

Keamanan• 5 menit•Runtime implementation

Konfigurasi runtime yang aman

Cara preview, konfirmasi risiko, reset, audit, allowlist host, dan status penerapan worker bekerja.

Inti panduan

Role operator atau admin berasal dari token server, bukan pilihan browser.

Sekumpulan perubahan disimpan atomik: semuanya berhasil atau semuanya dibatalkan.

Pair dengan posisi terbuka tidak dapat dikeluarkan dari whitelist.

Worker menampilkan status APPLIED setelah membaca versi settings terbaru.

Urutan kerja

1Masukkan token operator atau admin pada halaman Settings.
2Ubah parameter yang diperlukan lalu tekan Preview.
3Baca diff, warning, dan blocker dari backend.
4Konfirmasi perubahan berisiko lalu terapkan.
5Pastikan status berubah dari PENDING WORKER menjadi APPLIED.

Runtime Override Atomic Update Allowlist Worker Applied

Keamanan• 8 menit•docs/02_SECURITY_MODEL.md

Model keamanan dan batas data

Threat model, isolasi secret, permission exchange, hardening produksi, dan guard live trading.

Inti panduan

Permission withdraw wajib nonaktif untuk API key bot.

Dashboard publik membutuhkan HTTPS, autentikasi, dan idealnya VPN atau allowlist.

AI tidak boleh menerima credential, token, password, atau detail identitas akun.

Live order ditolak bila salah satu safety gate gagal.

Secret Isolation Kill Switch Withdraw Disabled RBAC

Operasional• 5 menit•docs/03_BACKUP_RESTORE.md

Backup dan restore

Data prioritas, retensi, checksum, restore test, RPO, dan RTO.

Inti panduan

Trade journal, decision snapshots, dan audit log memiliki prioritas tertinggi.

Checksum diverifikasi sebelum restore.

Restore dilakukan ke database testing dan jumlah record dibandingkan.

Backup produksi perlu terenkripsi dan disalin offsite.

Referensi

make backup
make restore
powershell -File scripts/release_check.ps1

RPO RTO Checksum Offsite Backup

Operasional• 5 menit•docs/04_UPDATE_AND_RELEASE.md

Update, release, dan rollback

Alur aman dari perubahan kode sampai smoke test, monitoring, dan rollback.

Inti panduan

Perubahan strategi harus memiliki versi yang dapat dilacak.

Rilis memerlukan test backend, build frontend, smoke, backup, dan kill-switch check.

Environment produksi tidak boleh ditimpa oleh konfigurasi proyek lain.

Rollback dilakukan ketika risk engine, order flow, atau dashboard kontrol gagal.

Urutan kerja

1Unit test
2Staging/paper validation
3Backup
4Deploy
5Smoke test
6Monitor
7Rollback bila gagal

Strategy Version Smoke Test Rollback Regression

Operasional• 6 menit•docs/13_LIVE_READINESS_RUNBOOK.md

Readiness menuju live-small

Bukti objektif dan tindakan manual sebelum sistem boleh menggunakan modal kecil.

Inti panduan

Readiness API harus menyatakan ready_for_live_small=true.

Minimal 14 hari bukti paper, order paper, restore test, dan kill-switch test diperlukan.

Batas harian dan laporan validasi mengikuti APP_TIMEZONE, default Asia/Jakarta.

Kualitas validasi juga memantau hari aktif, error worker/collector, drawdown, dan baseline 20 closed trade.

Operator harus memberi approval manual dan bukti withdraw permission nonaktif.

Jika bukti kedaluwarsa atau audit gagal, sistem kembali ke paper mode.

Referensi

GET http://127.0.0.1:18080/api/readiness/live-small

Live-small Readiness Gate Manual Approval Paper Evidence