Apa saja file yang harus disentuh untuk memodifikasi satu fitur? Masukkan satu operationId, dan jawabannya langsung muncul.
Masalah
Dalam aplikasi fullstack, “satu fitur” tidak berada dalam satu file.
Misalnya kita perlu memodifikasi fitur “AcceptProposal”. Fitur ini ada di API spec, ada di service logic, ada di database schema, ada di authorization policy, ada di state transition diagram, ada di pemanggilan fungsi eksternal, ada di test scenario, dan ada di frontend.
Selama ini ada dua cara untuk memahami cakupan keseluruhan ini:
- Jalankan Grep puluhan kali
- Lacak kode secara manual
Keduanya lambat, dan keduanya berpotensi melewatkan sesuatu. Khususnya, melacak referensi yang melewati lapisan — dari API spec ke service, dari service ke DB schema, dari service ke authorization policy — adalah hal yang sulit dilakukan manusia tanpa ada yang terlewat.
Namun jika setiap lapisan sudah saling mereferensikan secara simbolik, cukup mengikuti referensi itu untuk mengungkapkan seluruh cakupan secara otomatis.
Apa Itu Feature Chain
Feature Chain adalah ekstraksi semua node sumber yang terhubung ke satu fitur API (operationId).
Dimulai dari satu operationId sebagai titik awal, Feature Chain mengikuti referensi simbol antar-sumber dan menampilkan semua file beserta nomor baris yang relevan sekaligus. Puluhan kali Grep digantikan oleh satu perintah.
fullend chain AcceptProposal specs/
── Feature Chain: AcceptProposal ──
OpenAPI api/openapi.yaml:296 POST /proposals/{id}/accept
SSaC service/proposal/accept_proposal.ssac:19 @get @empty @auth @state @put @call @post @response
DDL db/gigs.sql:1 CREATE TABLE gigs
DDL db/proposals.sql:1 CREATE TABLE proposals
DDL db/transactions.sql:1 CREATE TABLE transactions
Rego policy/authz.rego:3 resource: gig
StateDiag states/gig.md:7 diagram: gig → AcceptProposal
StateDiag states/proposal.md:6 diagram: proposal → AcceptProposal
FuncSpec func/billing/hold_escrow.go:8 @func billing.HoldEscrow
Gherkin scenario/gig_lifecycle.feature:4 Scenario: Happy Path - Full Gig Lifecycle
Gherkin scenario/gig_lifecycle.feature:42 Scenario: Unauthorized Access
Seluruh struktur satu fitur terlihat dalam satu layar. Lapisan yang tidak terhubung tidak ditampilkan.
Mengapa Ini Bisa Dilakukan
Ini bukan sihir. Ini bisa dilakukan karena sumber-sumbernya sudah saling mereferensikan satu sama lain.
Dalam framework fullend, setiap lapisan SSOT (Single Source of Truth) menunjuk ke lapisan lain secara simbolik:
- SSaC
@get Model.Method→ tabel DDL - SSaC
@auth action resource→ authorization policy Rego - SSaC
@state diagramID→ state diagram Mermaid - SSaC
@call pkg.Func→ implementasi Func Spec - OpenAPI operationId → nama file SSaC
- Gherkin action step → operationId
- STML endpoint → path OpenAPI
Referensi-referensi ini awalnya dirancang untuk crosscheck — alat yang memvalidasi konsistensi antar-SSOT. Karena crosscheck sudah mem-parsing referensi ini, infrastruktur yang sama dapat digunakan kembali sehingga feature chain diekstrak hanya dengan penelusuran graf.
Jalur Penelusuran
Dengan operationId sebagai titik awal, graf referensi terbentang seperti ini:
operationId (titik awal)
├── OpenAPI → path + method
├── SSaC → file fungsi service
│ ├── @get → tabel-tabel DDL
│ ├── @auth → aturan policy Rego
│ ├── @state → transisi stateDiagram Mermaid
│ ├── @call → implementasi Func Spec
│ └── @publish → subscriber antrian
├── Gherkin → scenario-scenario yang mereferensikan operationId
└── STML → file frontend yang mereferensikan endpoint
Setiap cabang hanya mengikuti satu langkah referensi simbol. Penelusurannya lebar, bukan dalam. Semua lapisan tempat satu fitur meninggalkan jejaknya terungkap sepenuhnya.
Apa yang Berubah
Memahami Cakupan Modifikasi
“Apa yang harus diubah untuk memperbaiki fitur ini?”
Untuk menjawab pertanyaan ini kita biasanya membaca kode, menjalankan grep, atau bertanya kepada rekan kerja. Feature Chain menggantikan pertanyaan ini dengan satu perintah. Tidak ada file yang terlewat — selama referensi simboliknya ada.
Modifikasi Kode dengan AI
Hal tersulit saat menyerahkan modifikasi fitur kepada AI adalah “memberitahu cakupan modifikasinya”. AI bisa memodifikasi dengan akurat hanya jika semua file terkait dimasukkan ke dalam context window, namun manusia yang harus menentukan file mana saja yang relevan.
Dengan Feature Chain, ini berbeda. Cukup berikan satu operationId, dan seluruh cakupan modifikasi teridentifikasi secara otomatis. Context yang akan diberikan kepada AI sudah siap tanpa ada yang terlewat.
Code Review
Saat mereview PR, jika ada kecurigaan “kalau fitur ini diubah, seharusnya file itu juga berubah kan?” — tinggal dicocokkan dengan chain untuk langsung memverifikasinya. Ketidaksesuaian antar-lapisan ditangkap oleh struktur, bukan oleh manusia.
Onboarding
Saat developer yang baru bergabung bertanya “Saya ingin tahu AcceptProposal bekerja seperti apa”, cukup tunjukkan satu Feature Chain. Dari API hingga DB, dari authorization policy hingga test scenario — seluruh peta fitur terlihat sekaligus.
Mengapa operationId
Titik awal yang dipilih sangat penting. Feature Chain memilih operationId.
Alasannya sederhana. Dalam aplikasi fullstack, unit fitur adalah API endpoint. Saat pengguna menekan tombol, API dipanggil, API itu menjalankan service logic, membaca DB, memeriksa otorisasi, dan mentransisikan state. operationId adalah titik awal dari seluruh alur ini.
operationId sudah didefinisikan dalam OpenAPI spec dan merupakan nama yang dibagikan ke seluruh tim. Ketika dikatakan “AcceptProposal perlu dimodifikasi”, baik backend developer, frontend developer, maupun QA akan membayangkan hal yang sama. Desain Feature Chain adalah menembus seluruh stack dengan satu nama universal ini.
Prasyarat
Feature Chain memiliki prasyarat agar bisa bekerja:
Sumber-sumber harus saling mereferensikan secara simbolik. Direktif
@get,@auth,@state,@calldalam SSaC harus secara eksplisit menunjuk ke SSOT lain. Jika referensinya implisit — misalnya nama tabel DB hanya ada sebagai string di dalam kode — maka tidak bisa dilacak.Harus lulus crosscheck. Karena Feature Chain mengikuti referensi simbol, referensi yang tidak valid akan menghasilkan hasil yang salah. crosscheck menjamin konsistensi referensi, dan Feature Chain melakukan penelusuran di atasnya.
Inilah mengapa Feature Chain bukan alat serba guna. Tidak bisa diterapkan pada sembarang proyek. Ini hanya bekerja pada proyek yang referensi antar-sumbernya dirancang — seperti fullend, di mana SSOT-nya saling menunjuk satu sama lain secara eksplisit.
Masa Depan: GEUL + SILK
Saat ini Feature Chain bekerja dengan menelusuri setiap parser SSOT secara bergantian. Parser SSaC, DDL, Rego, dan Mermaid masing-masing dipanggil dan hasilnya digabungkan.
Ketika semua SSOT dikonversi ke graf GEUL, Feature Chain akan menjadi query indeks tunggal. Dengan operasi bitwise AND SIDX milik SILK, semua node yang terhubung ke operationId dapat diekstrak dalam satu query.
Dari penelusuran per-parser menjadi query graf. Interface Feature Chain tetap sama, namun internalnya berubah secara fundamental.
Kesimpulan
Dalam aplikasi fullstack, “fitur” tidak berada dalam satu file. Fitur tersebar di berbagai lapisan, dan lapisan-lapisan itu saling mereferensikan. Feature Chain mengikuti referensi ini untuk mengekstrak seluruh cakupan satu fitur secara otomatis.
Masukkan satu operationId, dan dari API spec hingga DB schema, dari authorization policy hingga test scenario — puluhan kali Grep digantikan oleh satu perintah.