 jiantw83
|
c56f3271b5
|
feat(workflow-assets): 整合流程正本與委派規則
以能力描述補齊可委派步驟，讓流程正本、委派規則、AGENTS、README 與 ADR 保持同一份繁體中文與 UTF-8 契約。
|
2026-09-22 15:31:36 +08:00 |
|
|
jiantw83
|
dd3a522b38
|
feat(交付文件): 接通文件交付規則與抽取契約
建立七種交付文件的規則正本，並讓需求模板與 issue-extract 使用文件欄位；測試涵蓋新欄位、缺段落與未知段落。
|
2026-09-22 14:44:17 +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
|
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 |
|
|
jiantw83andClaude Opus 5
|
6e0fa92e73
|
feat(規則正本): 新增實作規範與註解格式對照表
兩份規則只存在於本 plugin 裡，由流程正本指名讀取，不寫進目標專案的任何檔案。
coding-standards.md 管規則：六種專案檔對應語言、認不出就停下來問；分層看職責不看目錄，
三層各寫功能／邏輯／資料源註解，服務層要標註呼叫的方法讓 reviewer 追得到呼叫鏈；
屬性的用途註解遞迴到每一層，並附真實資料範例，優先取自 MCP，推理來的要明講未經驗證
——不註明的話，會有人照著沒對過的格式寫解析。
comment-styles.md 只管格式：六種語言各一節，都附可照抄的方法註解與屬性註解範例。
Go 的「以識別字開頭」與 Python 的「docstring 在定義的下一行」各自點名，那是最常被
照抄成別的語言寫法的兩處。
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
2026-09-17 07:39:48 +00:00 |
|
|
jiantw83andClaude Opus 5
|
b79c68613a
|
fix(可行性檢查): 補上時程估算的前提，並讓四份清單結構一致
時程清單的「相依鏈最長路徑」預設了一份工作拆法，但分析階段還沒有工作包可依，
照著問會問不出東西。補上說明：這個階段要先拉一份暫定拆法，它同時是下一段開
工作包的草稿；拆不出來本身就是一個要問使用者的問題。
架構清單原本在開頭多了一段中間文字，內容與自己的「問題怎麼問」重複，也讓它
成為四份裡唯一結構不同的一份，移除。
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
2026-09-17 05:11:07 +00:00 |
|
|
jiantw83andClaude Opus 5
|
549bd29313
|
feat(可行性檢查): 新增架構、邏輯、資料、時程四份檢查清單
四份規則正本，各自列出要對著需求議題回答的檢查項，回答不出來的就是一個要問
使用者的問題。每份末尾都交代「問題怎麼問」——檢查項只說要查什麼，不說怎麼把
它變成一句能收斂的提問，那才是實際卡住的地方。
四份各自點出一個最該先問的：架構問落點與循環相依，邏輯問既有功能是不是已經
做過同一件事（這條能整個取消工作），資料問 schema 與遷移（答案通常不在議題裡），
時程問未知數最大的一項（它決定整體估算的可信度）。
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
2026-09-17 05:11:05 +00:00 |
|
|
jiantw83andClaude Opus 5
|
7a8222a053
|
chore(骨架): 把模板 scaffold 換成 tea-sdlc 骨架
五份 manifest 的 name、description、homepage、repository 由 jsc-template
改指向 tea-sdlc，版本另起為 0.0.1；移除範例用的 skills/hello 並清掉
AGENTS.md 與 README.md 對它的引用。
建立後續工作包要落腳的四個目錄（prompts、scripts、templates、references）
並以 .gitkeep 納入版控；AGENTS.md 改寫為 tea-sdlc 的模組邊界與慣例，腳本
介面契約不複寫而指回議題 #1，避免正本分家。
新增 package.json 作為測試入口（node --test，Node 內建執行器，無任何相依
套件）；.gitignore 加入測試暫存目錄 .tmp/ 與 node_modules/。
Closes #2
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
2026-09-17 04:06:09 +00:00 |
|