เมื่อเทิร์นจบ ผลลัพธ์ไม่ได้ลงเลย — มันผ่าน เกต design kit ก่อน เกตรัน การตรวจของ kit กับไฟล์ที่ agent เขียน และรายงานใน transcript: Gate passed หรือรายการ FAIL ที่ชี้กฎที่แตกตัวไหนและตรงไหน
มันตรวจอะไร
เกตอ่านผลลัพธ์เหมือนที่เบราว์เซอร์ทำ — เรนเดอร์แล้ว ที่ความกว้างจริง:
- Contrast — ข้อความต้องผ่านพื้นความสว่างเทียบกับพื้นหลังของมัน
- Minimum type — ไม่มีข้อความต่ำกว่าพื้นขนาดของ kit
- Hit targets — ตัวควบคุมอินเทอร์แอกทีฟมีขนาดพอแตะได้
- Live navigation — ทุกรายการ nav ต้องไปถึงอะไรสักอย่าง ตรวจที่ความกว้าง โทรศัพท์และแท็บเล็ตที่ toggle มักตายที่สุด
- Dead zones — บริเวณที่เลย์เอาต์กลืนการโต้ตอบ
การตรวจรันข้ามห้าความกว้าง — เดสก์ท็อป แล็ปท็อป แท็บเล็ต และความกว้าง โทรศัพท์สองขนาด — ดีไซน์ที่ใช้ได้เฉพาะขนาดที่ agent บังเอิญเขียนจึงถูกจับได้ ไม่ใช่ส่งออก
PASS
Gate passed หมายความว่าผลลัพธ์ผ่าน kit — เป็นของคุณเก็บ steer ต่อ หรือ ส่งออก transcript แจงไฟล์ที่เทิร์นแตะ คุณจึงเห็นรัศมีผลกระทบของการเปลี่ยน ในหนึ่งเดียว
FAIL — และลูปแก้ไข
FAIL แจงแต่ละกฎที่แตกเป็น finding — id ของการตรวจ ความกว้างที่แตก และองค์ ประกอบ "Fix at this width" บน finding ส่งปัญหานั้นเป๊ะ ๆ กลับให้ agent เป็นบรีฟแก้ไขบรรทัดเดียว; FAIL ไม่ใช่ทางตัน มันคือเทิร์นถัดไปที่เขียนไว้ให้ แล้ว ลูป auto-fix ลองใหม่เองหนึ่งครั้งก่อน findings จะลงในมือคุณ
มันไม่ตรวจอะไร
เกตบังคับกฎ ไม่ใช่รสนิยม — ผลลัพธ์ที่ผ่านยังอาจเป็นดีไซน์ที่ผิดสำหรับบรีฟ ซึ่งเป็นหน้าที่ของ steering โหมดรีวิว และตาคุณ และมันตรวจเฉพาะที่ kit รู้: อินเทอร์แอกชันแปลกใหม่หรือโครงสร้างผิดปกตินอกกฎจะผ่านโดยอัตโนมัติ ไม่ใช่คำ ตัดสิน
มันรันตรงไหน
เกตรันตอนท้ายทุกเทิร์นของโปรเจกต์มาตรฐาน โปรเจกต์ codebase ต่างออกไป: repo ที่ adopt รันการตรวจแบบจำกัด diff บนไฟล์ที่เทิร์นเปลี่ยน เทียบกับ dev server ของคุณเอง — ดู Build mode Free และ Pro รัน เกตเดียวกัน; มันไม่ใช่ส่วนที่ license นับ
Tip: เมื่อ finding ของ FAIL ดูถูกตามเจตนาดีไซน์ (ข้อยกเว้น accent ที่ ตั้งใจ การแลกที่รู้อยู่) คุณไม่จำเป็นต้องแก้ — steer รอบมันด้วยคอมเมนต์หรือ Tweak หรือยอมรับ finding แล้วไปต่อ เกตให้คำแนะนำ; คุณเป็นคนตัดสิน