Feature Chain — Melacak seluruh stack dengan satu operationId

File apa saja yang harus disentuh untuk memodifikasi satu fitur? Ketik satu operationId, jawabannya muncul.

Masalahnya

Dalam aplikasi full-stack, “satu fitur” tidak hidup dalam satu file.

Misalkan kamu harus memodifikasi fitur bernama “ExecuteWorkflow”. Fitur itu ada di spesifikasi API, di logika service, di skema database, di kebijakan otorisasi, di diagram transisi status, di panggilan fungsi eksternal, di skenario pengujian, dan di komponen frontend.

Secara historis ada dua cara untuk memahami seluruh ruang lingkup ini:

  1. Menjalankan grep puluhan kali
  2. Melacak kode secara manual

Keduanya lambat, dan keduanya selalu melewatkan sesuatu. Terutama referensi lintas lapisan — dari spesifikasi API ke service, dari service ke skema DB, dari service ke kebijakan otorisasi — praktis mustahil dilacak tuntas oleh manusia.

Lebih parah lagi ketika penyuntingan diserahkan ke AI. Pada 200 endpoint, AI tidak lagi mampu memegang konteks penuh. Konteks runtuh, pola melenceng, dan fitur ke-201 jadi 10× lebih mahal daripada ke-21. Inilah tembok yang ditabrak vibe coding.

Namun jika setiap lapisan memiliki sumber yang secara simbolik mereferensikan lapisan lain, cukup ikuti referensi itu — seluruh ruang lingkupnya otomatis terungkap.

Apa itu Feature Chain

Feature Chain adalah himpunan semua node sumber yang terhubung ke satu fitur API (operationId).

Berawal dari satu operationId, ia mengikuti referensi simbolik antar sumber dan mencetak sekaligus semua file dan nomor baris yang terkait. Puluhan grep digantikan dengan satu perintah.

yongol chain ExecuteWorkflow specs/

── Feature Chain: ExecuteWorkflow ──

  OpenAPI    api/openapi.yaml                         POST /workflows/{id}/execute
  SSaC       service/workflow/execute_workflow.ssac   @get @empty @auth @state @call @publish @response
  DDL        db/workflows.sql                         CREATE TABLE workflows
  DDL        db/execution_logs.sql                    CREATE TABLE execution_logs
  Rego       policy/authz.rego                        resource: workflow
  StateDiag  states/workflow.md                       diagram: workflow → ExecuteWorkflow
  FuncSpec   func/billing/check_credits.go            @func billing.CheckCredits
  FuncSpec   func/billing/deduct_credit.go            @func billing.DeductCredit
  FuncSpec   func/worker/process_actions.go           @func worker.ProcessActions
  FuncSpec   func/webhook/deliver.go                  @func webhook.Deliver
  Hurl       tests/scenario-happy-path.hurl           scenario: scenario-happy-path.hurl

Struktur penuh sebuah fitur tampil di satu layar. Lapisan yang tidak terhubung tidak dicetak.

Mengapa ini mungkin

Ini bukan sihir. Mungkin karena sumber-sumber memang sudah saling mereferensi.

Di framework yongol, tiap lapisan SSOT (Single Source of Truth) menunjuk secara simbolik pada lapisan lain:

  • @get Model.Method pada SSaC → tabel DDL
  • @auth action resource pada SSaC → kebijakan otorisasi Rego
  • @state diagramID pada SSaC → diagram status Mermaid
  • @call pkg.Func pada SSaC → implementasi FuncSpec
  • @publish "topic" pada SSaC → fungsi-fungsi yang berlangganan topic yang sama
  • operationId pada OpenAPI → nama file SSaC
  • Skenario Hurl → endpoint OpenAPI
  • apiClient.<op>() pada React TSX → operationId OpenAPI

Referensi ini pada awalnya dirancang untuk yongol validate — tahap yang memvalidasi silang konsistensi 9 SSOT sebelum compile-time. Karena validate sudah memparse mereka, memakai ulang infrastruktur yang sama mengubah ekstraksi feature chain menjadi penelusuran graf.

Jalur penelusuran

Dengan operationId sebagai titik awal, graf referensi terbuka seperti ini:

operationId (titik masuk)
├── OpenAPI → path + method
├── SSaC → file fungsi service
│   ├── @get → tabel DDL
│   ├── @auth → aturan kebijakan Rego
│   ├── @state → transisi Mermaid stateDiagram
│   ├── @call → implementasi FuncSpec
│   └── @publish → pelanggan antrian
├── Hurl → skenario pengujian yang mereferensi operationId
└── React TSX → file frontend yang memanggil endpoint via apiClient

Tiap cabang hanya mengikuti satu langkah referensi simbolik. Ini penelusuran melebar, bukan mendalam. Setiap lapisan tempat sebuah fitur meninggalkan jejak akan muncul.

Apa yang berubah

Menentukan cakupan perubahan

“Untuk mengubah fitur ini, di mana yang harus kusentuh?”

Untuk menjawab itu kita membaca kode, menjalankan grep, bertanya ke rekan. Feature Chain mengganti pertanyaan itu dengan satu perintah. Tidak ada file yang lolos — selama referensi simboliknya ada.

Penyuntingan oleh AI

Yang paling sulit saat mendelegasikan perubahan fitur ke AI adalah “memberi tahu cakupannya”. AI hanya bisa menyunting secara benar saat file-file yang relevan ada di jendela konteksnya, dan manusialah yang harus menentukan mana yang relevan.

Dengan Feature Chain, lain ceritanya. Beri satu operationId, seluruh cakupan teridentifikasi otomatis. Konteks untuk AI disiapkan tanpa ada yang terlewat. Karena 9 SSOT adalah spesifikasi deklaratif — jauh lebih padat daripada kode Go yang dihasilkan — seluruh chain bisa dimasukkan ke jendela konteks dengan ruang tersisa.

Code review

Saat mereview PR, “kalau mereka menyentuh fitur ini, bukankah file itu juga harus berubah?” jadi sepele untuk diverifikasi — cukup bandingkan dengan chain. Ketidaksesuaian antar lapisan ditangkap oleh struktur, bukan oleh orang.

Onboarding

Saat orang yang baru bergabung berkata “saya ingin mengerti cara kerja ExecuteWorkflow”, tinggal tunjukkan Feature Chain-nya. Dari API sampai DB, dari kebijakan otorisasi sampai skenario pengujian — seluruh medan sebuah fitur terlihat dalam satu layar.

Mengapa operationId

Memilih titik awal itu penting. Feature Chain memilih operationId.

Alasannya sederhana. Di aplikasi full-stack, unit sebuah fitur adalah endpoint API. User menekan tombol, API dipanggil, logika service berjalan, DB dibaca, otorisasi diperiksa, transisi status terjadi. Awal dari seluruh alur itu adalah operationId.

operationId sudah didefinisikan di spesifikasi OpenAPI dan merupakan nama yang dibagi seluruh tim. Katakan “kita perlu memodifikasi ExecuteWorkflow” dan engineer backend, engineer frontend, maupun QA memikirkan hal yang sama. Feature Chain dirancang seputar nama universal itu sebagai benang yang menembus seluruh stack.

yongol menyebut ini “operationId adalah batu penjuru (keystone)”. Satu identifier PascalCase mengikat 9 lapisan secara fisik.

Prasyarat

Agar Feature Chain bekerja, ada asumsi:

  1. Sumber harus saling mereferensi secara simbolik. Direktif @get, @auth, @state, @call, @publish di SSaC harus menunjuk secara eksplisit pada SSOT lain. Kalau referensinya implisit — misalnya nama tabel DB yang hanya muncul sebagai string di dalam kode — tidak bisa dilacak.

  2. yongol validate harus lulus. Feature Chain mengikuti referensi simbolik, jadi kalau referensi tidak valid, hasilnya salah. validate menjamin integritas referensi; Feature Chain menelusuri di atasnya.

Itulah sebabnya Feature Chain bukan alat serba guna. Tidak bisa diterapkan ke sembarang proyek. Ia hanya bekerja di proyek yang referensi antar sumbernya dirancang secara eksplisit — struktur seperti yongol, tempat SSOT saling menunjuk satu sama lain secara eksplisit.

Masa depan: GEUL + SILK

Saat ini Feature Chain menelusuri dengan memanggil tiap parser SSOT secara bergiliran. Memanggil parser SSaC, parser DDL, parser Rego, parser Mermaid, parser Hurl, dan parser TSX, lalu menggabungkan hasilnya.

Ketika semua SSOT diterjemahkan menjadi graf GEUL, Feature Chain menjadi satu kueri indeks. Dengan operasi AND bitwise SIDX di SILK, semua node yang terhubung ke operationId dapat diekstrak dalam satu kueri.

Dari penelusuran per-parser ke kueri graf. Antarmuka Feature Chain tetap sama, tetapi bagian dalamnya berubah secara mendasar.

Penutup

Di aplikasi full-stack, “satu fitur” tidak hidup di satu file. Ia membentang di banyak lapisan, dan lapisan-lapisan itu saling mereferensi. Feature Chain mengikuti referensi itu untuk mengekstrak otomatis seluruh cakupan sebuah fitur.

Ketik satu operationId dan kamu dapat semuanya: dari spesifikasi API hingga skema DB, dari kebijakan otorisasi hingga skenario pengujian, dari implementasi fungsi hingga komponen frontend. Puluhan grep digantikan satu perintah. AI mendapat konteks tanpa yang terlewat; manusia mendapat kebebasan di atas rel.

Kode: github.com/park-jun-woo/yongol