jiantw83
232eb36158
What - 產生 HASH 的指令失敗時，依退出碼分流處理。 - 讀取問詢頁失敗時，依退出碼分流處理。 - 寫入目錄頁失敗時，依退出碼分流處理。 - 規範文件的指標改指向 jsc-meta 的 references/guidelines.md。 - 新增「Session cache」一節，兩頁在同一個工作階段只讀一次。 - wiki 存取庫在同一個工作階段只解析一次。 - 問後的三重完成條件收斂成一次確認。 Why - 原本只寫「執行指令取得 HASH」。指令失敗時沒有指示，技能會自行硬算雜湊或猜測頁名，寫錯頁面。 - 「讀取失敗」與「頁面不存在」意義不同。不分流就把失敗當成沒有紀錄，重問使用者已經回答過的問題。 - 目錄頁由所有存取庫共用。讀不回舊內容還照樣整頁覆寫，會抹掉別的存取庫的列，而且沒有備份可救。 - 指標指向的規範檔案已經搬到 jsc-meta，舊指標讓讀者找不到來源。 - 兩頁在一個工作階段內只有本技能會寫。重複讀取只是多花往返時間。 - wiki 位置本身就是要問的問題，答案卻要寫進 wiki 才記得住。不把答案留在工作階段內，每次呼叫都得再問一次，永遠問不完。 - 完成條件重複確認同一件事，主代理得多讀兩次頁面才敢往下走。 How - 取得 HASH 一步列明退出碼 0 與 1 的處理；其他非零退出碼一律停止執行，並回報退出碼與指令的錯誤輸出。 - 讀取一步把「頁面不存在」視為沒有紀錄，照常發問；其他失敗停止執行，並回報失敗頁名與退出碼。 - 寫入目錄頁一步依退出碼分流：正常就讀回整頁後更新單列，金鑰無效或無權限、以及其他 API 失敗都放棄寫入並回報。 - 新增「Session cache」一節，訂出首次讀取、後續沿用、寫入後更新副本、隨工作階段結束失效四個步驟。 - 解析 wiki 存取庫獨立成一步，答案留在工作階段內重複使用，收尾再建議使用者設定環境變數，永久結束追問。 - 兩份寫入交給同一個子代理，收斂成單一回報，主代理確認一次即可，不再回讀頁面驗證。 - 寫入失敗只重試該頁一次；再失敗就停止執行，回報未寫入的頁面與退出碼，答案仍交還呼叫端。 - 兩份範本的指標同步改指 jsc-meta。 Who - 決策樹問詢技能 ask 的問前準備、問後紀錄流程，以及問詢紀錄頁範本。
18 lines
717 B
Markdown
18 lines
717 B
Markdown
# 問詢紀錄 — {owner}/{repo}
|
||
|
||
> 由 `jsc-ask:ask` 維護。這是問詢紀錄頁 `QUESTION_{HASH}`；`HASH` 執行 `jsc-gitea/tools/hash-id {owner}/{repo}` 取得（共用 wiki hash 規則，演算法見 `jsc-meta` 的 `references/guidelines.md`）。新問答**附加**在文末，不覆蓋舊紀錄。相同問題再次出現時，直接採用此處答案，不再詢問。
|
||
|
||
## {yyyy-MM-dd HH:mm} {問詢主題}
|
||
|
||
- **意圖**: {使用者的原始需求與目的，一句話，供 AI 判斷選擇動機與答案適用性}
|
||
|
||
### Q1: {問題}
|
||
|
||
| 選項 | 影響範圍 |
|
||
| --- | --- |
|
||
| {選項 A} | {影響範圍} |
|
||
| {選項 B} | {影響範圍} |
|
||
|
||
- **答案**: {使用者答案}
|
||
- **時間**: {yyyy-MM-dd HH:mm}
|