CS 319 · buku: pangmandorin.kamil.web.id
EN ↗

CS 319 · Pertemuan 4 dari 10

Pipeline
dan Enam Dokumen

Spec-driven development sebagai pipeline bergerbang — dan deliverable khas sang mandor.

Agenda · 100 menit

  1. SDD: Specify → Plan → Tasks → Implement (25')
  2. Enam dokumen dan referensi-silangnya (25')
  3. Studi kasus: output sesi dewan Kirana (10')
  4. Sprint dokumen: dua draf satu jam (25') · briefing A4 (15')

Bacaan: bab 8–9

Konsep inti · bab 8

Pipeline bergerbang empat fase

SPECIFY
→ spec.md
→
PLAN
→ plan.md
→
TASKS
→ tasks.md
→
IMPLEMENT
→ kode+PR

tiap panah adalah artefak markdown · tiap gerbang adalah keputusan manusia (GitHub Spec Kit · BMAD · konsensus lapangan)

Pekerjaan manusia di tiap gerbang

Verifikasi dan kritik — bukan persetujuan pasif. Tanyakan: apa yang terlewat fase ini? Apa yang ambigu? Apa yang akan saya test?

Fase yang dilewati tim

Specify. Terasa lambat, dan melewatinya terasa efisien — sampai Plan mengarang requirement dan Implement mengirimnya dengan penuh keyakinan.

Konsep inti · bab 9

Enam dokumen

1 · PRD

Apa dan mengapa, untuk manusia. Satu-satunya dokumen yang dibaca stakeholder sampai tuntas.

2 · Arsitektur Sistem

Service, batasan, aliran data. Tempat debat dewan hidup.

3 · Kontrak API

Endpoint, skema, error. Dokumen paling penopang — lewatkan ini dan semua tim hilir patah.

4 · Skema Database

Tabel, migrasi, constraint. Perubahan merambat ke API + task.

5 · Struktur UI

Layar, state, kasus kosong/error. Yang benar-benar dialami pengguna.

6 · Task Breakdown

Item kerja terurut berukuran-agen tempat semua di atas dikompilasi.

Referensi-silang: skema berubah → kontrak API berubah → task berubah. Enam dokumen adalah satu artefak dengan enam tampilan. Mereka adalah bukti dewan sudah melakukan tugasnya.

Contoh · satu fitur, enam tampilan (ringkas)

CekFaktur: "API refund" — 1 jam per dokumen

PRD          merchant bisa mengajukan refund invoice terbayar ≤ 30 hari
ARSITEKTUR   service baru refunds, bicara ke invoicing + payments, async via queue
API          POST /refunds · GET /refunds/{id} · webhook refund.status_changed
             400 bad_request · 409 already_refunded · 422 window_expired
SKEMA        refunds(id, invoice_id, amount, status[pending|approved|paid|rejected],
             reason, created_at)  + status_history(refund_id, from, to, at, actor)
UI           RequestRefundScreen: nominal terisi, validasi ≤ live,
             state: idle / confirming / submitted / done | error(window)
TASKS        1 migrasi  2 core service  3 endpoint  4 webhook  5 UI  6 test e2e

Enam puluh menit total, oleh satu mandor + dewan. Tidak sempurna — referensi-silang dan jujur. Perhatikan error API (409, 422) sudah meng-encode aturan 30 hari dari PRD.

Mode kegagalan · bab 9

Dokumen mana yang kalau hilang paling banyak merusak hilir?

Jalankan eksperimen pikiran dampak-perubahan: hapus tiap dokumen malam sebelum implementasi.

  • Tanpa PRD → agen membangun hal yang salah dengan indah. Satu sprint terbuang.
  • Tanpa arsitektur → service dikarang dadakan. Perih, tapi bisa direfactor.
  • Tanpa kontrak API → tiap produsen dan konsumen menebak antarmuka yang berbeda. Integrasi adalah tempat tebakan bertabrakan — yang satu ini meracuni lima dokumen lainnya.
  • Tanpa task → pekerjaan jalan, tapi urutan dan ukurannya salah.

Aturan: kontrak adalah dokumen yang tak pernah Anda lewatkan. Ia juga yang bisa dicek secara mekanis oleh verifier Anda (validasi skema).

Studi kasus · bagian 4 dari 10

Sesi dewan pertama Kirana — output, bukan perasaan

Menjalankan alur kerja lengkap (Describe → Council Debates → Consensus → Execute) pertama kali untuk fitur refund. Dewan beranggotakan empat (PM, Arsitek, Backend, Data) menghasilkan enam dokumen dalam satu sesi malam.

Lalu verifier membuktikan nilainya: skema spesialis Data memakai amount integer rupiah; kontrak lead Backend bilang desimal. Cek skema deterministik menangkapnya — ketidakcocokan yang akan muncul sebagai bug pembulatan produksi di kolom mata uang. Nol perasaan terlibat.

Kutipan retro: "Dokumen-dokumennya berdebat sehingga kami tidak perlu."

Sprint dokumen · 25 menit · di kelas

Dua draf satu jam, sungguhan

Fitur Anda

"Group-split: bagi satu invoice ke beberapa pembayar."

Langkah

  1. Pilih dua dari enam dokumen. Pilih dengan sengaja — mana dua yang paling berisiko untuk fitur ini?
  2. Draf masing-masing ≤10 menit dengan bantuan agen. Anda mandornya: Anda meninjau, ia mengetik.
  3. Tukar dengan tetangga: temukan satu lubang referensi-silang (fakta yang satu dokumen sebut dan dokumen lain kontradiksi/abaikan).

Debrief: siapa yang memilih kontrak API? Pertahankan dua pilihan Anda masing-masing satu kalimat.

Tugas A4 · dikumpulkan sebelum Pertemuan 5

Enam draf satu jam, ide Anda sendiri

Tugas
Ambil ide greenfield (project sampingan, alat organisasi mahasiswa, atau kembangkan Kirana). Hasilkan keenam dokumen — satu jam masing-masing, batas keras. Agen boleh mengetik; Anda meninjau tiap baris.

Deliverable
Enam dokumen (boleh pendek — wajib referensi-silang) · peta referensi-silang (dokumen mana berubah saat tiap dokumen lain berubah) · hole-hunt: satu kontradiksi ditemukan dan diperbaiki, terdokumentasi.

Rubrik
Integritas referensi-silang 40% · ketelitian kontrak API 25% · kejujuran log waktu 15% · hole-hunt 20%.

Berikutnya: pola orkestrasi dan disiplin verifier — bagaimana loop tahu kapan berhenti. Baca bab 10–11.