การคำนวณรีวิว (cohort, แกน และ diff ที่กำหนดแน่นอน)
แท็บ รีวิว ของ PR คือความคืบหน้าแบบสดของไปป์ไลน์รีวิวในขณะที่มันทำงาน จากนั้น จึงกลายเป็นอาร์ติแฟกต์ที่มันเผยแพร่ พร้อมการกระทำต่าง ๆ บนอาร์ติแฟกต์นั้น แท็บเดียว ที่มีสองสถานะ เพราะทั้งสองเป็นสิ่งเดียวกัน ณ เวลาสองเวลาที่ต่างกัน มันไม่ใช่แท็บ เริ่มต้น: PR หนึ่งรายการจะไม่มีการรีวิวจนกว่าจะมีคนขอ ดังนั้น ถาม AI จึงเป็น สิ่งที่เปิดแท็บนี้
เบื้องหลังแท็บนั้น cc_server สร้าง cohort ของไฟล์ รันแกนที่กำหนดแน่นอน และให้
บริการผ่านการดำเนินการ RPC review_studio.* (cohorts, blastRadius,
cohortImpact, ciSignals, dependencyDiffs, setContractDecision,
approveVisual, compute และคู่แฝด watch* ของมัน) เลย์เอาต์ที่ถูกบันทึกไว้
ซึ่งยังระบุชื่อ pr.reviewStudio จะเปิดแท็บรีวิวเดียวกันนี้
บนแท็บรีวิว:
- เอเจนต์ผู้รวบรวมเผยแพร่อาร์ติแฟกต์บทสนทนาธรรมดาด้วย
publish_artifactดังนั้น แท็บจึงแสดงมันผ่านตัวดูอาร์ติแฟกต์ตัวเดียวกับที่บับเบิลแชทเปิด — ไม่มีสำเนา ระบบอาร์ติแฟกต์ที่ทำเป็นรูปรีวิวอยู่เลย - ข้อค้นพบอยู่ในแถบด้านข้างถัดจากอาร์ติแฟกต์ และคำตัดสินอยู่ในแถบเรียวบางเหนือ อาร์ติแฟกต์ แทนที่จะอยู่ในส่วนหัวของแดชบอร์ด
- แบนเนอร์ล้าสมัยจะปรากฏขึ้นเมื่อ head ของ PR เคลื่อนไปไกลกว่าที่รีวิวไว้
ดูใช้รีวิวด้วย AI สำหรับขั้นตอนการทำงาน และ รีวิวและรวม PR สำหรับการลงมือกับมัน
cohort จัดกลุ่มไฟล์ที่เปลี่ยนแปลงของ PR เป็นถังที่ได้มาจากเนื้อหา บรรจุไฟล์ที่ เป็นพวกเดียวกันโดยความหมาย และจัดอันดับตามผลกระทบ เพื่อให้กลุ่มที่เสี่ยงที่สุด ได้อ่านก่อน พวกมันถูกคำนวณใหม่ทุกครั้งที่ SHA ของ head เปลี่ยนและถูกแทนที่ทั้งชุด; cohort แต่ละอันมีคีย์ที่เสถียรข้ามการ push ดังนั้นสรุปและความคืบหน้าของรีวิวจึง รอดจากการ rebase
ถ้ารีโปไม่มีดัชนีโค้ด cohort จะถอยกลับไปใช้การจัดกลุ่มตามเส้นทาง หากต้องการจัดทำ
ดัชนีรีโป ให้ใช้ การตั้งค่า → เวิร์กสเปซ → รีโพสิทอรี — แต่ละแถวของรีโปมีปุ่ม
จัดทำดัชนีโค้ด ที่รันไปป์ไลน์ index_code และรายงานความคืบหน้าในที่นั้น
กราฟโค้ดจะแยกวิเคราะห์เฉพาะภาษาที่มีไวยากรณ์มาพร้อมระบบเท่านั้น (Dart, JS/TS, PHP, Python, Rust, Zig, C/C++, Go, Java, Ruby, C#, Swift, Kotlin, R, Assembly, MATLAB, Ada) รีโปในภาษาอื่นจะไม่มีทางผลิต cohort เชิงความหมายได้ ไม่ว่าคุณจะ จัดทำดัชนีบ่อยแค่ไหน
เอเจนต์สามารถบันทึกสรุปแบบ markdown สำหรับ cohort หนึ่งอันด้วย
set_cohort_summary และแนบแผนภาพพาไล่ดูแบบมีโครงสร้างด้วย add_review_diagram
— ออบเจกต์ที่มีชนิดชัดเจนแบบ sequence, entity-relation หรือ state-machine ไม่ใช่
ข้อความ mermaid ทุกเส้นเชื่อมจะถูกตรวจเทียบกับกราฟโค้ดจริง และเส้นเชื่อมที่กราฟ
ยืนยันไม่ได้จะถูกทำเครื่องหมายว่ายังไม่ยืนยัน แทนที่จะถูกวาดเป็นข้อเท็จจริง
แกนสัญญา API
หัวข้อที่มีชื่อว่า “แกนสัญญา API”แกนสัญญาจะ diff เฉพาะไฟล์สเปกที่ระบุชัดแจ้งเท่านั้น มันจับคู่กับชื่อเริ่มต้น
หกชื่อ — openapi.yaml, openapi.yml, openapi.json, swagger.yaml,
swagger.yml, swagger.json — บวกกับไฟล์ที่เปลี่ยนแปลงใด ๆ ที่ชื่อมีคำว่า
openapi หรือ swagger และลงท้ายด้วย .yaml, .yml หรือ .json สัญญาที่
อนุมานจากโค้ดของตัวจัดการอยู่นอกขอบเขต และสคีมา GraphQL จะไม่ถูก diff
การเปลี่ยนแปลงแต่ละรายการถูกจำแนก — การเพิ่ม การลบ และการแก้ไข endpoint, พารามิเตอร์, สคีมา และการตอบกลับ — และมีความรุนแรงกำกับ: breaking (ลบ endpoint หรือพารามิเตอร์, ชนิดข้อมูลเข้มขึ้น, พารามิเตอร์ที่จำเป็นตัวใหม่), non-breaking (เพิ่มเติม) หรือ informational การเปลี่ยนแปลงที่ถูกปฏิเสธทำให้เกต สัญญาไม่ผ่าน เช่นเดียวกับการเปลี่ยนแปลงแบบ breaking ที่ยังไม่ถูกตัดสิน; breaking แต่ได้รับอนุมัติจะเตือน; หากไม่มีการเปลี่ยนแปลงแบบ breaking เลยจะผ่าน diff ที่ ถูกทำเครื่องหมายว่า derived (advisory) จะไม่กั้นเกตเลย
การอนุมัติหรือปฏิเสธการเปลี่ยนแปลงหนึ่งรายการทำได้ด้วย
review_studio.setContractDecision
ถ้า PR เปลี่ยนคอมโพเนนต์ UI ในรีโป Flutter ที่มีแอป Widgetbook รอบคำนวณจะ
เรนเดอร์คอมโพเนนต์ที่เปลี่ยนไปทั้งก่อนและหลังผ่านรอบ golden ของ flutter test
แบบไม่มีหน้าจอ ใน worktree ของ base และ head ของ PR แล้วจึง diff พิกเซล
สแนปช็อตที่ถูกทำเครื่องหมายว่า changed หรือ removed จะยึดเกตภาพไว้ จนกว่าจะได้รับอนุมัติ; สแนปช็อต unchanged, added และ approved จะทำให้ เกตผ่าน ความไม่พร้อมใช้มีได้หนึ่งในสี่เหตุผล: ไม่มี Flutter SDK บนโฮสต์, ไม่มีแอป Widgetbook ในรีโป, ไม่มีกรณีการใช้งานที่ทดสอบด้วย golden ได้ หรือเกิดข้อผิดพลาด ของฮาร์เนส golden
การอนุมัติการเปลี่ยนแปลงที่ตั้งใจทำได้ด้วย review_studio.approveVisual
แกนและคำตัดสิน
หัวข้อที่มีชื่อว่า “แกนและคำตัดสิน”| แกน | ขับเคลื่อนโดย |
|---|---|
| ความถูกต้อง | เอเจนต์รีวิวเวอร์ (โทเคน) |
| ความปลอดภัย | เอเจนต์รีวิวเวอร์ (โทเคน) |
| ช่องว่างการทดสอบ | เอเจนต์รีวิวเวอร์ (โทเคน) |
| ภาพ | กำหนดแน่นอน (ฮาร์เนส golden) |
| สัญญา API | กำหนดแน่นอน (diff สเปก) |
แกนที่ขับเคลื่อนด้วยโทเคนทั้งสามจะถูกบันทึกเมื่อเอเจนต์หัวหน้าเรียก
finalize_review; แกนที่กำหนดแน่นอนทั้งสองจะถูกบันทึกโดยรอบคำนวณ
แกนแต่ละอันรายงานสถานะใดสถานะหนึ่งต่อไปนี้:
| สถานะ | ความหมาย |
|---|---|
| Pass | รันแล้ว ไม่พบสิ่งใดที่ขวาง |
| Warn | รันแล้ว พบข้อกังวลที่ไม่ขวาง |
| Fail | รันแล้ว พบปัญหาที่ขวาง |
| Partial | รันแล้วแต่ทำงานไม่ครบ; ผลลัพธ์ไม่สมบูรณ์ |
| Unavailable | รันไม่ได้เลย |
มีเพียง pass และ warn เท่านั้นที่ทำให้แกนที่มีเกตผ่าน Partial และ unavailable ถูกจงใจแยกออกจาก fail อย่างชัดเจน และทั้งคู่ก็ไม่ทำให้เกตผ่าน
แกนต่าง ๆ รวมกันเป็น Ship, Hold หรือ Block และมันทำได้เพียงทำให้ คำตัดสิน_รุนแรงขึ้น_เท่านั้น — ไม่มีทางถูกลดระดับลง แกนที่มีเกตซึ่งล้มเหลว บังคับให้เป็น Block; แกนที่ partial หรือ unavailable บังคับให้เป็น อย่างน้อย Hold ดังนั้นแกนที่ขวางอยู่ซึ่งรันไม่ได้จะ_ยึด_คำตัดสินไว้: การไม่มีหลักฐานไม่เคยทำให้เกตเป็นสีเขียว
คำตัดสินบนแท็บรีวิวคือคำตัดสินที่ finalize_review เผยแพร่