Fullend — Full-stack SSOT Orchestrator

Full-stack SSOT Orchestrator — CLI yang memvalidasi konsistensi 5 SSOT sekaligus dan menghasilkan kode.

Repositori GitHub

Retakan dalam vibe coding

Seiring populernya vibe coding, pola-pola mulai terlihat.

Anda meminta AI “buatkan fitur reservasi” dan ia membuatnya. “Tambahkan fitur pembatalan” dan ia menambahkannya. Saat menambahkan fitur kelima, fitur kedua rusak. Anda mengubah skema API tapi frontend tidak diperbarui. Menambahkan kolom di database tapi lapisan layanan tidak mengetahuinya.

Penyebabnya sederhana: AI tidak mampu mengingat seluruh kode.

Maka yang dilakukan orang: menemukan bagian yang rusak dan berkata kepada AI “perbaiki ini juga”. Diperbaiki, tapi bagian lain rusak. “Perbaiki itu juga.” Loop ini berulang. Semakin besar proyek, semakin panjang loop-nya, hingga pada titik tertentu “memulai dari awal lebih cepat”.

Mengapa kode membengkak?

Dalam kode, dua hal bercampur:

Keputusan: apa yang ditampilkan, API mana yang dipanggil, urutan pemrosesan, apa yang disimpan. Wiring: kode yang mengimplementasikan keputusan tersebut dalam framework tertentu.

Misalkan kita membangun sistem reservasi.

Keputusan: "Saat membuat reservasi, cari kamar; jika tidak ada, kembalikan 404; jika ada, buat reservasi"

Satu baris keputusan ini tersebar ke React hooks, Go handlers, query SQL, skema API, dan resource Terraform. Masing-masing dibungkus sintaks framework-nya, ditambah penanganan error dan konversi tipe.

Dari 100.000 baris kode, keputusan hanya 12.500 baris. Sisanya 87.500 baris adalah wiring.

Agen AI memiliki context window yang terbatas. Saat menambahkan fitur kesepuluh, mereka tidak mengingat sembilan fitur sebelumnya karena tidak bisa membaca 100.000 baris sekaligus.

Jika kita memisahkan keputusan saja, jumlahnya 12.500 baris — 55% dari konteks 200K token. Ukuran yang bisa dibaca AI sekaligus.

5 SSOT

Fullend memetakan satu DSL untuk setiap lapisan dari 5 lapisan yang membentuk perangkat lunak. Setiap DSL menjadi sumber kebenaran tunggal (SSOT) untuk lapisan tersebut.

OpenAPI, SQL DDL, dan Terraform adalah standar industri. Untuk antarmuka dan alur layanan, belum ada DSL yang berfungsi sebagai SSOT. Keputusan frontend terkubur dalam React hooks, dan alur layanan tersebar di Go handlers. Karena itu kami merancang STML dan SSaC. Keduanya adalah DSL yang dibuat oleh proyek ini.

specs/
├── frontend/*.html        → STML
├── api/openapi.yaml       → OpenAPI 3.x
├── service/*.go           → SSaC
├── db/*.sql               → SQL DDL + sqlc queries
└── terraform/*.tf         → HCL

specs/ adalah kebenaran. artifacts/ bisa diregenerasi kapan saja.

Validasi individual sudah ada

Alat validasi untuk 3 lapisan sudah tersedia:

• sqlc memeriksa konsistensi DDL dan query.
• Validator OpenAPI memeriksa validitas skema.
• Terraform memeriksa sintaks dan dependensi HCL.

Kami juga membuat validator bawaan untuk STML dan SSaC. SSaC memeriksa konsistensi internal alur layanan, dan STML memeriksa kesesuaian deklarasi UI dengan OpenAPI.

Masing-masing dari 5 lapisan bisa memvalidasi dirinya sendiri. Masalahnya muncul di antara lapisan-lapisan tersebut.

Frontend menampilkan field dengan data-bind="memo", tapi skema respons API tidak memiliki memo. SSaC memanggil @model Reservation.SoftDelete, tapi query sqlc tidak memiliki metode SoftDelete. OpenAPI mendeklarasikan x-sort: [created_at], tapi tabel DDL tidak memiliki indeks pada kolom tersebut.

Alat individual hanya melihat lapisannya sendiri. Retakan antar-lapisan tetap tidak terlihat.

Menyembunyikan struktur

“Tapi bukankah harus belajar 5 DSL?”

Benar. Tapi struktur tidak perlu ditampilkan kepada pengguna.

Jika kita memasukkan tech stack dan aturan SSOT terlebih dahulu ke system prompt agen, pengguna cukup berkata “buatkan fitur reservasi”. Agen secara otomatis menambahkan endpoint di OpenAPI, membuat tabel di DDL, mendeklarasikan alur layanan di SSaC, menggambar antarmuka di STML, dan menjalankan fullend validate untuk memverifikasi konsistensi.

Yang dilihat pengguna hanyalah hasilnya. Struktur adalah sesuatu yang dikonsumsi agen, bukan sesuatu yang harus dipelajari pengguna.

Pengalaman vibe coding tetap sama. Yang berubah adalah tidak ada yang rusak di balik layar.

Peran Fullend

Fullend adalah validator silang. Ia tidak menemukan ulang alat-alat individual. Ia memanggil setiap alat dan memeriksa batas antar-lapisan.

fullend validate specs/

✓ DDL          3 tables, 18 columns
✓ OpenAPI      7 endpoints
✓ SSaC         7 service functions
✓ STML         4 pages, 6 bindings
✓ Cross        0 mismatches

All SSOT sources are consistent.

Jika ada yang gagal:

✓ DDL          3 tables, 18 columns
✓ OpenAPI      7 endpoints
✗ SSaC         CancelReservation
               @model Reservation.SoftDelete — method not found in sqlc queries
✗ Cross        1 mismatch

FAILED: Fix errors before codegen.

Ketika validasi lolos, kode dihasilkan.

fullend gen specs/ artifacts/

sqlc menghasilkan model database, oapi-codegen menghasilkan tipe API, SSaC menghasilkan fungsi layanan, STML menghasilkan komponen React, dan Fullend menghasilkan glue code yang menghubungkan semuanya.

Aturan validasi silang

Nilai inti Fullend ada pada validasi silang.

OpenAPI ↔ DDL

SSaC ↔ DDL

SSaC ↔ OpenAPI

STML ↔ SSaC — Keduanya merujuk operationId OpenAPI yang sama. Ketika validasi keduanya lolos, kesesuaian antara API yang dipanggil frontend dan API yang diproses backend otomatis terjamin.

Dirancang untuk agen

Fullend dirancang untuk agen AI.

Agar agen bisa menulis spec, ia perlu mengetahui 10 tipe sequence SSaC, 12 atribut data-* STML, ekstensi x- OpenAPI, dan aturan pencocokan nama. Untuk itu kami menyediakan manual AI sekitar 350 baris. Cukup dimasukkan sekali ke system prompt agen.

Loop validasi setelah penulisan spec sederhana:

Alur kerja agen:
1. Modifikasi specs/
2. fullend validate specs/
3. Jika ada error → perbaiki SSOT terkait → kembali ke 2
4. Nol error → fullend gen specs/ artifacts/

Tidak perlu memahami keseluruhan sistem. Cukup perbaiki apa yang ditunjuk validate untuk memulihkan konsistensi. Model pintar berhasil sekali coba, model kecil berhasil tiga kali coba. Hasilnya sama.

Ukuran SSOT berdasarkan skala

Berdasarkan konteks 200K token. Hingga SaaS skala menengah, agen bisa membaca seluruh desain sekaligus.

Pemolaan pengecualian

Yang tidak bisa diekspresikan dengan 10 tipe sequence dialihkan ke call. Yang tidak bisa diekspresikan dengan atribut data-* dialihkan ke custom.ts. Jika escape hatch ini melebihi 20% dari total, strukturisasi kehilangan maknanya.

Namun, pengecualian begitu diisolasi menjadi bisa diamati. Ketika banyak proyek distrukturisasi dengan Fullend, pola berulang akan muncul di call dan custom.ts.

10 tipe sequence SSaC tidak dirancang sejak awal. Mereka konvergen menjadi 10 setelah mengamati ratusan kode layanan. Kami berharap prinsip yang sama berulang pada escape hatch. Pola call yang sering muncul menjadi tipe sequence baru, dan pola custom.ts yang sering muncul menjadi atribut data-* baru.

Pengecualian tidak berkurang — struktur tumbuh dari pengecualian.

Perluasan tech stack

Saat ini Fullend terpaku pada Go + React + PostgreSQL + Terraform. Ini disengaja. Pada tahap proof of concept, prioritasnya adalah menembus satu stack secara menyeluruh.

Namun, 3 dari 5 SSOT (OpenAPI, SQL DDL, Terraform) sudah independen dari bahasa pemrograman. 10 tipe sequence SSaC adalah pola yang tidak terikat bahasa — hanya diekspresikan sebagai komentar Go. STML menggunakan atribut HTML5 data-* sehingga independen dari framework.

Perluasan adalah masalah menambahkan backend generasi kode. Logika validasi dan aturan validasi silang tetap tidak berubah.

Hubungan dengan GEUL

5 DSL membentuk SSOT perangkat lunak. SSOT adalah data terstruktur. Data terstruktur adalah graf. Graf bisa dikodekan dalam GEUL.

data-fetch="ListReservations" di STML adalah relasi antar-entitas. @sequence get → @model → @guard → @response di SSaC adalah sequence peristiwa. Definisi endpoint di OpenAPI adalah kontrak. Semuanya adalah struktur semantik yang bisa diekspresikan dengan triple edge, event6 edge, dan entity node di GEUL.

Cara Fullend melakukan validasi silang antar 5 DSL — pencocokan simbolik, pemeriksaan konsistensi tipe, verifikasi integritas referensi — adalah prinsip yang sama dengan verifikasi mekanis dalam stream GEUL.

Lisensi

MIT — GitHub