工單變成 pull request。 中間的挖掘由 Polylane 負責。
加入候補名單它先看改了什麼。 一半的工單都能追溯到某人做的某次變更。
SQS visibility timeout lowered on checkout-events
VisibilityTimeout on checkout-events dropped from 120s to 15s. Consumers that hold a message longer than 15 seconds will see it delivered twice; the dead-letter queue threshold is unchanged.
SetQueueAttributes CloudTrail · deploy-bot · 12:41:02Z attached to this record's delta window 理論要檢驗，不是相信。 只有來自你真實系統的證據才能確認。
Hyperdrive pool exhaustion after deploy 9f3c2a1
Confidence: strong · 3 of 3 passes
Upstream PlanetScale degradation
Confidence: definitive · 3 of 3 passes
Cold-start regression in the new isolate
Confidence: weak · 2 of 3 passes
修復送到時已可審查。 包含根本原因、驗證與差異。
Cap retries on the checkout webhook worker #491
polylanemain from polylane/autofix/chat/k3x9f2-4e7d21a 
Retries on the checkout webhook worker were unbounded: a failing delivery re-queued itself forever and amplified load on payments-api. This caps delivery at 5 attempts with exponential backoff and dead-letters the payload after the last one.
What changed
worker/deliver.ts gains MAX_DELIVERY_ATTEMPTS = 5 and backoff between attempts; exhausted payloads land in checkout-webhooks-dlq instead of re-queueing.
Validation
npm test — 214 passed. A forced failing delivery stopped after 5 attempts and appeared in the dead-letter queue.
Polylane 如何運作。 它學習你的系統、監看它、調查，然後行動。
-
它先學習你的系統
情境圖描繪出你的雲端、儲存庫與可觀測性供應商之間的每一個資源與依賴關係。代理依據真實的拓樸推理，而不是猜測。
-
不靠閾值的偵測
每個供應商都有內建檢查，再加上從你自己儲存的查詢與儀表板產生的檢查。一次統計分析與一個代理共同決定，而改善永遠不會引發問題。
-
拿得出證據的調查
每一項主張都連回背後的查詢、日誌行或變更記錄。沒有證據的判定會退回無法定論。
-
寫入是掙來的，絕非理所當然
帳戶以唯讀方式連接。復原預設關閉、受頻率限制，且留有記錄。程式碼變更走你平常的審查流程。
-
它每週都更敏銳
記憶、每日筆記與對照真實資料重新確認的監控查詢：七月的調查會從六月的學到東西。
它接上你已經在跑的一切。 以唯讀方式連接，然後開始。
常見問題。
我怎麼把工單交給 Polylane？
在主控台、透過 CLI，或從你的編輯器經由 MCP 伺服器開一個對話串，描述這個 bug。代理會帶著工作區的完整情境接手：這張圖、遙測資料、變更記錄與程式碼。
如果它找不到原因呢？
它會直說。調查以已解決、已診斷或無法定論結束：無法取得資料的調查永遠不會確認，而任何需要人來決定的事會變成一次升級，而不是不斷糾纏的迴圈。
它會從過去的工單學習嗎？
會。確認過的發現會儲存為記憶，並在之後的對話串中依語意取回，每日筆記則持續記錄發生了什麼。七月的調查會從六月的學到東西。
修復由誰來寫？
預設是 Polylane 的自動修復：先調查、再撰寫並驗證，附上推理。或者把實作交給 Devin、Cursor 或 Factory。無論哪一種，都由你審查。
它支援哪些儲存庫？
透過 GitHub 應用程式連接的 GitHub 儲存庫。修復會落在受影響服務背後那個儲存庫的分支上，並從變更連結到調查。