Lewati ke konten utama

Delivery Foundry: Loop Pengiriman Perangkat Lunak Otonom

Ringkasan proyek Delivery Foundry — foundry dual-track untuk otonomi venture personal dan engineering 10x organisasi, dibangun di atas kernel terkelola bersama.

5 menit baca·Menengah·Konsep·25 Agu 2026
projectai systemsautonomous systems

Delivery Foundry: Loop Pengiriman Perangkat Lunak Otonom

Apa yang Dibangun​

Delivery Foundry mengemas arsitektur V12 untuk pengiriman perangkat lunak berbasis loop: berikan PLAN.md, mockup, atau pernyataan misi — sistem berloop build → verify → deploy → observe → improve sampai pekerjaan selesai secara jujur atau terbukti terblokir.

Repositori publik (dibuat 2026-07-20) berisi:

  • Arsitektur normatif — indeks master docs/foundry/delivery_foundry.md plus kontrak modular di docs/foundry/docs/ (architecture, workflows, autonomy, security, operations)
  • Roadmap implementasi — 83 task bernomor berurutan di docs/PLAN.md dengan artikel konstitusi C1–C22
  • Task 1–22 selesai (2026-07-25) — via PR #1: agent harness, plan runner otonom, workflow kernel Temporal, CLI/daemon, fitness suite, migrasi, profiles, dan policy compiler v1
  • Task 156–161 selesai (2026-08-08) — via PR #14: store config operator berbasis Postgres (operatorcfg.Store), policy/kuota/model versi, jalur load katalog packaging DB, dan -pg-dsn pada perintah foundry catalog
  • Task 162–164 parsial (2026-08-10, diperbarui 2026-08-11) — via PR #15 dan commit cdc80eb: loop input unattended dengan AutonomyPolicy, transport inputrouter, kernel InputRouteWorkflow, API mission brief, dan CI loop-proof terlindungi; lapisan executor CLI PARTIAL PASS (receipt live Path A/B tercapture 2026-08-11); loop Temporal+PG penuh dengan receipt SCM/billing/deploy masih pending per evidence gate sumber
  • Shared Kernel Proof (exit M0) — demo end-to-end membuktikan admit → worktree → verify → bukti → restart checkpoint

Task 23–155 dan 165–83 (integrasi OPA, rantai provenance penuh, track venture dan 10x) masih terbuka; halaman ini melacak evolusi proyek sebagaimana didokumentasikan di sumber.

Masalah​

Tim engineering ingin agen AI mengirim perangkat lunak secara otonom — dari sketsa mockup ke produk terdeploy, atau dari rencana disetujui ke commit terverifikasi di branch bersama. Dua konteks membutuhkan tata kelola berbeda:

  • Builder solo menginginkan otonomi terbatas: discover, build, deploy, amati revenue, dan self-improve di dalam envelope eksplisit dengan touchpoint minimal.
  • Organisasi menginginkan kontrol lebih ketat: rencana terverifikasi provenance, eksekusi multi-repositori, dan handoff ke workflow branch 10x yang ada tanpa kepercayaan implisit pada agen.

Keduanya membutuhkan kernel tahan lama yang sama — state, bukti, recovery, kebijakan — bukan dua stack orchestration terpisah.

Ringkasan Arsitektur​

Track A menerima misi (contoh terdokumentasi: capai net monthly recurring revenue terverifikasi), menjalankan venture loop dengan verifikasi sintetis dan self-adaptation terbatas, serta menggunakan tier admission A0/A1/A2/H plus Mission Setup Ceremony sebelum operasi tanpa pengawasan.

Track B menerima file PLAN.md disetujui manusia, mengeksekusi di satu atau banyak repositori, dan dapat berhenti di TEN_X_BRANCH_HANDOFF_READY — grup atomik terverifikasi di branch 10x bersama tanpa PR, merge, atau deployment dalam workflow itu.

Evolusi dan Milestone​

MilestoneApa yang dibuktikan / dikirim
Set dokumen V12Kontrak normatif modular; konten V11 dipertahankan via migration map
Task 1 (✅ 2026-07-20)Toolchain dev Docker, CI, scaffold paket Go, fitness v0
Task 2–22 (✅ 2026-07-25, PR #1)Agent harness (.ai/), plan runner, kernel Temporal, CLI/daemon, SKP e2e, migrasi + policy compiler
Task 156–161 (✅ 2026-08-08, PR #14)SoT config operator-hot Postgres: operatorcfg.Store, policy/kuota/katalog versi, foundry catalog berbasis DB
Task 162–164 (⚠️ parsial 2026-08-10, receipt CLI 2026-08-11, PR #15 + cdc80eb)Loop input M9 unattended: AutonomyPolicy, InputRouteWorkflow, CI loop-proof; receipt executor CLI tercapture; e2e Temporal penuh masih pending
M0 — Shared Kernel Proof (✅)Admit satu rencana → worktree → verify → bukti → lanjut setelah restart
M1 — Foundation (parsial)Task 20–22 selesai; OPA PDP, rantai provenance penuh, ledger (Task 23–26) pending
Venture MLS (Track A)Misi → produk deployable → observasi billing → satu siklus perbaikan terbatas
10x MLS (Track B)Rencana disetujui → provenance → grup atomik → push branch 10x langsung
Venture mission-capablePerbaikan otonom dalam envelope drift governance
10x org-productionOrkestrasi multi-repo dengan integrasi organisasi

Estimasi roadmap dan asumsi builder didokumentasikan secara jujur di docs/architecture/overview.md — rentang dengan tingkat keyakinan, bukan presisi palsu.

Keputusan Kunci​

KeputusanAlasan
Dua track, satu kernelMenghindari serialisasi otonomi venture di belakang milestone org
Mockup sebagai entry kelas satudocs/workflows/mockup-to-delivery.md dengan label Observed/Inferred/Assumed
Rename PEC dari "Forge"Menghindari bentrok dengan Atlassian Forge; kernel mempertahankan otoritas
Persyaratan host hanya DockerDocker + GNU make; tanpa instal Go/Node/Playwright lokal
Task gated konstitusiSetiap task rencana dicek terhadap C1–C22; make fitness di exit milestone
Autonomous plan runner (Task 3)Orchestrator AUTO/GATED ber-tier risiko; alat bootstrap pensiun setelah kernel admit backlog
Agent harness multi-provider (Task 2)Sumber canonical ARES .ai/ dikomposisi ke Claude/Codex; sebelas skill untuk enam peran
Constitution fitness (Task 18)fitlint menegakkan aturan enum C1, batas import, dan doc link di CI
Empat lineage image containerAturan anti-sprawl: dev, postgres/temporal, executor sandbox, release binary
Postgres operator config SoT (Task 156–161)Policy, kuota, tarif model, dan katalog packaging berbagi satu store versi; YAML disk seed sekali saat boot daemon
Loop input unattended (Task 162–164)Semua transport IDEA/MOCKUP/brief melewati input router persisten + workflow kernel di bawah AutonomyPolicy eksplisit; receipt executor CLI PARTIAL PASS (2026-08-11); bukti Temporal+deploy penuh masih pending

Tipe Entry dan Workflow​

Semua entry konvergen ke admission deterministik, lalu loop delivery standar:

Tipe entryDokumen workflow tipikal
PLAN.md disetujuidocs/workflows/direct-plan.md
Mockup atau sketsadocs/workflows/mockup-to-delivery.md
Pernyataan misidocs/workflows/venture-loop.md
Rencana org multi-repodocs/workflows/multi-repository.md
Branch bersama 10xdocs/workflows/ten-x-branch.md

Semantik recovery, retry, dan penyelesaian jujur ada di docs/workflows/recovery.md.

Layout Repositori (saat ini)​

docs/foundry/delivery_foundry.md   indeks arsitektur master
docs/PLAN.md                       rencana 83 task (Task 1–22 ✅)
docs/architecture.md               konstitusi satu halaman + peta link
.ai/                               agent harness canonical (format ARES)
AGENTS.md / CLAUDE.md              tampilan provider terkomposisi (jangan edit manual)
cmd/foundry/                       CLI operator
cmd/foundryd/                      worker kernel Temporal
cmd/fitlint/                       linter konstitusi
tools/planrunner/                  orkestrator task otonom bootstrap
deploy/                            toolchain dev Docker + compose postgres/temporal
internal/                          paket Go (kernel, state, admission, evidence, operatorcfg, inputrouter, autonomypolicy, …)
scripts/fitness.sh                 suite pemeriksaan konstitusi
scripts/loop_proof.sh              gate bukti loop unattended terlindungi
scripts/loop_proof_cli.sh          bukti receipt executor CLI host-only (Claude CLI berlangganan)
Makefile                           target dibungkus docker

Pelajaran​

  1. Dokumentasikan otoritas sebelum kode — V12 memindahkan prosa V11 ke kontrak modular sehingga agen implementasi hanya menerima bagian normatif yang relevan.
  2. Estimasi roadmap jujur — Scope dual-track meningkatkan total effort; arsitektur menyatakan ini secara eksplisit alih-alih menyembunyikannya di balik estimasi single-track.
  3. Bootstrap lalu kernel — Task 1–3 membutuhkan trigger manual atau runner; PR #1 mengirim runner dan workflow kernel pertama sehingga task berikutnya dapat dogfood Foundry.
  4. Fitness function memperoleh skor desain — Spesifikasi menargetkan desain kualitas 10/10 tetapi menyatakan skor diperoleh hanya saat fault-injection, keamanan, dan tes SLO lulus.
  5. Karantina legacy — docs/legacy/ ditandai sebagai riwayat superseded dan tidak boleh diberikan ke agen implementasi.

Terkait​

Sumber​