Pengiraan semakan (kohort, paksi dan diff deterministik)
Tab Semakan PR itu ialah kemajuan langsung pipeline semakan semasa ia berfungsi, kemudian artifak yang diterbitkannya, berserta tindakan ke atasnya. Satu tab dengan dua keadaan, kerana kedua-duanya ialah perkara yang sama pada dua masa. Ia bukan tab lalai: sesuatu PR tidak mempunyai semakan sehingga ada yang memintanya, jadi Tanya AI itulah yang membukanya.
Di sebalik tab itu, cc_server membina kohort fail, menjalankan paksi
deterministik dan menyajikannya melalui operasi RPC review_studio.*
(cohorts, blastRadius, cohortImpact, ciSignals, dependencyDiffs,
setContractDecision, approveVisual, compute dan kembar watch*-nya).
Susun atur kekal yang masih menamakan pr.reviewStudio membuka tab Semakan
yang sama ini.
Pada tab Semakan:
- Ejen pengkonsolidasi menerbitkan artifak perbualan biasa dengan
publish_artifact, jadi tab itu merendernya melalui pemapar artifak yang sama seperti yang dibuka oleh gelembung sembang — tiada salinan sistem artifak yang berbentuk semakan. - Penemuan berada dalam rel di sisinya, dan keputusan berada pada bar nipis di atas artifak dan bukan pada pengepala papan pemuka.
- Sepanduk lapuk muncul apabila head PR sudah bergerak melepasi semakan.
Lihat Gunakan semakan berkuasa AI untuk alurnya dan Semak dan cantumkan PR untuk bertindak ke atasnya.
Kohort mengelompokkan fail yang berubah dalam sesuatu PR kepada wadah yang diterbitkan daripada kandungan, iaitu fail yang memang berkelompok dari segi makna, disusun mengikut kesan supaya kumpulan paling berisiko dibaca dahulu. Kohort dikira semula pada setiap perubahan head-SHA dan diganti sepenuhnya; setiap kohort mempunyai kunci yang stabil terhadap push, jadi ringkasan dan kemajuan semakan bertahan melalui rebase.
Jika repo tidak diindeks kod, kohort kembali kepada pengelompokan mengikut
laluan. Untuk mengindeks repo, gunakan Tetapan → Ruang kerja → Repositori —
setiap baris repo membawa tindakan Indeks kod yang menjalankan pipeline
index_code dan melaporkan kemajuan di tempat.
Graf kod hanya menghuraikan bahasa yang tatabahasanya sudah tersedia (Dart, JS/TS, PHP, Python, Rust, Zig, C/C++, Go, Java, Ruby, C#, Swift, Kotlin, R, Assembly, MATLAB, Ada). Repo dalam mana-mana bahasa lain tidak akan pernah menghasilkan kohort semantik, tidak kira berapa kerap anda mengindeksnya.
Ejen boleh merekod ringkasan markdown untuk sesuatu kohort dengan
set_cohort_summary dan melampirkan gambar rajah penelusuran berstruktur
dengan add_review_diagram — objek bertipe jujukan, entity-relation atau
state-machine, tidak pernah teks mermaid. Setiap tepi diperiksa silang terhadap
graf kod sebenar, dan tepi yang tidak dapat disokong graf itu ditandakan belum
terverifikasi dan bukan dilukis sebagai fakta.
Paksi kontrak API
Bahagian bertajuk “Paksi kontrak API”Paksi kontrak hanya melakukan diff pada fail spec yang eksplisit. Ia
memadankan enam nama lalai — openapi.yaml, openapi.yml, openapi.json,
swagger.yaml, swagger.yml, swagger.json — serta mana-mana fail yang
berubah yang namanya mengandungi openapi atau swagger dan berakhir dengan
.yaml, .yml atau .json. Kontrak yang disimpulkan daripada kod pengendali
berada di luar skop dan skema GraphQL tidak di-diff.
Setiap perubahan dikelaskan — penambahan, pemadaman dan pengubahsuaian endpoint, parameter, skema dan respons — dan membawa keterukan: breaking (endpoint atau param dibuang, jenis diperketat, param wajib baharu), non-breaking (aditif), atau informational. Perubahan yang ditolak menggagalkan pintu kontrak, begitu juga perubahan breaking yang dibiarkan tanpa keputusan; breaking tetapi diluluskan memberi amaran; tiada perubahan breaking bermakna lulus. Diff yang ditandakan derived (advisory) tidak pernah menjadi pintu.
Meluluskan atau menolak sesuatu perubahan ialah
review_studio.setContractDecision.
Paksi visual
Bahagian bertajuk “Paksi visual”Jika PR mengubah komponen UI dalam repo Flutter yang mempunyai aplikasi
Widgetbook, laluan pengiraan merender komponen yang berubah sebelum dan
selepas melalui laluan golden flutter test tanpa kepala dalam worktree base
dan head PR, kemudian melakukan diff pada pikselnya.
Snapshot yang ditandakan changed atau removed menahan pintu visual sehingga diluluskan; snapshot unchanged, added dan approved membukanya. Ketidaktersediaan mempunyai salah satu daripada empat sebab: tiada Flutter SDK pada hos, tiada aplikasi Widgetbook dalam repo, tiada kes penggunaan yang boleh diuji golden, atau ralat harness golden.
Meluluskan perubahan yang dimaksudkan ialah review_studio.approveVisual.
Paksi dan keputusan
Bahagian bertajuk “Paksi dan keputusan”| Paksi | Digerakkan oleh |
|---|---|
| Correctness | Ejen penyemak (token) |
| Security | Ejen penyemak (token) |
| Test gap | Ejen penyemak (token) |
| Visual | Deterministik (harness golden) |
| API contract | Deterministik (diff spec) |
Ketiga-tiga paksi token dicatat apabila ejen ketua memanggil finalize_review;
kedua-dua paksi deterministik dicatat oleh laluan pengiraan.
Setiap paksi melaporkan salah satu daripada:
| Keadaan | Maksud |
|---|---|
| Pass | Berjalan, tiada perkara yang menyekat ditemui |
| Warn | Berjalan, ada kebimbangan yang tidak menyekat |
| Fail | Berjalan, menemui masalah yang menyekat |
| Partial | Berjalan tetapi tidak dapat diselesaikan; hasilnya tidak lengkap |
| Unavailable | Tidak dapat dijalankan langsung |
Hanya pass dan warn membuka paksi berpintu. Partial dan unavailable sengaja dibezakan daripada fail dan kedua-duanya tidak membuka pintu.
Paksi-paksi itu beragregat menjadi Ship, Hold atau Block, dan ia hanya boleh menjadikan keputusan itu lebih berat — ia tidak pernah diturunkan. Paksi berpintu yang gagal memaksa Block; paksi yang partial atau unavailable memaksa sekurang-kurangnya Hold. Jadi paksi yang menyekat yang tidak dapat dijalankan menahan keputusan itu: ketiadaan bukti tidak pernah menjadikan pintu hijau.
Keputusan pada tab Semakan ialah keputusan yang diposkan oleh
finalize_review.