delivery-team

delivery-team, takılabilir bir backend (Azure DevOps ya da GitHub) üzerinde iş-öğesi güdümlü, sprint tabanlı otonom bir yazılım-teslim organizasyonudur — gerçek bir tracker'da (Azure Boards + Repos ya da GitHub Issues + Projects + Pull Requests) iş öğelerini planlayan, ayrıştıran, geliştiren, doğrulayan, gözden geçiren ve teslim eden bir rol-ajan ekibi; Product Owner rolünde bir insanla. Bu bir proje-kapsamlı (project-scope) takımdır: teslim ettiği depoya kurulur.

atl install agentteamland/delivery-team

Kurulum, rol-ajanları, seremoni skill'lerini, bilgi paketlerini (knowledge packs) ve her iki backend adaptör paketini (backends/azure/, backends/github/) projenin .claude/ dizinine yerleştirir; ardından /delivery-init, seremonilerin ve orkestrasyon motorunun okuduğu .delivery/ config'ini yazar.

Organizasyon

delivery-team, her biri kendi reflekslerine sahip birer uzman olan rol-ajanlardan oluşur:

Rol	Ne yapar
intake	Ham bir isteği şekillenmiş bir Epic/Feature backlog öğesine ayıklar.
business-analyst	İş analizini yazar — Description'daki ## Problem / Business Value / Scope / Acceptance Criteria / Out of Scope.
technical-analyst	**[Technical Analysis]** sentinel yorumunu yazar — yaklaşım, fizibilite, NFR'ler, bağımlılıklar, önerilen alanlar.
project-manager	Sprint temposunu yürütür — sprint'in birimlerini admit eder, sprint taşıyıcısını damgalar ve review raporunu yazar. Kapasite ve velocity yalnızca scrum modunda.
tech-lead	Feature'ları iş-birimlerine ayrıştırır, her birimin **[Canonical Brief]**'ini yazar, proje wiki'sinin (Architecture/, Conventions/, ADR'ler) sahibidir ve tek review kapısıdır — her PR'ı gözden geçirir ve yeşilse tamamlar (= merge) ve Done'a set eder.
tester	Bağımsız Level-2 doğrulama — niyeti yeniden türetir, doğru yüzeyde test-gate'leri koşar, kanıt ekler, bir verdict yayınlar.
developer	İş-birimi başına spawn edilen, stack'ten bağımsız, dinamik bir worker; etiketli area:<name> bilgi-paketini yükler ve birimi implement eder.

Belirli bir stack için bir software team, jenerik developer'ın yüklediği alan-anahtarlı bilgi paketlerinden (packs/<area>/) ibarettir — M1 "knowledge-as-data" dikişi; böylece bir React ya da .NET ekibi yeni bir ajan olmadan takılır.

Seremoniler

Sprint, her biri doğru rol olarak davranan, senin çağırdığın skill'lerle işler:

/delivery-init      # backend'i (azure | github) + sprint modunu seç, koordinatları + metodolojiyi bağla
/kickoff            # intake + business-analyst Epic/Feature backlog'unu şekillendirir
/refine             # technical-analyst + tech-lead Feature'ları brief'li iş-birimlerine ayrıştırır
/sprint-plan        # project-manager sprint'in birimlerini seçer — kapasiteye göre ya da küme DAG-kapalı tutularak önceliğe göre
/sprint-start       # iş-birimi DAG'ını materialize et → motora devret
/sprint-review      # review sonucu sayfası, sprint kapanışı (+ scrum modunda velocity)
/request            # (her an) proje-ortası istek → triyaj → fizibilite → dürüst PO kapısı → kabul/ertele/ret

Metodoloji kod değil, config'tir: methodology.json (v1'de Scrum) seremonilerin okuduğu tempoyu bildirir — bakımı gereken bir workflow motoru yoktur.

İki sprint modu — scrum ve flow

methodology.json bir mode taşır ve bu alan tam olarak iki şeyi değiştirir. Alan yoksa scrum demektir, yani mevcut bir projenin davranışı ayağının altından kaymaz.

	mode: "scrum"	mode: "flow"
Sprint nedir	bir zaman kutusu — backend'in takviminde tarihli bir aralık, kapasite tavanıyla	aynı sprint, tarihsiz ve kapasite tavanı olmadan
/sprint-plan neye göre admit eder	önceliğe göre, velocity'den türetilen puan bütçesine kadar	önceliğe göre, admit edilen küme DAG-kapalı tutularak — hiçbir türde admit tavanı yok
/sprint-review ne raporlar	gerçekleşen velocity	velocity yok — tamamlanan ile devreden, sprint'in tüm hesabıdır
capacityModel	zorunlu	yok — anahtar tamamen atlanır
Sprint taşıyıcısı	backend'in iterasyon alanı	admit edilen her birimde bir sprint:<n> etiketi

DAG-kapalı (DAG-closed), bir birimin bağımlı olduğu öncüller olmadan asla admit edilmemesi demektir: öncüller ya onunla birlikte içeri alınır ya da zaten tamamlanmıştır. Böylece bir flow sprint'i, yalnızca bugün başlayabilecek birimleri değil, /sprint-start'ın sıralayacağı gerçek bağımlılık kenarlarını taşır — ve ~4–6 eşzamanlılık sınırı, motorun aynı anda kaç birim çalıştıracağını sınırlar; seremoninin kaç birim admit edebileceğini değil.

Geri kalan her şey aynıdır: aynı seremoniler, aynı roller, aynı DAG, aynı promotion kapısı. Sözlük de değişmez — sprint her iki modda da sprint'tir.

Projenin planlama yapılacak istikrarlı bir kapasitesi yoksa flow'u seç — sabit bir periyot üzerinden velocity, anlam taşıması için istikrarlı olması gereken bir şeyin ortalamasıdır ve otonom bir ajanla çalışan tek kişilik bir maintainer'ın böyle bir sayısı yoktur (bir oturum sekiz birim çıkarır, sonraki sıfır). Böyle bir sayısı olan bir ekip scrum'da kalır, hiçbir değişiklik olmadan.

Sprint'i bir etiket taşıdığı için bir flow projesi ne Iteration ne de Story Points board alanına ihtiyaç duyar — bu da GitHub'da gh'nin otomatikleştiremediği tek kurulum adımını ortadan kaldırır (bir Projects v2 Iteration alanı ayarlar arayüzünden elle eklenmek zorundadır). Status ve Priority hâlâ gerekir ve /delivery-init ikisini de senin için oluşturur ya da doğrular.

Motor — atl work dispatch

/sprint-start, seçilen birimleri bir .delivery/plan.json bağımlılık DAG'ına materialize eder, sonra deterministik Go motoru atl work dispatch devralır. Sıfır LLM context tutar ve sıfır Azure çağrısı yapar: hazır birimleri bir eşzamanlılık sınırına kadar admit eder ve her biri için tek bir git worktree'de üç izole claude -p worker'dan oluşan bir pipeline spawn eder —

developer  →  tester  →  tech-lead
(implement    (Level-2     (review → vote →
 + PR aç)      verify)      PR-complete = dev'e merge → Done)

Motor, bir worker'ın temiz çıkışında stage'i ilerletir, tech-lead'in merge'inin dev'e indiğini saf bir git okumasıyla doğrular (worker'ın exit code'una asla güvenmez), worktree'yi geri alır ve DAG'ı doldurur. Stall eden ya da çöken bir worker geri alınıp bir kez retry edilir, sonra mark-blocked olur — bunu /sprint-review'ın backend'e yansıttığı (blocked tag'i ya da label'ı + tanı yorumu) ve temizlediği kalıcı bir rapor. Her worker tracker'a yalnız motorun ona bağladığı şey üzerinden erişir — Azure backend'inde proje-kapsamlı azureDevOps MCP, ya da GitHub backend'inde motorun enjekte ettiği bir GH_TOKEN (config.credential.ref'ten çözümlenir) ile gh CLI — asla operatörün ortam MCP config'i ya da kimlik bilgileri değil.

Backend tek gerçek kaynaktır

Yerel bir veritabanı yoktur. İş-öğeleri geçici yürütme durumudur ve kalıcı-bilgi deposu kalıcı bilgiyi tutar (ATL wiki/journal ayrımının backend'de yaşayan hali: Azure'da proje wiki'si, GitHub'da repo-içi bir docs/ ağacı). Her rol, backend'e tek bir belgelenmiş sağlayıcıdan-bağımsız operasyon-sözleşmesi (knowledge/backend-interface.md) üzerinden erişir; bu, sağlayıcı başına bir adaptör paketiyle bağlanır — backends/azure/adapter.md (azureDevOps MCP: iş-öğeleri için wit_*, PR'lar için repo_*, bilgi için wiki_*, MCP'nin eksik olduğu tek operasyon için, kanıt ekleme, ince bir REST carve-out ile) ya da backends/github/adapter.md (gh CLI: Issues, Projects v2, Pull Requests ve repo-içi docs/ deposu). İçerik makine-bulunabilir sentinel'lerle yerleştirilir: iş analizi Description'da, **[Technical Analysis]** ve **[Canonical Brief]** yorumları her biri tam ilk satırıyla eşleşerek ("en yeni yorum" değil), alan bağlama System.Tags: area:<name> ile.

İşi teslim etmek — iki-branch akışı

İş dev'e entegre olur (tech-lead her birimin PR'ını yeşilde tamamlar — platformun never-merge kuralının kapsamlı istisnası) ve Product Owner onaylanmış bir sprint'i dev'den release'e promote eder — asla sohbette verilen bir onayla değil, atl work promote'un backend'den geri okuyup karşısında merge ettiği, commit'e bağlı bir onay kaydıyla (aşağıdaki kapı; v1 onu GitHub'da bağlar, Azure'da ise eksik okuma bağlanana kadar promote'u bekletir). Review delivery-native'dir: tech-lead adversarial review desenini (evidence gate + refute-to-keep) doğrudan backend'in PR'ı üzerinde koşar — Azure'da repo_* thread'leri ve vote, GitHub'da gh pr comment / gh pr review — /create-pr değil.

Promote kapısı — commit'e bağlı onay

dev → release, geri alınamaz tek adımdır; bu yüzden sohbette verilmez. /sprint-review raporu derler, dev → release promote PR'ını açar (ya da bulur) ve kararı atl work promote'a devreder — backend'den kalıcı bir onay kaydını geri okuyan, onu PR'ın güncel head'iyle karşılaştıran ve yalnız birebir eşleşmede merge eden deterministik bir komut. O PR'ı açmak artık promote etmek değildir — promote etmek onu merge etmektir. v1'de bu kapı yalnız GitHub backend'inde bağlıdır — Azure'da hâlâ neyin eksik olduğu için bu bölümün sonundaki v1'de yalnızca GitHub bloğuna bak.

Bu kontrol seremoni talimatı değil, koddur — ve asıl mesele budur. İlk sürümünde kontrol /sprint-review becerisinin içine yazılmış bir prosedürdü ve gerçek bir koşuda aynı seremoni onu bir turda uygulayıp bir sonraki turda sessizce atladı: sohbette "Approve or Reject?" diye sormaya, yani tasarımın ortadan kaldırdığı kapıya geri döndü. Hatırlanmaya bağlı bir adım er geç hatırlanmaz ve bu sessizce olur. Bu yüzden komut doğrulamayı ve merge'ü tek çağrıda yapar: bir seremoninin kontrolü atlayarak ulaşabileceği ayrı bir merge adımı yoktur; seremoninin işi komutu çalıştırıp verdiği kararı aktarmaya iner.

Onaylamak için Product Owner, promote PR'ına, ilk satırı tam olarak **[Promotion Approval]** olan ve onaylanan commit'i adıyla veren bir yorum ekler:

**[Promotion Approval]**

## Approved Commit
<40 karakterlik küçük harfli hex commit id'si>

## Sprint
Sprint <n> · <iterasyon-adı>

## Decision
APPROVE

(mode: "flow" altında adı verilecek bir iterasyon yoktur, dolayısıyla ## Sprint satırı yalnızca Sprint <n> olur.)

Yalnızca ## Approved Commit taşıyıcıdır — gerisi denetim bağlamıdır. Bunu PR'ın yorum kutusuna yapıştır ya da CLI'dan gönder:

gh pr comment <PR#> --repo <owner>/<repo> --body-file approval.md

PO'nun işi bundan ibarettir. atl work promote ardından PR'ın head'ini ve üzerindeki her kaydı tek çağrıda okur ve yalnız bir kayıt tam olarak o head'i verdiğinde merge eder — SHA'ya sabitlenmiş biçimde (gh pr merge --merge --match-head-commit <onaylanan-commit>), yani head arada oynadıysa merge'ü sağlayıcının kendisi reddeder. Sonuç, sprint'in review sayfasına ## Promotion decision başlığı altında yazılır: onaylanan commit, onaylayan, zaman damgası, PR bağlantısı. Diğer her sonuç bir HOLD'dur — komut sıfırdan farklı bir kodla çıkar, hiçbir şey merge olmaz, hiçbir iş-öğesi durum değiştirmez ve mesaj tam olarak neyi set etmen gerektiğini yazar:

Kapı ne bulur	Ne yapar (reason)
PR'da **[Promotion Approval]** kaydı yok	Bekletir; PR bağlantısını + onaylanacak head commit'i yazar (no-record).
Kayıt var ama ## Approved Commit altında 40-hex id yok	Bekletir; güncel head'i veren yeni bir kayıt ister (unparseable-record).
Kayıt, PR'ın head'i olmayan bir commit'i veriyor	Bekletir — onaylanan durum, teslim edilecek durum değildir (superseded).
Kayıt okunamadı	Bekletir. Doğrulanmamış, onaylanmış değildir (read-failed).
Kayıt eşleşti ama GitHub SHA'ya sabitlenmiş merge'ü reddetti	Bekletir (merge-refused) — kontrol ile merge arasında dev ilerlediği için sağlayıcı reddetti. Hiçbir şey promote edilmedi; yeni head'i onayla.
Üzerinde çalışılacak açık bir dev → release PR'ı yok	Bekletir — önce onu aç (no-open-pr). Zaten promote edilmiş bir sprint de böyle yakınsar: yeniden koşu hiçbir şeyi merge etmez.
Komut backend'e erişemiyor	Bekletir (backend-unbound) — aşağıdaki v1'de yalnızca GitHub bloğuna bak.

HOLD bir ret değildir: hiçbir şey kapatılmaz, hiçbir şeye carryover etiketi konmaz ve kayıt olduğu yerde bırakılır. Açık bir ret sohbette kalır ve mevcut carryover yolunu işletir — kapı yalnız geri alınamaz yönü korur; bir promote'u geri çevirmek fazladan bir şey teslim edemez.

dev, onaydan sonra ilerlediyse onay da onunla birlikte geçersizleşir. Kapı onaylanan commit'i ve güncel head'i bildirir ve onayı ileriye taşımaz. Güncel durumu promote etmek için tazelenmiş raporu yeniden oku ve yeni head için yeni bir kayıt ekle; tam olarak onayladığın şeyi promote etmek için önce dev'i o commit'e geri al. Eski kayıt denetim tarihçesi olarak yerinde kalır — kanal ekle-ve-geçersiz-kıl (append-and-supersede) biçiminde çalışır ve yeni kayıt, daha yeni bir commit'i vererek eskisinin yerini alır.

İki sınır, açıkça:

Kontrol edilebilir, taklit edilemez değil. Etkileşimli bir oturumda seremoni PO'nun kendi kimlik bilgisini taşır; dolayısıyla bir yazar kontrolü, seremoninin yazdığı bir kaydı PO'nun yazdığından ayırt edemez. Kapının kazandırdığı şey şudur: bir promote artık commit-kapsamlıdır (gözden geçirilen durumdan daha yenisini sessizce teslim edemez) ve atfedilebilirdir (bir commit, bir yazar ve bir zaman damgası veren kalıcı bir kayıt) — bu bir doğruluk kapısıdır, bir kimlik doğrulama kapısı değil.

v1'de yalnızca GitHub — ve sebebi veri değil, taşıma katmanı. Azure'da kapının her iki okuması da adapter'da bağlıdır: onay kaydı PR thread'leri üzerinden, head commit ise branch okuması (repo_branch, action: "get") üzerinden — yanıt onu objectId alanında taşır ve bu, canlı bir sunucuya karşı çözümlendiği için yazılıdır. Ne var ki bunlar yalnızca bir LLM turundan çağrılabilen MCP araçlarıdır ve atl work promote, MCP istemcisi olmayan bir Go ikilisidir. İki okumadan hiçbirini yapamaz; dolayısıyla commit'e bağlı kapı Azure backend'inde henüz çalışmıyor.

Bu bir HOLD'dur, bir geri-dönüş (fallback) değil — komutun yapamadığı bir okuma, okuma hatasıdır: Azure'da /sprint-review raporu derler, promote PR'ını açar (ya da bulur) ve sonra bekletir; atl work promote backend-unbound bildirir, hiçbir Azure yüzeyini çağırmaz ve hiçbir şeyi merge etmez. Sohbette verilen bir onayla promote etmeye geri dönmez; seremoni head'i kendisi okuyup ona göre promote de etmez — çağıranın verdiği bir head, çağıranın yanlış verebileceği bir head'dir ve bu, tam olarak yerine geçilen düzyazı kapısıdır. Bir taşıma katmanı çıkana kadar bu sürümdeki bir Azure projesi, promote'u o PR'ı Azure DevOps üzerinde kendisi tamamlayarak yapar. Deterministik bir Go kapısının Azure'a nasıl erişeceğine karar vermek — attachment carve-out'u gibi takıma ait bir REST yardımcısı mı, yoksa atl içinde bir Azure istemcisi mi — adı konmuş bir sonraki adımdır ve bir arama değil, açık bir tasarım kararıdır.

Neler geliyor

Tam rol-ajan organizasyonu, altı seremoni skill'i, atl work dispatch motoru, Azure DevOps ve GitHub adaptör paketleriyle sağlayıcıdan-bağımsız backend arayüzü, bir Scrum methodology.json'ı ve dört-alanlı bir referans paketi (web / mobile / api / go-cli). Otonom developer→tester→tech-lead döngüsü, canlı bir Azure DevOps projesine karşı uçtan uca kanıtlanmıştır.

Ertelenenler (tasarım yakalandı, tetik-kapılı): Scrum ötesi çoklu-metodoloji desteği, jenerik developer'ın stack-özel override'ı, dinamik-kapasite eşzamanlılığı, bir hotfix akışı ve device-farm emulator'ları. mobile-emulator test hattı yapıldı ama canlı doğrulaması bir masaüstü (GUI) oturumuna kapılı.

Ayrıca bakın

• atl install — bir takımın nasıl çözümlenip kurulduğu
• Takımlar — katalog ve ilk-parti yeniden inşa
• Kavramlar: scope — proje vs. global takımlar