GitHub Issue能放計畫書了：讓工作脈絡不再埋在留言裡
修復程式碼在PR裡，為什麼這樣改卻可能藏在很早的聊天中。如果代理的調查結果也放在別處，接手的人就容易重複調查。GitHub在10月28日推出Issue artifacts公開預覽，讓這些資料直接關聯到對應的Issue。
對話與持續更新的文件各有作用
資料可以是Markdown文件、外部連結或HTML文件，例如根因分析、原型、Slack與Teams討論。在github.com上可以建立、編輯並保留版本歷程。它與GitHub Actions執行產生的建置產物不同，不宜將兩種artifact混為一談。
假設有一個重複扣款的虛構故障。留言記錄新觀察，計畫書整理重試鍵的處理與待驗證實驗。第一張圖是為本文自製的範例，不是GitHub介面。把觀察、假設與實驗分開，有助於避免代理將猜測當成確定需求。
掛上一份檔案，再持續維護相同脈絡
gh issue artifact create在Issue編號或URL後接檔案或連結。gh issue artifact create 42 retry-plan.md -R OWNER/REPO會將檔案附到指定儲存庫的Issue 42。儲存庫與編號都是替代值，執行會寫入Issue；本文沒有實際執行。
名稱可來自檔名，也可用--name指定。--body-file讀取單份文件內容，--attach支援圖片與影片。gh issue artifact edit 42 1 --body-file retry-plan.md -R OWNER/REPO可取代內容。第二張圖是命令語法範例，不是上傳成功紀錄。
保留最新計畫，也留下變更原因
edit可改名或取代內容，但不改變資料類型。--restore-version將舊名稱與內容儲存為新版本，view可顯示編輯歷程。既能維護目前計畫，也不必抹去形成判斷的過程。
在扣款範例中，調查可能從網路逾時轉向重複鍵處理。更新計畫並連結解釋原因的留言，是一種文件組織建議，不是產品自動行為。附件本身不能證明程式碼正確，結論附近仍需要證據。
HTML支援取決於使用入口
公告描述了HTML呈現預覽與原始碼切換，但GitHub App內建立、檢視HTML仍標註為即將推出。工作階段產物自動附到Issue，不代表所有入口都完整支援HTML。CLI也處於預覽階段，語法與行為可能調整。
這次變化的價值在於脈絡資料的位置，而非文件數量。可以先關聯已有的一份計畫，再於下次修改時延續歷程。目前支援範圍以官方公告與CLI文件為準。