Biletler ve devretme

Bilet, Control Center’ın izlediği iş birimidir. Bilinçli olarak aptal bir yapıdır: bir başlık, bir gövde, bir durum, bir sahip ve bir ağaçtaki konum. Ajanların üzerinde yürüttüğü şey değildir — ajan işi konuşmalarda yaşar ve bir çalıştırmanın yapılandırılmış çıktısı çalıştırma günlüğünde bulunur.

Atama sahipliği kaydeder; hiçbir şey göndermez

Bu, biletlerle ilgili doğru anlaşılması gereken en önemli şeydir.

assignedAgentId ayarlamak bir alan yazar ve bir TicketAssigned alan olayı yayımlar. Bu olay bir denetim ve bildirim sinyali ile bir pipeline tetikleyicisidir. Bir ajana atama hiçbir çalıştırma başlatmaz. assignedAgentId’yi izleyip o ajanı uyandıran bir bilet göndericisi yoktur.

İstisna bir ekiptir: assignedTeamId ayarlandığında TeamRoutingService, çalışma protokolü ve kadroyla birlikte ekip liderini gönderir.

Belirli bir ajanın bir bilet üzerinde çalışmasını istiyorsanız, bunu bir konuşmada istersiniz; ya bir pipeline adımı onu gönderir ya da başka bir ajan ona devreder. Bir bileti bir ajana atayıp beklemek, asla iş üretmeyecek tek şeydir.

Ayna ve üst katman

Bir bilet tamamen yerel olabilir ya da harici bir takip sistemi tarafından desteklenebilir ve ikisini de tek bir satırda taşır.

Ayna — sağlayıcı, harici anahtar, URL, başlık, açıklama, öncelik, etiketler, ham ve normalleştirilmiş durum, zaman damgaları — bilet uzaktayken bir önbellektir. Orada doğruluk kaynağı uzak taraftır ve bir yenileme aynayı tümüyle yeniden yazar.

Üst katman — atama, devretme, alan bağlantısı, üst bilet, proje, bağlı PR’lar — yalnızca Control Center’a özgüdür. Takip sistemi bunun hakkında hiçbir şey bilmez ve bir yenileme ona asla dokunmaz.

Bu ayrım, eşitlemeyi baştan güvenli kılan şeydir: bir satıcı çekmesi, üzerine katmanlanan orkestrasyon meta verisini hiç kaybetmeden aynayı yıkıcı biçimde etkileyebilir.

Yaşam döngüsü grafiği sizi değil, ajanları bağlar

Durumlar backlog → open → inProgress → inReview → done şeklinde ilerler; blocked bir yan döngü, failed / cancelled ise diğer terminal durumlardır.

Geçiş grafiği yalnızca ajan ve otomasyon yolunda uygulanır — MCP araçları ve uzlaştırıcılar. Orada geçersiz bir geçiş günlüğe yazılır ve yok sayılır; böylece kafası karışan bir ajan bir bileti bir terminal durumundan geriye doğru çıkaramaz.

Arayüzdeki kullanıcı kaynaklı her değişiklik force: true geçirir ve grafiği tümüyle atlar. Bir insan bir bileti seçicinin listelediği her duruma taşıyabilir — terminal bir durumu yeniden açmak dahil. Seçici failed sunmaz; bunu ajanlar fail_ticket ile ayarlar. Grafik, otomasyon için bir güvenlik korkuluğudur; işin nasıl ilerleyebileceğine dair bir kural değil.

TicketWorkflowService, her değişikliğe tek bir darboğaz üzerinden sahiptir: satırı yükler, çağıranın çalışma alanına ait olduğunu doğrular ve beklenen bir version ile yazar; böylece iki eşzamanlı düzenleme birbirinin üzerine sessizce yazamaz.

Tam durum tablosu, geçişler, alan listesi ve ilişki türleri için Bilet yaşam döngüsü sayfasına bakın.

Köken: bir bilet nasıl oluştu

Her biletin bir originKind değeri vardır. Numaralandırmanın beş değeri vardır — manual, pipelineStep, agentDelegation, externalSync, recovery — ama bugün yalnızca ikisi yazılır: manual (createTicket üzerindeki varsayılan, devredilen alt biletler dahil) ve externalSync (eşitleme motoru, bir satıcı çekmesinde). TicketWorkflowService.createTicket bir köken argümanı almaz; bu yüzden pipelineStep, agentDelegation ve recovery hiçbir zaman bir satıra yazılmaz.

Korumalı devretme

Devretme, bir ajanın başka bir ajan için iş oluşturduğu yerdir ve ayrıcalığın sızabileceği nokta burasıdır; bu yüzden korumalar istem talimatlarında değil, sunucu tarafında bir darboğazda yaşar.

delegate_task, TicketWorkflowService.delegateGuarded üzerinden yönlenir; bu metot alt biletin derinliğini ve kökünü üst zincirden hesaplar ve ardından dört DelegationGuards denetiminin tümünü çalıştırır: 3 derinlik sınırını aşacak bir atlama, zincirde zaten bulunan bir ajana geri atlama (döngü algılama), bir özerklik tavanı (devredilenin alandaki etkin düzeyi, devredenin düzeyini aşmamalıdır) ve bir bütçe zarfı (devretme, devredenin kalan sert durdurma bütçesinden faturalandırır ve daha fazlasını üretemez). Üretim bağlantısı her iki çözümleyici portunu da sağlar. from_agent_id atlandığında özerklik ve bütçe atlanır (sınırsız / ilkesiz bütçe de geçer). Bir ret, iletisi devreden ajana birebir ulaşan bir DelegationRefusedException olarak fırlatılır — yüksek sesli bir ret, asla sessiz bir boş işlem değil.

delegate_ticket daha eski, korumasız kardeştir: doğrudan createTicket çağırır ve tüm korumaları atlar. delegate_task tercih edin.

Devretme derinlik sınırını (3, delegate_task zincirlerinde) yerleşik harness’ın alt ajan iç içe geçme sınırıyla (2) karıştırmayın. Bunlar farklı mekanizmalar üzerindeki farklı sınırlardır.

Hiyerarşi, bağlantılar ve projeler

Üst ve alt issue ilişkileri, setParent / clearParent tarafından yönetilen tickets.parent_ticket_id üzerinde yaşar. Bunlar ticket_links satırları değildir; bu yüzden bir biletin ilişkilerini okuyan her şeyin iki kaynağı da birleştirmesi gerekir.

ticket_links, başka türlü ilgisiz olan biletler arasındaki yönlü kenarları tutar:

Bağlantı türü	Anlamı
blocks	Kaynak, hedefi engeller
relatesTo	İki bilet ilişkilidir (simetrik)
duplicateOf	Kaynak, hedefin kopyasıdır

Bir proje, ortak bir hedefe yönelik çalışma alanı kapsamlı bir bilet gruplamasıdır. Projeler yalnızca Control Center’a özgüdür ve hiçbir zaman harici bir sağlayıcıya eşitlenmez.

İşbirlikçiler

TicketCollaborator satırları, bir bilete birden fazla katılımcının assignee, collaborator ya da reviewer rolüyle bağlanma yoludur. İnsanlar ve ajanlar eşit satırlardır — bir principalId artı bir collaboratorType — “kullanıcı” için bir nöbetçi değer ve iki tablonun hiçbirine yabancı anahtar olmadan.

Harici eşitleme

Control Center’ın bileti birincildir. Bir bileti silmek yalnızca yereldir; bu yüzden sildiğiniz satıcı destekli bir bilet takip sisteminde silinmez ve bir sonraki eşitlemede yeniden görünebilir. İşbirlikçiler ve alt biletler zincirleme silinir.

Adaptör kimlik bilgileri sunucunun kimlik bilgisi depolarından çözülür (Ayarlar’a yapıştırılan bir Linear anahtarı ya da GitHub token’ı bir sonraki istekte alınır; ortam yalnızca bu depoları tohumlar).

Biletler ve pipeline’lar

Hiçbir pipeline düğümü bilet oluşturmaz, tamamlamaz ya da iptal etmez — paletin böyle bir adımı yoktur ve motor TicketWorkflowService çağırmaz. Bir pipeline tetikleyicisi yine de TicketAssigned, TicketCompleted, TicketFailed ya da TicketCancelled üzerinde tetiklenebilir (bu dördü, EventPayloadMapper’ın gerçekte eşlediği bilet olaylarıdır). Bilette bir pipelineRunId sütunu yoktur; pipeline bağlantısı ajan çalıştırma günlüğünde yaşar.

Ayrıca bakınız

• Pipeline’lar ve otomasyon: bilet olayları bir pipeline’ı tetikleyebilir
• Orkestrasyon: alt biletlerden oluşan bir DAG nereden gelir
• Ajan modeli: bir biletin kime atandığı
• Alan olayları: bilet yaşam döngüsü olayları
• Bilet yaşam döngüsü: durumlar, alanlar, geçişler, ilişkiler
• Bilet oluşturma ve yönetme
• İşi ajanlara devretme
• İşleri projelerle düzenleme