quantlab-feature-implementation

name: quantlab-feature-implementation description: Gunakan skill ini saat mengimplementasikan fitur baru end-to-end di QuantLab — dari requirements, desain, backend engine, endpoint, frontend component, testing, sampai dokumentasi update. Panduan untuk fitur vertical slice yang complete.

QuantLab Feature Implementation Skill

Skill ini memandu agent dalam implementasi fitur end-to-end di QuantLab — dari analysis requirements sampai kode terintegrasi, tested, dan terdokumentasi.

🎯 Kapan Skill Ini Diaktifkan

Aktifkan OTOMATIS jika:

• User minta "implement fitur X" (sesuatu yang baru)
• User minta "buat halaman Y dengan data dari backend"
• User minta "tambah metric/indicator baru ke dashboard"
• User minta "integrasikan engine Z ke frontend"
• Ada request yang span backend + frontend sekaligus

🏗️ Framework Implementasi: Vertical Slice

QuantLab menggunakan Vertical Slice — setiap fitur harus complete dari backend ke frontend sebelum lanjut ke fitur berikutnya. Jangan implementasi horizontal (semua backend dulu, lalu semua frontend).

✅ BENAR: Fitur A (backend + frontend) → Fitur B (backend + frontend)
❌ SALAH: Semua backend → Semua frontend

📋 Phase Implementasi Standard

Phase 0: Requirements Analysis (WAJIB PERTAMA)

Sebelum tulis satu baris kode, jawab:

1. Apa user story-nya?
   "Sebagai [user], saya ingin [action], sehingga [benefit]"
   
2. Apa data yang dibutuhkan?
   - Input: apa yang masuk ke sistem?
   - Output: apa yang ditampilkan ke user?
   
3. Apakah butuh computation baru?
   - Jika ya → perlu engine module baru
   - Jika tidak → pakai engine yang ada
   
4. Apakah butuh data baru dari luar?
   - Endpoint baru ke Binance/external?
   - Upload dari user?
   
5. Apa success criteria-nya?
   - Bagaimana kita tahu fitur sudah done?
   - Apa yang bisa ditest?

Phase 1: Backend Engine (jika perlu komputasi baru)

[ ] Buat engine/new_feature.rs
[ ] Fungsi pure computation (no I/O)
[ ] Input/output types yang jelas
[ ] Min 3 unit tests (happy path, edge case, boundary)
[ ] Benchmark < target latency
[ ] cargo test engine::new_feature::tests → PASS

Phase 2: Service & Endpoint

[ ] Buat atau update services/new_service.rs
[ ] Tambah route di routes.rs (atau sub-module)
[ ] Tambah model struct di models.rs
[ ] Response menggunakan ApiResponse<T>
[ ] Error handling dengan AppError
[ ] Register route di main.rs
[ ] cargo check → 0 errors
[ ] Test endpoint: curl http://localhost:8080/v1/new-endpoint

Phase 3: Frontend API Client

[ ] Tambah type interface ke lib/api.ts
[ ] Tambah fetch function ke lib/api.ts
[ ] Tambah SWR cache jika perlu
[ ] Test fetch di browser console

Phase 4: Frontend Component

[ ] Buat Svelte component baru atau update existing
[ ] Loading state
[ ] Error state + retry button
[ ] Empty state
[ ] Real data dari API (bukan mock!)
[ ] Responsive mobile
[ ] npm run build → 0 errors

Phase 5: Integration & Page

[ ] Integrasikan component ke page (.astro)
[ ] Hydration strategy yang tepat (client:idle/load/visible)
[ ] Navigasi sidebar jika perlu (Sidebar.svelte)
[ ] E2E test dengan Playwright
[ ] Test di semua browser (Chromium, Firefox, Mobile)

Phase 6: Documentation Update

[ ] Update 00FRAMEWORK.md (jika ada perubahan arsitektur)
[ ] Update TASK_BOARD.md (mark task DONE)
[ ] Update CHANGELOG.md (tambah entry)
[ ] Update inventory endpoint di 00FRAMEWORK.md
[ ] Update QUICK_STATUS jika stage berubah

📝 Template: Implementasi Fitur Baru

Template Rencana (tulis ini dulu sebelum koding)

# Feature: [Nama Fitur]

## User Story
Sebagai [trader/analyst/developer], saya ingin [action], 
sehingga [benefit].

## Data Flow
Input:  [apa yang masuk]
Process: [computation yang terjadi]
Output: [apa yang ditampilkan]

## Files yang Akan Dibuat/Dimodifikasi
BACKEND:
- [ ] engine/[name].rs     ← computation baru
- [ ] services/[name].rs   ← service baru
- [ ] routes.rs            ← endpoint baru
- [ ] models.rs            ← tipe baru

FRONTEND:
- [ ] lib/api.ts           ← fetch function
- [ ] components/[name].svelte ← UI component
- [ ] pages/app/[name].astro   ← page baru (jika perlu)

DOCS:
- [ ] TASK_BOARD.md
- [ ] CHANGELOG.md
- [ ] 00FRAMEWORK.md

## API Contract
GET /v1/[endpoint]/{param}
Response: {
  success: bool,
  data: {
    [field]: [type],  // deskripsi
  },
  meta: { computation_time_ms, cache_hit, model_version }
}

## Success Criteria
[ ] curl endpoint → 200 dengan data valid
[ ] Component tampil dengan data real (bukan mock)
[ ] Loading/error/empty state bekerja
[ ] npm run build → 0 errors
[ ] playwright test → PASS
[ ] cargo test → PASS

🧩 Contoh: Implementasi Fitur "Hurst Dashboard Card"

Phase 0: Requirements

User Story: Sebagai trader, saya ingin melihat Hurst Exponent 
untuk asset yang saya pilih, sehingga saya tahu apakah pasar 
sedang trending atau mean-reverting.

Data Flow:
Input:  asset (BTCUSDT), timeframe (D1)
Process: Hurst R/S Analysis dari close prices
Output: { value: 0.67, confidence: [0.61, 0.73], regime: "trending" }

API Contract:
GET /v1/regime/current/BTCUSDT/D1
→ sudah ada! pakai hurst field dari RegimeState

Files:
- [ ] components/dashboard/HurstCard.svelte  (BARU)
- [ ] pages/app/index.astro                  (modifikasi)

Phase 1: Engine (sudah ada)

engine/hurst.rs → compute_hurst_exponent() → sudah selesai!

Phase 2: Endpoint (sudah ada)

GET /v1/regime/current/{asset}/{tf} → sudah include hurst field!

Phase 3: Frontend Type (dari existing)

// Sudah ada di api.ts sebagai bagian RegimeState
export interface RegimeState {
  // ...
  hurst: {
    value: number;
    confidence: [number, number];
    regime: string;  // "trending" | "mean_reverting" | "random"
  };
}

Phase 4: Component Baru

<!-- components/dashboard/HurstCard.svelte -->
<script lang="ts">
  import { fetchRegimeCurrent } from '@/lib/api';

  interface Props {
    asset?: string;
    timeframe?: string;
  }
  let { asset = 'BTCUSDT', timeframe = 'D1' }: Props = $props();
  
  let hurstData = $state<{ value: number; confidence: [number, number]; regime: string } | null>(null);
  let loading = $state(true);
  let error = $state<string | null>(null);
  
  $effect(() => {
    loading = true;
    fetchRegimeCurrent(asset, timeframe)
      .then(r => hurstData = r.hurst)
      .catch(e => error = e.message)
      .finally(() => loading = false);
  });
  
  // Computed: warna berdasarkan regime
  let hurstColor = $derived(
    hurstData?.regime === 'trending' ? 'var(--regime-trending-up)' :
    hurstData?.regime === 'mean_reverting' ? 'var(--regime-trending-down)' :
    'var(--color-muted)'
  );
</script>

{#if loading}
  <div class="card skeleton"></div>
{:else if error}
  <div class="card error">⚠️ {error}</div>
{:else if hurstData}
  <div class="card">
    <h4>Hurst Exponent</h4>
    <p class="value" style="color: {hurstColor}">
      {hurstData.value.toFixed(3)}
    </p>
    <p class="regime">{hurstData.regime}</p>
    <p class="confidence">
      CI: [{hurstData.confidence[0].toFixed(2)}, {hurstData.confidence[1].toFixed(2)}]
    </p>
  </div>
{/if}

<style>
  .card {
    background: var(--color-surface);
    border-radius: var(--radius-lg);
    padding: 1.5rem;
    border: 1px solid var(--color-border);
  }
  .value {
    font-size: 2.5rem;
    font-family: 'Roboto Mono', monospace;
    font-weight: 700;
  }
  .skeleton { 
    height: 160px;
    background: linear-gradient(90deg, var(--color-border) 25%, var(--color-surface) 50%, var(--color-border) 75%);
    background-size: 200% 100%;
    animation: shimmer 1.5s infinite;
  }
  @keyframes shimmer {
    0% { background-position: 200% 0; }
    100% { background-position: -200% 0; }
  }
</style>

⚡ Priority Decision Framework

Saat ada banyak fitur yang bisa diimplementasikan, prioritaskan berdasarkan:

P0 (Implement SEKARANG):
- Fitur yang user tidak bisa pakai produk tanpanya
- Bug yang break core functionality
- Security vulnerabilities

P1 (Implement SEGERA):
- Fitur yang improve experience secara signifikan
- Performance improvements yang terukur
- Fitur yang block P0 fitur lain

P2 (Implement NANTI):
- Nice-to-have improvements
- Experimental features
- Optimizations

Contoh saat ini:
P0: Deploy frontend, Supabase DB setup, SSL/HTTPS
P1: routes.rs refactor, trade cache per-user
P2: ONNX integration, ArcticDB

🔄 Mock → Real API Migration Pattern

Banyak komponen QuantLab masih punya sisa mock data. Pattern migrasi:

<!-- SEBELUM (mock) ❌ -->
<script>
  const MOCK_DATA = { value: 0.67, regime: "trending" };
  let data = MOCK_DATA;
</script>

<!-- SESUDAH (real API) ✅ -->
<script>
  import { fetchRegimeCurrent } from '@/lib/api';
  
  let data = $state(null);
  let loading = $state(true);
  
  $effect(() => {
    fetchRegimeCurrent('BTCUSDT', 'D1')
      .then(r => data = r.hurst)
      .catch(console.error)
      .finally(() => loading = false);
  });
</script>

📊 Fitur Backlog (Berdasarkan Analisis Project)

Fitur yang sudah teridentifikasi dan perlu diimplementasi:

Sudah Ada Engine, Belum Ada UI

Perlu Engine Baru

Missing dari Sidebar tapi Sudah Ada Page

✅ Definition of Done (DoD)

Sebuah fitur dianggap DONE jika:

BACKEND:
✅ cargo test → PASS (termasuk test untuk fitur baru)
✅ cargo clippy -- -D warnings → 0 warnings
✅ curl endpoint → 200 dengan data struktur yang benar
✅ Error handling: 400 untuk bad input, 500 tidak leak internals

FRONTEND:
✅ npm run build → 0 errors
✅ Component render dengan data real dari API
✅ Loading state → Error state → Empty state → Data state, semua bekerja
✅ playwright test → PASS
✅ Mobile responsive 375px

DOCUMENTATION:
✅ TASK_BOARD.md diupdate (task marked DONE)
✅ CHANGELOG.md diupdate dengan entry baru
✅ 00FRAMEWORK.md diupdate jika perlu