  jiantw83andClaude Opus 5
|
f61ef3fa78
|
test(delegation): 把標記與判準正本雙向綁住
沒有這條斷言，兩邊會慢慢漂開，而漂開時不會有任何東西報錯：正本上多標一步不會壞，
判準表少列一項也不會壞，只是下一個讀的人會以為自己讀到的是全部。
十三條，重點在三處：正本上被標記的集合等於判準表列出的集合；會問使用者的步驟一律
未被標記（判準第二條的迴歸保護，四個點名的步驟加上一次全域掃描）；被標記的步驟碰得到
寫入時要寫明哪一半不委派（第四條）。
掃描類的斷言都補上自我檢查，因為這種測試最常見的壞法是「一條都沒掃到」而它照樣是綠的：
提問語至少要認出四個步驟、至少要掃過四十個步驟。標記位置那一條原本把三種合法位置寫成
`/^#{2,3} /`，那條會把「### 沒編號的標題 〔可委派〕」也放過去，改成三條互斥的規則。
helpers 新增 promptSteps（名字、有沒有標記、內文），promptStep 改建在它上面，
順帶讓步驟標題容得下後綴。
議題 #58
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
2026-09-18 09:12:08 +08:00 |
|
|
jiantw83andClaude Opus 5
|
84cd8fc41f
|
docs(prompts): 六個只在意結果的步驟標上〔可委派〕
三份正本各加一節說明這個後綴是什麼意思，只留能力描述那一句與指回判準正本的指路，
判準本身不複寫——抄過去就會有兩份各自演化的規則（AGENTS.md 的 references/ 那一列）。
標的是六個：sdlc-plan 的產生圖解版總覽；sdlc-analyze 的對四份清單列出疑點、算出截止日、
產生分析版的圖解總覽；sdlc-feat 的把議題標題翻成英文、分批提交。
其中三步是部分委派，各自在該步寫明哪一半留給主流程：兩份圖解總覽委派的是產出 HTML，
寫回議題的 issue-update 不委派；分批提交委派的是方案計算，實際跑 commit-split.js 不委派。
理由不在這裡複述，指回判準第四條。
**「認出語言，讀規則正本」不標**，儘管議題的列舉點了它。那一步的核心動作含「認不出語言
就停下來問、不要猜」，正是判準第二條硬排除的事；排掉它之後剛好是議題所寫的六個。
這一條與 repo 擁有者確認過。
AGENTS.md 的 references/ 那一列補上「委派判準」，否則那串括號裡的列舉會漏掉新的一份。
議題 #58
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
2026-09-18 09:12:08 +08:00 |
|
|
jiantw83andClaude Opus 5
|
3da822adc6
|
docs(references): 新增委派判準，四條全部成立才可委派
只在意結果的步驟——翻譯分支名、算截止日、逐條比對可行性清單、產生 HTML 總覽——
它們的中間產物目前全部留在主脈絡裡，把後面真正需要判斷力的步驟愈擠愈窄。要把這些
交出去，得先說清楚「哪些交得出去」，否則下一個人只能憑感覺標。
四條判準裡有兩條是硬排除，各自寫上理由，因為沒有理由的規則遲早會被繞過去：
第二條（步驟中不會詢問使用者）是因為子代理問不到使用者，一旦卡在提問就只能自行決定；
第四條（不直接寫入 Gitea 或 git）不是因為子代理做不好，而是**它的失敗沒有人看著**
——備妥工作樹失敗會中止整個領取、實際提交失敗會留下半套 git 歷史。
委派一律以**能力描述**表達，不指名任何平台的工具：子代理是平台專屬能力，而流程正本
必須保持平台中立（#4 的驗收標準）。能力描述對不支援的平台是自然降級，同一份正本兩邊
都讀得通，不必維護兩份。這份正本明寫「不要把它改寫成工具名」，因為那是讀到它的人
最可能動手改的地方。
那張「目前標記為〔可委派〕的步驟」表與正本上的標記互為正本，由資產測試雙向綁住。
議題 #58
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
2026-09-18 09:12:08 +08:00 |
|