Triage: #42 "Export to CSV crashes"
Recommendation: category bug, state needs-info. The issue is unlabeled now. The normal path is needs-triage first, but I think it can go straight to needs-info. Either way, the label change and comment wait for your go-ahead.
What I checked
- Prior rejection: there is no
.out-of-scope/directory, so there is no earlier rejection to surface. - Redundancy: this is a crash report, not a feature request, so an existing implementation doesn't apply.
- Codebase: I couldn't explore it. The working directory isn't a git repo, and I only have a file reader here, with no way to list directories or search. I didn't want to guess at paths. If you tell me where the reports page and its export handler live, I'll trace the code path.
- Reproduction: not attempted. There's no running app or repro data, and the report has no steps I could follow.
Why needs-info
The report is too thin to reproduce or to write a durable agent brief from:
- "Spins forever, then the page goes blank" could be a hung request or a server timeout. It could also be an unhandled client-side exception or a memory blowup on a large dataset.
- "Happens on my laptop" gives no browser, OS or app version.
- It doesn't say whether the export works for smaller reports, other reports or other users.
Draft comment (not posted)
> *This was generated by AI during triage.*
## Triage Notes
**What we've established so far:**
- Clicking Export on the reports page shows a spinner that never finishes, then the page goes blank.
- Reported on the reporter's laptop only; we haven't seen it elsewhere yet.
**What we still need from you (@sam):**
- Which report were you exporting, and roughly how many rows does it have? Does a smaller report or a narrower date range export fine?
- Which browser and version are you using, and which OS?
- Open the browser dev tools (Console and Network tabs) and click Export again. Is there a red error in the Console? Does the export request show a status code, or stay "pending"? Please paste what you see.
- Does it fail every time, or only sometimes? Does it also fail for a teammate or on another machine?
- Which app version or deploy are you on?
Next step: should I apply bug + needs-info and post that comment? Or would you rather go to needs-triage first, or give me the code location so I can try to verify the crash from the source before asking @sam anything?
How it was tried: I installed triage together with the grilling and domain-modeling skills it can call, in a clean temporary folder, and invoked it as a slash command with one pasted issue and no issue tracker connected. Only Skill and Read tools were allowed, so nothing was posted, labelled or closed, the codebase could not be explored and no bug was reproduced. It shows only the recommend step and a drafted comment, and it stops to wait for your go-ahead.
它做什麼
給維護者用的工作流程。它讓每個議題（以及每個外部 PR，視為帶程式碼的議題）走過兩類角色（bug、enhancement）與五個狀態（needs-triage、needs-info、ready-for-agent、ready-for-human、wontfix）。
運作方式
- 列出需要關注的：未打標籤的、
needs-triage的、以及needs-info且有新回覆的。 - 針對一個項目：完整讀一遍，檢查該行為是否已經實作，並查看
.out-of-scope/裡有沒有以前拒絕過的類似請求。 - 給出分類與狀態的建議，然後等你的指示。
- 驗證說法是否成立：重現缺陷，或確認 PR 的確做了它宣稱的事。
- 需要細化時，進行一輪
grilling+domain-modeling。 - 落實結果：寫任務說明、寫待補充資訊的說明，或附上解釋後關閉。內附的兩份指南講怎麼寫經得起時間的代理任務說明，以及
.out-of-scope/知識庫的用法。
適合情境
議題很多的專案維護者。它會發留言、也能關閉議題，請逐項確認它要做的動作。
高風險：它會操作你的議題系統：打標籤、發留言（每則都以「由 AI 產生」的聲明開頭）、關閉議題。遇到缺陷或外部 PR 時，它可能重現缺陷，或拉取 PR 程式碼並執行其中的測試，也就是會執行你沒有審過的程式碼，處理不可信的 PR 請用沙箱或乾淨的複製目錄。它還會向儲存庫寫入檔案（`.out-of-scope/`，以及術語表、ADR 的更新）。它的設計是先給出建議、等你指示再執行，但核准前請逐條看清它要做的動作。需要你的議題系統標籤對應，以及 `grilling` 和 `domain-modeling` 兩個 Skill。 已試用一次：只貼了一個議題，沒有連接議題系統，也沒有寫檔案與命令列工具，只觀察到了推薦分類與草擬留言這一步。沒有發留言、打標籤或關閉議題，也沒有重現缺陷或拉取 PR。