DEV-WEB Situs edukasi

Bagaimana sistem ini disusun

Keputusan struktural yang menopang semua hal lain, dijelaskan berurutan.

Ringkas dulu

Apa ini?
Peta bagaimana DEV-WEB dibagi menjadi ruang kanonik, inti netral framework, dan adapter.
Mengapa penting?
Kalau pembagian ini tidak jelas, materi penjelasan pelan-pelan berubah menjadi aturan, dan aturan yang sesungguhnya ditinggalkan.
Bagaimana cara kerjanya?
Ketergantungan hanya satu arah: adapter boleh bergantung pada inti, inti tidak pernah bergantung pada adapter.
Contoh konkretnya?
Perintah build dan diagnostik khas Astro tinggal di adapter Astro. Kontrak inti tidak boleh diubah supaya mewajibkan Astro.
Berikutnya baca apa?
"Mengadopsi situs yang sudah ada", untuk melihat struktur ini dipakai pada repositori nyata.

Dua ruang, dan alasannya

DEV-WEB memisahkan kernel kanonik yang bersifat privat dari situs edukasi statis ini. Kernel adalah tempat otoritas berada: apa yang diwajibkan, apa yang harus dibuktikan sebuah perubahan, apa yang harus ditunjukkan sebuah rilis. Situs ini adalah presentasi.

Peta di bawah ini menyusun keseluruhannya sebagai lapisan bertumpuk. Bacalah dari atas ke bawah: makin ke bawah, sebuah lapisan makin mengikat, dan makin ke atas ia makin sekadar menjelaskan.

Bagian 1 dari 3

Empat lapisan, dari yang paling longgar ke yang paling mengikat

  1. Lapisan 1 bukan otoritas

    Situs edukasi ini

    Menjelaskan isi ruang kanonik dengan bahasa yang bisa dipahami pemula. Halaman yang enak dibaca tidak pernah menggantikan aturan yang ditegakkan.

  2. Lapisan 2 lokal, tidak mengikat proyek lain

    Adapter dan penerapan lokal

    Tempat kenyataan khas satu framework boleh tinggal: perintah build, diagnostik, dan konvensi keluarannya. Astro adalah Reference Adapter #1, sebuah contoh yang dinomori.

Batas otoritas Lapisan atas boleh bergantung pada lapisan bawah dan menjelaskannya. Arah sebaliknya tidak pernah berlaku.

  1. Lapisan 3 otoritas

    Kontrak dan skema

    Bentuk yang bisa diperiksa mesin: urutan adopsi, perutean kapabilitas, dan wujud bukti yang sah. Di sinilah aturan berhenti menjadi niat baik.

  2. Lapisan 4 otoritas, privat

    Kernel inti

    Dasar semua hal di atasnya: siklus hidup, kelas perubahan, aturan verifikasi, dan semantik rilis. Netral terhadap framework mana pun.

Bagian 2 dari 3

Pekerjaan sekecil apa pun melewati tiga tahap yang sama

  1. Memahami DISCOVER · DEFINE · DESIGN Keadaan dibaca dulu, hasil dan batasnya ditetapkan, bentuk perubahannya dirancang.
  2. Mengerjakan BUILD · VERIFY · RELEASE Perubahan dikerjakan dalam batas yang sudah disepakati, dibuktikan, lalu dilepas.
  3. Merawat OBSERVE · HARDEN · GROW Perilaku nyata diamati, kelemahan ditutup, kemampuan baru ditumpuk di atas dasar yang sudah terbukti.

Rincian sembilan fase beserta artinya ada pada diagram siklus hidup di bagian berikutnya pada halaman ini.

Bagian 3 dari 3

Dua gerbang yang tidak boleh dilewati begitu saja

  • Memilih kapabilitas

    izin terpisah

    Mengaktifkan alat atau runtime

    Memilih kapabilitas hanya menetapkan keahlian apa yang relevan untuk sebuah tugas. Menyalakan alat atau runtime adalah keputusan tersendiri dan tidak pernah ikut secara otomatis.

  • Bukti secukupnya

    tanpa bukti, tidak lewat

    Rilis beserta jalan pulang

    Besar pembuktian mengikuti besar dampak perubahan. Sebuah rilis wajib menyebut artefak yang persis dan menyiapkan titik pulih sebelum apa pun disentuh.

Ketinggian pada gambar ini hanya menandai jarak dari otoritas: makin ke bawah makin mengikat, makin ke atas makin sekadar menjelaskan. Seluruh keterangan tetap berupa teks, sehingga peta ini utuh dibaca tanpa gerak, tanpa tetikus, dan tanpa gaya visual sekalipun.

Alasan pemisahan ini lahir dari pola kegagalan, bukan dari selera. Ketika materi penjelasan diizinkan membawa otoritas, versi yang mudah dibaca dan versi yang ditegakkan perlahan berbeda, lalu orang mengikuti yang mudah dibaca.

Inti yang netral terhadap framework

Inti bersifat framework-agnostic dan tidak menyebut framework wajib. Ia menjelaskan siklus hidup, kelas perubahan, harapan verifikasi, urutan adopsi, dan semantik rilis dalam istilah yang tetap berlaku baik situs dirender statis, dirender di server, atau campuran keduanya.

Memahami

  1. DISCOVER Memahami keadaan yang sebenarnya sebelum menyentuh apa pun.
  2. DEFINE Menetapkan hasil yang dituju dan batasnya.
  3. DESIGN Merancang bentuk perubahan sebelum menulis kode.

Mengerjakan

  1. BUILD Mengerjakan perubahan dalam ruang lingkup yang sudah dibatasi.
  2. VERIFY Membuktikan perubahan bekerja, sebanding dengan risikonya.
  3. RELEASE Melepas ke publik dengan titik pulih yang sudah disiapkan.

Merawat

  1. OBSERVE Melihat perilaku nyata setelah rilis, bukan menganggapnya beres.
  2. HARDEN Menutup kelemahan yang terlihat setelah sistem dipakai.
  3. GROW Menambah kemampuan di atas dasar yang sudah terbukti.
Setiap fase wajib meninggalkan satu keputusan dan buktinya. Urutannya tetap sama untuk pekerjaan sekecil apa pun, yang berbeda hanya kedalaman buktinya.

Inilah yang membuat kernel bisa dipakai ulang lintas repositori yang sama sekali tidak berbagi teknologi.

Adapter dan adapter rujukan

Adapter adalah tempat kenyataan khas satu framework boleh tinggal: perintah build, diagnostik, konvensi keluaran, dan pemeriksaan yang hanya masuk akal untuk teknologi itu.

Adapter dilarang mengubah kontrak inti agar mewajibkan frameworknya sendiri. Arah ketergantungannya satu: adapter boleh bergantung pada inti, inti tidak pernah bergantung pada adapter.

Contoh konkret

Astro adalah Reference Adapter #1 — contoh yang dinomori, bukan yang diistimewakan. Situs ini justru dibangun tanpa Astro, memakai runtime bawaan saja. Kalau intinya benar-benar netral, situs resminya sendiri tidak wajib memakai adapter rujukannya.

Di mana siklus hidup berada

Siklus hidup adalah urusan inti, bukan urusan adapter. Setiap pengadopsi melewati fase yang sama apa pun teknologinya, dan setiap fase diharapkan meninggalkan sebuah keputusan beserta buktinya.

Yang berbeda antar-pengadopsi adalah cara sebuah fase dipenuhi, bukan apakah fase itu terjadi. Perbedaan itulah yang membuat kernel yang sama bisa mengatur repositori yang sangat berbeda tanpa ditulis ulang untuk masing-masing.

Contoh konkret

Fase VERIFY pada situs statis mungkin berarti membangun ulang lalu memeriksa keluarannya; pada aplikasi dengan basis data ia mungkin berarti uji integrasi dan migrasi percobaan. Fasenya sama, isinya berbeda, dan yang diminta kernel tetap sama: sebuah keputusan beserta buktinya.

Sumber kanonik yang dijelaskan halaman ini

Halaman ini menjelaskan berkas-berkas berikut. Kalau isinya berbeda, berkas itu yang berlaku — bukan tulisan di sini.

  • adapters/astro/reference-adapter.json
  • docs/governance/2026-08-30-DEV-WEB-EXECUTION-GOVERNANCE.md
  • docs/product/DEV-WEB-PRODUCT-REQUIREMENTS.md
  • kernel/core/foundation.contract.json

Lanjutkan ke