ecosystem.yamlคือ สิ่งที่เราตั้งใจ · ตารางกลุ่มนี้คือ สิ่งที่เกิดขึ้นจริง คุณค่าอยู่ที่การเทียบสองอย่างนี้ — ไม่ใช่ที่การมีข้อมูล GitHub เฉย ๆ
make sync # ดึงเข้า graph (incremental)
make work # ตอนนี้ใครทำอะไรอยู่ + งานซ้ำข้ามทีมmake import ของ M1 ลบและเขียนตาราง ecosystem ใหม่ทั้งชุดทุกครั้ง ถ้าผูก FK ไว้
ข้อมูล sync จะโดนลบทิ้งทุกครั้งที่ import หรือไม่งั้น import ก็จะพัง
และมันควรเป็นอิสระอยู่แล้ว — สองฝั่งนี้ต้องเทียบกันได้ ไม่ใช่ผูกกันจนแยกไม่ออก
| ข้อกำหนด | วิธี |
|---|---|
| ล้มบางส่วนไม่ทำให้ทั้งรอบพัง | แต่ละ repo อยู่ใน try ของตัวเอง · ล้มแล้วบันทึก last_error ราย repo แล้วไปต่อ |
| incremental | since จาก last_synced_at · PR เรียง updated desc แล้ว break เมื่อเจอตัวเก่ากว่า cutoff |
| เคารพ rate limit | ตรวจก่อนเริ่ม ต่ำกว่า 200 ไม่เริ่ม |
| upsert ไม่ใช่ลบแล้วเขียนใหม่ | ข้อมูลเก่ายังอยู่ถ้ารอบนี้ล้ม |
รายการไฟล์ของ PR แพงที่สุด (1 call ต่อ PR) จึงดึงเฉพาะ PR ที่ขยับใน 120 วัน
และข้ามตัวที่ files_synced แล้วและปิดไปแล้ว
จำนวน API call นับเองในตัว client ไม่ได้คำนวณจากส่วนต่างของ
rate_limitเพราะตัวเลขนั้นไม่ขยับทันทีและบางบัญชีใช้คนละ bucket — รอบแรกที่ทำแบบนั้น รายงานว่าใช้ไป 0 call ทั้งที่ยิงจริงเป็นร้อย
ความต่างนี้คือหัวใจของ #17 — ถ้านับ issue ที่เปิดค้างมาสองปีเป็น "กำลังทำ" คำเตือนเรื่องงานซ้ำจะกลายเป็นเสียงรบกวนจนไม่มีใครอ่าน
| สัญญาณ | state | confidence |
|---|---|---|
| PR เปิดอยู่ ขยับใน 14 วัน | in-progress |
high |
| PR เปิดอยู่ เงียบเกิน 14 วัน | in-progress |
medium |
| issue มีคนรับ + ขยับใน 14 วัน | in-progress |
high |
| issue มีคนรับ แต่เงียบ | in-progress |
medium |
| issue ไม่มีคนรับ แต่เพิ่งขยับ | declared |
medium |
| issue ไม่มีคนรับ และเงียบ | declared |
low |
จับสามทาง เรียงตามความแม่น
- component ของ repo ที่งานนั้นอยู่ — โดยปริยาย ไม่ต้องเอ่ยชื่อ
- ไฟล์ที่ PR แตะ —
contracts/<name>/<version>/→ contract id · แม่นที่สุด - ชื่อเรื่อง — หยาบสุด แต่ใช้ได้กับ issue ที่ยังไม่มีโค้ด · แมตช์แบบคำเต็ม
(
agent-platformต้องไม่ไปแมตช์กับagent-platform-experimental)
สองอย่างที่ M2 ทำไม่ได้ก่อนมี M3
1. ไม่เสนอสิ่งที่มี issue อยู่แล้ว — จับคู่ข้อเสนอกับงานที่เปิดค้างด้วยคะแนน
entity ที่ตรงกัน × 2 + คำในหัวข้อที่ตรงกัน แล้วเลือกตัวที่ได้คะแนนสูงสุด
ชี้ไป issue ผิดใบแย่กว่าไม่ชี้ จึงต้องมีสัญญาณมากกว่าแค่ "อยู่ repo เดียวกัน"
[1] ทำให้ enterprise-knowledge conform ตาม ADR-0006
… · มี issue เปิดค้างอยู่แล้วที่ enterprise-knowledge#17 — ควรทำต่อจากอันนั้น ไม่ใช่เปิดใหม่
2. เตือนงานซ้ำข้ามทีม — นับเฉพาะ in-progress เท่านั้น
87 issues · 46 PRs · 662 ไฟล์ใน PR · 7 repo
งานที่เปิดอยู่ 44 ชิ้น · กำลังทำจริง 0 · ประกาศไว้เฉย ๆ 44
ไม่มี PR เปิดค้างเลยสักตัว และไม่มี issue ไหนมี assignee เลย — ทั้งสองอย่าง เป็นเรื่องปกติของ ecosystem ที่มีคนดูแลคนเดียว แต่แปลว่าสัญญาณ "ใครกำลังทำอะไร" ที่ M3 ออกแบบมาจับ ยังไม่มีข้อมูลจริงให้จับ
กลไกจึงพิสูจน์ด้วยข้อมูลสังเคราะห์ใน tests/test_github.py
— รวมถึงเคสที่สองทีมเปิด PR แตะ execution/v1 พร้อมกันแล้วระบบต้องเตือน