 jiantw83
|
c56f3271b5
|
feat(workflow-assets): 整合流程正本與委派規則
以能力描述補齊可委派步驟，讓流程正本、委派規則、AGENTS、README 與 ADR 保持同一份繁體中文與 UTF-8 契約。
|
2026-09-22 15:31:36 +08:00 |
|
|
jiantw83
|
744eee04ba
|
feat(sdlc-analyze): 加入交付優先確認流程
讓 sdlc-analyze 逐項確認七種交付文件與 PERT 三點估算，排序交付工作包並在確認前阻擋建立與排程；補上流程正本測試。
|
2026-09-22 15:06:08 +08:00 |
|
|
jiantw83
|
7f723adff8
|
feat: 移除計時並停用報表預覽
|
2026-09-21 17:41:44 +08:00 |
|
|
jiantw83
|
867a23497f
|
feat(overview-artifact): 產生可預覽總覽與截圖 fallback
|
2026-09-18 15:59:34 +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
|
7ee050de2f
|
docs(sdlc-plan,sdlc-analyze): 兩份正本各自起停自己的錶
起錶與停錶寫在同一份正本裡成對出現，讀的人一眼看得出這段計時涵蓋到哪；兩份各加一節
「計時範圍」把兩端指出來。
sdlc-plan 記兩段：議題建立之前那段在第一步記下開始時間、議題建立之後以補登記上去；
之後起錶，回報那一步停錶。補登排在議題建立之後、起錶之前，順序反過來的話補登會被
time-log 當成「這一步做過了」而跳過。
sdlc-analyze 在它分析的那顆需求議題上起錶，起點放在第一段開頭——分析最耗時的正是
共識之前那一段，從第二段才起的話那段時間永遠是零。因此「共識摘要之前不對 Gitea
產生任何寫入」改寫成「不寫入任何**內容**」，並把碼錶明文除外、寫上理由：它記的是
工時，不是內容。這一條與 repo 擁有者確認過。
sdlc-feat 的「碼錶一律由使用者自己停」收斂成「**別顆議題上的**錶一律由使用者自己停」
——它原本讀起來像全域規則，而現在每道指令都會停自己起的那一支。
正本之間改以步驟**名稱**互指，不用編號：編號會整批位移，名字不會。測試跟著改用新的
promptStep 輔助函式，以名字框出某一步的內容，別人插一步時不會無聲地框到另一段上。
議題 #57
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
2026-09-17 19:32:37 +08:00 |
|
|
jiantw83andClaude Opus 5
|
f85fabb758
|
feat(流程正本): 新增 sdlc-sync，並讓另外兩份正本整併完自動接回
挑出哪些留言真的是決策、寫回去之前讓使用者點頭、略過的保持未標記——三件都只有正本做得到。
analyze 與 feat 原本寫「建議先執行 /sdlc-sync，再回來」，那等於要使用者重打指令。改成直接走
sync 的流程、做完自動接回，並在接回前重新抽取一次——接著用舊的那一份做事，這一整段就白做了。
略過的留言會讓未處理留言數停在大於 0，於是 analyze 與 feat 每次都會再停一次。這是驗收標準
本身的兩條放在一起的結果，正本把它講明白，讓使用者分得出「沒整併乾淨」與「我選了略過」。
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
2026-09-17 09:19:10 +00:00 |
|
|
jiantw83andClaude Opus 5
|
6b30552ee2
|
feat(流程正本): 兩份正本加入產生總覽與寫回網址的步驟
規劃版填總覽、目標、流程圖，工作包全景填空字串；分析版沿用同一份模板，額外把
工作包的相依與截止日畫成 graph TD 的全景圖。節點一樣以 12 個為上限，超過就只畫
相依鏈最長路徑上的那幾顆。
兩份都寫回同一顆需求議題的同一行，所以分析版會取代規劃版——同一顆需求議題只掛
一個總覽網址，這是預期行為，正本裡寫明免得被當成 bug。
另外交代填模板時流程圖不帶圍欄：圍欄是議題 markdown 用的，填進 HTML 會多出一段
沒有意義的字。
Closes #10
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
2026-09-17 06:22:28 +00:00 |
|
|
jiantw83andClaude Opus 5
|
7a6cf948f5
|
fix(流程正本): 補回標題後被吃掉的空行
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
2026-09-17 06:06:10 +00:00 |
|
|
jiantw83andClaude Opus 5
|
c635465751
|
feat(sdlc-analyze): 加入第三段，把工作包排上時程與看板
先算後寫：schedule 算出截止日，再由 issue-link、issue-update、project-add 逐顆
補上相依、時程與看板。三支都先試跑再實跑，三支都是冪等的。
另立一節寫明人天估算的 API 限制，而不是把它藏在行文裡——estimate 只寫得進 body，
sdlc-report 之後讀的也是那一行，這件事踩到才知道就太晚了。
邊界改成三段各自列：哪一段不做什麼講清楚，兩顆工作包才不會互相踩。
Closes #8
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
2026-09-17 06:06:08 +00:00 |
|
|
jiantw83andClaude Opus 5
|
9a67c8074f
|
fix(流程正本): 「不畫圖」綁回上限，不是免死金牌
兩份正本原本都只寫「不畫：一行說明為什麼不畫」，讀起來像是隨時可以跳過。
議題 #1 的原意是「超過上限即拆圖或不畫」——退路是給畫不下的情況用的。
改成只在超過上限拆不開、或畫了不會比文字更清楚時才選，兩份正本一起改，
免得兩邊講法不同。
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
2026-09-17 05:43:26 +00:00 |
|
|
jiantw83andClaude Opus 5
|
0cd25d49d4
|
feat(sdlc-analyze): 擴充為兩段式，第二段把共識變成工作包議題
第一段到共識摘要為止仍然完全不寫入；使用者點頭之後才進入第二段建立議題。
邊界條文隨之改寫成「共識摘要之前不對 Gitea 產生任何寫入」，並明列第二段
不做的事：不建相依、不掛 Milestone、不加看板、不寫人天估算——那些是後續
流程的工作，寫在這裡會讓兩顆工作包互相踩。
工作包的切法、標題規則（動詞加名詞、禁止 WP-01 這類流水編號）、待辦與驗收
的巢狀寫法（附可照抄的範例）、架構圖依性質三選一，都在這一段定下來。
邊界的斷言跟著條文一起改，因為條文換了語意；分開成兩顆 commit 的話中間那顆
會是紅的。另補一條斷言：第一段不得出現任何寫入型腳本的名字。
Closes #7
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
2026-09-17 05:43:24 +00:00 |
|
|
jiantw83andClaude Opus 5
|
775909bd3d
|
feat(sdlc-analyze): 新增可行性分析的流程正本
一次問一題、依架構→邏輯→資料→時程清空、每題固定給「建議（含理由）」與
「手動輸入」兩個選項、最後輸出共識摘要。摘要只印在終端，這一段完全不寫入
Gitea——把工作包開出去是下一段的事。
開頭先看 issue-extract 回傳的未處理留言數：不是 0 就代表描述可能是過期的，
先提示使用者以 sdlc-sync 整併回描述再回來，堅持要繼續就在摘要裡註明。
明令「能在程式碼裡查證的就自己去查」，把問題留給只有人能回答的事。
Closes #6
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
2026-09-17 05:11:05 +00:00 |
|