Tiket dan perwakilan

Tiket ialah unit kerja yang dijejaki oleh Control Center. Ia sengaja merupakan artifak yang bodoh: tajuk, badan, status, pemilik dan kedudukan dalam pokok. Ia bukan perkara yang dijalankan oleh ejen — kerja ejen hidup dalam perbualan dan output berstruktur sesuatu larian terletak pada log larian.

Penugasan merekod pemilikan; ia tidak menghantar apa-apa

Inilah perkara paling penting yang perlu difahami dengan betul tentang tiket.

Menetapkan assignedAgentId menulis satu medan dan menerbitkan TicketAssigned acara domain. Acara itu ialah isyarat audit dan pemberitahuan serta pencetus pipeline. Penugasan kepada ejen tidak memulakan sebarang larian. Tiada penghantar tiket yang memantau assignedAgentId dan mengejutkan ejen itu.

Pengecualiannya ialah pasukan: apabila assignedTeamId ditetapkan, TeamRoutingService menghantar ketua pasukan dengan protokol operasi dan senarai ahli.

Jika anda mahu ejen tertentu mengerjakan sesuatu tiket, anda memintanya dalam perbualan, atau satu langkah pipeline menghantarnya, atau ejen lain mewakilkan kepadanya. Menugaskan tiket kepada ejen dan menunggu ialah satu-satunya perkara yang tidak akan pernah menghasilkan kerja.

Cermin dan tindanan

Tiket boleh bersifat tempatan semata-mata atau disandarkan oleh penjejak luar, dan ia membawa kedua-duanya pada satu baris.

Cermin — penyedia, kunci luar, URL, tajuk, perihalan, keutamaan, label, status mentah dan ternormal, cap masa — ialah cache apabila tiket itu jauh. Sistem jauh ialah sumber kebenaran di situ dan penyegaran menulis semula cermin itu sepenuhnya.

Tindanan — penugasan, perwakilan, pautan ruang, induk, projek, PR yang dipautkan — hanya wujud dalam Control Center. Penjejak tidak tahu apa-apa tentangnya dan penyegaran tidak pernah menyentuhnya.

Pemisahan itulah yang membolehkan penyegerakan dilakukan dengan selamat: tarikan vendor boleh merosakkan cermin tanpa sekali pun kehilangan metadata orkestrasi yang bertindan di atasnya.

Graf kitaran hayat mengikat ejen, bukan anda

Status berjalan backlog → open → inProgress → inReview → done, dengan blocked sebagai gelung sisi dan failed / cancelled sebagai keadaan terminal yang lain.

Graf peralihan dikuatkuasakan hanya pada laluan ejen dan automasi — alat MCP dan penyelaras. Peralihan tidak sah di situ dilog dan diabaikan, jadi ejen yang keliru tidak boleh memundurkan tiket keluar daripada keadaan terminal.

Setiap perubahan yang dipacu pengguna dalam UI menghantar force: true dan melangkau graf itu sepenuhnya. Manusia boleh memindahkan tiket ke mana-mana status yang disenaraikan oleh pemilih — termasuk membuka semula tiket yang berada dalam keadaan terminal. Pemilih tidak menawarkan failed; ejen menetapkannya melalui fail_ticket. Graf itu ialah guardrail untuk automasi, bukan peraturan tentang cara kerja dibenarkan berjalan.

TicketWorkflowService memiliki setiap mutasi melalui satu titik kawalan tunggal yang memuatkan baris itu, mengesahkan ia milik ruang kerja pemanggil dan menulis dengan version yang dijangka supaya dua suntingan serentak tidak boleh menimpa satu sama lain secara senyap.

Untuk jadual status penuh, peralihan, senarai medan dan jenis hubungan, lihat Kitaran hayat tiket.

Asal usul: bagaimana sesuatu tiket wujud

Setiap tiket mempunyai originKind. Enum itu mempunyai lima nilai — manual, pipelineStep, agentDelegation, externalSync, recovery — tetapi hanya dua yang ditulis hari ini: manual (lalai pada createTicket, termasuk anak yang diwakilkan) dan externalSync (enjin penyegerakan, pada tarikan vendor). TicketWorkflowService.createTicket tidak menerima argumen origin, jadi pipelineStep, agentDelegation dan recovery tidak pernah sampai ke sesuatu baris.

Perwakilan yang dikawal

Perwakilan ialah tempat ejen mencipta kerja untuk ejen lain dan di situlah keistimewaan boleh bocor, jadi guardrail itu terletak di sebelah pelayan pada satu titik kawalan dan bukan dalam arahan prompt.

delegate_task melalui TicketWorkflowService.delegateGuarded, yang mengira kedalaman dan akar anak itu daripada rantaian induk dan kemudian menjalankan kesemua empat pemeriksaan DelegationGuards: satu hop yang akan melebihi had kedalaman 3, satu hop kembali kepada ejen yang sudah berada dalam rantaian (pengesanan kitaran), satu siling autonomi (tahap berkesan penerima wakilan dalam ruang itu tidak boleh melebihi tahap pemberi wakilan) dan satu peruntukan belanjawan (perwakilan mengebilkan baki belanjawan hard-stop pemberi wakilan dan tidak boleh menjana lebih banyak). Pendawaian pengeluaran membekalkan kedua-dua port penyelesai. Autonomi dan belanjawan dilangkau apabila from_agent_id ditiadakan (belanjawan tanpa had / tanpa polisi juga lulus). Penolakan dilemparkan sebagai DelegationRefusedException yang mesejnya sampai kepada ejen yang mewakilkan secara verbatim — penafian yang lantang, bukan no-op senyap.

delegate_ticket ialah saudara yang lebih lama dan tidak dikawal: ia memanggil createTicket secara terus dan melangkau setiap guardrail. Utamakan delegate_task.

Jangan kelirukan had kedalaman perwakilan (3, pada rantaian delegate_task) dengan had bersarang subejen harness terbina dalam (2). Kedua-duanya had yang berbeza pada mekanisme yang berbeza.

Hierarki, pautan dan projek

Hubungan induk dan sub-isu terletak pada tickets.parent_ticket_id, dimiliki oleh setParent / clearParent. Ia bukan baris ticket_links, jadi apa-apa yang membaca hubungan sesuatu tiket perlu menggabungkan kedua-dua sumber.

ticket_links menyimpan tepi berarah antara tiket yang sebaliknya tidak berkaitan:

Jenis pautan	Maksud
blocks	Sumber menyekat sasaran
relatesTo	Kedua-dua tiket berkaitan (simetri)
duplicateOf	Sumber ialah pendua kepada sasaran

Projek ialah pengelompokan tiket yang berskop ruang kerja menuju matlamat bersama. Projek hanya wujud dalam Control Center dan tidak pernah disegerakkan ke penyedia luar.

Kolaborator

Baris TicketCollaborator ialah cara lebih daripada satu prinsipal dilampirkan pada sesuatu tiket, pada peranan assignee, collaborator atau reviewer. Manusia dan ejen ialah baris yang setara — principalId tambah collaboratorType — tanpa nilai sentinel untuk “pengguna” dan tanpa kunci asing kepada mana-mana jadual itu.

Penyegerakan luar

Tiket Control Center ialah yang utama. Memadam tiket adalah tempatan sahaja, jadi tiket bersandarkan vendor yang anda padam tidak dipadamkan pada penjejak dan mungkin muncul semula pada penyegerakan seterusnya. Kolaborator dan tiket anak melata.

Kelayakan penyesuai diselesaikan daripada stor kelayakan pelayan (kunci Linear atau token GitHub yang ditampal dalam Tetapan akan diambil pada permintaan seterusnya; persekitaran hanya menyemai stor itu).

Tiket dan pipeline

Tiada nod pipeline mencipta, melengkapkan atau membatalkan tiket — palet tidak mempunyai langkah sedemikian dan enjin tidak memanggil TicketWorkflowService. Pencetus pipeline masih boleh terpicu pada TicketAssigned, TicketCompleted, TicketFailed atau TicketCancelled (empat itu ialah acara tiket yang benar-benar dipetakan oleh EventPayloadMapper). Tiada lajur pipelineRunId pada tiket; gandingan pipeline terletak pada log larian ejen.

Lihat juga

• Pipeline dan automasi: acara tiket boleh mencetuskan pipeline
• Orkestrasi: dari mana DAG sub-tiket datang
• Model ejen: kepada siapa tiket ditugaskan
• Acara domain: acara kitaran hayat tiket
• Kitaran hayat tiket: status, medan, peralihan, hubungan
• Cipta dan urus tiket
• Wakilkan kerja kepada ejen
• Susun kerja dengan projek